What are some techniques to deal with this issue as I am currently trying to write a communications module using Modbus. If the struct containing ints, floats etc is typecasted to chars for Tx/Rx, how to dynamically detect a variable change and thus a required byte swap?

Thanks!
Jeet

as far as structure fields with bit fields, they are reversed

I do this when needed, and see no issue with it.

@steve: The C compiler is not required to pack structures, and though many compilers can be forced to do this it is silly to rely on it.

Compilers have some sort of “#pragma packed” for this very issue. I jusrt dealt with it reading in a structure on an external EPROM on a replaceable item (the EPROM provides info on the item’s use).

BUT – packing and byte sex are unrelated.

@steve: The argument that if the local byte order is “correct” then it will be more efficent is also foolish, again I/O is the limiting factor.

Agreed – but the real issue is you still need to read a struct from something external and turn it into the “native” format – sometimes a packing issue, sometimes a byte sex issue; sometimes both.

The only reason to create an unpacked version of the struct and laboriously transfer the fields from the original to the copy is the native version will not support the packed fields, ie a byte takes 16 bits, or you cannot access a byte on an odd address.

@steve: Oh dear, have I started ranting again…

It’s OK, you are in good company, and the drugs should kick in right about … now :^)

@OP: If you stay completely in the native CPU/memory/peripherals, you rarely need to worry about byte sex. HOWEVER, the embedded world does not have this luxury. Embedded systems of any complexity *always* deals with protocols and devices on the “outside of the CPU”, so byte sex is one of the issues.

As noted before, the C preprocessor can easily deal with this:

#if SWAP_BYTE_SEX
#define SWAP16(x) swap16( x )
#else
#define SWAP16( x ) x
#endif

ptr->field = SWAP16( ptr->field );

is perfectly OK. I prefer to pass in the address of the field, and have the code swap in place, but that is a style issue:

swap16( &(ptr->field) );

put all of the swap calls in a single function that can be ignored if needed.

It’s been a while since I worked on an x-86 platform, but last I saw, they used either a fixed little endian or defaulted to little endian with a boot configurable option for big endian. If they have an on-the-fly adjustment now, I’d like to see the details, but last I was aware, this was also just a boot option. I don’t think an auto-detect scheme would work well since, even if you could detect CPU opcodes, you would still never know the format of external data and there would be no way to auto detect that. In any case, I would expect this to produce a small efficiency cost on the CPU as well.

The problem with the boot configuration option is that it tends to just make things more confusing. It’s almost always less efficient for the CPU core and it just adds extra points of potential confusion and failure to the platform development when developers may expect the platform to operate in the native configuration. Most production or architecture teams will never use the option since it creates more complexity than it solves.

Most standardized software suites have headers and driver interfaces that bury this at the lower levels, so it might be semi-transparent to application layer coders. Applications would rarely need to deal with this unless they were looking directly at a raw data packet that had not been processed for the host format or if a file with raw numeric data is transferred from one host file system to another without adjusting (like between MSWin and NIX systems.)

Driver developers need to deal with this at peripheral device input or other external data sources. Most external data devices and protocols do not include the endianness data in the data stream or packet, they define it hard-coded in the device data interface spec based on the device family or manufacturer. Some communications protocols, like ethernet, define a fixed format for all standard data on the network side. Others, like CAN or SPI, define endianness in the definitions for messages or individual values.

Once the data is conditioned for the host, you rarely need to deal with this for internal system processing. As Dennis mentioned above, it’s generally an issue at system boundaries.

Other than that, the main time I think about endianness is during debugging, when I call a generic dump function that dumps bytes in hex and ASCII. If it is a structure that I am dumping, I have to be pay attention to both endianness and alignment issues.