Lpc2000

Hi,

Check out a recent post - message 10244.

Your example simply re-enforces the point I made there: trying to map 
hardware registers onto structures/bit-fields is just asking for 
trouble. Unfortunately, this is mostly discovered by (bitter and 
painful) experience.

There's a suggested alternative approach in message 10244, which has 
the advantage of simplicity and most importantly will not fail, 
regardless of compiler.

As others have pointed out, using "packed" structures can help on 
your specific point, but similarly as others have also pointed out 
can introduce yet more problems related to allignment.

Hope this helps!

Brendan

P.S. If someone can say why using structures/bit-fields is a 
recommended approach for accessing hardware, I'd be interested in 
hearing it. Maybe I'm missing something....

--- In lpc2000@yahoogroups.com, "lehmannjluc" <lehmannjl@n...> 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.
> 
> 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
>