Hallo zusammen, ich habe mit Hilfe des MSP430G2553 udn MSP403FR5969 das Programmieren von Mikrocontrollern im Studium gelernt. Mittlerweile musste ich auf einen Arduino Uno umsteigen, da der von einem anderem Prof vorgegeben wird. Das Programmieren von den Arduino's in den Sketch Dateien und das Nutzen des Serial Monitors gefällt mir nicht wirklich. Zum Programmieren des MSP's habe ich den Code Composer Studio von TI genutzt. Hier konnte ich das Programm vernünftig debuggen. Mir wurden damit die Registerzustände (Ports, Timer, Interrupts, usw.) angezeigt. Ich fande das zum lernen super, da ich im Detail nachvollziehen konnte, was genau bei welchem Befehl mit den Registern passiert und zusätzlich jeden einzelnen Schritt in Einzelschritten durchgehen und/oder Breakpoints setzen. 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? Mir wäre es egal, ob ich das Ding in C oder als Sketch programmiere. Register View vom CCS: https://e2e.ti.com/resized-image/__size/1230x0/__key/communityserver-discussions-components-files/81/reg.png Viele Grüße und Danke für die Hilfe, Robin
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: > Dazu brauchst Du einen JTAG-Adapter, Ich sage mal voraus dass es nicht gelingen wird einen Mega328p wie er auf dem Arduino Uno vorhanden ist, mit einem JTAG ICE zu debuggen. Das Kürzel JTAG kommt im Datenblatt des Mega328p nicht vor. Anders sieht die Sache beim Arduino Mega mit dessen ATMega2560 aus .....
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
Manche AVR's haben ein JTAG Interface zum Debuggen. Viele andere wiederum haben den DebugWire, das ist physiskalisch betrachtet der Reset Pin. Den muss man jedoch über ISP aktivieren. Also benutzt man in der Praxis zu Debuggen über DebugWire den ISP Anschluss. Du hast richtig erkannt, dass das Debuggen über DebugWire im Prinzip darauf hinaus läuft, Unterbrechungspunkte zu setzen, wo der Controller angehalten wird und dann kann man rein schauen. Ohne Unterbrechungspunkt kann man sie nicht debuggen. > Vor allem vermisse ich das durchgehen des Programms in > Einzelschritten in C auf dem Arduino Uno. Die Arduino IDE kann das nicht, wohl aber das Atmel Studio. Schau es Dir dort mal an.
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.
:
Bearbeitet durch User
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...
Der Debugwire funktioniert genauso, wie JTAG, ist nur eine andere Schnittstelle, bevor das JTAG gekommen ist. Auf dem ARDUINO Board sollte der auf keinen Fall benutzt werden, sondern nur das ISP (wenn man einen anderen Bootloader braucht). Da am Arduino am Reset Pin ein ziemlich fetter 100nF Kondensator ist. Dieser verhindert das Debuggen mittels Debugwire. Einen Nano versuchte ich zu debuggen mit dem Atmel-ICE, daraufhin war der ATmega verfused. Um diesen zu reparieren, kann man noch versuchen diesen mittels Oscillatorschaltung am XTAL einzuspeisen, wärend man die Fuses schreibt. Wenn das nicht funktioniert, dann geht es nur noch mit High-Voltage-Programmer, hier ist allerdings bei jedem Atmel chip eine andere Schaltung notwendig.
Hallo, mit ATMEL Studio 7.X kannst Du Arduino Sketche importieren und dann ganz "normal" mit einem AVR-Emulator Debuggen. Tante Google ist dein Freund. Ciao
Das ist extrem langsam. Und man kann keine externe Hardware debuggen, z.B. Ports, I²C, SPI, Interrupts, Timer, ADC usw. (War ja die Ausgangsfrage) Aber wenn man den Kondensator vom Reset-Pin auf dem Arduino ablötet, kann man den für debugWire verwenden. Allerdings muss später der Bootloader wieder geflasht werden und der Kondensator wieder angelötet werden, wenn dieser wieder als Arduino verwendet wird.
Beitrag #5979913 wurde von einem Moderator gelöscht.
Angehängte Dateien:
-
Schema.png
140 KB -
Oben.png
15 KB -
Unten.png
12 KB
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.
Maxim B. schrieb: > Debugwire nutzt Mikrocontroller extrem ab. Werden die dünner? Oder verfärben die Chips sich schwarz?
MaWin schrieb: > Werden die dünner? Oder verfärben die Chips sich schwarz? @MaWin: vor dem Schreiben Hirn einschalten! Nach jedem breakpoint wird der Controller neu programmiert und die Anzahl der Schreibzyklen einer Zelle im FLASH sind endlich.
> @MaWin: vor dem Schreiben Hirn einschalten! Also da muss ich MaWin aber mal in Schutz nehmen. Es kann doch niemand ahnen das die AVR so ein Murks sind und noch nicht mal fuer 1-2 Breakpoints ein spezielles Register haben. Olaf
Beitrag #5980176 wurde von einem Moderator gelöscht.
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.
Olaf schrieb: > Es kann doch niemand ahnen das die AVR so ein Murks sind Man muss das im Kontext der Zeit sehen, zu der diese Chips erstmalig veröffentlicht wurden. Vorher konnte man Mikrocontroller grundsätzlich nicht debuggen. Da war diese abgespeckte Krücke, die in AVR und viele andere Mikrocontroller eingebaut wurde schon ein Segen. Allerdings: Eben weil es sehr langsam ist und ich meine µC nicht kaputt debuggen möchte, nutze ich dieses Feature nur selten. 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. Ich komme meistens mit Logmeldungen besser klar, die im Release-Build weg gelassen werden. Andere Baustelle: Auf der Arbeit programmiere ich Backend Services für Internet-Dienste. Dort schreibe ich die Debug Meldungen in einen Ringpuffer. Wenn ein Fehler erkannt wird, schreibe ich den Inhalt des Puffers + die Fehlermeldung ins Logfile. So kann ich nachträglich analysieren, wie es zum Fehler gekommen ist. Das kostet im Schnitt ca. 3% Performance, dies es Wert sind.
> Man muss das im Kontext der Zeit sehen, zu der diese Chips erstmalig > veröffentlicht wurden. Vorher konnte man Mikrocontroller grundsätzlich > nicht debuggen. Doch konnte man, deshalb bin ich damals vom Mega8 zu Renesas gegangen weil das da einfach und kostenlos moeglich war. (KD30 mit M16C) In der Firma hab ich zu der Zeit den 68332 genutzt weil der auch ein BDM hatte. Ausserdem sollte man doch annehmen das ein Hersteller seine Produkte mit der Zeit verbessern kann! Er braucht ja nur bei anderen abzuschreiben. > Ich komme meistens mit Logmeldungen besser klar, die im Release-Build > weg gelassen werden. 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. Gerade bei Anfaengern ist es doch so das der Compiler aus ihrem C-code etwas ganz anderes macht als sie glauben. Wenn die nur einmal in einer Minute im Singlestep durch den Code gehen haben die mehr gelernt als in 2h printf. Oh..und die Existenz eines Debuggers heisst nicht das man nicht auch mal Fehlermeldungen anderweitig ausgeben kann! Es ist nur der erste Loesungsansatz. Olaf
Olaf schrieb: > Ausserdem sollte man doch annehmen das ein Hersteller seine Produkte mit > der Zeit verbessern kann! Was ja auch geschehen ist. In der Xmega Serie gibt es Hardware Breakpoints. > 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. Ist auf jeden Fall hilfreich. Ich hatte mich anfangs mit dem Simulator begnügt (weil der Atmel Debugger so teuer war), das war schon lehrreich genug.
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.
MaWin schrieb im Beitrag #5980176: > Olaf schrieb: >> @MaWin: vor dem Schreiben Hirn einschalten! >> >> Also da muss ich MaWin aber mal in Schutz nehmen. Es kann doch niemand >> ahnen das die AVR so ein Murks sind und noch nicht mal fuer 1-2 >> Breakpoints ein spezielles Register haben. >> Olaf > > Danke! Wenigstens einer der meinen Intellekt zu würdigen weiß Viele IDEs nutzen zum debuggen Software-Brekpoints. Und da wird mit dem Setzen eines Breakpoints jedesmal ein Schreibvorgang auf das Flash gemacht. Üblicherweise wird aber nur eine Page geschrieben, nicht der ganze µC. So unüblich ist das gar nicht, wie du jetzt darstellen willst. Bei üblicherweise 10k Schreibvorgängen hält ein µC da durchaus eine Weile durch. Also ist das gar nicht so ungewöhnlich, wie du denkst, und deine Überraschung ist nur Unwissen auf deiner Seite.
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.
:
Bearbeitet durch User
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.
ohje... schrieb: > Und da wird mit dem Setzen eines Breakpoints jedesmal ein Schreibvorgang > auf das Flash gemacht Es gibt auch MC, die eine eigene Debuglogik eingebaut haben. Diese führt einen Adressvergleich mit dem IP durch und löst bei Übereinstimmung einen Interrupt aus. Dafür benötigt man kein Umschreiben des Codes im FLASH.
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.
Thomas E. schrieb: > Was ist denn das für ein an den Haaren herbeigezogener Schwachsinn? Das ist kein Schwachsinn. Viele Systeme fallen in dem Moment aus, wo du das laufende Programm einer Komponente anhältst. Selbst im Job (Web Anwendungen im Backend) kann ich nicht einfach den Server beliebig lange anhalten, weil sonst die Clients in einen Timeout laufen und infolge dessen danach etwas ganz anderes machen, als im Normalbetrieb. Noch ein Beispiel: Eine gemultiplexte 7-Segemtn Anzeige darfst du in der Regel nicht einfach anhalten, weil dabei das gerade leuchtende Segment durchbrennt (oder zumindest geschädigt wird).
> 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 Du meinst sein Gehirn wird schonmal weichgekocht damit er spaeter Eclipse fuer ein brauchbares Stueck Software haelt? :-D > Was ist denn das für ein an den Haaren herbeigezogener Schwachsinn? Naja, es gibt schon Faelle wo man nach einem Breakpoint nicht einfach so weitermachen kann. Ein einfaches Beispiel ist z.b ein Temperaturregler. Trotzdem kann ein Debugger auch da ganz nett sein weil man halt einfach mal den Systemzustand an einem bestimmten Punkt ablesen kann. 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. BTW: In aller Regel nutze ich den Debugger natuerlich auch aus einer grafischen Umgebung raus. Trotzdem kann ich nur empfehlen sich auch mal mit dem gdb auf der Kommandozeile zu beschaeftigen. Der kann naemlich so ungefaehr 100x mehr als man denkt. Damit kann man sich dann retten wenn man einen sehr komplexen Bug hat. Das ist dann wie das Paradies auf Speed. Olaf
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 :>
Olaf schrieb: > Du meinst sein Gehirn wird schonmal weichgekocht damit er spaeter > Eclipse fuer ein brauchbares Stueck Software haelt? Der war gut. Aber ja, Eclipse ist bessere Kacke als die Arduino IDE.
Olaf schrieb: > Bei ARMs ist da ja moeglich. Geht auch mit Registern. Ich finde beides sehr praktisch. Unter Debuggen verstehe ich allerdings, das Programm anzuhalten, irgendwas nachzugucken und dann fortzusetzen. Vermutlich sind die Begriffe diesbezüglich nicht eindeutig.
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.
Beitrag #5980664 wurde von einem Moderator gelöscht.
Beitrag #5980682 wurde von einem Moderator gelöscht.
Maxim B. schrieb: > 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. Ich glaube da täuschst du dich. "Du" setzt da keine Breakpoints deine Entwicklungsumgebung aber schon.
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.
Thomas E. schrieb: > Was du da von dir gibst, ist einfach nur Schwachsinn. Wie du meinst. Wir müssen uns nicht einig werden. Ich bin alt genug, damit leben zu können.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch Moderator
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.
Jörg W. schrieb: > Das Ganze geht erstaunlich schnell; Naja. Mein erster Eindruck vom Debug Wire (mit AVR Studio, Atmel ISP MKii) war eher, dass es super lahm ist. Wobei ich bis dahin noch nie zuvor Mikrocontroller debuggt habe. STM32 mit SWD Schnittstelle (und ST-Link Adapter) ist da schon um Welten schneller. Der eine Draht mehr lohnt sich scheinbar. Trotzdem liebe ich dieses Feature. Ich brauche es nur selten, aber wenn, dann bin ich dankbar für diese Möglichkeit.
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.
Thomas E. schrieb: > Dann pass aber auf, daß du deine Wohnung nicht unter Wasser setzt, falls > du mal wieder deine Waschmaschine debuggen mußt. Mach ich. An der Waschmaschine experimentiere ich nicht und mein Modellauto hängt beim Debuggen mit den Rädern in der Luft.
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.
:
Bearbeitet durch User
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.
Thomas E. schrieb: > Aber dein Roboter läuft beim Debuggen gegen die Wand Ja, das ist noch einer aus der alten Serie, mit dem Bug wo er epileptische Anfälle bekommt, wenn man im selben Raum Fortnite spielt. Hast du schon das neue Modell mit Entspannungs-Massage? Auch schon das Root-Chakra Upgrade probiert?
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.
:
Bearbeitet durch User
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.
Beitrag #5982732 wurde vom Autor gelöscht.
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!
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.