Welche Möglichkeiten der Fehlersuche hat man beim Arduino?

[Mxt]

Was soll das heißen?

Ich programmiere schon seit über 35 Jahren und habe schon genug solcher Programme gesehen. Nach dem ersten Blick auf den Code in dem zitierten Thread und war damals schon klar, dass es zu einem Thread wie diesem kommen würde.

Ich kann mir kein umfangreiches Programm ohne UP's vorstellen. Das trägt doch eindeutig zur Übersichtlichkeit bei

Du redest davon, tust es aber nicht. Das Konzept in C um Programme zu Strukturieren sind Funktionen nicht gotos.

Statt wie bei dir

switch(irgendwas)
{ 
  case 0:
    Mx =42;
    goto Mblub;
    break;
	
    // ...
	
Mblub:

   // code ...
   
   goto Mbob;
   
   // anderes Zeug
   
Mbob:

   // nochmehr Code
   
   goto Nochweiter;

ist die Sprache eigentlich so gedacht

void blub(int paran)
{
  // Der Code hinter dem einen Label
}

void bob()
{
  // Der Code beim anderen
}

// ...

switch(irgendwas)
{
  case 0:
    blub(42);
    bob();
    break;

   // ...

und nicht kilometerlanger Bandwurmcode in dem mit goto rumgehüpft wird.

Dann hätten einmal mehr Leute überhaupt Lust sich das anzusehen und man kann jede Funktion mit Ausgaben versehen.
Eventuell auch mit zusätzlichen Parametern, die nur dazu dienen in der Ausgabe anzuzeigen, woher der Aufruf kam.

Also in der Art

void foo(int caller, int arg)
{
  Serial.print("Aufruf von");
  Serial.print(caller);
  Serial.print(" mit ");
  Serial.println(arg);
}

und bei der Verwendung

   // Eine Stelle

   foo(1, M42);


   // woanders

   foo(2, M42);

[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.

[HaWe]

switch/case ist nichts anderes als ein goto.
Die case (irgendwas) sind nichts anderes als Sprungmarken für gotos, daher müssen es in C immer auch Integer-Konstanten sein (und keine Floats oder logische Ausdrücke).
So ungern hier also manche das goto in C-Programmen sehen: es ist nur persönliches Ästhetikempfinden, nicht mehr und nicht weniger

an fredyxx:
wenn du sicher bist, dass deine Sprünge im richtigen Moment an die richtige Stelle führen, ist das kein Grund, sie durch switch/case Anweisungen zu ersetzen.
Allerdings müssen sie beide in jedem Falle immer im richtigen Moment an die richtige Stelle führen.
Bist du also sicher, dass sie stimmen, lass sie drinnen - und such den Fehler woanders.
Goto Anweisungen innerhalb von switch/case ist allerdings reichlich doppelt gemoppelt und wirklich extrem unschöner Programmierstil.

zum Debuggen mit serial:
Du kannst Wartepunkte einfügen, indem du in dein Programm ein Warten auf einen Buttondruck und wieder loslassen einfügst:

#define testpin 13 // or whatever

while(!testpin);
Serial.print(irgendwas);
while(testpin);

[fredyxx]

zum Debuggen mit serial:
Du kannst Wartepunkte einfügen, indem du in dein Programm ein Warten auf einen Buttondruck und wieder loslassen einfügst:

#define testpin 13 // or whatever

while(!testpin);
Serial.print(irgendwas);
while(testpin);

Hallo HaWe,

funktioniert hat es so:

#define testpin 13 // or whatever

while(!testpin){
Serial.print(irgendwas);
}

while(testpin);

[/QUOTE]

Nötig sind die geschweiften Klammern.

Die letzte Zeile war bei mir nicht nötig.

Aber prima die Idee!!

vG

fredyxx

[HaWe]

mmmhhh... versuch es mal so wie ich ursprünglich schrieb -
erst wartet er an der Stelle bis die Taste gedrückt wurde,
sobald das der Fall war, macht er sein print,
dann wartet er erneut, bis die Taste wieder losgelassen wurde.

Zumindest war das meine ursprüngliche Idee.

[Sisor]

Jungs, ihr prüft hier auf Konstanten. HaWe's Code

#define testpin 13

while(!testpin);
Serial.print(irgendwas);
while(testpin);

ist gleichzusetzen mit:

Serial.print(irgendwas);
while(true); // Endlosschleife