CAN Endianness

Notes on Endianness

Also, see Binary, Decimal and Hexadecimal.

If we try to transmit a number from the Pilot we expect the receiver to read it as the same value. Mismatched endianness can cause “unrecognisable” values at the receiver. If you take a CAN message, the common way to write it down may be as:

[PREAMBLE][BYTE1][BYTE2][BYTE3][BYTE4][BYTE5][BYTE6][BYTE7][BYTE8][POST]

This, electrically, means the most significant bit of the preamble is received first, through to its least, then the MSB of byte 1 to its LSB, then MSB of byte 2 ... all until the LSB of the postamble.

This representation is the style the Embedded Setup CAN dialogue presents, however, there are two separate issues that can come into play.

Byte Ordering: if only byte values are used then this has no relevance. However, if you send 16, 24 or 32-bit values, how may they be interpreted?

E.g. If we send a 16-bit value (i.e. of two bytes), the first being 0x12 and the second being 0x34; the Pilot, when sending as Most Significant Byte First, would put in the message:

[PREAMBLE][0x12][0x34][POST]

But a Least Significant Byte First receiver would argue the value received of [0x12][0x34] actually represents 0x3412 i.e. the bytes (but not the nibbles!) are reversed.

Worse still, some devices treat the whole bitstream as being the other way round. This means it is not just bytes that appear to have been reversed but the underlying binary ones-and-zeros.

There is a config named “CAN Endianness.test.ycd” in the Embedded Setup installation Configs folder that makes the CAN bus output 0x12345678 for each defined CAN stream slot. This is useful when compared with the receiver value to diagnose endianness mismatches.

For 32 bits, the following table shows resultant endianness switches:

For 24, 16 and 8 bits, the result will be a portion of the values given in the above table.

For example, if the receiver claims the value from Pilot is 0x1E6A2C48 then the receiver’s bitstream order is the opposite. If you see recognisable number like 0x12, 0x34 etc then you know the bit order is correct but possibly the byte order is wrong. If you see numbers like 0x1E or 0x6A then you may have a bit reversal and a byte reversal as well as the receiver cropping the value to a byte!

NOTE: Pilot can change the byte order from MSB to LSB but currently has fixed bit ordering.