Lpc2000

Hi,

I read your message, which by the way is 10224 (not 10244), and I 
agree with you. However our problem is that we are using a library 
provided by the supplier of one of the chip we use (Profichip). So we 
have to leave with it unless we want to rewrite everything.
We tried the __attribute__ ((packed)) and also some pragma: #pragma 
pack(1) and #pragma align(1)- of course not all at the same time - 
this improved the first part of the structure but after the second 
sub-structure we continuously got a jump in the address (the compiler 
keeps on forcing alignment to 32bit there).
So we are going to start modifying the code.
Thanks for your input.
Regards,
Jean-Luc
--- In lpc2000@yahoogroups.com, "brendanmurphy37" <brendan.murphy@i...
> wrote:
>
> 
> 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
> >
>