Serial Monitor schaltet Ausgänge ab? Und Debouncingfrage

International Deutsch
1

Hallo zusammen,

ich taste mich langsam in einzelnen Blöcken an mein aktuelles Projekt ran und bin momentan etwas irritiert:
Ich habe 8 Taster via PCF8574 und I2C am Uno hängen und schalte damit 8 Ausgänge vom Uno, dabei Toggle ich die Ausgänge damit die Taster wie Schalter funktionieren.
So weit so gut, wenn ich allerdings den SerialMonitor (IDE 1.0.1) öffne werden alle bereits eingeschalteten Ausgänge abgeschaltet.
Ist das normal?
Und wenn ja, was passiert bei einer anderen Kommunikation auf der seriellen Schnittstelle, dasselbe? Denn dann hätte ich ein massives Problem, da die Ausgänge später außerdem noch über die serielle Schnittstelle per DMX via MAX485 geschaltet werden sollen. Oder habe ich einfach nur in meinem Testsketch Murks gebaut?

#include <Wire.h>

#define acPCF (0x20)

byte acInputs = 0;
int i;

void setup() {
  Serial.begin(9600);
  Wire.begin();
  for (i=2; i<=9; i++) {
    pinMode(i, OUTPUT);
  }
}

void loop() {
  readACdata();
}

void readACdata() {
  Wire.requestFrom(acPCF, 1);
  if (Wire.available()) {
    acInputs = Wire.read();
    delay(200); //debouncing ?
  }
  Serial.println(acInputs, BIN);
  setOut(acInputs);
}

void setOut(byte inputs) {
  for (i=0; i<=8; i++) {
    if (bitRead(inputs,i) == 0) {
      if (digitalRead(i+2) == LOW) { //toggle
        digitalWrite(i+2, HIGH);
      } else {
        digitalWrite(i+2, LOW);
      }
    }
  }
}

Und gleich noch eine Frage zum debouncing, wo setze ich da an? Die momentane Stelle mit dem delay(200)? oder woanders? Irgendwie werde ich da nicht so richtig glücklich damit.
Wäre evtl. ein Hardwaredebouncing - grade im Hinblick, daß ja auch noch die DMX-Leserei dazukommt evtl. vernünftiger?

Grüßle Bernd

2

Das resetieren ist normal wenn das Terminal des IDE startet. Andere Terminale machen das nicht. Man kann das auch unterdrücken. Frag mich aber bitte um diese Zeit nicht wie.
Fürs debouncing genügen 5mSekunden.

 if (digitalRead(i+2) == LOW) { //toggle
        digitalWrite(i+2, HIGH);
      } else {
        digitalWrite(i+2, LOW);
      }

besser:
digitalWrite(i+2, !digitalRead(i+2));
Grüße Uwe

3

Nutze hterm für das debbuging und schon ist dein Problem behoben. Ist eine eigenart des Serial Monitors der IDE.
Hier der Link

Gruß
Der Dani

4

Wenn du magst, kannst du mit dem Programmstart auch warten, bis der Serial Monitor offen ist zB zum debuggen.
Wenn die Serial Ausgabe erst beim öffnen des Serial Monitors gestartet werden soll, kann in der Setup Routine folgendes eingetragen werden:
Serial.begin(9600);
while(!Serial);
So dreht diese while Schleife endlos, erst das öffnen des Serial Monitors setzt Serial auf true

5

So dreht diese while Schleife endlos, erst das öffnen des Serial Monitors setzt Serial auf true

Das ist leider falsch. Diese Schleife dreht auf einem UNO überhaupt nicht und ist sofort true, nur auf einem Leonardo zeigt sie Wirkung und wartet bis sich der Leonardo korrekt auf dem USB-Bus als Serial-Device angemeldet hat.

Der Serial Monitor öffnet das serielle Device des Computers, was den Treiber veranlasst, die DTR (Data Terminal Ready) hochzuziehen. Dies ist beim Arduino gleichbedeutend mit einem Reset, weil dieser normalerweise für das Hochspielen eines neuen Sketches gebraucht wird (damit der Bootloader aktiv wird). Es gibt auf dem Board eine Lötbrücke, die durchtrennt werden kann, damit dieses Verhalten (Reset beim Hochfahren des DTR) nicht stattfindet. Dann musst Du beim Sketch Hochladen aber immer von Hand den Reset-Taster betätigen.

6

Wow,
danke euch für die ausführliche "Verserialisierung" :wink:
Jetzt ist mir klar, was in dem Moment des Öffnens des Seriellen Monitors passiert.
Ich hatte das irgendwie gar nicht gecheckt, daß da ein Reset ausgelöst wird und mir (wohl unnötiger Weise) 'nen Kopp gemacht, das später im Betrieb bei einer "normalen" seriellen Kommunikation (also ohne Monitor) auch was schief gehen könnte.

@Dani: danke für den Tip mit dem hTerm, habe zwar unter Linux das CuteCom - ist auch ganz nett - werde es aber trotzdem mal ausprobieren.

Was mir jetzt noch bischen Bauchweh macht ist das Debouncing. Irgendwie komme ich da auf keinen wirklich stabilen Zustand. Vielleicht doch besser Hardwaremäßig? Damit mir später keine DMX-Daten flöten gehen ...

Grüßle Bernd