Actually, it’s rather intuitive. It’s obvious but for some reason, I did not see it. In the OP post, I said that the big-endian byte order with the current (big-endian) bit order would have been nice because its native representation of data matches what we use in text (assuming the standard positional binary system). In the case of little-endian bytes + little-endian bits the same holds if the bit string is inverted such that the most significant digit is on the right.
Take the above example: (uint5)14 + (uint8)187 = 01110 + 10111011. The obvious case of big-endian bit/byte ordering:
- Concatenated:
01110 10111011 - Padded to 8:
01110 10111011 000 - Split into bytes:
01110101 11011000 - As hex: 75, D8
Same in the case of little-endian bit/byte ordering but the concatenation operands are inverted and the final byte swap is added to account for the fact that the numeral system is bit-big-endian:
- Concatenated:
10111011 01110 - Padded to 8:
000 10111011 01110 - Split into bytes:
00010111 01101110 - Swap bytes:
01101110 00010111 - As hex: 6E, 17
We should switch to little-endian. I am going to merge https://github.com/UAVCAN/pyuavcan/pull/99.