Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Re: [lpc2000] Re: Looking to buy compiler

2005-11-08 by ????????? ???????

On Tue, 08 Nov 2005 04:47:49 -0500
  Tom Walsh <tom@...> wrote:
> vaneenbergen wrote:
> 
>>That the first bit of the second byte also changed is very possible. 
>>This is de to the processor. The timer register should be handled in 
>>a 32 bit access. this is what i found out. so instead of these kind 
>>of structures i just handle them in 32-bit. this way it is also 
>>quicker, you can change all values at the same time.
>>
>>is this really the fault of the compiler?????
>>  
>>
> He didn't understand what it was that he wrote so how can he answer 
>that 
> question?
> 
> 
> TomW
> 

What you mean? I think it obviously, that it's really fault of 
compiler. I explain my point of view to Paul
> 
> 
>>BTW using rowley and being very happy with it.
>>
>>Joost van Eenbergen
>>ELC lighting
>>
>>--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
>>  
>>
>>>Alex_Rambler wrote:
>>>
>>>    
>>>
>>>>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_!.
>>>>
>>>> 
>>>>
>>>>      
>>>>
>>>Huh?  I only see the LSB getting changed, where do you see a 
>>>    
>>>
>>second byte 
>>  
>>
>>>involved??
>>>
>>>_ldrb_ and _strb_ are byte operations, not word ops.
>>>
>>>You got what you said in the typedef, assignment of address to the 
>>>structure, and the the bit being set in T1MCR.  What is your 
>>>    
>>>
>>problem???  
>>  
>>
>>>As I read the code, nothing looks out of place, it all makes 
>>>    
>>>
>>sense...
>>  
>>
>>>TomW
>>>
>>>
>>>
>>>-- 
>>>Tom Walsh - WN3L - Embedded Systems Consultant
>>>http://openhardware.net, http://cyberiansoftware.com
>>>"Windows? No thanks, I have work to do..."
>>>----------------------------------------------------
>>>
>>>    
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 
>>Yahoo! Groups Links
>>
>>
>>
>> 
>>
>>
>>
>>  
>>
> 
> 
> -- 
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net, http://cyberiansoftware.com
> "Windows? No thanks, I have work to do..."
> ----------------------------------------------------
> 
> 
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 
> 
>

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.