Unsupported devices wrt avr-gcc v 11.2.0

[stefanrueger]

[edited] Avr-libc does not appear to support the following mcus in contrast to the avr-gcc 11.2.0 compiler documentation. There used to be avr-libc support in previous versions (regression?): ata5791, ata8210, ata8510, atmega168pb, atmega328pb, atxmega16e5

I note, there are patches amongst the open issues that bring some to life again.

[sprintersb]

avr-gcc and AVR-LibC are only loosely coupled. In particular, when the compiler lists a device as being supported that does not imply it is also supported by LibC.

The compiler support is much simpler (one line of code) whereas for the LibC support you need correct header files and symbol files and whatnot.

As there are so many devices (do date avr-gcc lists more than 350), it was decided to out-source device support from the compiler into spec files. These are text files that tell the compiler which sub-processes to invoke with which options. Apart from the device-specs/specs-<mcu> file, an I/O header avr/io*.h is needed, startup code in crt<mcu>.o, and a lib lib<mcu>.a with EEPROM support. This is described in detail in the link to the avr-gcc Wiki above.

Such device support is provided by Atmel and Microchip in .atpack files which are just ZIP files. Unzip them and then use the files in folder gcc/dev/.

• http://packs.download.atmel.com
• https://packs.download.microchip.com

[stefanrueger]

Thanks for explaining.

out-source device support from the compiler into spec files

I can see the attraction of this idea from the AVR-LibC point of view. How would thousands of users know, though? And would it not be kinder to the world if AVR-LibC provided the right files once and for all rather than asking every user to replicate what is needed?

I probably read about specs files at some point but even with the wiki above it looks kinda hard graft. Actually, re-reading the wiki, I have to say it is much better at hedging against possible problems and emphasising what could go wrong than at giving specific, hard and fast advice on how actually to do this right. An example at the beginning would be helpful. As would be if the hedging phrases were converted into actionable trouble-shooting of the kind If x is observed y might be the reason and z is a likely remedy.

Best of course, if none of that was necessary for parts that are long in existence, and leave outsourcing device support for those new devices that appeared in between releases.

[sprintersb]

How would thousands of users know, though? And would it not be kinder to the world if AVR-LibC provided the right files once and for all rather than asking every user to replicate what is needed?

Yes, of course. AFAIK most users don't know about it; they just click on "Device XYZ" in their GUI and the GUI does the rest.

The "would it be kinder" is actually true, but the issue was, and is, that the tool versions (compiler, Binutils and LibC) as used by the users are usually much older than head. For example, my Ubuntu's avr-gcc is v5.4 (released around 2015), but it has avrxmega3 which was only supported in v8, so someone back-ported that.

Also there is a constant lack of maintainers / contributors, so that the newest tool versions don't have support for the newest devices. And AVR-LibC queries for avr-gcc device support in configure, hence when avr-gcc doesn't mention the device, AVR-LibC won't support it.

For the avr-gcc wiki, one problem with it is definitely that I am no native speaker, and I am mostly dealing with stuff that doesn't work, so my view on the tools is quite biased...

[stefanrueger]

when avr-gcc doesn't mention the device, AVR-LibC won't support it.

Well, when I first opened the issue, I used a docker with Archlinux with the newest avr-gcc (11.2.0) at the time, but AVR-LibC still misses quite a few of devices that then had been around for some time

[users] just click on "Device XYZ" in their GUI and the GUI does the rest

Aha, so the packages that provide the GUI have figured out what needs doing and offer the needed files in the context of the GUI workflow? Fair cop and good on them.

I still think it would be amazing if AVR-LibC were to offer the same for those who prefer compiling in a shell.

[sprintersb]

so the packages that provide the GUI have figured out what needs doing and offer the needed files in the context of the GUI workflow?

The GUI itself is providing the support, e.g. Microchip Studio or what it's called these days. I never used it though, and all I know is from hearsay.

I still think it would be amazing if AVR-LibC were to offer the same for those who prefer compiling in a shell.

100% ACK