www.mikrocontroller.net

Forum: Compiler & IDEs (Linux-) Debugger für Mega8


Autor: Christian Wolf (clupus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(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.

Autor: Christian Wolf (clupus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Wolf (clupus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ein Monitorprogramm, ginbt's da was, das gut funktionier (möglichst
mit gdb) und das nicht zu viel Speicher frisst.

MfG
Christian

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Christian Wolf (clupus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Wolf (clupus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/eve...
helfen.

Gibt es hierfür eine IDE/gdb-frontend, die/das mir erlaubt, grafisch
die Codes zu debuggen?

MfG
Christian

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Christian Wolf (clupus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Christian Wolf (clupus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bist du dir sicher, dass er den AVR-GDB aufruft und nicht den
GDB des Systems?

Autor: Christian Wolf (clupus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Christian Wolf (clupus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.