Notes on Endianness

Also, see Binary, Decimal and Hexadecimal.

CAN Bus Slot Size

The Pilot can send stream data on the CAN Bus in 1, 2, 3 or 4 byte slots (i.e. 8, 16, 24 or 32 bit slots). The Pilot always truncates the value to be sent to the given bit-size before it is loaded into the CAN packet. So transmitting the value 0x12345678 on the bus with different modes will give the results shown below.

0x12345678 1 Byte (8 Bit) 2 Byte (16 Bit) 3 Byte (24 Bit) 4 Byte (32 Bit)
Sent as MSB First 0x78 0x5678 0x345678 0x12345678
Sent as LSB First 0x78 0x7856 0x785634 0x78563412

 i.e. you will always get the 0x78, but in bigger slots you get more of the number.

Note: changing endianness is NOT the way to try to fit larger-sized data values into smaller sized CAN slots. The correct method for this is described in the Maths sections.

On the bus

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:

 

Binary

Decimal

Hex

Pilot test value is always:

b00010010001101000101011001111000

305419896

0x12345678

All bits reversed

b00011110011010100010110001001000

510274632

0x1E6A2C48

Byte endian mismatch

b01111000010101100011010000010010

2018915346

0x78563412

All bits reversed and byte endian mismatch

b01001000001011000110101000011110

1210870302

0x482C6A1E

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.