Endian Options

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mattferrari on Wed Nov 03 15:12:33 MST 2010
The LPC1756 is a "Little-Endian" device. When coding an application on the LPC1756 such as an interface to a "Big-Endian" oriented protocol like Modbus, the byte ordering of the LPC's native data storage is problematic.

Is there a Compiler Option in LPCXpresso/Code Red which allows for application data to be stored/retrieved in a Big-Endian format? Or are there any other provisions for doing so?

I know there is an Assembler instruction "REV" which will swap the endianness of a register and write the result into another register. I'm thinking that the Compiler might have the ability to tap this instruction to do this for application variables via a compiler option of some sort...?

Any guidance will be appreciated.

Thank You,

Matt

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mattferrari on Thu Nov 04 10:53:04 MST 2010
Thank you CodeRedSupport for your help - I appreciate your timely replies.

FallGuy - thank you for your idea about the DMA controller. This is an intriguing possibility. My application is to transfer a block of little-endian memory to a big-endian peripheral (serial port) so this at first sounds promising. But since the blocks of data to be transferred will be comprised of a mix of data types (character strings, uint16, uint32) this still may not work. I believe that the DMA Controller will uniformily perform byte swapping over the entire block of data being transferred and would be unable to discriminate between bytes comprising data types requiring swapping (uint16, uint32) and bytes comprising data bytes which must not be swapped (character strings).

Since apparently there is no way to create a big-endian data storage environment, it appears that I will need to discretely perform the byte swapping as needed prior to data storage and transmission. If I'm missing something, please comment - I would love to find a more elegant/global solution. In hindsight, I should have based this design on a big-endian processor, or one capable of being configured as such. Live and learn...

Thank you again for your responses!

Matt

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Thu Nov 04 01:58:31 MST 2010
The DMA controller has a Big-Endian mode, meaning you can use it to map your data to/from Little from/to Big.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Thu Nov 04 01:47:05 MST 2010
Sorry, this isn't a tools issue - it is a CPU / MCU issue. The Cortex-M3 has support for treating data as little endian or big endian - but this is a controlled via an input pin sampled by the CPU at reset. In the LPC17xx this pin into the CPU is tied to little endian mode. This cannot be switched during the execution of your application

For more information, please see the LPC17xx User Manual from the NXP website, and ARM's Cortex-M3 and Architecture v7M documentation (links for which can be found at http://support.code-red-tech.com/CodeRedWiki/ArmCpuInfo

Thus if you want to handle big endian data, you need to deal with the reversing yourself.

Regards,
CodeRedSupport

lpcware · ‎06-15-2016

Content originally posted in LPCWare by mattferrari on Thu Nov 04 01:08:12 MST 2010
Thank you for your reply.

Apart from actually using discrete "REV" function calls upon each interaction with a stored data value, I was hoping that there might be a global build option of some sort which would globally cause my variables to be stored & read back as big-endian instead of little-endian. Perhaps a compiler option or something?

I'm transferring blocks of data comprised of mixed data types, so I cannot universally apply a byte swapping function, because some data types (e.g. character strings) must not be byte swapped while others (e.g. uint32) must be byte swapped, and during transmission of a block of memory as a byte sequence, there's no way to differentiate between bytes belonging to character strings and bytes belonging to uint32 variables.

So I guess my question is: "Is there any provision available for globally manipulating the endianness of data storage when using the LPCXpresso / Code Red IDE with the LPC1756?"

Thank you for your help on this,

Matt

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Thu Nov 04 00:21:48 MST 2010
Assuming you are using CMSIS (http://support.code-red-tech.com/CodeRedWiki/Support4CMSIS), then this defines (in core_cm3.c / core_cm3.h) a number of functions to access the various REV related instructions, as these are not directly generatable from C:

/**
 * @brief  Reverse byte order in integer value
 *
 * @param  value  value to reverse
 * @return        reversed value
 *
 * Reverse byte order in integer value
 */
extern uint32_t __REV(uint32_t value);

/**
 * @brief  Reverse byte order in unsigned short value
 *
 * @param  value  value to reverse
 * @return        reversed value
 *
 * Reverse byte order in unsigned short value
 */
extern uint32_t __REV16(uint16_t value);

/**
 * @brief  Reverse byte order in signed short value with sign extension to integer
 *
 * @param  value  value to reverse
 * @return        reversed value
 *
 * Reverse byte order in signed short value with sign extension to integer
 */
extern int32_t __REVSH(int16_t value);

/**
 * @brief  Reverse bit order of value
 *
 * @param  value  value to reverse
 * @return        reversed value
 *
 * Reverse bit order of value
 */
extern uint32_t __RBIT(uint32_t value);

To use these, just make sure you [FONT=Courier New][SIZE=1]#include "LPC17xx.h"[/SIZE][/FONT] in your code and link with the LPC17xx CMSIS library.

Regards,
CodeRedSupport