Re: [avr-libc-dev] interrupt enable functions

[Joerg Wunsch]

As E. Weddington wrote:

> Concerning namespace pollution: It's there whether you like it or  
> not. What difference does it make to have all the bits in a reg     
> #defined to have their own arcane symbol that's difficult to  
> remember, or to have macros defined like 
> above that at least tie the name with what it does? Which way is more 
> mnemonic?

The arcane symbols, as long as they match the device's datasheet.  We
have to include them anyway (people can reasonably expect them to be
defined somewhere).

> Now since most other compiler don't provide these kinds of macros, 
> one could argue that avrgcc shouldn't do it either and it should be 
> left up to the programmer.

Yes, in that case i'm arguing for this.

I propose that we ship an <avr/compat.h> that includes those things
that are deprecated in new programs.  This also includes outp() and
inp(), maybe a few others.  This should provide some transitional path
for those who need a quick way to compile their old programs using the
new avr-gcc/avr-libc.  As Theodore mentioned, those interrupt register
tweaks were merely meant as examples (and not even as very useful ones
as we now know :).  There are so many other things that would have the
very same right to get special functions inside avr-libc,
e. g. setting the UART baud rate register from a given CPU clock and
target baud rate comes to mind.

> Concerning the new headers: I think that perhaps it came from the 
> AVRFREAKS site. I'm including the relative files for your perusal. 

Thanks.  Now i know what you mean.  Looking at <avr/sfr_defs.h>, that
seems to incorporate the principles of this "new headers" idea now.
We can make it clear in the documentation that the direct assignment
of values to IO registers is the preferrable way over outb()/inb()
etc. now (and i'll adapt my examples for this as well), in particular
since it'll make the code more portable to other AVR C compilers as
well.

> Personally I don't use that macro; I roll my own with the same 
> definition and call it BIT(). Personally I don't like making 
> abbreviations unless absolutely necessary. I find it easier to 
> understand PORTA |= BIT(5) than PORTA |= BV(5) and then remember that 
> BV stands for Bit Value.

Hmm, even for me as a non-native English speaker, it was quite clear
from the beginning that it must mean `Bit Value'. :-)

Still, i don't get the idea why the name with the underscore should be
the preferrable way now.  I hope Marek might tell us about his
reasons, but i'm afraid that he's way too busy to follow all of our
lengthy discussions...

> Sounds great! It looks like the /doc/examples directory could use 
> some looking at.

I'll keep that in mind.

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/