[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: support for atmega4809 family?
From: |
Georg-Johann Lay |
Subject: |
Re: support for atmega4809 family? |
Date: |
Mon, 9 Dec 2019 18:55:56 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 |
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.