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
Angehängte Dateien:
-
Conf_avarice.jpg
93 KB -
Conf_gdb_1.jpg
89 KB -
Conf_gdb_2.jpg
89 KB -
Conf_gdb_3.jpg
100 KB
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.
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
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.
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??
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...
@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
@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
Ah, alles klar ! Kein Ding, dann weiß ich Bescheid !! Aber das mit dem Namen und dem Nick ist schon lustig :) so long, cu
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.
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.
Angehängte Dateien:
-
avr_studio_con_dia.jpg
47 KB
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):
1 | 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
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:
1 | c:\Bat>avarice -2 -B4000khz --jtag /dev/com2 :10000 |
2 | AVaRICE version 2.9, Jan 7 2010 22:42:57 |
3 | |
4 | JTAG config starting. |
5 | Found a device: JTAGICEmkII |
6 | Serial number: 00:b0:00:00:27:fc |
7 | Reported JTAG device ID: 0x9704 |
8 | Configured for device ID: 0x9704 atmega1281 |
9 | JTAG config complete. |
10 | Preparing the target device for On Chip Debugging. |
11 | |
12 | Disabling lock bits: |
13 | LockBits -> 0xff |
14 | |
15 | Enabling on-chip debugging: |
16 | Extended Fuse byte -> 0xf5 |
17 | High Fuse byte -> 0x1d |
18 | Low Fuse byte -> 0xfd |
19 | 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.
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. :-(
Ich habe vorhin mal ausprobiert im avr-gdb die Baudrate umzuschalten, also über eine Konsolensession mit
1 | (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
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.
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
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ß.
@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
Hallo Leute, hatte gleiche Probleme. Sehr wahrscheinlich Lösung wurde hier beschrieben: http://www.mail-archive.com/avarice-user@lists.sourceforge.net/msg00010.html 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
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.
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.