Arduino Debuggen

Robin H. schrieb:
> Gibt es für den Arduino, bzw. für den ATmega 328p auch die Möglichkeit
> den µc so zu debuggen

Dazu brauchst Du einen JTAG-Adapter, der in der AVR-Welt nicht so 
verbreitet und beliebt ist wie beim MSP430 (wo es mit SBW ein 
funktionales Äquivalent gibt).

Die Arduino-Umgebung selbst sieht ein Debuggen nicht vor, da kann man 
nur probieren, ob ein Programm funktioniert.

Wenn Du diesen Nachteil auch auf dem MSP430 haben möchtest, kannst Du 
Dir die Energia-Umgebung ansehen, die nutzen zwar die üblichen 
JTAG-/SBW-Interfaces zum Programmieren, können aber praktischerweise 
auch nicht debuggen ...

Rufus Τ. F. schrieb:
> Wenn Du diesen Nachteil auch auf dem MSP430 haben möchtest
 Ja genau das möchte ich nicht haben :D

spess53 schrieb:
> Aber Debugwire
Dann werde ich mal die Datenblätter nach dem Begriff durchsuchen und mal 
weiter googlen.

Das einzige was ich gefunden habe, ist das "Debuggen" über (ich glaube) 
ISP, bei dem man Breakpoints setzt und Aktionen in die Breakpoints 
schreibt. Naja, wirkt erstmal so wie das Serielle Lesen, nur das es in 
einer anderen Oberfläche präsentiert wird. Ist auch nicht das was ich 
wirklich suche. Vor allem vermisse ich das durchgehen des Programms in 
Einzelschritten in C auf dem Arduino Uno.

Danke schon mal für alle Antworten. Mal schauen was sich noch raus 
finden lässt. Ansonsten bleibt nur das serielle Auslesen über den Serial 
Monitor...

Grüße,
Robin

Rufus Τ. F. schrieb:
> Die Arduino-Umgebung selbst sieht ein Debuggen nicht vor, da kann man
> nur probieren, ob ein Programm funktioniert.

leider da hilft nur brain 4.0 und Debugausgaben, das macht es etwas 
unbequem ist aber möglich.

Grundsätzliche Sachen kann man ja in anderer Umgebung testen um Fehler 
im Code oder Unzulänglichkeiten der Arduino IDE zu entdecken.
Ich weiche da gerne auf AVR Studio oder LCC32 aus.

Funktioniert eine Sub in den genannten hatte ich auch keine Probleme die 
in Arduino zu nutzen.

Stefan U. schrieb:
> Die Arduino IDE kann das nicht, wohl aber das Atmel Studio. Schau es Dir
> dort mal an.

Das wäre auch mein Vorschlag.
Zu Beginn hast du geschrieben:

Robin H. schrieb:
> Mir wäre es
> egal, ob ich das Ding in C oder als Sketch programmiere.

Dann setzt dich mal mit dem AtmelStudio außeinander. Hier kannst du 
alles in C programmieren und dann mit einem Programmer auf den Mega328 
flashen.
JTAG hat der kleine µC leider nicht. Aber du könntest hier zumindest
im Simulator schonmal deine Registerwerte überprüfen. Dort hast du alle 
von
dir gewünschten Werte. Wenn das nicht reicht, dann wie gesagt über 
DebugWire arbeiten.

Hab ich allerdings selbst auch noch nicht gemacht...

Gottfried schrieb:
> Der Debugwire funktioniert genauso, wie JTAG, ist nur eine andere
> Schnittstelle, bevor das JTAG gekommen ist.

Debugwire nutzt Mikrocontroller extrem ab.
Ich verwende gerne Platine von Arduino Mega2560. Ich habe dafür eine 
Adapterplatine gemacht (sie dient auch für andere Fälle). So kann ich 
JTAG bequem einschließen.

Motorola schrieb:
> Nach jedem breakpoint wird der Controller neu programmiert und die
> Anzahl der  Schreibzyklen einer Zelle im FLASH sind endlich.

Das hat dann aber nichts mit DebugWire selbst zu tun, sondern is unter 
JTAG genauso.

Robin H. schrieb:
> Gibt es für den Arduino, bzw. für den ATmega 328p auch die Möglichkeit
> den µc so zu debuggen, dass mir die Register des ATmega 328p angezeigt
> werden und ich einzeln durch das Programm "steppen" kann?

