Hi everyone,
Since the discussion about bit masks (C-style) vs. bit numbers (ASM-style)
seems to come up every now and then, here are my thoughts for what they're
worth:
Atmel opted for the bit numbers for whatever reasons. That's that
and it's moot
to argue about it. The gcc port for AVR's chose early on to be as
compatible to
Atmel's lead as possible. That's also history. Good or bad, that's where we
are.
I personally agree with Joerg that using bit masks would be the 'natural' way
in C (and all other non-assembler languages I know). But, there are these guys
who still want to do assembler coding, at least every now and then (including
myself). And nobody wants to maintain 2 sets of header files, which is a good
idea.
But the bit masks can be easily generated from the existing ioXXX.h files,
letting the compiler do the brunt work, as Eric pointed out. The generation
can be integrated with the build process and nobody has to maintain them
separately. All that is needed is a little convention (already in
place) during
the definition of the bit numbers.
I've attached a bash script that creates a
#define _XXXX _BV(XXXX)
for each XXXX that represents a bit number. Think of it as a proof of concept.
All the ioXXX.h files could be moved into a separate 'include/avr/bits/'
directory since the only file that is allowed to include them is io.h anyway
(so that shouldn't break any existing code). The generated convenience header
files can be included directly by their respective blue print io file, since
they only extend the definitions.
This would allow us to have the best of both worlds:
* full compatibility with Atmel's definitions/publications
* bit masks for C programs (in the controlled namespace)
* no additional maintenance overhead
* no need to have this discussion over and over again
The last point might be wishful thinking on my part, but I think it's worth a
shot.
Markus