AVR programmierung unter Linux basiernede Systeme

Hallo ratssd.

Ggf. seh dir doch mal diese Seite an:
http://matrixstorm.com/avr/tinyusbboard/

Da ist zwar weniger Erklaerung als vielmehr die Tools, aber speziell in 
der Sektion "Linux" 
(http://matrixstorm.com/avr/tinyusbboard/#asmorc_linux) kannst du dir 
die notwendige Software (selbst fuer raspi) downloaden.

MfG

ratssd schrieb:
> 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.

Funktionieren die Direktlinks auchnicht?

http://www.atmel.com/forms/software-download.aspx?target=tcm:26-47216

http://www.atmel.com/System/GetBinary.ashx?target=tcm:26-47216&type=soft&actualTarget=tcm:26-47214

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