mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Avr Studio 4 und die neue AVR Toolchain - So funktionierts!


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Andi R. (beefi)


Bewertung
8 lesenswert
nicht lesenswert
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
von Jörn P. (jonnyp)


Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die Hinweise ;-)

von Karl H. (kbuchegg) (Moderator)


Bewertung
0 lesenswert
nicht lesenswert
Hmm. Die einzige Frage ist jetzt nur, wohin mit diesem Tip, so dass er 
nicht verloren geht.

von Davis (Gast)


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

von Stefan W. (dl6dx)


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

von m.n. (Gast)


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

von Andi R. (beefi)


Bewertung
0 lesenswert
nicht lesenswert
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
von Jörg (Gast)


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

von m.n. (Gast)


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

von Andi R. (beefi)


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

von m.n. (Gast)


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

von Andi R. (beefi)


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

von m.n. (Gast)


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

von Michael D. (mike0815)


Angehängte Dateien:

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

von Chandler B. (chandler)


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

von P. F. (funkpurzel)


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

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.