Re: [avr-gcc-list] Winavr / gcc include files

[E. Weddington]

On 21 Jul 2004 at 10:10, Steve @ Franks Development, LLC wrote:

> Hello,
> 
> We have been working with gccavr now for a few months, and we have a couple of
> questions about the default WinAVR include files for general digestion:
> 
> 1) All the commercial compilers have a "byte.bit" notation for working with
> bits.  A lot of source code out there uses this notation as well.  If you look
> at the "Vic's byte" struct in our sfr_defs.h file, you will find an incomplete
> example of how to do this.  Is this a good thing to include in the general
> distribution?  It also makes for more readable code in our 
> opinions...thoughts? 
> Also, how would we go about officially proposing this as an addition to the
> distribution?  (I have placed our sfr_defs code at the end of this message, in
> case the list doesn't allow includes)

If you read the README file, it indicates that the main project responsible for 
this is avr-libc (the Standard C library for the AVR for the GCC toolset). 
There has been recent discussion about this issue on that projects mailing 
list, avr-libc-dev. You can go to the avr-libc project on Savannah and take a 
look at the mailing list archives. Links can be found in the README.

 
> 2) The includes for various parts tend to conflict a bit (i.e. TCCR on
> Mega32, TCCR0 on Mega128), making code somewhat non-portable between
> machines.  Is there a reason for this, or just a lack of someone willing to 
> step
> forward and bring the older parts in line with the newer ones? As they say, 
> "he
> who complains about the cooking"...

avr-libc has a policy of defining bit names that are found in Atmel's 
datasheets. So due to this, there are some incompatibilities between parts. 
There is a TODO item in avr-libc to try to make some common functionality 
between parts, specifically for the U(S)ARTs, but no volunteer has stepped 
forward for this yet, but there has been a lot of discussion of this. For other 
peripherals, though, you can always make your own compatibility layer.

Eric