Lpc2000

lehmannjluc wrote:

>I have the following structure definition:
>=========================
>#define PTR_ATTR                
>#define VPC3_PTR                PTR_ATTR *
>typedef struct
>{
>    UBYTE int_req1;
>    UBYTE int_req2;
>    union
>    {
>        struct
>        {
>            UBYTE int_reg1;
>            UBYTE int_reg2;
>            UBYTE status_L;
>            UBYTE status_H;
>        } (ULONG rd);
>        struct
>        {
>            UBYTE int_ack1;
>            UBYTE int_ack2;
>            UBYTE int_mask_L;
>            UBYTE int_mask_H;
>        } wr;
>    } isreg;
>    UBYTE mode_reg0_L;
>    //....and so on with various union and sub-structure.
>}  VPC3_STRUC;
>#define VPC3_STRUC_PTR    VPC3_STRUC    VPC3_PTR
>extern VPC3_STRUC_PTR     p_Vpc3;
>=========================
>This structure is used to point to a real hardware address.
>And the code is:
>=========================
>#define EM_START_ADDR_BANK3	(0x83000000)
>#define VPC3_ASIC_ADDRESS	(EM_START_ADDR_BANK3 + 0x0000)
>    p_Vpc3 = (VPC3_STRUC VPC3_PTR)VPC3_ASIC_ADDRESS;
>=========================
>But when we compile using the Ashling dev tools with GNU compiler 
>version 3.4.2 for a LPC2214 ARM, I have an alignment problem.
>&p_Vpc3->int_req1 points to 0x83000000 (which is correct) but whereas 
>I would expect &p_Vpc3->isreg.rd.int_reg1 to point to 0x83000002, it 
>points to 0x83000004 (same for &p_Vpc3->mode_reg0_L which points to 
>0x83000008 rather than the expected 0x83000006) and so on with the 
>following byte of the structure.  
>It looks like the compiler aligns the union on 32 bits, so drop an 
>empty 2 bytes after int_req2 element.
>I searched the archive for similar problem, but also I found some 
>alignment questions, none matched my problem or where even close.
>  
>
Oh it is a common problem for an 8 bit programmer coming into a 32bit 
world, not just ARM but other processors.

There was a series of emails, recently, regarding data alignment of 
structure and ANSI standards.  The gist of that is that structures are 
begun on 32bit boundries (ARM) and the internal members are aligned in a 
fashion that is "comfortable" for the processor to access.

You may want to look into the "__attribute__ ((packed))" keyphrase of 
your C sources.  Also take a look at the objdump utility to see how the 
compiler generated your code..

TomW






>I am using a library supplied by the hardware chip manufacturer and I 
>cannot just rewrite the whole library.
>What could be done to force the compiler to point byte after byte and 
>not align to 32-bit ARM word ? If it can be done at all...
>
>Thanks in advance for any help you can provide,
>Jean-Luc Lehmann
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>


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