LPC17xx: accessing C-type structs via bit-banding?

[lpcware]

Content originally posted in LPCWare by ntipping on Mon Sep 30 04:20:34 MST 2013
Hi All,

I'm looking to port an existing application from PIC18 to ARM, and am currently playing with the LPC812 LPCXpresso board as an introduction. If we move to ARM, it will probably be Cortex-M3 (in fact possibly LPC1758 - Ethernet with small footprint). The application we have makes extensive use of sub-byte(mostly bit) sized variables in arrays of unions/structs. Having realised now how ARM deals with bits, is there any way to map C-type structs into memory and have the compiler use bit-banding addressing where possible to access members? A simple example might be something like:

    typedef union 
    {
        unsigned char value;
        struct
        {
            unsigned char bit0:1;
            unsigned char bit1:1;
            unsigned char bit2:1;
            unsigned char bit3:1;
            unsigned char bit4:1;
            unsigned char bit5:1;
            unsigned char bit6:1;
            unsigned char Bit7:1;
        };
    }reg08;

    REG08    MyReg08s[20];

    int main(void)
    {
        while(1)
        {
            MyReg08s[10].value = 0; // byte access
            MyReg08s[10].bit2 = MyReg08s[5].bit3; // bit access?
            MyReg08s[10].bit4 = MyReg08s[3].bit6; // bit access?
        }
    }

As I understand it, the conventional approach would be to either word-align everything (expensive on RAM) or pack the structs and take the hit on code. But then again I'm new to this architecture. Could someone comment on what is possible?

Thanks in advance.

Regards,

Nick Tipping

[lpcware]

Content originally posted in LPCWare by ntipping on Mon Sep 30 10:03:44 MST 2013
Thanks for the advice rocketdawg.

Nick

[lpcware]

Content originally posted in LPCWare by rocketdawg on Mon Sep 30 08:44:52 MST 2013
OK, you are coming from a resource constrained 8 bit, so I understand all the data packing.
You will have to be careful that those unions do not access short or long variables that are not aligned.
secondly, all that bit crap just generates a lot of code in tradeoff for RAM which you now have 64K bytes not 3.5K
probably a big effort to refactor, but it actually takes less code to access a 32 bit variable than any other size variable.


Bit banding is an ARM thing, not a compiler thing.  So the compiler will not automatically use bit banding.

remember what bit banding is
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337e/Behcjiic.html
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0179b/CHDJHIDF.html

it is just an address alias.  there is some 32bit location in the SRAM bit band memory map (NOT SRAM memory map), when set to a 0 or 1, atomically clears/sets a corresponding bit in SRAM.  (Same for memory mapped peripherals)
so you could create 8 pointer variables whose addresses are the particular bit band address that correspond to the bits in a particular "unsigned char"
these pointer variables take up no SRAM space, since they already have storage in bit band memory map.
There are other method such as the CMSIS lib functions.

Now, if you really do not need the atomic nature of bit banding, then your current C code should still work (check for endian issues and compiler bit ordering, C18 is not GCC) .
And the code might be easier to read with the structure/union.

remember, interrupts are very inexpensive (12 clocks stacking).  Don't poll a 100/120 mhz CPU.
and do not forget to use DMA, it really is your friend.