[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: Eric Weddington
Subject: Re: [avr-libc-dev] Bit number/mask, Part 3000
Date: Mon, 10 Apr 2006 08:27:15 -0600
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

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

reply via email to

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