mikrocontroller.net

Forum: Compiler & IDEs XP Eclipse AVR Debugging sehr langsam


Autor: Michael S. (elmsfeuer)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

da ich mich immer mehr über AVR Studio (IDE/Debugging) geärgert habe, 
bin ich kurzerhand auf Eclipse C/C++ zusammen mit dem AVR-Plugin 
umgestiegen. Nach ein wenig lesen hier im Forum und folgen der üblichen 
Tutorien läuft nun die komplette Toolchain. Einziger Wehrmutstropfen ist 
jetzt aber, dass das Debugging mit AVaRICE sehr langsam abläuft, pro 
Stepping vergehen mehrere Sekunden. Da ist das AVR Studio doch sehr viel 
schneller mit der selben Hardware und gleicher Source. Bei meinen 
Versuchen habe ich einen AT90CAN128 verwendet, andere uCs habe ich 
leider nicht zum testen.

Hat jemand das gleiche Problem und/oder eine Lösung, damit das Debugging 
schneller läuft unter Eclipse? Ich bin etwas ratlos was ich noch 
unternehmen kann, ausser die Baudraten umstellen was ich schon getan 
habe.

Zum Ablauf: Ich flashe das Programm mit AVRdude, schmeisse AVaRice an 
und starte dann avr-gdb.
Der Vollständigkeit halber als Anhang: Source-Code, Bilder von der 
Eclipse-Konfiguration, Debuginformationen von avarice und avr-gdb.

Toolchain:
----------
uC: AT90CAN128. 16MHz.
Flasher/Debugger: Atmel JTAG ICE mkII (Aktuelle Firmware).
LibUsb-Win32: Filter 1.2.2.0
WinAVR: WinAVR-20100110
Eclipse: Helios Service Release 1
Avr-Eclipse - Plugin: 2.3.4.20100807PRD
Eclipse GDB Hardware Debugging - Plugin: 7.0.0.201009241320

MfG
elmsfeuer

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem gab es auch schon in den Vorgängerversionen von Eclipse und 
den Plugins. Ich habe dann aufgehört, diese Form des Debuggens zu 
benutzen, weil es nichts bringt. Besonders umfangreiche und komplexe 
Algorithmen hat man in den kleinen Controllern ja ohnehin nicht, und 
überschaubare Codeschnipsel lassen sich besser testen, wenn man sie 
einfach in ein Consolenprojekt wirft und auf der Hardware der 
Entwicklungsmaschine debuggt.
Am häufigsten treten nach meiner Erfahrung ohnehin solche Probleme auf, 
die von externen Ereignissen an irgendwelchen Pins des Controllers 
ausgelöst werden, wenn diese Ereignisse in bestimmten zeitlichen 
Zusammenhängen stattfinden. Diese Probleme findet man per JTAG oder 
DebugWire ohnehin nicht, selbst wenn die Pausen beim Debuggen kürzer 
währen, weil man die externen Ereignisse eben in der Regel nicht mit dem 
Stepping beim Debuggen synchronisieren kann. Für diese Fälle hat es sich 
bewährt, an strategischen Stellen im Programm einen ungenutzten Pin zu 
toggeln und ein Scope dran zu hängen. Da sieht man dann in Echtzeit, was 
abgeht, und meistens kommt man dann auch ziemlich schnell dahinter, 
warum es anders läuft, als man das ursprünglich vorgesehen hatte.

