Welche Möglichkeiten der Fehlersuche hat man beim Arduino?

Zitat:

---

Zitat von oberallgeier

BREQ k Branch if Equal if (Z = 1) then PC ← PC + k + 1 None 1/2[/CODE]Branch und Skip Befehle nicht genau für so ein "else" geeignet?

---

Jetzt zäumst du aber das Pferd von Hinten auf!

Bedingte Verzweigungen gab es schon bei der "Analytical Engine" (1837) von Babbage. Allgemeine Probleme lassen sich nur mit bedingten Verzweigungen lösen.
Lady Ada hat dann die Assembler-Sprache erfunden und z.B. der Begriff Mnemonic stammt von ihr.

Das Vorgänger-Modell (die Differenzmaschine, angefangen 1822) war noch ein reiner Number-Cruncher. Da konnte man nur eine mathematische Formel Programmieren, welche dann von der Maschine abgearbeitet wurde.

MfG Peter(TOO)

- - - Aktualisiert - - -

Hallo Mxt,

Zitat:

---

Zitat von Mxt

Wahrscheinlich ja. Die Aussage "kein else" ist ja eventuell auch wieder Architekturabhäng. Manchal gibt es nur ein "jump if zero" und "jump if not zero", da muss ein if else dann natürlich etwas umgebaut werden.

---

Nein, man brauch nur ein GOTO :-)

Code:

---

10  IF <Bedingung> GOTO 100
20  REM hier ist der ELSE-Zweig
.
.
90  GOTO 200
100 REM hier beginnt der IF-Zweig
.
.
200 REM hier geht das Programm weiter

---

IF- und ELSE-Zweig kann man vertauschen wenn man die Bedingung invertiert.

Bei manchen CPUs können bedingte Sprünge aber z.B. nur +/- 127 Byte weit springen. Dann muss man bei grösseren Zweigen auch mit GOTO nachhelfen.

Code:

---

10  IF <Bedingung> GOTO 30
20  GOTO 100
30  REM IF-Zweig
.
.
90  GOTO 200
100 REM ELESE-Zweig
.
.
200 REM hier geht das Programm weiter

---

MfG Peter(TOO)

- - - Aktualisiert - - -

Hallo Un,

Zitat:

---

Zitat von Unregistriert

"goto" wurde meiner Meinung nach nur in höhere Programmiersprachen aufgenommen um den Maschinensprachlern den Aufstieg zu erleichtern und wurde später nicht entfernt, um am Vorkommen im Sourcecode auf den erstn Blick den Anfängerauthor vom Fortgeschrittenen unterscheiden zu können ;-)

---

Schau die mal ein altes BASIC an, so 1970 oder älter.

Da gab es nur GOSUB und noch keine Prozeduren.
Alle variablen waren global.
Zeilen-Nummern waren zwingend und man konnte nur an Zeilennummern springen.

Um Platz für Änderungen zu haben, hat man standardmässig die Zeilen in 10er Abständen nummeriert. Einen RENUMBER-Befehl gab es Anfangs nicht. Musste man zu viele Zeilen einfügen musste alle GOTOs von Hand anpassen :-(


Abgesehen davon:
Strukturiert und Objektorientiert programmieren konnte man auch schon in Assembler. Allerdings lag das einzig und alleine in der Verantwortung des Programmierers.

MfG Peter(TOO)

goto ist nicht mehr und nicht weniger zeitgemäß als switch/case oder if/else, und auch eine Zeitreise durch die Historie seit Adam und Eva in der Geschichte der Computer führt hier nicht wirklich weiter (wir reden schließlich von C und C++ jetzt und hier im Allgemeinen und bei Arduino im Besonderen, und nicht von Algol oder Cobol oder Fortran von anno einundleipzig). Die Verwendung ist sowohl reine Geschmackssache als auch abhängig von den individuellen Anforderungen im Programm, um unnötig komplizierte if/else/switch/case Verschachtelungen zu umgehen, und jedem Programmierer ist es selbstverständlich erlaubt, alle Befehle zu verwenden, die die Programmiersprache hergibt. Alles andere ist unsinniges und unzulässig verallgemeinerndes Geschwätz und eine ziemlich arrogante Bevormundung, die allesamt zu nichts führen, und wenn man hier auch hundert mal etwas anderes behauptet, wird es dadurch nicht richtiger.

Es ist mir sowieso ein Rätsel, weshalb die Frage eines Hobbyprogrammierers zu solchen Grundsatzdikussionen führt. Das erlebe ich nun schon zum zweiten Mal und kann doch wohl nicht Sinn des Forums an dieser Stelle sein.

Außerdem schreckt es den Leser ab, weiter zu lesen, der sich vielleicht nur für die Ursache des Fehlers interessiert.

vF

fredyxx

Zitat:

---

Zitat von fredyxx

Es ist mir sowieso ein Rätsel, weshalb die Frage eines Hobbyprogrammierers zu solchen Grundsatzdikussionen führt. Das erlebe ich nun schon zum zweiten Mal und kann doch wohl nicht Sinn des Forums an dieser Stelle sein.

Außerdem schreckt es den Leser ab, weiter zu lesen, der sich vielleicht nur für die Ursache des Fehlers interessiert.

---

Ja, das ist unschön für den Ratsuchenden.

Aber da kann man nichts machen. Soziales Internet funktioniert heute nun mal "postfaktisch". Es gibt nur die Wahrheit der am meisten geäußerten Behauptung.
(HaWe wird gleich zustimmen in dem er widerspricht.)

Aber so ein Thread entwickelt sich natürlich aus der Frage und da bist du nicht ganz unschuldig. Du fragst

Zitat:

---

Ich Suche aber nach einer Möglichkeit, durch einen Interrrupt, der auf eine Veränderung einer Variablen reagiert und die Position im Programm ausgibt, die genaue Stelle im Programm zu finden.

---

Das führt natürlich in Richtung Debugger. Also antworten erfahrene Leute in dieser Richtung. Erfahrene Leute stören sich natürlich am goto, weil sie damit schon genug Ärger hatten.

Damit werden ihre Antworten aber automatisch falsch. Weil sie auf Erfahrung basieren und damit nicht die Meinung anderer repräsentieren. Durch die Frage geleitet hat man ja auch kaum die Möglichkeit Zeit auf einfache Dinge wie LED und Taster hinzuweisen. Die gehören dann zur Argumention der wahren Wissenden.

keine Einwände, Euer Ehren.

Zitat:

---

Zitat von HaWe

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

Code:

---

#define testpin 13 // or whatever

---

Code:

---

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

---

---

Hallo HaWe,

funktioniert hat es so:

Code:

---

#define testpin 13 // or whatever

---

Code:

---

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

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.

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

Code:

---

#define testpin 13

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

---

ist gleichzusetzen mit:

Code:

---

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

---

@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).

Zitat:

---

Zitat von 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.

---

Zitat:

---

#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

Zitat:

---

Zitat von fredyxx

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