Wenn es unbedingt ein Arduino Board sein muss, der Arduino UNO WIFI REV2 
hat einen ATMega 4809 verbaut. Dieser besitzt eine UPDI Schnittstelle 
(Single pin programming and debugging interface). Damit kann direkt auf 
Hardwareebene debuggt werden. Muss es kein Arduino Board sein, kann man 
schon mit einem Curiosity Atmega4809 Nano beginnen.

Mw E. schrieb:
> Das hat dann aber nichts mit DebugWire selbst zu tun, sondern is unter
> JTAG genauso.

Mit JTAG kann man auch ohne Brekpoints gehen, einfach "Run to Cursor" 
und weiter Schritt zu Schritt, und alle Register und Variablen an einer 
verdächtigen Stelle beobachten. Mit DebugWire habe ich das noch nicht 
versucht, aber mit JTAG wird dabei Mikrocontroller nicht umprogrammiert.

Aber Atmel selbst warnt vor Abnutzung mit DebugWire, es steht aber 
nichts Ähnliches für JTAG.

Olaf schrieb:
> Gerade fuer jemanden der lernen will, also noch Student ist, ist ein
> Debugger unverzichtbar weil man nur so effizient und schnell begreift
> was in einem Controller abgeht.

Auch später ist die Existenz eines Debuggers ein liebgewonnenes Werkzeug 
auf das man nur ungern verzichten möchte, er ist in vielen Situationen 
hilfreich und kann viel Zeit sparen.

Aber jetzt bekommt der Threadersteller erzwungenermaßen die Gelegenheit 
zu erfahren wie es ist wenn man ohne Debugger auskommen muß und sich 
spezielle Debuggingtechniken und spezielle Kniffe für solche Fälle 
anzueignen, das kann sich später irgendwann mal als sehr nützlich 
erweisen. Zusätzlich wird er noch gezwungen eine vollkommen verkrüppelte 
und nahezu funktionslose IDE zu benutzen und die erfolgreiche Bezwingung 
all dieser pädagogisch auferlegten Handicaps kann ihn unterm Strich nur 
besser und erfahrener machen! Er wird hinterher die Vor- und Nachteile 
besser einschätzen können und bessere Entscheidungen bei der Auswahl der 
Werkzeuge treffen können.

Stefanus F. schrieb:
> In vielen Fällen muss ich den ganzen Aufbau stark modifizieren, um
> überhaupt debuggen zu können. Wenn ich z.B. das Programm einer
> Waschmaschine im Debugger anhalte, könnte sie mit Wasser überfluten.
> Wenn ich einen fahrenden Roboter mit dem Debugger anhalte, könnte er
> gegen die nächste Wand knallen.

Was ist denn das für ein an den Haaren herbeigezogener Schwachsinn? 
Niemand kommt auf die Idee, seine Waschmaschine zu debuggen. Und das mit 
dem Roboter, der gegen die Wand fährt, scheitert schon am Aufbau.

Bei sowas packt man auch nicht den Debugger aus, sondern den Tracer ;)
Zum Glück haben STM32 mit M3-7 den Traceblock drinne und wir nen J-Trace 
auf Arbeit :>

Weil sich Olafs Post mit meinem überschnitten hat:

Olaf schrieb:
> Du meinst sein Gehirn wird schonmal weichgekocht damit er spaeter
> Eclipse fuer ein brauchbares Stueck Software haelt? :-D

DER war richtig gut!

Olaf schrieb:
> Fuer so Problemfaelle hab ich mir im uebrigen eine eigene Software
> geschrieben die ueber den j-Link beliebige Variablen aus dem laufendem
> Programm ausliest. Bei ARMs ist da ja moeglich.

Das hat Segger schon für dich geschrieben -> J-Scope.
Ansonsten kann Ozone auch Variablen im Watchfenster in einem gewissen 
Intervall neua auslesen und live anzeigen.
Mit Diagrammen als Verlauf geht das auch (also J-Scope in Ozone 
eingebaut).

Damit konnte ich mir dann die Lüftersteuerung meiner E-Last einstellen.
(PI(D) Regler der Lüfterspannung nach Temperatur)

Ansonsten gibts noch Systemview, das zeigt dir dann auch an wie zB 
FreeRTOS scheduled. Falls man mal nen deadlock suchen muss.

Stefanus F. schrieb:
> Unter Debuggen verstehe ich allerdings, das Programm anzuhalten,
> irgendwas nachzugucken und dann fortzusetzen. Vermutlich sind die
> Begriffe diesbezüglich nicht eindeutig.

Doch: Debuggen vs Tracen, hatte ich oben geschrieben.

