Guten tag, ich versuche gerade nach dieser Anleitung
http://www.system-maker.de/pdfdocus/avrlinux.pdf das Programmieren und
Flashen unter Linux mit zu ermöglichen. Jedoch scheitere ich schon
daran, dass ich die Toolchain für Linux von Atmel erst garnicht
herunterladen kann. Unter
http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORLINUX.aspx habe ich die
Daten in die Form eingetragen, habe erfolgreich den Link bekommen, aber
wenn ich dann zu dieser Seite weitergeleitet werde, kommt die Meldung
Acces Denied. Also habe ich kein Zugriff auf den Server? Gibt es noch
andere Quellen, die diese Toolchain anbieten, oder was mache ich falsch
?
lg
Als Erstes brauchst du die 4 folgenden Pakete:
gcc-avr
avr-binutils
avr-libc
avrdude
Am einfachsten installierst du sie aus deiner Linux-Distribution mit dem
entsprechenden Installer (z.B. "apt-get install gcc-avr" in Debian)
Damit kannst du bereits auf Kommandozeilenebene kopilieren und "brennen"
Wenn du mit makefiles kein Problem hast:
http://wiki.ubuntuusers.de/avr
Auch wenn manchen das klicki-bunti einer IDE lieber ist, favorisiere ich
immer noch diese Lösung..
jojo schrieb:> http://www.ladyada.net/learn/avr/setup-unix.html
Hmm. Interessant. Aber warum compilieren die alles von Hand? Gerade
Ubuntu liefert avr-gcc & Co doch schon als fertige Pakete. So lange man
nicht eine neuere Version braucht (die fertigen Packages sind oft gut
... abgehangen) muß man einen Einsteiger ja nicht gleich mit autoconf
konfrontieren.
XL
Axel Schwenke schrieb:> Aber warum compilieren die alles von Hand? Gerade> Ubuntu liefert avr-gcc & Co doch schon als fertige Pakete.
Weil oft die mitgelieferten Pakete uralt sind.
Diese enthalten dann entwender unangenehme Bugs ("can not spill register
...") oder untestuetzten nicht neuere AVRs. (Oder beides ;-) )
MfG
Stephan B. schrieb:> Axel Schwenke schrieb:>> Aber warum compilieren die alles von Hand? Gerade>> Ubuntu liefert avr-gcc & Co doch schon als fertige Pakete.>> Weil oft die mitgelieferten Pakete uralt sind.> Diese enthalten dann entwender unangenehme Bugs ("can not spill register> ...") oder untestuetzten nicht neuere AVRs. (Oder beides ;-) )
Ich halte deine Behauptung für reichlich übertrieben. Kannst du mal
Butter bei die Fische tun?
Das aktuelle Ubuntu 13.04 (Raring) bringt den avr-gcc 4.7.2 mit. Die
letzte LTS (12.04 aka Precise) immerhin 4.5.3. Welchen relevanten Bug
oder welches fehlende Feature in diesen Versionen kannst du konkret
benennen?
Und komm jetzt nicht mit Ubuntu von vor 5 Jahren. Distributionsupgrades
sind bei Ubuntu relativ schmerzfrei. Auf jeden Fall deutlich
anfängertauglicher als die Toolchain alle 2 Wochen [1] neu aus den
Quellen zu bauen und dann am Paketmanagement vorbei nach /usr/local zu
installieren.
XL
[1] oder alle 4 Wochen. Auf jeden Fall regelmäßig. Denn sonst würdest du
ja eine veraltete Version verwenden und könntest dann auch gleich bei
den Paketen der Distribution bleiben. Nicht zu vergessen, daß
Distributionen ja auch mal Pakete updaten. Dein selbstinstalliertes Zeug
allerdings nicht. Da mußt du dich schon selber kümmern.
Axel Schwenke schrieb:> Ich halte deine Behauptung für reichlich übertrieben.
Hallo. Nur kurz, da ich mich echt nicht an diese Lapalie aufhalten will.
Dein Ubuntu schein schon ziemlich aktuell zu sein, original Debian
Nutzer sind da weniger gluecklich...
Zunaechst aber habe ich "oft" geschrieben - glaube aber das es auch auf
deine genannten Beispiele zutrifft.
Die Toolchain um den gcc 4.5XX duerfte die mesiten XMEGAs (mit USB
Transceiver) noch nicht unterstuetzen.
Desweiteren ist im gcc 4.7.X ein BUG bei der Codegroessenoptimierung
(-Os ) enthalten, der z.T. eine Codeuebersetzung unmoeglich macht.
Beispiel dafuer hab ich jetzt nicht unmittelbar auf der Hand - das
muesste ich erst auskramen.
MfG
Axel Schwenke schrieb:> Die letzte LTS (12.04 aka Precise) immerhin 4.5.3. Welchen relevanten> Bug oder welches fehlende Feature in diesen Versionen kannst du konkret> benennen?
Features auf jeden Fall. Es gibt extrem viele Dinge, die erst seit 4.7
dabei sind, weil das die erste Version ist, bei der der Großtteil von
Johanns Arbeit eingeflossen ist. Das betrifft beispielsweise Dinge
wie das neue Flash-Interface via named address spaces (“NAS”). Aber
es gibt auch endlos viele Optimierungen, die da reingekommen sind.
Zuvor war es leider so, dass mit jeder neuen GCC-Version die
Codegenerierung für den AVR (insbesondere die Code-Dichte) eher
schlechter
als besser wurde; 4.7 ist der erste, bei dem da dank Johann ein
deutlicher
Sprung nach vorn erfolgte.
Der fehlende Xmega-Support wurde ja schon genannt; muss halt nicht für
jeden ein Thema sein. Wer nur ATmega8 oder ATmega328 bearbeiten will,
den interessiert das eher nicht.
Dann gab es noch einen uralten Bug, der seit GCC 4.4 manifest wurde
und dessen Bugfix meines Wissens nur bis 4.6 zurück portiert worden
ist; 4.4 und 4.5 sind dahingehend also buggy. Der Bug führte zur
stillschweigenden Generierung völlig falschen Codes im Zusammenhang
mit dem (wenn ich mich recht entsinne) Y-Zeiger, da wurden intern
irgendwelche Register überschrieben. Schon von daher ist ein GCC 4.5.3
also eine absolute Nicht-Empfehlung für den AVR.
Jörg Wunsch schrieb:> Axel Schwenke schrieb:>> Die letzte LTS (12.04 aka Precise) immerhin 4.5.3. Welchen relevanten>> Bug oder welches fehlende Feature in diesen Versionen kannst du konkret>> benennen?>> Features auf jeden Fall. Es gibt extrem viele Dinge, die erst seit 4.7> dabei sind, weil das die erste Version ist, bei der der Großtteil von> Johanns Arbeit eingeflossen ist.
Oh, prima. Informationen statt FUD :)
> Zuvor war es leider so, dass mit jeder neuen GCC-Version die> Codegenerierung für den AVR (insbesondere die Code-Dichte) eher> schlechter> als besser wurde; 4.7 ist der erste, bei dem da dank Johann ein> deutlicher> Sprung nach vorn erfolgte.
OK. Das erklärt dann, warum ich hier auf meinem (allerdings wirklich
antiqierten) Debian Etch mit einem selbergebauten (immerhin als .deb)
avr-gcc 4.3.3 so prima zurecht komme.
> Der fehlende Xmega-Support wurde ja schon genannt; muss halt nicht für> jeden ein Thema sein.
Tatsächlich ist das ein Grund, warum ich jetzt doch mal upgraden will.
Konkret ist es ein Atmega32u2, aber Xmega steht auch vor der Tür.
Allerdings wird zumindest ersterer in 4.5.3 schon unterstützt.
> Dann gab es noch einen uralten Bug, der seit GCC 4.4 manifest wurde> und dessen Bugfix meines Wissens nur bis 4.6 zurück portiert worden> ist; 4.4 und 4.5 sind dahingehend also buggy.
Hmm. Das ist ja doof. Man muß also entweder antike avr-gccs verwenden
oder brandneue. Gut daß wir darüber gesprochen haben.
XL
In Zusammenhang mit LTO gab es Unterschiede zwischen den Versionen,
weshalb ich einmal in die Lage kam mir einen gcc bauen zu müssen.
Wenn aber ab 13.04 (und damit Mint15) eh der 4.7.2 dabei ist hat sich
das Problem eh bald erledigt :-)
Folgende Zeile fehlt in meinem vorherigen Beitrag :/
Mein Mint14 hatte den 4.7.1 dabei, unter Windows hatte ich 4.7.2 (weiß
aber grad nicht mehr woher das Binary war, WinAVR ist imho nicht so
aktuell).
