avr-libc-dev
[Top][All Lists]
Advanced

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

Re: [avr-libc-dev] New device support


From: Joerg Wunsch
Subject: Re: [avr-libc-dev] New device support
Date: Sat, 14 Jul 2007 21:24:18 +0200
User-agent: Mutt/1.5.11

As Bob Paddock wrote:

> > union tccr0b {
> >     uint8_t byte;
> >     struct {
> >             uint8_t cs0: 3;
> >             uint8_t wgm02: 1;
> >             uint8_t : 2;
> >             uint8_t foc0b: 1;
> >             uint8_t foc0a: 1;
> >     } bits;
> > };

> MISRA-2004 rule 6.4: "Bit fields shall only be defined to be of type
> unsigned int or signed int."

OK, accepted.  The C standard explicitly only makes guarantees that
signed int, unsigned int, or _Bool (C99) are mandatory to be supported
as type names for bit-fields.  My only concern was that declaring them
as `unsigned int' rather than `uint8_t' would extend the size of such
an object to 16 bits (sizeof(unsigned int)), but that doesn't appear
to be the case.

> Rule 6.5: "Bit fields of type signed int shall be at least two bits
> long".

That makes no sense at all to me (but that's not surprising with
MISRA, I'd say ;-).  I don't see any value in that requirement, and
it's in the way not only of using bit-fields for IO bits as proposed
here, but also of using bit-fields as space-saving bit variables which
can sometimes be useful in a microcontroller environment.  But
obviously, MISRA is not concerned about resource consumption anyway.

Given that it prevents you from using IO bit names, it's even
counter-productive for MISRA's purpose: doing it the classical way,
you could easily mix up the bit names (which are just numbers then),
and e.g. try to assign WGM02 to register TCCR0A rather than TCCR0B,
yielding something completely different than you intended.  This
cannot happen when saying »TCCR0B_.wgm02 = 1;« because the wrong
statement »TCCR0A_.wgm02 = 1;« would not be accepted by the compiler.

> I do hope that the existing format will be supported along with this
> new bit field format?

Yes, that's been my intention.

The question arises then: do you need a compile-time option (say,
define _NO_IO_BITFIELDS from the command-line) to turn IO bit-fields
completely off so they won't be seen by the MISRA checker?  Or would
it be sufficient if they were present in a header file but are not
used by your code?

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)




reply via email to

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