MaWin schrieb im Beitrag #5980682:
> MaWin schrieb im Beitrag #5980664:
>> Autor: MaWin (Gast)
>> [...]

Ich kannte mal eine Frau die hatte 2 Persönlichkeiten. Die eine war 
unsterblich in mich verknallt und hat mir den Kopf verdreht und die 
andere konnte mich überhaupt nicht leiden und war eher an meinem 
Nachbarn interessiert. Und die eine wußte anscheinend nie was die andere 
in ihrer Abwesenheit getan hat und stritt es vehement ab. Das war ein 
kurzer aber intensiver Höllenritt kann ich euch sagen, ich wußte nie 
neben welcher ich morgens aufwache, ich hab nach einer Woche reißaus 
genommen.

Stefanus F. schrieb:
> Noch ein Beispiel:

Da kannst du noch so viele Beispiele anführen. Was du da von dir gibst, 
ist einfach nur Schwachsinn.

Einer schrieb:
> Ich glaube da täuschst du dich.
> "Du" setzt da keine Breakpoints deine Entwicklungsumgebung aber schon.

Nein. So eine Sache wie Umprogrammieren braucht Zeit. Das kann nicht in 
Mikrosekunden passieren. Auch Breakpoints mit JTAG führen nicht zu 
Umprogrammieren.

Sollte wirklich "Break" einprogrammiert werden, so sollte das zu 
Umrechnen von allen Adressen und Neuprogrammieren von Flash führen. Das 
passiert aber nicht.

Mw E. schrieb:
> Motorola schrieb:
>> Nach jedem breakpoint wird der Controller neu programmiert und die
>> Anzahl der  Schreibzyklen einer Zelle im FLASH sind endlich.
>
> Das hat dann aber nichts mit DebugWire selbst zu tun, sondern is unter
> JTAG genauso.

Nein. Die AVRs mit JTAG haben schon immer Hardware Breakpoints gehabt, 
Soft BPs konnte natürlich der Debugger zusätzlich benutzen, wenn er 
wollte. Bei der JTAG debug engine kann man auch zwei der insgesamt vier 
Breakpoint-Register für einen Daten-Breakpoint (Adresse + Bereich) 
benutzen. Das ging schon immer bei den Megas, aber AVR Studio hat erst 
sehr spät gelernt, das zu unterstützen. ;-)

debugWIRE ist dagegen weiter nichts als ein Monitor-ROM, die anfängliche 
Bezeichnung (die man noch an ein oder zwei Stellen in der Doku finden 
kann) war "MonCon". Das ist nicht viel anders als die Monitor-Programme 
früherer Mikroprozessorsysteme, um hier einen Breakpoint zu setzen, muss 
man halt explizit im Programmspeicher einen BREAK-Befehl hinterlassen. 
Datenbreakpoints gibt es hier natürlich nicht.

debugWIRE ist übrigens jünger als die voll ausgefeilten debug engines 
der älteren AVRs mit JTAG; der einzige Grund, es überhaupt (und in 
dieser Form) einzuführen war, dass man auf diese Weise auch den kleinen 
ATtinys überhaupt  zu einem Online-Debugging verhelfen konnte; JTAG ist 
auf die Megas beschränkt, da es insgesamt aufwändiger ist (mehr Drähte 
für die Steuerung, mehr Chipfläche).

Allerdings ist der bei den Arduinos so populäre ATmega328 halt kein 
„richtiger Mega“, sondern nur ein „aufgebohrter Tiny“ (einschließlich 
des Hardwaremultiplizierers der Megas), daher hat man ihm auch nur 
debugWIRE spendiert.

Maxim B. schrieb:
> Sollte wirklich "Break" einprogrammiert werden, so sollte das zu
> Umrechnen von allen Adressen und Neuprogrammieren von Flash führen.

Nein. Es wird einfach statt des originalen Befehls ein BREAK 
programmiert. Beim Erreichen des BREAK programmiert der Debug-Dongle 
(also das ICE) automatisch den ursprünglichen Befehl zurück, sodass 
dieser als nächstes ausgeführt wird. Daher ist es auch verdammt wichtig, 
die debugWIRE-Session sauber zu beenden. Schaltet man einfach nur 
zwischendrin aus, bleibt der BREAK stehen, und das Wissen über den 
ursprünglich an dieser Stelle befindlichen Befehl geht verloren. Dann 
hilft nur ein komplettes Neuprogrammieren.

Das Ganze geht erstaunlich schnell; ich hatte damals erwartet, dass 
debugWIRE Debugging deutlich langsamer wäre als JTAG Debugging. Ist es 
nicht.

