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

[Eric Weddington]

Vic Wagner wrote:

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

You don't seem familiar with the cons of bitfields:
- Implementation defined (as Joerg Wunsch mentioned)
- They cannot be used if a logical value covers non-contiguous bits
- You still have to use bitwise operators to toggle bits, not just set 
and clear.


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

Look, these are names of bits and registers in a datasheet. The compiler 
implementations are where those names are defined and implemented. If 
you have a problem with it, then you shouldn't be complaining about 
Atmel, you should go to the compiler vendors. Atmel is not a compiler 
vendor. They make chips. This way of naming registers and bits is 
nothing new. And, historically, C language cross-compilers have 
implemented it like this.

There are mechanisms available so you don't have to change your source 
code. You can always wrap things up in macros.

......

This entire thread smacks of a solution looking for a problem. Somebody 
please show me the masses of people who are outraged at how registers 
are defined, at how difficult it is to manipulate registers, and how the 
avr-libc project has no clue what it is doing. Go ahead. Point me to the 
numerous messages on the avr-libc-dev mailing list, the avr-gcc-list 
mailing list, the avr-chat mailing list, the AVR Freaks Forums, the 
comp.arch.embedded newsgroup, Yahoo groups, etc where complaints are not 
being heard.

If somebody wants to do a different implementation for themselves, 
that's fine. If you want to do something different for C++, that's great 
too. avr-libc is a Standard *C Language* library for the AVR for use 
with GCC. It is not designed for any other language. It is not designed 
to be used with any of the 5 known commercial AVR cross-compilers either.

I can't speak for Joerg, or Marek, or any of the other members of the 
project, but AFAIK, we all listen to reasoned arguments and we are open 
to new ideas. But we don't appreciate indiscriminate mud-slinging. We 
are *all* trying to find solutions to problems.

So, with that in mind, please show me a real problem. And a reasoned 
solution to said problem. This project then has to balance out many 
different trade-offs. I've even made proposals in the past that have 
been shot down because of conflicts and dealing with trade-offs. It's no 
big deal. Just keep at it.

--
Eric Weddington