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
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
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.
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.
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.
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
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
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...
@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
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
@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
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).