Autor: Michael S. (elmsfeuer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nabend Andreas,

sprichst Du von eigenen Erfahrungen oder von Berichten anderer? Denn 
mich würde interessieren ob es an meiner Toolchain liegt, speziell in 
Verbindung mit dem AT90CAN128 oder ob es ein genereller Umstand ist mit 
den AVR-Tools und Eclipse, dass das Debuggen so lame ist.

Das Debuggen der Hardware ansich über JTAG/Dwire find ich schon 
brauchbar, aber Du hast in sofern recht, dass man damit schwer eine 
laufende Kommunikation ordentlich untersuchen kann, deshalb benutze ich 
auch gerne eine Mischung aus JTAG-Debug/Konsolen-Debug/Pin-Debug je nach 
Anforderung.

Ich bin eigentlich begeistert von der Eclipse IDE in Verbindung mit der 
Debug-Umgebung durch Erfahrungen mit dem Entwickeln von 
Android-Anwendungen, deshalb mag ich mich nicht recht damit zufrieden 
geben, dass das Debuggen nun mit AVR so maulig laufen soll.

MfG
elmsfeuer

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael S. schrieb:
> Einziger Wehrmutstropfen ist
> jetzt aber, dass das Debugging mit AVaRICE sehr langsam abläuft, pro
> Stepping vergehen mehrere Sekunden.

Das Debuggen unter Eclipse ist recht langsam, aber bei mir nicht soo 
langsam. Ich debugge über die serielle Schnittstelle, das geht 
schneller(!) als über USB. Programmieren des AVRs mache ich mittels 
AVRDude (+ AVR-Plugin) und USB(!). Beim programmieren ist das die 
schnellste Lösung.

Ich habe keine andere Lösung. AVaRice scheint über USB irgendwie Mühe zu 
haben. Warum weiß ich nicht. Hab es auch schon mal an den Autor 
gemeldet, der wußte aber auch keine Lösung.

Edit: Ich nutze eine echte serielle Schnittstelle, keinen 
USB-Seriell-Wandler.

Autor: Micha S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael S. aka Elmsfeuer.

Ich heiße auch Michael S. und nutze auch den Nick Elmsfeuer, kenne 
dieses Froum aber überhaupt nicht. Bekomme aber auf meine mailadi 
Elmsfeuer@xxxxxxx immer die Benachrichtigung das jemand hier auf Deinen 
Post geantwortet hat.

Zufall, Vorhersage oder gar Manipulation??

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael S. schrieb:
> sprichst Du von eigenen Erfahrungen oder von Berichten anderer? Denn
> mich würde interessieren ob es an meiner Toolchain liegt, speziell in
> Verbindung mit dem AT90CAN128 oder ob es ein genereller Umstand ist mit
> den AVR-Tools und Eclipse, dass das Debuggen so lame ist.

Ja, ich rede von eigenen Erfahrungen. Ich hatte Eclipse Ganymede, 
WinAVR-20081205, Atmel JTAGICE MKII und ein Board mit einem ATmega644P. 
Das Stepping im Debugger war mit dieser Kombination nicht nur langsam, 
sondern ist mir auch regelmäßig komplett um die Ohren geflogen (Absturz 
Eclipse). Ein paar mal habe ich dann hilfsweise AVR Studio verwendet, um 
wenigstens den nackten Assemblercode debuggen zu können. Das 
funktionierte im Prinzip gut, ist aber auch keine befriedigende Lösung, 
wenn das Projekt in C++ programmiert ist...

Autor: Michael S. (elmsfeuer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Micha S.:
Ich habe mich hier mit Deiner jetzigen Adresse angemeldet als sie noch 
in meinem Besitz war. Die Adressumstellung hat nicht geklappt, hab das 
grad mal gemeldet und solang die Mailbenachrichtigung abgeschaltet, 
sorry für die Unannehmlichkeiten. Das mit dem ähnlichen Namen und dem 
gleichen Nick ist aber schon unheimlich.

@900ss D.:
Vielen Dank für den Tipp mit der seriellen Schnittstelle, werd ich mal 
ausprobieren, evtl. ist das ja erträglicher!

MfG
elmsfeuer

Autor: Michael S. (elmsfeuer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas:
Danke für die Information.

@Andreas und 900ss D.:
Habt ihr auch den libUsb-Win32 Filter verwendet oder die libUsb-Win32 
unabhängig vom AVR Studio installiert? Kein Plan wie die Filter-Variante 
funktioniert, aber evtl. geht ja da Performance verloren!?

MfG
elmsfeuer

Autor: Micha S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, alles klar !
Kein Ding, dann weiß ich Bescheid !!

Aber das mit dem Namen und dem Nick ist schon lustig :)

so long, cu

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael S. schrieb:
> Habt ihr auch den libUsb-Win32 Filter verwendet oder die libUsb-Win32
> unabhängig vom AVR Studio installiert?

Ich habe die LibUsb ohne Filter verwendet. AVR-Studio hatte ich in einer 
Virtuellen Maschine installiert, so dass es seinen Jungo-Treiber 
verwenden konnte, ohne mit LibUsb zu kollidieren.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael S. schrieb:
> Habt ihr auch den libUsb-Win32 Filter verwendet oder die libUsb-Win32
> unabhängig vom AVR Studio installiert?

Ich arbeite direkt ohne den Jungo-Treiber.

Autor: Michael S. (elmsfeuer)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

ich habe das Debuggen mit dem "Atmel JTAG ICE mkII" nun mal über die 
serielle Schnittstelle ausprobiert und es war auch langsam, aber 
geringfügig schneller als über USB.

Mir ist nun was "neues" aufgefallen. Beim Start von avarice erscheint 
eine Meldung (siehe Anhang):
Attempting synchronisation at bitrate 19200

Daraufhin habe ich mal im AVR Studio die Baudrate umgestellt und eine 
Debugsession gestartet mit 19200, was auch als default-Wert markiert ist 
(siehe Anhang). Und siehe da, die Debugsession läuft genauso langsam wie 
die in Eclipse, es liegt also an der eingestellten Baudrate zwischen 
avarice und dem mkII. avarice benutzt offensichtlich den default-Wert.

Die Frage ist nun:
- Wie kann man im avarice die Baudrate umstellen?
- Wie mit avarice die mkII Baudrate umstellen?

Ich werde mich mal auf die Suche begeben, wenn jemand schon was darüber 
weiß bitte melden!

MfG
elmsfeuer

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael S. schrieb:
> Mir ist nun was "neues" aufgefallen. Beim Start von avarice erscheint
> eine Meldung (siehe Anhang):

Attempting synchronisation at bitrate 19200

Das sehe ich bei mir nicht. Sieht so aus:
c:\Bat>avarice -2 -B4000khz --jtag /dev/com2 :10000
AVaRICE version 2.9, Jan  7 2010 22:42:57

JTAG config starting.
Found a device: JTAGICEmkII
Serial number:  00:b0:00:00:27:fc
Reported JTAG device ID: 0x9704
Configured for device ID: 0x9704 atmega1281
JTAG config complete.
Preparing the target device for On Chip Debugging.

Disabling lock bits:
  LockBits -> 0xff

Enabling on-chip debugging:
  Extended Fuse byte -> 0xf5
      High Fuse byte -> 0x1d
       Low Fuse byte -> 0xfd
Waiting for connection on port 10000.


Edit: Ach doch, wenn ich debug einschalte, dann sehe ich auch die 19200 
Baud. Da werd ich mal nachhaken. Es gibt soviel ich sehen kann keinen 
Paramter, dass zu ändern.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So hab nachgehakt und auch schon eine Antwort.

Zitat:
Die Kontaktaufnahme mit dem ICE (das "Einloggen") erfolgt stets und
ständig mit 19200 Bd.  Erst danach wird auf die veränderte Baudrate
umgeschaltet: .....
Zitatende

Es dann auf 115200 Baud geschaltet. Also da ist nix mehr drin. :-(

Autor: Michael S. (elmsfeuer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe vorhin mal ausprobiert im avr-gdb die Baudrate umzuschalten, 
also über eine Konsolensession mit
(gdb) set remotebaud 115200
leider gab es dann beim manuellen "durchsteppen" keine Verbesserung der 
Laufzeit, der Weg scheint also verschlossen zu sein.

Bleibt ja nur die Source von avarice mal auseinanderzuflücken und zu 
versuchen die Kommunikation dort zu beschleunigen. Vielleicht lehne ich 
mich jetzt zu weit aus dem Fenster, aber es muss doch möglich sein den 
Ablauf so schnell zu "machen" wie im AVR-Studio. Ohne jetzt den 
kompletten Hintergrund zu kennen macht mir Hoffnung die Seite 58 im 
AVR067.

Ich werd einfach mal anfangen zu wurschteln, versuch macht kluch...

MfG
elmsfeuer

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael S. schrieb:
> Ich habe vorhin mal ausprobiert im avr-gdb die Baudrate umzuschalten,

Liest du meine Postings? ;-)
Ich schrieb doch, es wird erst mit 19200 begonnen(!). Danach erfolgt 
eine Umschaltung auf 115200 Baud. Also da gibt es nichts mehr zu 
beschleunigen.

Was allerdings auch hilft ist folgendes:
Im Eclipse Debuggerfenster mußt du alle Anzeigefenster, die du nicht 
wirklich brauchst, zumachen. Z.B. das Disassemblerfenster, das 
Memoryfenster, nur soviele Variablen anzeigen, wie nötig.
Dadurch muß Eclipse diese Daten nicht vom Target lesen und es wird alles 
etwas flüssiger. Mache den Test, man merkt das wirklich.

Autor: Kai S. (zigzeg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In Eclipse gibt es zwei "Ankopplungen" fuer den gdb. Die aeltere ist 
dafuer beruechtigt, dass sie ziemlich langsam ist (u.A. weil jeder View 
asyncron Anfragen stellt).

Die neue heisst "DSF-gdb" (sie benutzt das DSF "Debug Services 
Framework"). Mittlerweile (ich glaube seit Eclipse 3.6) sollte sie 
eigentlich der Standard sein, zumindest bei 3.5 (Galileo) war es aber 
glaube ich schon dabei (wenn ich das alles richtig im Kopf habe).

Am besten mal checken, was da aktiv ist: Im "Debug configurations..." 
Dialog, im "Arguments" Tab, da ist unten eine Zeile, in der sowas steht 
wie:

Using (GDB)(DSF) Create Process Launcher ... _Select other..._

(in diesem Fall ist es schon richtig konfiguriert). Wenn man auf den 
blauen "Select other..." Link klickt kann man das umstellen. Bei mir 
heisst die alte Anbindung "Standard Create Process Launcher".

Generell natuerlich die Empfehlung, die neueste Release von Eclipse 
(3.6, Helios) zu verwenden, da Debug Performance durchaus ein Thema war.

Vielleicht konnte ich ja etwas weiter helfen ?

ZigZeg

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kai S. schrieb:
> Vielleicht konnte ich ja etwas weiter helfen ?

Hab gerade mal nachgesehen bei mir (Helios). Da ist bei allen Debugger 
Configs DSF aktiviert, aber ich komme mit der Geschwindigkeit klar. Es 
ist gerade ausreichend schnell. Ich kann damit leben. Schneller wäre 
schöner aber es geht.

Nichts desto trotz merkt man die Anzahl der Fenster, die der Debugger 
nach jedem Step füllen muß.

Autor: Michael S. (elmsfeuer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@900ss D.:
Habe deinen Post tatsächlich erst entdeckt nachdem ich meinen letzten 
geschrieben hatte, sorry :-) Hatte mir trotzdem mal die avarice-source 
angeschaut und kann damit dein Zitiertes nur bestätigen. Hatte gehofft 
dass es zwischenzeitig zu einer Zurücksetzung der Baudrate kommt, aber 
in der avarice-Source wird nur einmal am Anfang eine Synchronisation 
ausgeführt und da die Kommunikations ja ohne mucken weiterläuft wird die 
Eingestellte Baudrate also konstant bleiben. Irgendwie enttäuschend :-(. 
Werde deinem Vorschlag mit dem schließen der zusätzlichen 
Debuginformationen mal folgen und schauen ob es was verbessert.

@Kai S.:
Beide Varianten probiert, aber keine Laufzeitverbesserung festzustellen, 
aber Danke für den Tipp.

MfG
elmsfeuer

Autor: Philipp K. (case55)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

hatte gleiche Probleme. Sehr wahrscheinlich Lösung wurde hier 
beschrieben:
http://www.mail-archive.com/avarice-user@lists.sou...
Ich habe bei "Debug Configurations-> GDB Hardware Debugging ->Startup -> 
Load Image" ohne Haken gemacht. Dann muss als erste Image hochladen und 
nur danach debbugen starten.
Eclipse 3.6 Helios, avarice 2.9, avr-gdb 7.0.1

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Philipp K. schrieb:
> Load Image" ohne Haken gemacht

Es ist hier nicht das Laden langsam, sondern das debuggen selber. Also 
single step o.ä.
Das Laden ist allerdings auch langsam, wenn man bei "Load " das Häkchen 
setzt, das ist wahr. Das sollte man nicht über den GDB machen sondern 
wie du geschrieben hast separat.

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.