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

[Joerg Wunsch]

As Bob Paddock wrote:

(About MISRA and bit-fields.)

> A *signed* integer requires two bits, one for the value, the other
> for the sign of the value.  Don't see that as an issue,
> as it would not make sense to have a signed register bit for I/O.

Sure, that way, it makes sense.  I'm pretty sure we won't have a need
for signed integer bit-fields in IO registers.

Actually, I've only seen one situation where a signed-integer
bit-field would have made sense during the past 10 years, that's the
"tx power" PIB attribute in the IEEE 802.15.4 PHY layer: while the
upper two bits of that attribute form an enumeration type describing
the tx power accuracy, the lower 6 bits form a signed integer
bit-field that allows to adjust or report the tx power in the range of
-32 dBm ... +31 dBm.

So I take it that introducing bit-field structures into the IO header
files would not get into the way of people who need MISRA compliance.
Good.

> > you could easily mix up the bit names (which are just numbers then),

> "Magic Numbers" are never allowed in the code, this includes the I/O
> usage.  Everything beyond the simple values like 0 through 9, are
> syboles.

I didn't imply magic numbers, but even with the current use of bit
names, you can easily confuse the registers which they have to be
applied to.  Been there myself.

> I agree.  If I was writing new code, and it did not make the code
> grow in size, or get slower, I'd use them, when operating on a
> single bit value.

When concerned about software safety, I'd even prefer them if the code
grew (because of becoming a read/modify/write operation rather than an
assignment), as it helps preventing fatal errors.  Obviously, unless
the code size growth or slower speed would be a real concern.

> My point was with backwards compatibility.

OK, take it as granted that backwards compatibility will be there.  So
far, we've broken that only twice in the past, and each time, it was
the reason to bump the library minor number: first was to get rid off
inb/outb/sbi/cbi, but they have been deprecated for years before
(actually they were already marked deprecated by the time avr-libc
1.0.0 was released).  The second one was the change in the
stdio/fdevopen interface, this was basically due to the experience and
user feedback, as by the time of its design, embedded stdio was a
completely new enterprise to all of us.

> I use Gimpel Lint myself, but there
> is also the open source Splint.  http://www.splint.org/

Does splint do MISRA checking?  That would be interesting.  I guess we
badly need someone to `splintify' our header files...

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

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