Stefanus F. schrieb:
> Trotzdem liebe ich dieses Feature. Ich brauche es nur selten, aber wenn,
> dann bin ich dankbar für diese Möglichkeit.

Dann pass aber auf, daß du deine Wohnung nicht unter Wasser setzt, falls 
du mal wieder deine Waschmaschine debuggen mußt.

Stefanus F. schrieb:
> Naja. Mein erster Eindruck vom Debug Wire (mit AVR Studio, Atmel ISP
> MKii) war eher, dass es super lahm ist.

Das lag aber eher am AVR Studio.

Ich habe im Anfang bei Arduino eine Led in den Ablauf eingebaut.
Ist natürlich nichts gegen richtige Werkzeuge, hilft aber für den 
Anfang.
Einfach an einem freien Pin anschließend und immer ein Stück weiter 
durch den Programmablauf schieben.
Wenn man noch keinen LA oder Oszi hat, kann das bei einfachen Programmen 
helfen.

Nachtrag:
Gerade im Anfang unterschätzt man die Geschwindigkeit, mit der so ein 
Programm abläuft.

Stefanus F. schrieb:
> und mein
> Modellauto hängt beim Debuggen mit den Rädern in der Luft.

Aber dein Roboter läuft beim Debuggen gegen die Wand oder lässt beim 
Geschirrspülen den Teller fallen. Woraufhin deine Frau das persönlich 
nimmt und dir das restliche Geschirr um die Ohren haut. Du soltest nicht 
debuggen, das ist viel zu gefährlich.

Stefanus F. schrieb:
> Hast du schon das neue Modell mit Entspannungs-Massage? Auch schon das
> Root-Chakra Upgrade probiert?

Ich habe eine echte Masseurin. Die lässt sich nicht debuggen.

F. F. schrieb:
> Einfach an einem freien Pin anschließend und immer ein Stück weiter
> durch den Programmablauf schieben.
> Wenn man noch keinen LA oder Oszi hat, kann das bei einfachen Programmen
> helfen.

Das ist zu wenig. Mit JTAG kannst du alle Register und alle SRAM-Zellen 
sehen, was dort im Moment passiert. manchmal stört zwar Optimieren von 
Compiler dabei, aber man kann für Zeit einige Variablen als static oder 
volatile erklären, um sie sehen zu können.

Jörg W. schrieb:
> Es wird einfach statt des originalen Befehls ein BREAK
> programmiert. Beim Erreichen des BREAK programmiert der Debug-Dongle
> (also das ICE) automatisch den ursprünglichen Befehl zurück, sodass
> dieser als nächstes ausgeführt wird.

Dann ist vielleicht Abnutzen von Flash doch nicht so hoch, wenn nur eine 
Speicherzelle umprogrammiert wird? Man setzt Breakpoint ja immer auch 
verschiedenen Stellen.

Maxim B. schrieb:
> Das ist zu wenig. Mit JTAG kannst du alle Register

Klar ist das zu wenig, aber bei Arduino eine mögliche und günstige Art 
Fehler einzugrenzen.

F. F. schrieb:
> aber bei Arduino

Dann sollte man lieber Arduino Mega 2560 benutzen. Dort kann man 
unkompliziert JTAG anschließen, mit einfachen Adaptern oder gar per 
Draht. SPI-Buchse gibt es sowieso, man sollte zuerst per SPI JTAG 
einschalten und evtl. Bootloader löschen. Dann kann man ruhig mit C 
debuggen.
Solange IDE von Arduino mit JTAG nicht arbeiten kann, benutzt man lieber 
was anderes. Aber Platine ist zu gebrauchen. Ich habe in meinem Programm 
für PCB die Platine von Arduino als Modul gemacht, so kann ich diese 
Platine wie andere Mikrocontroller auch frei nutzen.

Thomas E. schrieb:
> Aber dein Roboter läuft beim Debuggen gegen die Wand oder lässt beim
> Geschirrspülen den Teller fallen.

Man muss halt 2 Sekunden nachdenken bevor man einen Breakpoint setzt. 
Notfalls ändert man vorher den Code so daß die Motoren oder was auch 
immer die ganze Zeit über in der sicheren Position verbleiben oder 
schaltet sie von Hand ab oder dreht das Wasser von Hand zu wenn der 
Breakpoint triggert oder stellt vorher nen Eimer drunter. Oder nen 
Schlauch zum Abfluss. Bisschen Phantasie und Kreativität braucht man 
halt schon in dem Job!