[Top][All Lists]

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

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

From: E. Weddington
Subject: Re: [avr-libc-dev] interrupt enable functions
Date: Fri, 09 Aug 2002 15:38:55 -0600

On 9 Aug 2002 at 21:17, Joerg Wunsch wrote:

> > 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.  

Sounds great!
Also concerning compatibility: what about things in avrlibc that are 
in strictly for "compability with other compilers" (mostly IAR). 
Right now its spread out in pgmspace.h, eeprom.h, ina90.h. Keep them 
there or some other system to help people migrate?

> 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.

Well it brings up the question, does avrlibc want to get into 
providing APIs for AVR hardware subsystems (such as UARTs, timers, 
etc.)? Not that I'm necessarily advocating it. But if not, it seems 
odd to provide /include/avr/timer.h, ./twi.h, even for that matter 
./eeprom.h as somebody could roll their own. parity.h seems more like 
a candidate for /libc/misc as its own assembler file than as a macro.

> > 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'. :-)

Yeah, I figured it out too... I just don't like to unnecessarily 
abbreviate. :-) 
> 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...
Perhaps he could drop us a line... (bad pun intended).


reply via email to

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