Lpc2000

\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd \ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd wrote:

>>Alex, 
>>
>>    
>>
>>>b> Just one data point, but: I'm a professional developer (30 
>>>years s/w 
>>>b> development experience from micros to mainframes).  Now working 
>>>on 
>>>b> third LPC-based commercial product.  Compared Keil, IAR, 
>>>and gcc and 
>>>b> chose Rowley Crossworks (gcc-based).
>>>
>>>Oh, I can't hold out from the reply.
>>>I tried to use Crossworks in the begining to explore LPC2xxx.
>>>It ugly work with the structures. I tried to define T0MCR like
>>> struct:
>>>{{
>>>typedef struct
>>>  { 
>>>    __REG32 MR0I :1;
>>>    __REG32 MR0R :1;
>>>    __REG32 MR0S :1;
>>>
>>>    __REG32 MR1I :1;
>>>    __REG32 MR1R :1;
>>>    __REG32 MR1S :1;
>>>    
>>>    __REG32 MR2I :1;
>>>    __REG32 MR2R :1;
>>>    __REG32 MR2S :1;
>>>    
>>>    __REG32 MR3I :1;
>>>    __REG32 MR3R :1;
>>>    __REG32 MR3S :1;    
>>>    __REG32      :4;    
>>>} __txmcr_bits;
>>>
>>>#define T0MCRbits (*(volatile __txmcr_bits *)0xE0004014)
>>>
>>>}}
>>>
>>>but when I handle to it, Crossworks GCC compile it to this code:
>>>
>>><<T0MCRbits.MR0I = 1;>>
>>>
>>>mov r3, #0xE0000000
>>>add r3, r3, #0x00004000
>>>add r3, r3, #0x00000014
>>>ldrb r2, [r3]
>>>orr r2, r2, #0x00000001
>>>strb r2, [r3]
>>>
>>>so, I get change in LSB and _in_the_second_byte_!.
>>>      
>>>
>>And you tell me *why* this is incorrect code generation?  You might 
>>not
>>like what is generated, but is is *not* incorrect according to the
>>standard.  It is only incorrect *if* you think volatile has some 
>>extra
>>meaning above what it does in the standard.  Or *if* you think an
>>"unsigned long" bitfield is somehow "standard".  That is why the
>>Embedded C TR has I/O support.  Volatile does *not* mean "I'm 
>>dealing
>>with a device" or "Access this data atomically".  Far from it.
>>    
>>
>
>I tried to explain my point of view in other mail.
>The generated code works incorrectly because it use BYTE instructions. 
>You can compile it, load into the chip and debug. We discuss compiler 
>for ARM core, or what? I think IAR, Keil compilers know about data 
>access in the ARM core.
>
>  
>
You are very very confused...  You have absolutely no idea what "__REG32 
MR0I :1" means, do you???  It is obvious that you are operating under 
some other understanding of just what it is that you wrote.

Go have someone explain it to you, it would take too long to do here.

TomW

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------