www.mikrocontroller.net

Forum: Compiler & IDEs Verwirrung mit avr-gcc-Versionen


Autor: Sebastian Fahrner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hab mir mal verschiedene Threads in diesem Forum durchgelesen und 
bin etwas verwirrt, was neue Versionen von avr-gcc angeht.

Also, ich benutze bisher die AVR-Freaks-Distribution V3.0.2, und würde 
nur ungern etwas daran ändern, weil es problemlos klappt (never change a 
running system).
Allerdings möchte ich bald eine ATMega8 einsetzen, und habe gelesen, daß 
V3.0.2 diesen nicht unterstützt, da er wohl SFRs hat, die außerhalb des 
outp()/inp()-Speichers liegen.

Die AVR-Version 3.2 ist "experimental" und WinAVR scheint auf den ersten 
Blick wieder etwas anderes zu sein?!

Daher meine Frage:
Lohnt es sich, die Mühe zu machen, und auf ein neuere Version als 3.0.2 
zu wechseln?
Oder sollte ich mir ein Headerfile für den ATMega8 schreiben und die 
inkompatiblen SFRs "von Hand" ansprechen?

Danke,

Sebastian

Autor: Sebastian Fahrner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ups, Korrektur: Habe gerade nochmal ins Datenblatt vom Mega8 geschaut 
und gesehen, daß der gar keine SFRs im Bereich über 3fh hat. Dann dürfte 
der ja gar kein Problem für 3.0.2 sein... (hab den Compiler gerade nicht 
da und weiß es daher nicht, SORRY).

Grüße,

Sebastian

Autor: Peter Fleury (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vergiss die alten Versionen 3.0.2 und Avrfreaks 3.2, WinAVR ist nichts 
anderes als avr-gcc 3.3

AVRfreaks Version ist veraltet und wird nicht mehr weiter entwickelt.

Steige auf WInAVR 3.3 um, dann hast Unterstützung vom ATmega8 und andere 
neue ATmega.

Autor: made in germany (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
never change a running system = verändere nie ein bereits laufendes 
System!

Autor: BAB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo made in germany,

wenn du die unterschiede zwischen den gcc compilern kennen würdest, 
hättest du dir deinen post gespart.

hallo sebastian,

wie peter schon sagte steig auf die winavr version um die ist die 
aktuellste version. die avr version ist zu veraltet.
also es lohnt sich wirklich umzusteigen.

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Außerdem hat WinAVR den Vorteil, daß es endlich auch mit
Dokumentation erscheint.  Wir wollen die doch schließlich
nicht für die Katz' geschrieben haben...  Und nein, es
genügt auch nicht, die aktuelle Doku zu nutzen und dann
Vogel Strauß zu spielen (``never change...''), es hat sich
durchaus einiges geändert in den letzten Jahren.

Autor: Sebastian Fahrner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also die Tatsache, daß man kein "outp()" mehr benötigt, finde ich 
wirklich sehr positiv. Ich programmiere im Geschäft mit IAR-C für 
MSP430, und da ist das ja genauso - muß ich weniger umdenken.
Aber es ist nunmal so, daß ich mich mit diesen Sachen wie "make" etc. 
nicht auskenne (und auch nicht Zeit habe, mich einzuarbeiten). Deswegen 
bin ich froh, wenn es einmal läuft und laß dann am liebsten ganz die 
Finger davon.

Grüße,

Sebastian

Autor: Notker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich arbeite nach wie vor mit der 3.02. Diese ominöse 
"Experimentalversion" 3.20 habe ich genau so schnell wieder von meiner 
Festplatte heruntergeschmissen, wie ich sie installiert hatte, da sie 
meiner Meinung nach Schrott ist. In einer früheren Diskussion hier in 
diesem Forum ist sogar herausgekommen, dass diese Version bei gewissen 
Statements weitaus uneffektiveren Code produziert als die 3.02!!!
Was die 3.3er Version (WinAVR) betrifft, habe ich von anderen Leuten 
ähnliche Erfahrungen gehört (Originalkommentar: total buggy!).
Diese "Novitäten" der neueren Versionen wie z.B. outp -> outb usw. sind 
alles bloss Makros, die kann man sich in einem Headerfile selbst machen.

Fazit: Solange ich von den neueren Versionen keine wirklich 
überzeugenden Argumente mehr höre, bleibt bei mir die 3.02 installiert, 
ganz getreu dem Motto meines Forum-Diskussions-Kontrahenten Peter 
Dannegger ;-)
"never change a runnig team!"
Notker

Autor: Notker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder hiess es "never change a winning team"???

Man könnte aber auch sagen, an einem Moped das gut läuft, schraubt man 
nicht herum.

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mach was Du denkst, aber Du irrst, wenn Du meinst, daß Du
Dir die neuen IO-Macros auf einen alten Compiler gestopft
bekommst.

Der gcc 3 erzeugt keineswegs schlechteren Code als die 2.x,
nur wenn man trottligerweise alles mit -O3 übersetzt, bekommt
man die Quittung in Form von massenhaft inline functions.
Optimiert?  Ja.  Aber für kürzere Laufzeit. ;-)  Wer für
kurze Codegrößen optimieren will, nehme halt -O1 oder -Os.

