Lpc2000

Alan Strickland wrote:
> I agree, avoid using bit fields.  How bit fields are implemented is
> compiler dependent.  Granted many (all?) compilers give the option of
> signed/unsigned and such, but I'd prefer to avoid that issue entirely.
>  Plus accessing individual bits can be wasteful as far as code size is
> concerned, and flat out may not give the results you want.
> 
> Last year I had one piece of code that crashed the system when it ran.
>  I was setting up the EMC register and GPIO for external RAM by using
> bit fields, and the code died a miserable death.  After I replaced it
> with simple register assignments it worked. I learned my lesson and
> ripped out every bit field definition I had.  Bit fields are in the
> grey area of C/C++ standards and are probably best left out of code.

Just to add to the 'never use bit-fields advice', here's an article
I found a while ago (where the author calls bit-fields brain-dead) ...

A 'C' Test: The 0x10 Best Questions for Would-be Embedded Programmers
by Nigel Jones

http://www.embedded.com/2000/0005/0005feat2.htm

I can relate an experience with bit-fields. I was using a TI DSP and
TI had provided a library that used bitfields. I dutifully wrote
additional code that looked similar. When I went use the code
over the PCI bus - things broke! The reason was that some PCI
devices expect 32-bit accesses, since the hardware (eg. a 32-bit
wide register) ignor the PCI bus byte enables. I took a look
at the assembler code produced by GCC and noticed that the
bit-field code was translated to by assembler commands.
For comparison I took that same code and built with Visual C++,
and it produced code that used 32-bit instructions (x86 host).

So, I never used bit-fields again ...

Cheers
Dave