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.