Re: support for atmega4809 family?

[Georg-Johann Lay]

Am 08.12.19 um 21:10 schrieb Britton Kerin:
> I notice there are official arduinos (arduino nano every and variants)
> which use the 4809 now so there's presumably some support for this
> chip somewhere. Is it going to show up in my beloved avr-libc?

The common approach is to fiddle with device packs provided by 
Microchip.  They contain, amongst other stuff, io*.h, crt*.o, specs-* 
and lib*.a for the devices.

There are also patches for avr-libc floating around, and there is a fork 
that tries to supply all that

https://github.com/stevenj/avr-libc3/

I cannot say anything about how reliable that is (with respect to (long 
term) support, bug-fixing, running test suites before integrating, 
sanity checking, ...)

However, in order to make the patches for the 0-series devices to have 
any effect, the compiler must support these devices, which will be in 
v10 for 0-series, cf.

http://gcc.gnu.org/PR92545

This support is not needed if you are using device packs (the rationale 
behind them is that you can generate code for a device without native 
support from the compiler).

> If there's work to be done I'd be interested in helping with this
> though I haven't done any avr-libc work before.  I saw some email

The tedious work is checking coding rules, writing ChangeLogs, running 
tests, integrating the stuff, reviewing if it might conflict with 
anything, it it's appropriate, etc.  For many of the issues there are 
patches available, but someone would have to integrate them (which is 
much more wirk than just pressing some "merge" button).

> mentioning it as well
>
> https://lists.nongnu.org/archive/html/avr-libc-dev/2019-11/msg00002.html

This is the support for the multilib variants so that libm.a and libc.a 
are generated as needed.  This is the minimum that's required to make 
device-packs for avrxmega3 devices work (without multilib support you 
will get linker errors even if your lib<device>.a, ioxxx.h, 
crt<device>.o and specs-<device> are in the right place).  However you 
could use the existing avrxmega2 with some performance penalty.

Johann

> so maybe it's already done, but would be lovely if it showed up in a
> release of course.