Hallo zusammen,
ich versuche derzeit möglichst schmerzfrei, eine aktuelle AVR-Toolchain
auf meinem Rechner zu installieren (Debian Bullseye). Früher war das ja
sehr einfach, da es out-of-the-box funktionierte:
1
apt install gcc-avr avr-libc avrdude
Der gcc-avr in Debian ist aber uralt. Die avr-libc sowieso.
Nun bin ich, auch (besser: vor allem) dank dieses Forums und Beiträgen
insb. von Jörg, Veit D. und Johann, meinem Ziel gefühlt schon näher
gekommen. Mein Vorgehen soweit:
1. Alten gcc-avr 5.4.0 installieren (s.o.)
2. Eine aktuelle avr-libc bauen:
2a. Klone https://github.com/avrdudes/avr-libc
2b. ./bootstrap (Achtung, das hat eine python2-Abhängigkeit!) &&
./configure ... && make && make install
3. Von https://packs.download.microchip.com/ die zu den gewünscht
Controllern (d.h. von legacy gcc-avr nicht unterstützten Typen)
"device-specs" nach /usr/lib/gcc/avr/5.4.0/device-specs/ kopieren.
4. Ebenfalls von dort die gewünschten *.o- und *.a-Dateien nach
/usr/local/avr/lib/avrxmega3/short-calls/ kopieren. (Der restliche
Inhalt unter /usr/local/avr/ kommt von der selbstgebauten avr-libc).
Das, so dachte ich, müsste genug sein, um ein Projekt für einen der
neuen AVR-Typen zu bauen. Funktioniert aber leider nicht.
Konkretes Beispiel: Ich möchte ein Minimalprojekt "test.c" für einen
attiny202 bauen:
In file included from /usr/local/avr/include/avr/io.h:438:0,
7
from test.c:2:
8
/usr/local/avr/include/avr/iotn202.h:4655:0: note: this is the location of the previous definition
9
#define LOCKBITS_DEFAULT (0xc5)
10
^
11
/usr/lib/gcc/avr/5.4.0/../../../avr/bin/ld: cannot find crtattiny202.o: Datei oder Verzeichnis nicht gefunden
12
collect2: error: ld returned 1 exit status
Die warnings bekomme ich bestimmt selbst in den Griff. Das Problem ist,
dass er die crtattiny202.o nicht findet. Die ist aber da (siehe Punkt 4
von oben):
Was mache ich falsch?
Ich möchte bei dieser Gelegenheit ganz herzlich Jörg und Johann und
allen anderen Beteiligten danken, dass sie die Arbeiten an der avr-libc
wieder aufgenommen haben. Ich trage beizeiten gerne mal mit einer
Aktualisierung der Dokumentation bei.
Viele Grüße,
funkmaus.
Ich schätze, dass die .o-Dateien analog zu zb crt0.o auf Linux
funktionieren. Dafür gelten die normalen lib-Suchpfade nicht. -B<pfad>
als zusätzlicher Parameter könnte funktionieren.
Ich habe mir eine VM als buildserver eingerichtet. Die kann man notfalls
auch zusammen mit dem Projekt archivieren und den build auch in 20
Jahren noch nachvollziehen.
Musste dabei auch feststellen dass der avr-gcc unter Debian asbach-Uralt
ist, deswegen bin ich in der VM dann zu Arch Linux gewechselt.
Das beantwortet deine Frage zwar nicht direkt, gibt dir aber vielleicht
neue Anregungen.
Ich persönlich mag mir das Hostsystem nicht so verbasteln.
Und wild eigene Compiler und libs zu bauen und auf dem System zu
verteilen läuft für mich unter "Basteln". Ich finde es schwierig, nach
einigen Monaten Abstand noch nachzuvollziehen was man damals gemacht
hat.
Le X. schrieb:> Ich finde es schwierig, nach> einigen Monaten Abstand noch nachzuvollziehen was man damals gemacht> hat.
Es steht dir frei, dein Vorgehen, in einer dir angenehmen weise, zu
dokumentieren.
funkmaus schrieb:> Der gcc-avr in Debian ist aber uralt. Die avr-libc sowieso.
Ja, zum Glück war das für mich bisher noch kein Showstopper.
Mich wundert allerdings, dass solche Programmpakete überhaupt
Bestandteil der Distribution sind. Vermutlich nutzen es weniger als 1%
der User.
Meine SMS Server Tools (smstools) hat auch irgendwer zur Distribution
hinzugefügt - weiß der Geier warum. Wer benutzt das noch?
Hallo zusammen,
danke für die Antworten. Die Lösung von Heiko L. funktioniert bestens.
Mir war in meinem bisherigen Leben schlicht noch nie die -B-Option
untergekommen. Bei den ARM-Cortex-Prozessoren bzw. deren Toolchain liegt
der Startup-Code meist als Quelldatei vor und wird beim Build direkt
mitverwurstet, sodass ich bisher noch nie in die Bredouille gekommen
bin, mich mit -B auseinanderzusetzen. Also
funktioniert bestens, vielen Dank!
Damit ergibt das oben beschriebene Vorgehen eine, wie ich finde, ganz
akzeptable Lösung für eine Toolchain für die "neuen" AVR-Prozessoren.
Ideal wäre es natürlich, wenn Debian direkt einen aktuellen gcc für AVR
mitliefern würde. Upstream scheint es den ja zu geben. Und die aktuelle
avr-libc tut ja auch bereits vieles (obiges Repository).
Vlt. noch eine Frage zum Schluss: Ich dachte bisher immer, dass die
avr-libc den Startup-Code mitliefern würde. Warum ist das in diesem Fall
nicht so? Ist das schlicht noch nicht implementiert oder habe ich hier
etwas missverstanden?
Vlt. noch eine blöde Frage: Gibt es mittlerweile eine Zukunftsaussicht
für das AVR-Target ab gcc 11 bzw. 12?
Besten Dank noch einmal und einen heiligen Restabend noch (Kind schläft,
ich darf wieder basteln),
funkmaus.
Vlt. doch noch einen Nachtrag:
Le X. schrieb:> Ich persönlich mag mir das Hostsystem nicht so verbasteln.
Kann ich durchaus nachvollziehen. Allerdings empfinde ich einen Haufen
VMs im Archiv auch irgendwie belastend. Ich will aber auch auf gar
keinen Fall für jedes Projekt bzw. jeden Controller einen Haufen Mist
installieren und/oder irgendeinen proprietären Kram benutzen, der es
beim nächsten Systemupdate unnachvollziehbarerweise nicht mehr tut.
Die oben skizzierte Lösung ist für mich akzeptabel. Ich müssen lediglich
für jeden Controller, der nicht von den Repository-Quellen unterstützt
wird, drei Dateien von Microchip heruntergeladen und ins System abgelegt
werden. Dort dürfen sie dann schlummern. Der avr-gcc- bzw. -libc-Rest
ist ja auch nur ein einziges Mal da.
Viele Grüße,
funkmaus.
Man könnte auch die Toolchain aus Arduino nutzen wenn der verwendete
Controller unterstützt wird. Hab ich auch schon probiert und
funktioniert. Da ist dann auch die avr-libc gleich dabei.
Am Ende hab ich mir aber auch mit -B geholfen :) Das ging auch klaglos.
funkmaus schrieb:> Vlt. noch eine Frage zum Schluss: Ich dachte bisher immer, dass die> avr-libc den Startup-Code mitliefern würde. Warum ist das in diesem Fall> nicht so? Ist das schlicht noch nicht implementiert oder habe ich hier> etwas missverstanden?
Da drin muss nicht unbedingt StartUp-Code sein - es können auch
allgemein Hilfsfunktionen vom Compiler sein. Zum Beispiel Floating-Point
Operationen für Controller ohne Hardware CPU Support oder sowas. Das
Zeug liegt sozusagen also eine Ebene tiefer als die libc und enthält
das, was man zur Realisierung des Sprachstandards braucht. Die Grenze,
was davon direkt im Compiler mit eingebacken und was so extern
bereitgestellt wird, ist vermutlich nicht ganz so leicht zu ziehen.
Ich weiss aber auch nicht definitiv, was da jetzt genau drin ist: Mit
readelf oder objdump könnte man in die .o Dateien reinschauen, ob das
irgendwelche Hinweise gibt.
funkmaus schrieb:> Vlt. noch eine blöde Frage: Gibt es mittlerweile eine Zukunftsaussicht> für das AVR-Target ab gcc 11 bzw. 12?
Nach damaliger Spendenaktion wird die AVR Unterstützung im gcc
fortgesetzt. Für den avr-gcc Nutzer ist alles unverändert.
funkmaus schrieb:> Das Problem ist, dass er die crtattiny202.o nicht findet.> Die ist aber da (siehe Punkt 4 von oben):>
1
ls /usr/local/avr/lib/avrxmega3/short-calls/
>
1
crtattiny202.o ...
2
>
Hier bin ich mir nicht sicher, ob avr-gcc die CRTs in diesen Pfaden
sucht, weil avrxmega3 und avrxmega3/short-calls erst mit v8 zu
Multilib-Pfaden wurden, siehe
https://gcc.gnu.org/gcc-8/changes.html#avr
Zur allgemeinen Vorgehensweise:
1) -I /usr/local/avr/include/ -L
/usr/local/avr/lib/avrxmega3/short-calls/ würde ich weg lassen. Diese
Pfade kennt gcc von --prefix bei configure, und den Multilib-Anteil vom
specs-File. Dieses wiederum gibt man an per -B <pfad>, wobei <pfad> den
Ordner device-specs enthält.
2) Falls das Device bereits nativ dem Compiler bekannt ist (was seit v5
lediglich bedeutet, dass device-specs ein entsprechendes specs-<mcu>
enthält) dann natürlich kein -B angeben.
3) Include-Pfade kann man sich anzeigen lassen mit -v:
1
avr-gcc -v ...
2
...
3
#include "..." search starts here:
4
#include <...> search starts here:
5
<install>/bin/../lib/gcc/avr/8.5.0/include
6
...
3b) Auch verwendete lib-Pfade kann man mit -v anzeigen lassen,
vorausgesetzt es kommt bis zum Linken.
4) Ob avr-gcc den richtigen Multilib-Pfad kennt (abhängig von Version)
kann man testen mit
Wegen diverser Bugs wie PR90706 würde ich maximal v8 nehmen. Und
minimal v8 wegen neuer Features, siehe die obigen Release Notes.
5) Falls avrxmega3 noch nicht unterstützt wird, kann man ATtiny202 etc.
auf avrxmega2 abbilden mit den offensichtlichen Nachteilen, dass z.B.
Flash-in-RAM-Address-Space noch nicht unterstützt wird. Die Abbildung
erfolgt im specs-<mcu>.
Prinzipiell sind specs-Files nicht komplett unabhängig von Compiler- und
Binutils-Version, auch wenn das wünschenswert ist. Neue Features wie
-mgcc-isr sollen aber auch nicht blockiert werden, so dass sich solche
Features auch im specs-File niederschlagen.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang