Hallo allersits, ich hab das Problem, dass ich zwar ein Programmer habe, jedoch kann dieser nicht debuggen (hab das dapa-Kabel von uisp). Wenn ich jetzt meine Programme im ATmega8 prüfen will, kann ich nur versuchen, soweit es mir möglich ist, durch gewisse Zustände (z.B. Motor 5 mal nacheinaner ein- und ausschalten) die aktuelle Position im Programm zu erahnen. Eine richtige Debuging-Session kann das aber nicht ersetzen. Wie kann ich mir einen möglichst einfachen Debugger (selber) herstellen und welche Software (hab SuSE Linux) verwende ich dazu? (Hab schon die Erfahrung gemacht, dass nicht jede Version von gdb mit allem zusammenläft ;-)) Wie gesagt eine einfache Programmierung/Aufspielung von Hex-Dateien ist problemlos möglich. MfG Christian
(1) Software-Debugging, Debug-Monitor im Mega8. Aber dafür braucht's einen Schnittstelle, üblicherweise eine serielle, die nicht schon anderweit verbraten ist. Wenn Du schon den Motor als Ausgabemedium benutzt, scheint das offenbar auch nicht in Frage zu kommen, denn Trace-Output per UART ist neben Status-LEDs üblicherweise der erste Ansatz. (2) Hardware-Debugging via JTAG. Geht mit dem Mega8 nicht, wohl aber mit Mega16/32. (3) Hardware-Debugging via debugWire. Auch das geht mit dem Mega8 nicht, wohl aber mit dem pinkompatible Mega88. Benötigt Hardware von Atmel 300-400EUR. Und Windows, echt oder simuliert.
OK, wie würde das mit dem Software-Debugging (1) laufen? Ich hab notfalls den Platz für einen UART. Das mit dem Motor hat mehrer Gründe: 1. Ich hab nicht drangedacht, LEDs einzuplanen. 2. Ich hab das SPI Interface unbelegt belassen, weil ich nicht wollte, dass mein ATmega wärend der Programmierung, bzw. direkt danach Spannung an den Paralell-Port des PCs legt (hab auf die Art schon mal meinen LPT durchgeschossen (!)). Daher hatte ich da ein wenig Mores. 3. Eingänge wollte ich auch nach Möglichkeit keine an das SPI legen, weil ich nicht wusste, ob der PC und die zugehörige Schaltung evtl. stört. Ich hätte also noch nen SPI frei (wenn das was bringt) oder könnte notfalls auch den SPI für die Ausgänge, die momentan auf dem UART liegen, verwenden. Mfg Christian PS: Gibt es eine Möglichkeit, das Verhalten des Chips im PC vorausberechen zu lassen? Eine Simulation sozusagen?
Atmel bietet ja die Controller-Simulation kostenlos, Windows halt. Dein Motor wird da freilich nicht mit simuliert. Irgendwas Linux-mässiges gibt's auch, ich weiss aber nicht drüber. Kombinierte Simulation mit externer Hardware: http://www.amctools.com. Debug-Monitor: Zusätzliches vom Hauptprogramm unabhängiges Monitorprogramm (1-2KB werden das schon sein) wird per UART-Receive-Interrupt oder Breakpoint aktiv. Hauptprogramm ist dann inaktiv und das Monitorprogramm kommuniziert mit Terminalprogramm auf PC. Kann Register/IO/Speicherinhalte anzeigen und ändern, evtl. auch im Einzelschittbetrieb Befehle ausführen, Breakpoints setzen, das Hauptprogramm weiterlaufen lassen usw.
Der erste Ansatz sind natürlich Trace-Ausgabe statt Debugging. Reicht meistens, aber nicht immer. Oft per UART. Also alle naselang per printf() oder ASM-Macro mitteilen lassen, was grad so läuft. Kommt das aus Zeit/Platz/Sonstwiegründen nicht in Frage, geht beispielsweise auch LED per SPI. 8bit Schieberegister ans SPI, LEDs dran (Luxusversion: 7-Segment-Anzeigen) und immer fleissig einen Code draufschieben, der klarmacht was grad läuft.
mit Software debugging ist eher folgendes Gemeint: du hängst den µC über die serielle an den PC und programmierst immer Ausgaben an kritischen Stellen im Sourcecode. SPI bringt dir hier nicht viel... Ein Simulator ist im AVRStudio für Assembler und C Projekte.
So ein Monitorprogramm, ginbt's da was, das gut funktionier (möglichst mit gdb) und das nicht zu viel Speicher frisst. MfG Christian
OK, ich hab grad bei Atmel noch ein bisschen Dokus gewältzt. Stimmt meine Vermutung, dass der ATmega48/88/168 die gleiche Pin-Konfiguration wie der "normale" mega8 hat? Ich müsste also eigentlich den mega8 durch einen der oben genannten austauchen können, oder? Die haben ja dieses debugWire, das dann per JTAG ausgelesen werden kann, oder? Gibt es hier vielleicht einen entsprechenden Programmer, der das dW verwendet? (Einen solchen mega168 zu Debug-Zwecken wäre ja kein Problem) MfG Christian
DebugWire und JTAG dienen dem gleichen Ziel, sind jedoch völlig verschieden. Für DebugWire ist Hardware von Atmel nötig, 300-400EUR. Ein Nachbau existiert bislang nicht. Zur Migration Meta8 => Mega88 gibt's einen Atmel Application Note. Sind intern ein paar Register und Bits anders adressiert und benannt.
Gesetzt den Fall, ich würde einen ATmega16 einsetzen (ersetzen), dann könnte ich doch JTAG verwenden, oder?Hier kann mir die Hardware von http://www.siwawi.arubi.uni-kl.de/avr_projects/evertool/index.html helfen. Gibt es hierfür eine IDE/gdb-frontend, die/das mir erlaubt, grafisch die Codes zu debuggen? MfG Christian
Ja, mit dem Mega16 geht es mit JTAG ICE Nachbauten wie dem Evertool. Da Mega8 und Mega16 hinsichtlich der Funktionalität eng verwandt sind, kann es folglich sinnvoll sein, die Entwicklung auf Mega16/32 zu machen und dann erst auf den Mega8 zu gehen. Zu AVR/gdb kann ich wenig sagen, hab nur gelesen dass es gehen soll (verwende selbst Atmel Studio). Evtl. ist Eclipse sinnvoll, jedenfalls ist das bei ARM/gdb recht überzeugend.
> Gibt es hier vielleicht einen entsprechenden Programmer, der das dW > verwendet? dW ist keine Programmierschnittstelle (per se), sondern eine Debugschnittstelle. Wie dir schon geschrieben wurde, dW wird vom JTAG ICE mkII unterstützt. Zwar wird das mkII prinzipiell von den opensource-Tools AVaRICE (als GDB-Ankopplung zum Debuggen) und AVRDUDE (als Programmer) unterstützt, die debugWire-Funktionalität derzeit jedoch nicht. Volunteers welcome. ;-) > Ja, mit dem Mega16 geht es mit JTAG ICE Nachbauten wie dem > Evertool. Da Mega8 und Mega16 hinsichtlich der Funktionalität eng > verwandt sind, kann es folglich sinnvoll sein, die Entwicklung auf > Mega16/32 zu machen und dann erst auf den Mega8 zu gehen. debugWire ist ohnehin nur der kleine Bruder von JTAG-Debugging. JTAG kann z. B. echte breakpoints, debugWire kann das nur als Software- BREAKs, indem jeweils der entsprechende Befehl durch ein BREAK überschrieben wird und beim Erreichen des Breakpoints der ursprüngliche Opcode zurück in den Flash geschrieben wird. Ich habe noch nicht damit gearbeitet, vermute aber, dass das doch nochmal einiges langsamer geht als via JTAG.
OK, ich merke, bzw. vermute mal, dass das mit dem dW eher eine unglückliche Sache ist, die nur bedingt funktioniert. Mal anders gefragt: Welche Software brauche ich, um per evertool einen mega16 zu debuggen? 1. avr-gcc und avr-uisp/avrdude (klar) 2. gdb (auch klar) 3. Frontent zu gdb (eclipse, ddd, insight) (Welches ist gut?) 4. Software, die die Verbindung avr(JTAG) <--> gdb herstellt (Nötig? Wenn ja, wie heißt die Software?) 5. ggf.: Simulator, um Software auszuprobieren, bevor man in den Chip schreibt, in die man dann einfach eingeben kann, wie die Eingangszustände sind und dann sieht, wie der Chip reagieren würde. MfG Christian
> Mal anders gefragt: Welche Software brauche ich, um per evertool > einen mega16 zu debuggen? > 1. avr-gcc und avr-uisp/avrdude (klar) AVRDUDE kann auch via JTAG ICE (seit Version 5.1 nun auch via JTAG ICE mkI) Code in den AVR laden. > 2. gdb (auch klar) Ja. :) > 3. Frontent zu gdb (eclipse, ddd, insight) (Welches ist gut?) Emacs. ;-) Hat jeder seinen Geschmack. Ted Roth (zu Zeiten, als er noch in der AVR-Opensource-Szene aktiv war) hat mal auf DDD geschworen, wenig später meinte er aber, dass er mittlerweile fast wieder beim nackten GDB angelangt war. > 4. Software, die die Verbindung avr(JTAG) <--> gdb herstellt (Nötig? > Wenn ja, wie heißt die Software?) AVaRICE. > 5. ggf.: Simulator, um Software auszuprobieren, bevor man in den > Chip schreibt, in die man dann einfach eingeben kann, wie die > Eingangszustände sind und dann sieht, wie der Chip reagieren würde. simulavr bzw. simulavrxx, die haben jeweils eine eigene GDB-Remote- Funktionalität (wie sonst AVaRICE bei Benutzung des JTAG ICE). simulavr wird nicht mehr weiter entwickelt und hat nur eingeschränkte IO-Features. simulavrxx soll IO-seitig besser sein, dafür ist es mir bislang auf FreeBSD noch nicht gelungen, das wirklich schon zum Compilieren zu bekommen. VMLAB kann man unter Wine benutzen, allerdings bringt deren setup.exe mittlerweile unter Wine eine unhandled exception, sodass man es nicht mehr installiert bekommt. :-( War ansonsten eine recht gut ausgefeilte Simulation (aber auch recht langsam). avrora habe ich mir noch nicht angesehen. Wenn man sich ansieht, was die Schöpfer damit bereits simuliert haben (ganze wireless networks mit vielen, vielen interagierenden Knoten), muss es ziemlich mächtig sein.
Zum avrora: Ic blick da ehrlich gesagt nicht ganz durch. (Vielleicht
liegts auch an mir. Sagt's dann bitte ;-)) Ich sehe ehrlich gesagt
keine Möglichkeit mir in avrora die Ausgabe-Register PORT{A,B,...}
auszugeben, noch die Eingaberegister PIN{A,B,...} zu setzen. Zudem sehe
ich keine Möglichkeit, die Geschwindigkeit auf ein "humanes" (im
wahrsten Sinne des Wortes) Nivau zu reduzieren. Hat jemand Erfahrung
mit avrora?
MfG
Christian
PS: Ich habe simulavr und insight kompiliert, jeweils mit --target=avr.
Wenn ich jetzt eine Simulation mit avr-simulavr -g -p 1212 -d atmega8
blinker.hex starte und anschließend in insight versuche remote mit Port
1212 zu kommunizieren, erhalte ich die Melung:
gdbarch.c:3906: internal-error:
gdbarch_deprecated_register_convertible: Assertion
`gdbarch->deprecated_r
A problem internal to GDB hab been detected, futher debugging may prove
unreliable. Quit this debugging session?
<Yes><No>
Was kann ich hier machen?
Wenn ich insight mit avr-insight --nx aufrufe, muss ich zwar alle Einstellungen neu stetzen, jedoch kommt der Fehler trotzdem "irgendwann". Wenn ich mir z.B. die Register anschauen will, kommt oben genannte Fehlermeldung. MfG Christian Auch hier meine Frage: Wie kann ich Eingangs- und Ausgangsregister lesen/schreiben? Nur über den Register-Regler, oder? Oder ist die Einstellung der In-ports irgenwo außerhalb vom gdb-frontend zu machen?
OK, ich hab ein bisschen rumprobiert. Wenn ich jetzt mal von insight weggehe (hab viele Problemberichte gesehen) und zurück zu avr-ddd gehe, scheint es einigermaßen zu funktionieren. Leider hab ich noch 2 Probleme: 1.) Wenn ich in Einzelschritten durch mein Programm durchgehe, kommt es irgendwann dazu, dass der Simulator immer im Kreis rechnet. Die CPU-Last jagt in die Höhe und der gdb lässt sich nur noch per SIGTERM beenden (soweit ich das herausgefunden habe). Eigentlich sollte aber irgendwann wieder ein Breakpoint kommen und außerdem war es nur eine "step"-Anweisung. Der verwendete avr-simulavr meldet tausende Breakpoints, stoppt aber nicht (Meine Konsole braucht ca. 1-2 Sek. um 1000 Zeilen zu produzieren). Was läuft da falsch? 2.) Wie kann ich die IO-Register in ddd/simulavr setzen/lesen? Ich will ja auch sehen, was die Software/Firmware da verzapft. MfG Christian
Thread beobachten
Seitenaufteilung abschaltenBitte 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.