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

[Theodore A. Roth]

On Thu, 8 Aug 2002, E. Weddington wrote:

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

That was meant to be tongue in check. Didn't mean to offend, sorry if I
did. ;-)

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

Well, for me, it's more of a maintenance issue. I prefer a single simple
interface for all cases and use the bit value macros which hind the device
specifics (although right now that needs some work). The "cryptic" bit
value macros are not that cryptic if they use (mostly) the same mnemonic
as the data sheet, which you'll most likely be reading any how. The bit
value macros are easier to maintain than the many function like macros you
propose.

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

You're always welcome to do whatever you want in your code and I agree
that BIT makes more sense than BV (or _BV). In the manual though, our
examples should try to use non-deprecated interfaces and not introduce new
ones.

I really don't know why Marek changed BV() to _BV().

Ted Roth