[Top][All Lists]

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

Re: [avr-libc-dev] Bit number/mask, Part 3000

From: Vic Wagner
Subject: Re: [avr-libc-dev] Bit number/mask, Part 3000
Date: Sun, 09 Apr 2006 19:46:49 -0600

At 22:21 2006-04-04, Markus Lampert wrote:
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

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

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

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


It's getting tiresome to keep reminding people that C (and C++, of course) has always had a mechanism for dealing with single bits (multiple bit fields, too) called, _big surprise_ bit fields go look it up on your favorite elementary book on your fave of the two languages.

they don't require any changes to any compilers
they don't pollute the global namespace with ugly   #define  symbols
Or is it simply that hardware engineers can't figure out how to give NAMES to the bits (fields)?

Markus, this is NOT directed at you in particular, but the whole embedded "family".

as for Atmel's public definitions, someone there should be summarily drawn and quartered. I partuclarly mean the person that thnks that if there is only ONE item in a chip it should be named UCSRA, but if there are two, for example, they would be labelled UCSR0A and UCSR1A grow up folks, those of us who have been writing software for a few decades or so really really REALLY don't like to have to change our source because you're too braindead to name things correctly to start with.

reply via email to

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