Unaligned memory access through pointer in cortex-m3

Hi friends, I am using stellaris LM3s6965 micro-controller, Keil (MDK-ARM 4.20) as IDE.

I want to know the alignment restrictions on using pointer of following type.

Uint8_t * (unsigned char 8-bit) Uint16_t * (unsigned 16-bit) Uint32_t * (unsigned 32-bit)

I need to access 32-bit or 16-bit data from a memory buffer. There is no guarantee that address will be aligned. In this case what should I do?

Thanks & regards, Kishore.

Reply to
kishor
Loading thread data ...

I'm not familiar with the LM3s6965, but the Cortex-M3 core allows unaligned accesses. It does have the option to generate a fault on such an access, so you have to make sure this is disabled (this is the default after a reset)

For best performance, you'd want to use aligned accesses as much as possible, though.

Reply to
Arlet Ottens

Declare the buffers as 32 bits array. The compiler should take care of the alignment.

Reply to
linnix

Why "there is no guarantee"? Do you have control on how these buffers are defined/created?

If they are "malloced", they should be aligned properly for all built-in data types.

If they are defined explicitly, tricks like this will assure proper alignment:

union align32 { Uint32_t anchor; Uint8_t buffer8[???]; Uint16_t buffer16[???]; };

Your compiler may provide something like "#pragma align" to do the same, (I'm not familiar with Keil tools), or a #pragma to control what memory section is used for the buffers, and then the alignment for that section can be specified in the linker configuration file.

If none of the above is doable, you can just take a performance hit when accessing unaligned 16/32-bit data.

Lastly, if you need the code to be portable to architectures that will not allow unaligned memory accesses, write read_u16(...) / write_u16(...) / read_u32(...) / write_u32(...) functions working on

8-bit values only.

-- Roberto Waltman

[ Please reply to the group, return address is invalid ]
Reply to
Roberto Waltman

Thanks for quick replies.

The buffer is 8-bit array of 512 bytes. It contains data protocol mixed with 8-bit & 16-bit data types. so all data access can not be aligned.

Method -1 Disable the unaligned access fault Read unaligned data from buffer Enable the unaligned access fault

Did disable/enable "unaligned access fault" process takes time?

Method - 2 Read multiple 8-bit data through 8-bit pointer Pack them to 16-bit or 32-bit variable

Which is the better option for efficiency & performance. I don't want to port this code outside of cortex-m3.

Thanks & regards, Kishore.

Reply to
kishor

Thanks for quick replies.

The buffer is 8-bit array of 512 bytes. It contains data protocol mixed with 8-bit & 16-bit data types. so all data access can not be aligned.

Method -1 Disable the unaligned access fault Read unaligned data from buffer Enable the unaligned access fault

Did disable/enable "unaligned access fault" process takes time?

After disabling the unaligned memory access fault, will its performance affects on aligned memory access too? If not then I can disable the fault at reset. I will try aligned memory access as much as possible.

Method - 2 Read multiple 8-bit data through 8-bit pointer Pack them to 16-bit or 32-bit variable

Which is the better option for efficiency & performance. I don't want to port this code outside of cortex-m3.

Thanks & regards, Kishore.

Reply to
kishor

Enabling/disabling the fault only takes a single write to a register, so it's negligible. You could also leave it disabled all the time, as long as you pay attention to the alignment of your other variables.

Unaligned reads are going to be faster than single byte reads and assembling the data yourself.

In some cases there are some other options, such as copying a block of data to align all its variables at the same time. Of course, this only works if all variables inside the block are mis-aligned in the same way. This may be combined with CRC calculations and/or copying the headers to faster memory.

Reply to
Arlet Ottens

Thanks Arlet Ottens.

Reply to
kishor

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.