[avr-libc-dev] New device support

[Eric Weddington]

Hi All,

Jörg brought up this topic privately. We're moving this topic to
avr-libc-dev so others can have input.

There are new devices that need support:
AT90PWM216
AT90PWM316
ATmega48P
ATmega88P
ATmega168P
ATmega328P
AT90PWM2B
AT90PWM3B
And possibly ATA6289, though I would have that as a lower priority.

However, I have a policy proposal for avr-libc. Previously, there have been
devices in sub-families where the device IO header file is minimal and it
includes another header file for the sub-family. For example, there are IO
header files that cover multiple devices such as: iomx8.h, iomxx0_1.h,
iomxx4.h iomxxhva.h, iousbxx2.h, and iousbxx6_7.h. While I understand the
reason for doing this, to save time primarily, and common definitions in a
single place, I would like this practice to be changed.

There will many more devices in the future and creation of the IO header
files needs to be automated, and it will in fact, be automated in the near
future. This means that the IO header file will have to be generated from
the device XML file that is released from Atmel. This has several
implications:

- One IO header file per device, ONLY. Common parts should NOT be put in a
separate family header file (like described above) and included in the
device IO header file. Each IO header file needs to be atomic in order to do
the automated generation.

- The IO header file for a new device will very probably be generated before
the XML device is released in AVR Studio, i.e. we will NOT have to wait
until an AVR Studio release to put together device support. However, the XML
file itself may not be made public before we have the IO header file.

- Backwards comptability will be taken care of. If Atmel has a change to the
XML file, then not only will the generated IO header file have the new
definitions, but the old ones should still be available for backwards
comptability. This has to be taken care of in the source XML file, so this
can be automated.

- This also means that these IO header files should not be hand modified in
the future.

There are several advantages to doing this:
- We can get devices support in the toolchain *before* the device is
released.
- We can guarantee that we will match the device's features.
- We can guarantee that we will get updated headers if there are bugs in the
XML faster than we have before.

IIRC, currently we have a Python script within avr-libc to convert the XML
device file from AVR Studio to an IO header file. I don't know if this
script is up-to-date. However, I am leaning away from using this Python
script. In the future, I would very much like to use XSLT transforms and
using the XMLStarlet command line tool within Makefiles to do the
conversions.
<http://sourceforge.net/projects/xmlstar>

And, yes, I am willing to get a conversion system running and in place.

We also have a challenge for the future. Adding device support across the
whole toolchain needs to be easier. Currently we have to touch several
tables in binutils, gcc, and avr-libc. Jörg, I know that we have previously
discussed changing this in the past, with Ted Roth. But we need to consider
again if we can somehow centralize at least *some* of this (such as with
binutils and gcc) and use something like autogen. HOWEVER, I *really* do not
want any major changes to the port in GCC 4.3. I would really like to defer
this to at least 4.4, or perhaps 4.5 (depending on GCC's schedule).

Also, please let me know of any major changes to the AVR "architectures" in
the port. (Hi Anatoly! :-) I would like this portion to be somewhat stable
for the next 3-4 months. Any changes in this can severely impact work that
I'm doing now.

Thanks,
Eric Weddington