Hi Leute, seit einer längeren Pause gibt's im Moment bei mir wieder ein AVR-Projekt. Ich gehöre jedoch zu den Leuten, die das AVR Studio 4 bevorzugen. Hier hab ich einfach alles was ich brauche und auch eine bessere Simulation als bei dem neuen Atmel Studio (vor allem mit HAPSIM). Nun gibt es ja als WinAVR-Nachfolger die AVR Toolchain. Hier gibt's jedoch Probleme mit dem AVR Studio (vor allem bei neueren Toolchains). Um einiges im Voraus zu klären: ------------------------------- - AVR Studio 4.18 + SP3 ist NICHT das gleiche wie AVR Studio 4.19! Die 4.19er ist aktueller und unterstützt auch aktuellere Controller. - Es ist in der Version 4.19 KEIN BUG, dass WinAVR nicht erkannt wird. 4.18 war für WinAVR ausgelegt, dieses wurde auch vom Studio erkannt. 4.18 + SP3 erkennt WinAVR UND die neue AVR Toolchain 4.19 erkennt mit Absicht nur noch die AVR Toolchain, WinAVR kann aber manuell angegeben werden...ist aber nicht mehr relevant. - Die AVR Toolchain ist eigentlich das gleiche wie WinAVR, nur dass es jetzt von Atmel selbst gepflegt wird...bzw der WinAVR-Typ jetzt für Atmel arbeitet, wie ich gelesen habe. Es wird nichts in der Toolchain eingebaut, was den Umgang mit AVR Studio 4 einschränkt bzw User aufs neue Atmel Studio zwingt. So, jetzt zum Problem: ---------------------- Programme, vor allem etwas umfangreichere machten im AVR Studio 4 Probleme beim Debuggen. Kompilieren ist kein Problem, jedoch ist kein Debuggen möglich. Mit steigender Version der AVR Toolchain häuften sich die Probleme immer mehr, so dass nur bei bestimmten Optimierungsstufen ein Debuggen/Simulation möglich war. Mit der aktuellen AVR Toolchain 3.4.2.1573 kann man eigentlich gar nichts mehr machen. Unter Windows 7 x64 stürzt AVR Studio einfach komplett mit einer MFC-Fehlermeldung ab...unter Windows 2000 erscheint eine Info "Error loading Objectfile Datei.elf". Es gibt die verrücktesten Gerüchte und Vermutungen im Internet was das betrifft. Auch viele Lösungvorschläge werden genannt, aber nichts funktioniert. Ich hab die Lösung, und wies aussieht als erster im WWW :D Lösung: ------- Es liegt ganz einfach am avr-gcc selbst. AVR Studio 4 benötigt zum debuggen das dwarf-2 Format...hiermit kann man angenehm seinen C-Code Simulieren. Man gehe im AVR Studio auf PROJECT -> CONFIGURATION OPTIONS -> CUSTOM OPTIONS. Hier unter [All Files] gibt man seine Flags an den Compiler an. Es steht hier im Normalfall "-gdwarf-2". Hiermit wird das Format Dwarf Version 2 erzeugt. Die GCC-Entwickler erlaubten sich aber ab einer bestimmten GCC-Version auch Erweiterungen aus den Versionen 3 und 4 mit einzubringen...das bracht dem AVR Studio 4 das Kreuz! Man muss ZUSÄTZLICH folgendes goldene Flag hinzufügen: -gstrict-dwarf So wird dem Compiler mitgeteilt, auch wirklich NUR die Dwarf Version zu nutzen, welche angegeben war (hier Version 2). Jetzt funktioniert AVR Studio 4 wieder absolut ohne Fehler mit der neuesten AVR Toolchain und auch mit den Kommenden ;) Rauf und runter debuggen in allen Optimierungsstufen kein Problem ;) Also Version 4.19 installieren + neueste Toolchain + goldenes Compiler-Flag unter FERTIG. Der einzige "Fehler" der eventuell noch auftreten könnte ist, wenn man zB mit der Optimierungsstufe -O0 Programmcode erzeugt, der größer als der Speicher im Chip ist...hier schlägt natürlich auch die Simulation fehl...das ist aber richtig so und kein Fehler (und war auch mit WinAVR schon so). So das war jetzt viel um den heißen Brei geredet, aber ich hoffe, dass dies vielen weiterhilft ;) Es wäre vielleicht gut, wenn man diesen Tip hier allgemein auf der Webseite unter Atmel Studio/AVR Studio in der Beschreibung erwähnt...am besten groß, dick und rot :) Gruß Andi
:
Bearbeitet durch User
Hmm. Die einzige Frage ist jetzt nur, wohin mit diesem Tip, so dass er nicht verloren geht.
Mit der aktuellen Toolchain und dem Studio 4.19 funktioniert es. Danke für dem Tipp Andi. --- Der Thread sollte nach GCC verschoben werden, dort sinkt er langsamer nach unten.
Karl Heinz schrieb: > Hmm. Die einzige Frage ist jetzt nur, wohin mit diesem Tip, so dass er > nicht verloren geht. Ich hab mal im Artikel http://www.mikrocontroller.net/articles/Atmel_Studio unter Tipps & Tricks einen Link zu diesem Thread eingetragen. Grüße Stefan
Vielen Dank für Deinen Erfahrungsbericht. Wie von Dir vorgeschlagen, habe ich die 4.19 Version samt aktueller Toolchain installiert. Ein kurzer Test mit einem kleinen Programm für den ATmega48 zeigt, dass der Code durch "-gstrict-dwarf" von 2340 auf 2390 Byte steigt. Da ich nie den Debugger/Simulator verwende, lasse ich diese Option doch lieber weg. Bei den µCs mit wenig Programmspeicher könnten diese Bytes entscheidend dafür sein, ob das Programm noch in den knappen Speicher paßt.
Das ist komisch...dieser Parameter hat eigentlich gar nichts mit dem Programm zu tun und beeinflusst nur die ELF-Datei. Ich habs bei mir gerade probiert, ein einfaches Programm mit den LCD-Routinen hier aus dem Forum hat nicht-optimiert 6860 Bytes und Speicher-Optimiert 450 Bytes. Und es ändert sich absolut nichts dran, wenn ich mit oder ohne -gstrict-dwarf kompiliere. Wenn du gar nicht Debuggst, dann empfehle ich dir mal, CodeBlocks zu verwenden. Warum ich AVR Studio 4 benutze, liegt eigentlich nur an der mächtigen Debug-Funktion bzw. Simulation. Als ich Atmel Studio 6 ne Zeit lang verwendete, hab ich das Programm ständig in die Testplatine geladen und live getestet, weil der Simulator einfach nicht zu gebrauchen ist. Wenn man dazu noch HAPSIM 2.20 benutzt, kann man sogar direkt Taster, LEDs, Displays usw. Simulieren. Das alles funktioniert simuliert als wäre es auf der Testplatine. Bei CodeBlocks hast du halt den Vorteil, dass du Unterstützung beim Code-Schreiben hast...ähnlich wie IntelliSense vom Visual Studio. Wenn du ein CodeBlocks-Nightly nimmst (was zu empfehlen ist) musst du es nicht mal installieren. Das ist ja auch noch so ein Knackpunkt bei Atmel Studio 6...es ist ja schon unangenehm, dass mein Visual Studio 2012 so viel installiert und der PC langsamer startet, wenn da noch das Visual Studio 2010 (wegen Atmel) dazu kommt, hatte ich schon ein paar mal Probleme. Achja, ich habe mal vor kurzem alle Toolchains durchinstalliert, die alten bzw die erste Toolchain die nach WinAVR kam, erzeugte den kleinsten Code...der mit WinAVR war auch so bzw noch etwas kleiner. Mit den Toolchains danach stieg die Programmgröße und ist jetzt wieder etwas kleiner geworden. Also was ich damit sagen will ist, dass du mit einer alten Toolchain oder sogar noch WinAVR kleineren Code erzeugen kannst. Dafür hast halt andere Nachteile. Vielleicht hast du deine Programmgröße auch mit Atmel Studio 6 verglichen...das Studio 6 hat nämlich ne ältere Toolchain ;)
:
Bearbeitet durch User
Andi R. schrieb: > Warum ich AVR Studio 4 benutze, liegt eigentlich nur an der > mächtigen Debug-Funktion bzw. Simulation. Jap, so ist es, leider ist in Studio 4 z.B. keine Unterstützung für den JTAGICE3 ;-( und somit muss man auf dem klein und schönes Debugger verzichten.
Andi R. schrieb: > Das ist komisch...dieser Parameter hat eigentlich gar nichts mit dem > Programm zu tun und beeinflusst nur die ELF-Datei. Stimmt! Noch einmal getestet und die Größe bleibt unverändert. Wenn es mich nicht irritiert hätte, hätte ich ja nichts geschrieben. Weiß der Henker, was da passiert ist. So haben wir zumindest den schönen Beitrag wieder nach oben geschoben :-) Jörg schrieb: > Jap, so ist es, leider ist in Studio 4 z.B. keine Unterstützung für den > JTAGICE3 ;-( und somit muss man auf dem klein und schönes Debugger > verzichten. Ich muß mal ganz naiv fragen: Wozu braucht man bei den kleinen Teilen einen Debugger? Ab und zu mal das Ass.-Listing ansehen, ist ja in Ordnung. Testweise hatte ich auch mal einen 'Dragon' zum Debuggen probiert, aber keinen tieferen Zweck erkennen können. Bei 32 Bittern (STM32F4.., RX...) kann ich es nachvollziehen. Da ist es sehr angenehm bei laufendem Programm IO-Register anzupassen, um die Funktion der einzelnen Bits zu ergründen.
> Weiß der Henker, was da passiert ist. Vielleicht beim Hinzufügen des Parameters nicht auf Add gedrückt, sondern gleich auf Ok...dann wird er nicht in die Liste übernommen. Aber dann dürfte sich ja auch nichts verändert haben :D > Ich muß mal ganz naiv fragen: Wozu braucht man bei den kleinen Teilen > einen Debugger? Also ich Debugge nur mit Simulator. Der Grund bei mir ist die Bequemlichkeit. Nehmen wir an, man möchte einen Frequenzzähler basteln. Eine Frequenz geht auf einen Interrupt-Eingang welcher als Routine die Zählervariable eines Hardware-Timers Resettet. Aus dieser Periodenzeit wird die Frequenz berechnet und auf einem Display ausgegeben. Wenn du das einfach so hinschreibst und auf den Chip spielst, dann geht erstmal die Sucherei los, warum dir bei 100 kHz eine Frequenz von zb 134 kHz angezeigt wird :D Dann wird hier und dort geguckt und gespielt und immer wieder auf den Chip gebrannt. Dazu kommt ja auch noch, dass du einen extra Versuchsaufbau machen musst...bei mir die zwei Pollin-Boards "AVR Evaluation Board" + "AVR Add-on Board" + einen Frequenzgenerator und evtl noch Oszilloskop. Im Simulator siehst du alles schon gleich von Anfang an, wie das Programm funktioniert. Du kannst ja absolut jeden Programmschritt nachvollziehen und siehst auch die exakte Zeit, die der Controller dafür braucht (diese Funktion hab ich im Atmel Studio 6 ganz vermisst). So erkennst du gleich, die Grenzen des Chips/Programms. Ne Frequenz kannst ja per Stimuli in den Simulator führen. So kannst du gemütlich auf der Couch oder sonst wo programmieren und testen...den Versuchsaufbau gibt's dann noch am Schluss zum Endtest "jo passt" :D Auch wenn du Code-Optimierungen des Compilers nutzt (was man eigentlich immer muss), so siehst du direkt die Auswirkungen, was verändert wird. Debuggest du nicht, wunderst dich vielleicht irgendwann, warum der Controller jetzt nicht dies und das macht :) Für mich ist der Simulator im Studio 4 Gold wert. Ich frage mich jedoch, für was man dann wieder diese JTAG-Dinger braucht :) Damit hab ich noch nie was gemacht und wüsste auch nicht, was die mir noch mehr dazu bringen :)
Andi R. schrieb: > Im Simulator siehst du alles schon gleich von Anfang an, wie das > Programm funktioniert. Da wollte ich Deinen Worten mal meine Taten folgen lassen, und habe als Debugging-Plattform 'AVR Simulator' und 'AVR Simulator 2' probiert: AVR Studio stürzt ab, irgendetwas mit MFC ... Wenn ich mir das Fenster genauer ansehe, sehe ich unter "select device and debug platform' selbst nach Update auf 4.19 noch die Version 4.18.716. Da meine Leidensfähigkeit sehr begrenzt ist, verichte ich auf weitere Versuche. Andi R. schrieb: > So kannst du gemütlich auf der Couch oder sonst wo programmieren und > testen...den Versuchsaufbau gibt's dann noch am Schluss zum Endtest "jo > passt" :D Ich kenn das ja von der werten Kundschaft: die Hardware ist noch nicht einmal vorhanden (z.B. Meßautomat), aber ich könnte ja schon mal mit der Programmierung beginnen. Meine Erfahrung dazu: bevor nicht eine ordentliche Hardware auf meinem Tisch steht, rühre ich keinen Finger :-)
> Da wollte ich Deinen Worten mal meine Taten folgen lassen, und habe als > Debugging-Plattform 'AVR Simulator' und 'AVR Simulator 2' probiert: AVR > Studio stürzt ab, irgendetwas mit MFC ... Genau, diese Fehlermeldung kommt zB unter Windows 7 wenn der Parameter fehlt. Dass es sicher an der ELF-Datei liegt, konnte ich nur feststellen, da in einer virtuellen Maschine unter Windows 2000 eine andere Meldung kommt "Error loading Object .elf". Windows 7 stürzt hier irgendwie komplett mit einer MFC-Fehlermeldung ab. Es muss wirklich so sein, dass du den Parameter nicht richtig hinzugefügt hast. In den Optionen unter "Custom Compilation Options" muss [All Files] selektiert sein. Dann musst du in der Zeile neben dem Add-Button "-gstrict-dwarf" eingeben und unbedingt danach den Add-Button drücken! Nicht einfach auf OK klicken! Erst wenn "-gstrict-dwarf" in der Liste steht, darfst du mit OK bestätigen. "-gdwarf-2" muss ebenfalls drinstehen. Hier meine Liste als Beispiel: -Wall -gdwarf-2 -std=gnu99 -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -gstrict-dwarf > Wenn ich mir das Fenster genauer ansehe, sehe ich unter "select device > and debug platform' selbst nach Update auf 4.19 noch die Version > 4.18.716. Ja, diese Versionsangabe könnte unter anderem zur Verwirrung geführt haben. Auf der Atmel-Seite war aber angegeben, welche Neuerungen in der Version 4.19 im Vergleich zur Vorversion (auch SP3) enthalten sind. Unter anderem waren dies auch mehr Controller. Ich bin darauf durch ein Englischsprachiges Forum gekommen, hier wurde dieser Fall aufgeklärt.
Andi R. schrieb: > In den Optionen unter "Custom Compilation Options" muss [All Files] > selektiert sein. Dann musst du in der Zeile neben dem Add-Button > "-gstrict-dwarf" eingeben und unbedingt danach den Add-Button drücken! > Nicht einfach auf OK klicken! Das hatte ich schon so gemacht. Allerdings war gestern wohl nicht mein Tag; es waren zuviele Rechner gleichzeitig eingeschaltet. Wenn Du mich nicht auf den Simulator gestuppst hättest, hätte ich diese dicke Wanze überhaupt nicht bemerkt :-) Jetzt läuft der Simulator auch bei mir, obwohl ich ihn eher als eine Spielerei sehe. Software schreibe ich immer so, dass ich auf dem Zielsystem jeden Schritt testen kann. Gerade bei diesen Controllern, wo viele Zustände von äußeren Signalen abhängen, bringt mir eine Simulation garnichts. Anders mag es für Jemanden sein, der noch keinerlei Erfahrung mit µCs hat. Für ihn ist es sehr wichtig, die interne Funktion eines AVRs kennenzulernen. Um auf Dein obiges Beispiel für den Nutzen eines Simulators zu kommen: sobald ein LCD am Controller hängt, lasse ich mir bei Bedarf Zwischenwerte anzeigen. Über die UART kann man an passenden Stellen ein einzelnes Zeichen ausgeben lassen. Alternativ lasse ich einen Portpin signalisieren, wo das Programm langläuft und sehe mir Funktion und Timing auf einem Scope an, wie man es in der Steinzeit gelernt hat :-) Einen schönen Sonntag!
Angehängte Dateien:
Nabend... vielleicht sollte man noch erwähnen, das das Flag "-gstrict-dwarf" nicht hinzugefügt werden kann, wenn ein "externes Makefile" benutzt/angegeben wird. Siehe Screenshot! Des weiteren habe ich gerade das Studio4.19 inkl. aktuelle Toolchain neu installiert. Unter Info wird auch die korrekte Version angezeigt. Gruß Michael
Hallo, ich habe da noch einmal eine Frage. Bei mir ist das Programm beim debuggen immer abgestürzt und mir wurde diese Seite genannt. Jetzt habe ich -gstrict-dwarf bei All Files eingefügt (zuerst Add und dann OK). trotzdem Stürzt das Programm immer mit der Meldung: "AVRStudio MFC Application funktioniert nicht mehr" ab. woran könnte das noch liegen? Chandler
Hallo, Andi, Ich habe deinen Post gelesen und versucht, AVRStudio 4.19 installiert und das goldene Flag implementiert. Leider stürzt AVRStudio immer noch beim Versuch zu Debuggen ab. Ich habe versucht, das Problem einzukreisen und habe den Verdacht, dass dieses mit einer früheren Installation von AVRStudio 6 zusammen hängt. Diese habe ich zwar längst wieder einstalliert aber es befinden sich wohl Überreste davon auf dem Rechner. AVRStudio 4.18 SP3 funktioniert. Wie machst du es, AVRStudio 4 und 6 parallel auf dem Rechner zu haben??
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.