Lpc2000

Hi, 

> There was an initiative to standardize a set of macros and library
> routines for ISO C for Hardware access.  I havn't heard of it in a
> while though.

There is a TR for Embedded C.  It has an unweildy set of crappy macros.
No wonder users have never heard of it, compiler vendors probably don't
want anything to do with it.  More odeous even than C99.

> >> Basically bitfields are a very bad idea for I/O.  Sooner 
> or later thay will bite you in the fundament.
> >
> > Why do you think so? Or is it so only with LPC?
> 
> Nope, all processors.  The issues off the top of my head are
>   - Bitfield order is implementation defined

Correct.

>   - Bitfield write is necessarily an RMW sequence which is 
> invalid for a lot of hardware and non-atomic on a lot of
> processors.

Actually, some ARM processors are now becoming available with bit-level
I/O to ports.  I'm thinking here of the MAC7100 series and another
that's coming up soon.  Writing a one or a zero to a single bit in an
I/O port simply becomes a 32-bit write to the bit-addressed register,
and reading that register returns a 0/1 based on the bit in the port.
You can write all 32 bits at a time too, if you need to.  The MAC7100's
I/O is actually pretty good, you can byte-write to part of the 32-bit
port register and only affect those 8 bits...

>   - Access size is indeterminate.

Certainly with language processors there is no need to define access
characteristics IIRC.

>   - Bitfields default to signed.

Yeah, just like plain "int" and mostly unlike plain "char".
Consistency?  ;-)

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors