avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-libc-dev] New device support


From: Weddington, Eric
Subject: [avr-libc-dev] New device support
Date: Sat, 14 Nov 2009 22:02:21 -0700

Hi All,

I just committed a patch to HEAD and 1.6 branch to add support to a bunch of 
new devices.

Two things:

- New policy: There are a bunch of new devices coming out from Atmel that have 
an 'A' suffix. In most cases, these are the same devices without the 'A' 
suffix, except that they are die shrinks. There are some cases where the new 
'A' device has a new I/O register or two. For all of these cases, I am adding 
support to the toolchain (binutils, gcc, avr-libc) for the new device name 
whether there are changes or not. This also includes adding a new, 
automatically generated header file. This policy is being implemented mainly to 
easily support the end user. The end user may not know, or care, that the 'A' 
part is the same as the non-'A' part. All they know is the device name, and 
that is what they will select, and ultimately what will end up in the 
-mmcu=<device> flag. So these part names *will* be added as separate names 
simply for the convenience of the end-user. With that, we already have a policy 
in place of a single I/O header file per device, and that header file will be 
initially generated from the XML device file that is shipped with AVR Studio. 
So these new 'A' devices will have separate I/O header files in avr-libc.
(BTW, this is informative only. I'm not debating these policies.)

- So I added support for a bunch of new devices. However, some of the I/O 
header files are not ready yet, specifically for these devices:
ATtiny261A
ATtiny861A
ATtiny461A
ATmega64HVE
ATmega169PA
ATmega649P
ATmega324PA

The XML files for these devices had various issues with them and I could not 
generate a proper header file for these devices. The issues are well known, and 
I'm pushing to get the XML files fixed hopefully early next week. But I wanted 
to let all the developers know that everything is now in place in avr-libc to 
look for these I/O header files, they just don't exist yet.

Sorry for the hassle, but as I mentioned, I hope to get this worked out by 
Monday or Tuesday. Let me know if this is a problem for anyone.

Thanks,
Eric Weddington




reply via email to

[Prev in Thread] Current Thread [Next in Thread]