support for atmega4809 family?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

support for atmega4809 family?

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?

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
mentioning it as well

https://lists.nongnu.org/archive/html/avr-libc-dev/2019-11/msg00002.html

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

Reply | Threaded
Open this post in threaded view
|

Re: support for atmega4809 family?

Georg-Johann Lay-2
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.