Welche Möglichkeiten der Fehlersuche hat man beim Arduino?

[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

[i_make_it]

@Sisor:

Das ist so schon richtig.
in der pins_arduino.h
ist je nach Board die Zuordnung der µC Pins zu den Arduino Pin Nummern festgelegt.
Bsp.:
static const uint8_t PinB5 = 13;

Damit ist "while(!testpin);" eine Prüfung darauf ob PIN 13 nicht gesetzt ist, da PIN13 der Name "testpin" zugewiesen wurde.

Auszug aus der revisions.txt der 1.6.11 vom 17.8.2016.
* The new, variant-specific pins_arduino.h files now provides additional
macros with information about the characteristics of the board (e.g.
the locations of the SPI and TWI pins, and the number of digital and
analog pins).

[Klebwax]

@Sisor:

Das ist so schon richtig.
in der pins_arduino.h
ist je nach Board die Zuordnung der µC Pins zu den Arduino Pin Nummern festgelegt.
Bsp.:
static const uint8_t PinB5 = 13;

Damit ist "while(!testpin);" eine Prüfung darauf ob PIN 13 nicht gesetzt ist, da PIN13 der Name "testpin" zugewiesen wurde.

#define testpin 13

testpin wird durch das #define durch die Zahl 13 ersetzt. Nichts anderes, auch nicht durch "PIN13", und "!13" ist in C false. Das bei einer while-loop, die nur aus einem Befehl besteht, geschweifte Klammern nötig sind, hätte einen sofort auf die Spur bringen müssen.

Es sind also Vergleiche mit Konstanten, und alles was schon zur Compilezeit false ergibt, wird gar nicht erst compiliert.

Aber BTT

Wie dem auch sei. Ich habe die Ursache gefunden und die hatte nichts mit goto o.ä. zu tun.

Es handelte sich um zeitliche und logische Abläufe bei der STOP-Tastenauswertung, die ich nicht vollständig durchschaut und richtig umgesetzt hatte.

Natürlich hat dein Problem mit den gotos zu tun. Nur damit kann man so unstrukturierten, unlesbaren und damit unwartbaren Code schreiben. Und die Chance, durch verständliche Labels etwas Ordnung in das Chaos zu bringen, wurde auch vertan. Da sind dann Fehler wie " die ich nicht vollständig durchschaut und richtig umgesetzt hatte " unvermeidbar. Der Code könnte in einem Lehrbuch als Beispiel dienen, warum man gotos meiden soll.

MfG Klebwax

[HaWe]

fang bitte nicht wieder mit dem goto-Sch**** an, das Thema ist durch, und daran lag es auch nicht.
Das mit dem testpin oder !testpin war allerdigs tatsächlich nicht richtig , es musste heißen
while(!digitalRead(testpin));
while( digitalRead(testpin));
https://www.arduino.cc/en/Reference/DigitalRead

sorry for that!

[Unregistriert]

fang bitte nicht wieder mit dem goto-Sch**** an, das Thema ist durch,

Richtig, goto-Sch**** und das Thema ist noch lange nicht durch, solange es verschiedene Ansichten darüber gibt.

[HaWe]

unregistrierte Trolle sollte man hier wirklich bannen bzw. gar nicht erst posten lassen. Sie vergiften nur das Diskussions-Klima und schaden letztendlich auch sehr der Reputation des Forums.

[i_make_it]

Ich sage es mal so,

Es wurde nach Hilfe gefragt ohen das Code gepostet wurde.
Als dann ein Code sniplet gepostet wurde, habe ich für mich so viele GOTOs gesehen, das ich keine Lust mehr verspührte mir das anzutun.
Rein auf verdacht, vermute ich mal das es einigen Leuten die schon etwass Programmiererfahrung haben, ähnlich geht.
Da die Sprache besser lesbaren Code erlaubt.
Es liegt halt an dem fragenden, entweder sich damit abzufinden das man ihm sagt "Räum deinen Code erst mal auf und komm dann wieder wenn sich das Problem dabei nicht schon von selbst gelöst hat".
Oder zu hoffen das sich jemand seiner erbarmt.
Zu erwarten ist, aus meinen Erfahrungswerten ,das es wieder zu Fragen kommt und der Code bis dahin nicht besser aussehen wird.
Womit sich die Fehlerträchtigkeit dieses Programmierstils dann von selbst beweisen wird.
Ich teste Sachen oft auch erst mal mit quick and dirty Code.
Sobald es dann aber um die Integration in größere Sachen geht, macht es auch Sinn darüber nachzudenken ob der bisher eingeschlagene Weg der bessere oder der schlechtere ist.
GOTOs funktionieren, wenn man sie beherscht und den Überblick behällt.
Aber nur dann und nur solange man sich intensiv mit dem Code befasst.
Wenn das mit den GOTOs (und ein paar anderen Assembler Befehlen) so einfach wäre, wären Hochsprachen nie entstanden und alle würdne assembler nehmen.
Aber man wollte Abstraktion und Portierbarkeit sowie einfacher zu lesenden Code, Denn das können mehr Menschen verstehen wie Assembler.
Ein GOTO ist nun mal nichts anderes wie eine andere Schreibweise für ein JMP.
ALso eigentlich Assembler.
Aber es ist halt jedem selbst überlassen wie er Programmiert.
Dafür muß man dann aber auch hinnehmen das es immer wieder zur selben Diskussion kommt, wenn man solchen Code vorlegt.