WinAVR ist nicht mehr buggy als all seine Vorgänger.  Was
daran noch buggy ist, ist der Wandler von ELF nach AVR-COFF,
aber der war vorher nur anders buggy.  Die Leute, die
derartige ,,Original''kommentare verfassen sind oft die, die
sich nichtmal das README durchlesen können und dann z. B.
darüber stolpern, daß sie mit der WinAVR-Version infolge
falschen %PATH% noch den alten, nach wie vor installierten
Compiler aufrufen...

Autor: BernhardT (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Notger Solange ich von den neueren Versionen keine wirklich 
überzeugenden Argumente mehr höre...
Ich glaub ab 3.2 werden die Hardwaremultiplier der Mega-Typen 
unterstützt. Es ist erstaunlich was der Mul-Befehl an Zeit und Code 
Einsparung , nicht nur bei Integerarithmetik, bring.
Gruß Bernhard

Autor: Notker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na schön, ich lasse mich auch gerne überzeugen. Bin mal gespannt, ob 
dieser WinAVR bei mir länger überlebt als die "Experimentalversion" von 
AVRfreaks.

Wehe ihr hattet nicht Recht, dann kommen aber die Jungs mit den 
schwarzen Sonnenbrillen ;-)

Gruss,

Notker

Autor: BAB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Notker:

ich bin genau so skeptisch gewesen wie du..:)..
ich wusste auch erst nicht was der ganze kram soll...
wieso eine neue version rausbringen und nicht die alte weiter 
entwickeln...um diese missverständnisse aus dem weg zu schaffen hab ich 
mir die erste winavr version erstmal gezogen und installiert...
nach ca. 10min hatte ich schon eins meiner grösseren projekte auf die 
winavr version umgestellt und dass ohne probleme...ich war sehr positiv 
überrascht...als nächstes bin ich dann über die geniale doku 
gestossen...
und schon war die avr freaks variante dem abschuss nahe..:)...dann noch 
dieses memory i/o map verfahren ist auch super genial...somit kann man 
sehr übersichtlichen code schreiben...ich könnte jetzt noch einige 
andere sachen aufzählen aber das könnt ihr alles in der doku nachlesen..
das einzige problem ist dieses objtool...man kann leider keine 
structuren und diverse andere sachen debuggen...
ich bin aber gerade dabei mich in den aufbau von coff und elf einzulesen 
und objtool weiter zu entwickeln...

MfG
BAB

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, warum die bisherigen Windows-Distributionen
(insbesondere die von AVRfreaks) nicht mehr weiterentwickelt
worden sind, mußt Du diejenigen fragen, die diese zusammen-
gestellt haben.  Wahrscheinlich Zeitmangel.

WinAVR ist aus der Frustration über diesen Zustand entstanden.

Vergiß objtool.  Es ist letztlich das Fahrrad zum 5. Mal
erfunden.  Der sinnvollste Ansatz erscheint mir ringsum,
daß man objcopy (bei uns avr-objcopy genannt) so weit
aufbohrt, daß es mit den AVR-typischen Formaten umgehen
kann.  Dabei gibt es zwei Formate, die prinzipiell in Frage
kommen: das sogenannte `Nordic object format', dafür gab es
früher mal einen Patch für die binutils, der auf die aktuelle
Version nicht mehr ganz paßt.  Habe das Ganze zum Laufen
bekommen, aber das Format scheint nicht ganz unproblematisch
(es ist auch nicht offiziell dokumentiert von Atmel),
jedenfalls werden Dateien von AVRstudio 3.x abgelehnt, die
4.x dann doch ordentlich lädt...

Das zweite ist halt COFF.  Kommt aus der Unix-Welt, und die
AVR-Version ist in der Tat stark daran angelehnt.  Insofern
ist es auch nicht allzu schwer, den binutils das noch
beizubringen.  Nur: was mir wie ein gültiges COFF-File
aussieht, wird von AVRstudio mit "Memory size error" oder
sowas abgelehnt.  Ziemlich unverständlich, da das COFF-File
selbst gar nichts über eine Speichergröße weiß...  Der
zweite Haken ist, daß beim Übergang von ELF auf COFF in
den binutils bislang die Zeilennummerninformationen
verlustig gehen, da beide Formate hier ziemlich verschiedene
Modelle benutzen (ELF speichert sie in der Symboltabelle,
während COFF sie pro section mit anhängt).  Da ist ein
bissel Arbeit vonnöten.

Wie gesagt, wenn Dich das interessiert, dann kannst Du Dich
gern in einer privaten Mail mit mir in Verbindung setzen.
Ich suche vor allem Leute, die das dann auch auf Windows
bauen & testen können -- ich habe nur Unix und maximal
AVRstudio 3.56 unter Wine (aber die Emulation scheint da
zusätzliche Stolperfallen zu bringen).

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.