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