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

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

RE: [avr-libc-dev] fuse API on the xmega16a4


From: Weddington, Eric
Subject: RE: [avr-libc-dev] fuse API on the xmega16a4
Date: Sat, 20 Mar 2010 12:08:20 -0600

 

> -----Original Message-----
> From: Galen Seitz [mailto:address@hidden 
> Sent: Saturday, March 13, 2010 12:36 PM
> To: Weddington, Eric
> Cc: address@hidden
> Subject: Re: [avr-libc-dev] fuse API on the xmega16a4
> 
> Weddington, Eric wrote:
> > 
> > Please let me know if you have any further suggestions or patches.
> > 
> 
> OK, since you asked, it appears that bit field information for the 
> fuses is being duplicated in the iox*.h files.  For example, in 
> iox16a4.h the fuse bits are first defined with macros like this:
> 
> #define NVM_FUSES_BODLVL1_bm  (1<<1)
> 
> Then later a similar, but inverted version is defined:
> 
> #define FUSE_BODLVL1  (unsigned char)~_BV(1))
>
> If both of these are automatically derived from the XML file, then I 
> suppose there's no problem.  But if one of them is added by 
> hand, then 
> it seems that the hand added macro should be defined in terms of the 
> other, automatically derived one.

The situation is a bit different for the XMEGA devices. The first definition 
above comes directly from the XML device that comes with AVR Studio. The second 
defintion above it generated by the convertor script that converts the XML 
device file to the header file. The convertor script gets the basic fuse 
information from the XML file, but it massages the data and generates a bunch 
of fuse information and specifically creates the *inverted* mask that you see 
in the second definition, because these are used with the Fuse API in avr-libc. 
To have the second definition be based on the first definition would involve a 
lot of exceptions made in the convertor script. However, this convertor script 
is a part of the avr-libc source code, so anyone can modify it. Though in 
reality I will be giving any changes to that script *a lot* of scrutiny. That 
script may change in the future based on the format of the XML device file that 
comes from Atmel.

 
> Also, what is the origin of the fuse default values?  I'm not certain 
> they are correct for the devices I'm working with.

As mentioned above, the XML device file that ships with AVR Studio. These XML 
files come from Atmel. In fact, avr-libc has a policy that all header file 
information is based on the XML device file data, and not the datasheet. 
However, discrepencies always sneak in. If the XML file differs from the 
datahseet, then Atmel needs to figure out which one is correct, and which one 
is wrong and fix the one that is wrong. For those type of bugs, you have to 
send that to Atmel.

FYI, I changed the avr/fuse.h header file per your suggestion. Thanks!

Eric




reply via email to

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