Welche AVR Toolchain ist unter Linux zu bevorzugen ? Es gibt einmal die bei der Distribution enthalten ist und nachinstalliert werden kann. Z.B. mit: sudo apt-get install gcc-avr binutils-avr gdb-avr avr-libc avrdude Und zum anderen gibt es eine von Atmel gepflegte. http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORLINUX.aspx In Tutorials wird manchmal darauf hingewiesen, daß die Toolchain aus den Distributionen oft veraltet sind oder falsch kompiliert wurden. Aber trotzdem wird in fast allen Beispielen die Toolchain aus der Distribution genommen. Nirgendwo habe ich bis jetzt eine klare Empfehlung für die Atmel Toolchain gefunden und bin deswegen etwas verwirrt. Oder sind bei aktuellen Linux Versionen die Toolchains ok?
Mit den Paketen aus der Distribution (debian) hatte ich nie Probleme. Das ist dann auch am einfachsten. Davon abweichen würde ich nur, wenn ich gezielt eine neuere Version brauche. Ob dann die Atmel neu genug ist, müsste man im Einzelfall sehen.
Hi, ich verwende auch die Mint (bzw. Ubuntu) eigene Toolchain. Mich würde aber auch mal interessieren was die Unterschiede zur Atmel Toolchain sind. Um. z.B. den Attiny10 programmieren zu können, mußte ich den avra patchen (Rolf Pfister patches), da avra seit 2010 nicht mehr gepflegt wird. Hat da jemand Erfahrungen mit gcc bzw. avra? Gruß Andreas
Andreas B. schrieb: > Um. z.B. den Attiny10 programmieren zu können, mußte ich den avra > patchen (Rolf Pfister patches), da avra seit 2010 nicht mehr gepflegt > wird. > > Hat da jemand Erfahrungen mit gcc bzw. avra? Hallo Andreas, ich verwende fast immer avra oder gcc. Läuft bisher ohne Probleme – auch mit dem "Floh" ATtiny10. Welchen Patch musstest du denn installieren, und warum? Meine Toolchain: Assembler: avra (http://avra.sourceforge.net/) C: gcc (normalerweise die einfache Variante "C ohne Makefile") Übertragen: avrdude
Hallo Markus, so ähnlich mache ich das auch, eben nur mit dem patch für avra. (allerdings mit make file und Kate als Editor) Es sind Anpassungen für den neuen Tiny10. (vor ca. 5 Jahren gab es ja schon mal einen anderen) Hier bin ich drübergestolpert: http://www.rolfp.ch/elektronik/#tiny10 Vermisst habe ich bis jetzt nichts. Ich wollte nur mal wissen, was ich bei der Atmel Toolchain versäume. ;-) Gruß Andreas
Andreas B. schrieb: > http://www.rolfp.ch/elektronik/#tiny10 Danke für den Link! Mir war das Problem gar nicht aufgefallen, weil ich das SRAM des ATtiny10 bisher nicht verwendet hab. Mir haben die 16 Register gereicht. :-) > Vermisst habe ich bis jetzt nichts. Ich wollte nur mal wissen, was ich > bei der Atmel Toolchain versäume. ;-) Die Frage kann ich leider auch nicht beantworten. Ab und zu bereite ich Projekte auch für Windows vor (z.B. gulostart), dort verwende ich dann aber auch avra und WinAVR, was letztlich ja wieder die freie gcc-Toolchain ist. Vermisst habe ich bisher auch nichts...
Hallo, ich kompiliere mir den aktuellen avr-gcc (z. Z. gcc-4.9) immer für Linux und Windows (mingw) selbst. Funktioniert hervorragend. Die neuen Compiler mit LTO (LinkTimeOptimization) erzeugen viel kleinere Binaries. Ob das aber für die Tinys relevant ist, kann ich nicht sagen. Wenn jemand Interesse hat, könnte ich die Scripte auch veröffentlichen. Gruß Olaf
:
Bearbeitet durch User
Andreas B. schrieb: > Mich würde aber auch mal interessieren was die Unterschiede zur Atmel > Toolchain sind. Da müsstest du dir die Patches von Atmel ansehen. Im Wesentlichen ist es das Hinzufügen neuer MCU-Typen, und natürlich dann dieser nach wie vor wohl nur halbgare Support von ATtiny10 &c. im Compiler selbst.
Olaf Dreyer schrieb: > Hallo, > > ich kompiliere mir den aktuellen avr-gcc (z. Z. gcc-4.9) immer für Linux > und Windows (mingw) selbst. Funktioniert hervorragend. > Die neuen Compiler mit LTO (LinkTimeOptimization) erzeugen viel kleinere > Binaries. Ob das aber für die Tinys relevant ist, kann ich nicht sagen. > > Wenn jemand Interesse hat, könnte ich die Scripte auch veröffentlichen. > > Gruß > > Olaf Update: Ich konnte den avr-gcc-5.1.0 sowohl für Linux als auch für Windows übersetzen. Das Link-Problem dass seit Oktober im gcc enthalten ist, konnte ich patchen. Gruß Olaf
> In Tutorials wird manchmal darauf hingewiesen, daß die Toolchain > aus den Distributionen oft veraltet sind oder falsch kompiliert wurden. Ich hatte dieses Problem (seit >10 Jahren) noch nie. Stattdessen bin ich mehrfach bei einzelnen Versionen von Atmels Toolchain (unter Windows) auf Probleme gestoßen. Ich nutze zur Zeit Ubuntu 14.04.
Olaf Dreyer schrieb: > ich kompiliere mir den aktuellen avr-gcc (z. Z. gcc-4.9) immer für Linux > und Windows (mingw) selbst. Funktioniert hervorragend. > Wenn jemand Interesse hat, könnte ich die Scripte auch veröffentlichen. Mich würden Anpassungen/Änderungen besonders für mingw interessieren. Seit den (für mich gelösten) Problemen mit 4.8 hab ich nicht mehr versucht eine aktuellere Version zu kompilieren. http://embdev.net/topic/332088#3643746
Hi Batchman, ich erzeuge den WinAVR gcc mittels einer mingw-Installation von hier: http://www.drangon.org/mingw/ Diese befindet sich unter (Linux) in /opt/uC/i686-w64-mingw32-gcc-4.8.3-binutils-2.24.0 Dann starte ich aus dem angehängten Archiv das Script install-toolchain.sh mehrfach für verschiedene Pakete: ./install-toolchain.sh avr /opt/uC/avr-gcc-5.1.0-binutils-2.25-win32 binutils canadian ./install-toolchain.sh avr /opt/uC/avr-gcc-5.1.0-binutils-2.25-win32 minimal-gcc canadian ./install-toolchain.sh avr /opt/uC/avr-gcc-5.1.0-binutils-2.25-win32 libc canadian ./install-toolchain.sh avr /opt/uC/avr-gcc-5.1.0-binutils-2.25-win32 gcc canadian ./install-toolchain.sh avr /opt/uC/avr-gcc-5.1.0-binutils-2.25-win32 gdb canadian ./install-toolchain.sh avr /opt/uC/avr-gcc-5.1.0-binutils-2.25-win32 avrdude canadian ./install-toolchain.sh avr /opt/uC/avr-gcc-5.1.0-binutils-2.25-win32 clean canadian Das ganze lädt die Sourcen der verwendeten Pakete herunter und erzeugt einen unter Windows lauffähigen AVR Compiler. Lässt man den Parameter canadian weg, bekommt man einen unter Linux lauffähigen AVR Compiler. Gruß Olaf
:
Bearbeitet durch User
Ah, du verwendest mingw also direkt unter Linux. Werde ich mir einmal genauer anschauen, wobei ich dafür allerdings keine 64-Bit Hardware zur Hand habe. Ist aber für mich eine weitere Motivation mir einmal eine für die alten Rechner passende Version zu suchen. Danke jedenfalls für das Aufzeigen dieser Möglichkeit.
Hi, die mingw Variante "i686-w64-mingw32" ist für 32Bit (i686). Es gibt aber auch eine 64Bit Variante "x86_64-w64-mingw32". Ich hatte halt keine Lust für meine Kunden (die meisten haben kein Linux) zwei unterschiedliche Compiler anzubieten. Da muss 32Bit genügen ;-) Gruß Olaf
Jörg Wunsch schrieb: > halbgare Support von ATtiny10 &c. im Compiler selbst. Den Support gibt's auch ganz "offiziell" in der aktuellen Version. Aufgrund der eher limitierten Hardware aber nicht wirklich testbar, und z.B. avrtest unterstützt den auch nicht. Inwieweit der Support bei GNU dem von Atmel entspricht weiß ich net; Atmel trägt da nicht wirklich zeitnah bei. Wozu sind eigentlich die neuen Attrubute gut? Atmel hat die miese Angewohnheit, neue Features wie Attribute oder Optionen nicht zu dokumentieren und immer wieder mal Ostereier zu verstecken.
:
Bearbeitet durch User
Johann L. schrieb: > Wozu sind eigentlich die neuen Attrubute gut? Frag' mich mal was Leichteres. :/ Ich bin nicht mehr dort, aber selbst zu Zeiten, als ich das noch war: die Jungs in Indien, die das jetzt alles machen (müssen), sind so weit weg von hier, dass man da kaum einen Draht hin bekommt. Am meisten präsent sind noch die, die auch in der avr-libc aktiv sind. Die kannst du da sicher fragen und auch auf die fehlende Doku hinweisen.
Jörg Wunsch schrieb: > Johann L. schrieb: >> Wozu sind eigentlich die neuen Attrubute gut? > > Frag' mich mal was Leichteres. :/ hmmm... als ich das Zeug in des Quellen sah, hab ich mal ein bisschen mit rumgespielt um zu sehen, was das so macht. Nach 1/2 Minuten hatte ich einen Internal Compiler Error — wie für den ATtiny auch. Letzterer ließ sich einfach beheben: 50 Atmel-Zeilen raus, 1 GNU-Zeile rein :-) Aber wenn irgendwas nicht spezifiziert, nicht dokumentiert, und in den Quellen auch nicht kommentiert ist, und einem das Zeug nach 1 Minute schon um die Ohren fliegt, wird's mit der Deutung schon arg schwer... > die Jungs in Indien, die das jetzt alles machen (müssen), sind > so weit weg von hier, dass man da kaum einen Draht hin bekommt. Immerhin scheinen die inzwischen langsamer zu wechseln, als man sich die Namen merken kann :o)
Johann L. schrieb: > Aber wenn irgendwas nicht spezifiziert, nicht dokumentiert, und in den > Quellen auch nicht kommentiert ist, [...] “An undocumented feature is called a bug.” (Autor unbekannt) >> die Jungs in Indien, die das jetzt alles machen (müssen), sind >> so weit weg von hier, dass man da kaum einen Draht hin bekommt. > > Immerhin scheinen die inzwischen langsamer zu wechseln, als man sich die > Namen merken kann :o) Was man durchaus als Vorteil betrachten kann. Ja, die Fluktuation dort ist eins der grundlegenden Probleme, wenn man versucht, die Bewältigung der Aufgaben dahin zu verlagern.
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.