Welche Möglichkeiten der Fehlersuche hat man beim Arduino?

[fredyxx]

Hallo,

während der Fehlersuche frage ich mich, wie ein Serial.Print-Befehl im Programm verarbeitet wird.
Bleibt das Programm an dieser Stelle stehen, bis z.B. eine Quittung über den erfolgreichen Sendevorgang vorliegt oder wird der Befehl nur initiiert und das Programm setzt die Abarbeitung der folgenden Befehle unverzüglich fort.

Wie ist das bei 4 -5 Serial.print's direkt hintereinander? Kann zwischen den einzelnen Serial.print's noch eine Programmabarbeitung erfolgen, so dass die auf dem Monitor angezeigten Werte nicht exakt den selben Programmzustand zeigen?
Nur zur Info: ich habe " Serial.begin (250.000);" eingestellt.

vG

fredyxx

[Peter(TOO)]

Hallo fredyxx,

während der Fehlersuche frage ich mich, wie ein Serial.Print-Befehl im Programm verarbeitet wird.
Bleibt das Programm an dieser Stelle stehen, bis z.B. eine Quittung über den erfolgreichen Sendevorgang vorliegt oder wird der Befehl nur initiiert und das Programm setzt die Abarbeitung der folgenden Befehle unverzüglich fort.

Grundsätzlich benötigt die Ausgabe von Debug-Informationen etwas Zeit.
Mit und ohne ist das Timing auf alle Fälle unterschiedlich!

Zu deinem Grundproblem:
Bevor noch irgendeine Zeile C ausgeführt wird, werden die globalen Variablen initialisiert. Die meisten bekommen den Wert 0
int i;
Bei
int j = 3;
Wird der entsprechende Wert (hier 3) zugewiesen.
Dies wird aber nur nach einem Reset durchgeführt.
Andernfalls haben dein globalen Variablen den letzten vom Programm zugewiesenen Wert.


Wenn ich dein Programm noch richtig im Kopf habe hast du Hilfsvariablen in der Form
Motor_fertig = TRUE;
Womit du weiterschaltest.
Bei einem zweiten Aufruf bleiben diese auf TRUE, wenn du sie nicht extra zurück setzt.
Dann rasselt halt alles durch.

MfG Peter(TOO)

[fredyxx]

Hallo fredyxx,

Grundsätzlich benötigt die Ausgabe von Debug-Informationen etwas Zeit.
Mit und ohne ist das Timing auf alle Fälle unterschiedlich!


MfG Peter(TOO)

ok, aber kann man sicher sein, dass aufeinder folgende Serial.Print's auch direkt nacheinander gesendet werden und das Programm auch dann erst weiter geht?

Wenn ich dein Programm noch richtig im Kopf habe hast du Hilfsvariablen in der Form
Motor_fertig = TRUE;
Womit du weiterschaltest.

Alle Achtung! Das hast du noch genau richtig im Kopf. Deshalb setze ich in der LOOP mit dem STOP-Schalter auch alle Mx-fertig's auf false und erst wenn ich den wieder umschalte, kann das Justierprogramm wieder beginnen. Bei M1 ist das auch so, aber direkt danach sind alle Mx-fertig's auf true!!!???????????????????

vG
fredyx

[Peter(TOO)]

Hallo fredyx,

ok, aber kann man sicher sein, dass aufeinder folgende Serial.Print's auch direkt nacheinander gesendet werden und das Programm auch dann erst weiter geht?

Im einfachsten Fall wartet man bis das Senderegister leer ist und schreibt dann das nächste Zeichen in das Sende-Register. So lange man wartet, ist die CPU blockiert, bzw. kann nur Interrupts bearbeiten. Das geht dann ganz ohne Interrupts, ist aber die langsamste Variante. Zudem hängen die Zeiten direkt von der Baudrate ab.

Bei der eleganteren Art richtet man einen Puffer ein und der Print-Befehl kopiert die Zeichen in diesen Puffer. Nach dem Kopieren kann die CPU weiter das Programm abarbeiten. Wenn das Sende-Register leer ist erzeugt es einen Interrupt und die ISR kopiert dann das nächste Zeichen aus dem Puffer ins Sende-Register.
Es braucht dann noch etwas Aufwand für die Pufferverwaltung. Wenn man das erste Zeichen in den leeren Puffer schreibt muss man den Interrupt anwerfen. Umgekehrt muss die ISR den Interrupt abschalten, wenn das letzte Zeichen aus dem Puffer gelesen wird.
Wenn der Puffer voll ist, muss man warten, bis ein Zeichen gesendet wurde, dann ist man gleich langsam wie bei der einfachen Variante.
Noch etwas schneller wird es, wenn man die Daten, sofern vorhanden, per DMA vom Puffer in das Sende-Register kopiert. Die Verwaltung wird dafür etwas aufwändiger, dafür wird die ISR seltener aufgerufen (Nur wenn die DMA fertig ist und somit nicht für jedes Zeichen).

Die Technik mit dem Puffer funktioniert auch beim Empfangen und hat den Vorteil, dass man keine Zeichen verliert, besonders wenn man noch Handshake (XON XOFF) implementiert.

Leider stehen viele Programmierer mit den Interrupts etwas auf Kriegsfuss und die erste Variante ist deshalb sehr häufig anzutreffen. Allerdings entwickelt man den Treiber eigentlich nur einmal im Leben für eine Programmiersprache. Die Anpassung an unterschiedliche µCs betrifft dann eigentlich nur die Handhabung des Interrupt-Controllers und des Sende-Registers, der Rest ändert sich eigentlich nicht.

MfG Peter(TOO)

[Mxt]

Hallo,

Bleibt das Programm an dieser Stelle stehen, bis z.B. eine Quittung über den erfolgreichen Sendevorgang vorliegt oder wird der Befehl nur initiiert und das Programm setzt die Abarbeitung der folgenden Befehle unverzüglich fort.

Ganz allgemein erfolgt bei Arduiono kein Test auf erfolgreichen Sendevorgang. Wenn keiner empfängt sind die Daten halt weg.

Ob das print wartet, hängt vom Arduino Modell ab:
Bei den meisten Modellen gehen die Daten über UART vom Hauptcontroller zum USB-Controller auf dem Board. Das ist entweder ein zweiter Controller (meist ein 16U2) oder nur ein seriell zu USB Wandler (FTDI, CH340, ...). Das Print muss in diesem Falle warten, bis die Daten aus dem UART raus sind.

Dieser Vorgang kann durch einen Interrupt unterbrochen werden, z.B. wenn ein Library verwendet wird, die damit arbeitet. Was hinter dem print steht, kommt aber erst dran, wenn das print fertig ist.

Bei Arduinos mit Controllern, die selbst einen USB-Anschluss haben (Leonardo, Micro, Due, Teensy, ...), ist ein print meist nur ein sehr schneller Kopiervorgang, um den Rest kümmert sich die USB-Hardware im Chip.