Post by Pitchumani SivanupandiPost by Joerg WunschCan Microchip at least grant us permission to back-integrate their
header files here? I assume they still have the usual 3-clause
BSD-like copyright statement, so it wouldn't be a legal issue to have
them here.
I think there is no change in licensing terms after Microchip
acquisition.
OK, that means we are allowed to import them. Good.
Post by Pitchumani SivanupandiIt would be easier if we could blindly copy the Atmel generated
headers and overwrite avr-libc headers.
Well, in general, no.
What's there should stay there. If there are bugs, they can be fixed,
but it's always been our policy even in that case to retain full
backwards compatibility (e.g. by keeping both, the old and the new
name). Thus, you can sometimes find things in the header files like:
#define UCSZ 2
#define UCSZ2 2 /* new name in datasheet (2467E-AVR-05/02) */
It's not only important to have both names, but also to comment on
*why* it is that way, so people questioning it get to know what's the
way to go for them.
By generally dumping auto-generated files over them, we'd risk this
tradition. Besides, avr-libc used to continue to support devices long
after Atmel has given up on them.
I think you are mainly referring to the large discrepancy in the
ATmega*RF[AR]* header files. We (avr-libc together with the Atmel
developer team) tried to introduce an extended IO register addressing
scheme with the introduction of these devices: register-safe bit
access. With the traditional register definitions, you are always at
a risk to do something like this:
TCCR0A = _BV(WGM01) | _BV(WGM02);
/* wrong: WGM02 belongs to TCCR0B */
No compiler would tell you about that mistake, it just yields
completely wrong results.
With register-safe access, you will get an error trying to do this:
TCCR0A_struct.wgm02 = 1;
because "wgm02" is only present in TCCR0B_struct.
The idea here was to eventually make this standard for all future
AVRs. However, by that time, all future AVRs turned out to become
Xmega devices (for quite some time), which got a completely different
naming scheme. However, even the Xmega scheme is *not* register-safe:
TCC1->CTRLB = TC_CLKSEL_DIV64_gc;
/* wrong: clock selection is performed in CTRLA */
Only starting with the SAMD ARM series, something similar finally got
state of the art:
SYSCTRL->XOSC32K.bit.STARTUP = 6; /* ≈ 1 s */
SYSCTRL->XOSC32K.bit.XTALEN = 1; /* this is a crystal */
(Alas, writing the bitfield names all uppercase has other bad
implications, since there happen to be subregisters that have the same
name as global IO modules. Writing them lowercase, as we did in 2009
with the ATmegaRFA, would have avoided that.)
So in general: backwards compatibility of the code of our userbase is
a value which is not to be broken.
Of course, for new devices that have no precedent cases, this is never
an issue, so you are free to import the auto-generated files for them.
Post by Pitchumani SivanupandiIt is also worth nothing that avr-gcc moving away from hard-coding
device specific details.
I cannot imagine how this would be possible for a library as avr-libc
though. At least the startup code is always device-dependant and
needs to be pre-compiled. In addition, history shows that for each
new device, a number of header files usually needs to be patched as
well (avr/eeprom.h, avr/power.h, avr/sleep.h come to mind).
--
cheers, Joerg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)