Lpc2000

5:08:07 PM, Wednesday, March 1, 2006, Robert wrote:

>>> In 8051 to set a bit we use
>>> P1_7=1;
>> typedef struct
>>  {
>>    unsigned long n0:1;
>>    unsigned long n1:1;
>>    unsigned long n2:1;
>>    unsigned long n3:1;
>>    unsigned long n4:1;
>>    unsigned long n5:1;
>>    unsigned long n6:1;
>>    unsigned long n7:1;
>>  } BITS32;
>> #define P1 (*((volatile BITS32 *)  0xE0028014))
>>
>> #define P1_7 (P1.7)
>>

> Not portable even between compilers.  For non-I/O code this is just 
> fine but for
> operations involving I/O this may produce unexpected results.  IE the compiler
> may produce perfectly valid code from the viewpoint of what the language is
> specified to do but it may not actually work with the I/O.

> In particular with this construct you could get a 8 bit I/O operation,
> a 16 bit
> I/O operation or a 32bit I/O operation.

 I agree, it should be tested. IAR uses operations according to
bit field type, GCC shorten to byte. IAR acceptable.

> Also if you have a different read and write register at the same 
> address you may
> get really odd results.

 My variant uses the same register for read and write. It is possible
for LPC.

 There is another solution. Use C++, create class "port" and overload
operator=(int) and int(port). But some overhead will be unavoidable.

> 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?

 WBR,  Alex