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.
never change a running system = verändere nie ein bereits laufendes System!
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
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.
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).
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.