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

[E. Weddington]

On 8 Aug 2002 at 12:33, Joerg Wunsch wrote:

> As E. Weddington wrote:
> 
> > As a counter example, it would require a bit more effort but could
> > be implemented in macros:
> > 
> > // Example for ATmega128
> > #define timer_1_IC_interrupt_enable()               (TIMSK |= BV(5))
> > #define timer_1_IC_interrupt_disable()      (TIMSK &= ~BV(5))
> > #define timer_1_OCA_interrupt_enable()      (TIMSK |= BV(4))
> > #define timer_1_OCA_interrupt_disable()     (TIMSK &= ~BV(4))
> > #define timer_1_OCB_interrupt_enable()      (TIMSK |= BV(3))
> > #define timer_1_OCB_interrupt_disable() (TIMSK &= ~BV(3))
> 
> What i don't like with this is the namespace pollution resulting
> from it.
> 
> Btw., how do other AVR compilers solve this?
> 
> Thinking more about it, it's probably best to leave them entirely
> away.  If some old code still relies on it, we could perhaps invent an
> <avr/compat.h> documenting the obsolete features.  Would be a good
> place to also include a #warning statement. ;-)
> 
> > Also this brings up another question, in your example Joerg, you do
> > direct-assignment to the registers. I prefer that as well, using the
> > "new headers" from Chris Morse and Don Carveth. This method is used
> > frequently in other cross-compilers (at least on Windows). How about
> > deprecating the io macros? The compiled output is the same for
> > direct- assignment vs. macros, and the assignment is easier to read
> > and understand. See the file newhdrs.txt from the above authors for
> > discussion.
> 
> Where's that document to be found?
> 
> Yes, i'd also prefer that new functionality, but it needs to be
> explained in the docs.
> 
> As Theodore A. Roth wrote:
> 
> > :) However, in the example above, the programmer is still required
> > to :) know the structure of the TIMSK register and ensure that s/he
> > is :) setting the correct bit.
> > 
> > I don't think you can escape this.
> 
> Me neither.  Btw., the timer bit macros are matching the AVR
> documentation which you clearly need anyway.
> 
> > :) #define timer_1_IC_interrupt_enable()            (TIMSK |= BV(5))
> 
> > Magic numbers! Boo, hiss! :-)
> 
> And instead of cryptic timer bit names, you gotta learn cryptic
> interrupt enable function names. :)
> 

First off, yes I know it included magic numbers... then I said that 
the numbers could be replaced with the defines from the processor-
specific headers. I didn't originally write it that way due to time 
constraints of  having to look up all the blasted names for the bit 
values.

How do other compilers solve this? They don't. They leave it up to 
the user to create their own. Which always seems to be reinventing 
the wheel. 

Yes, we all know that the user still has to know what they are doing 
whether they flip bits in registers on their own or whether they have 
macros do it for them.

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?

And if you're concerned about these macros conflicting with users' 
macros, then these could be placed in a separate, optional header 
file. Most often, programmers write their own macros to name system-
specific bit flipping. If they already have their own, they don't 
have to include the header. If they are starting a new project they 
could include this header and spend time writing their application 
with readable code without reinventing the macros.

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. One could make another argument and say 
that since no other compiler offers anything like this, why not 
differentiate avrgcc from other compilers and offer a convenience to 
programmers. .... Really it could go either way. But don't do it half-
way.

Concerning the new headers: I think that perhaps it came from the 
AVRFREAKS site. I'm including the relative files for your perusal. 
I'm not particularly thrilled with the implementation, but it works 
and they tried to make it backwards-compatible with the macros with 
conditional compilation and such.

> > First, I think that you should be using _BV() instead of the
> > deprecated (I believe) BV(). That's an off topic nit though.
> 
> Hmm, i didn't know BV() was deprecated.  Sure, its name is in the
> application namespace, but we've got so many other macro names that
> pollute the application namespace so that could hardly be an argument.
> 
> All the other macros with leading underscores (like __inw etc.) have
> even been removed now, why do we want to make the people move from
> BV() to _BV() then?  I can't quite follow this.

Yeah I didn't know it was deprecated either.

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.

 
> > I vaguely remember Marek telling me that some things like this are
> > only in there to be used as examples. The documentation should
> > probably say that this is an example, note the flaw in it and leave
> > it at that.
> 
> Hmm.  Then we should IMHO add examples files instead.  I noticed
> doxygen has some support for it (i. e., it can suck in an entire
> external file).  I can provide the simple-demo.c that has been
> written for Rich's document (a simple PWM ramp-up ramp-down LED
> control), as well as my more advanced demo.c based on it (it
> basically makes the PWM controllable by a few switches, a
> potentiometer, and even by RS-232 commands).
> 

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

Eric

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  io-hdrs2.zip
     Date:  27 Apr 2002, 3:48
     Size:  59594 bytes.
     Type:  ZIP-archive

io-hdrs2.zip
Description: Zip archive