Playing with the NXP FlexCAN peripheral makes me realize we should handle endianness in the serialization logic. The issue is that, for some weird reason, FlexCAN transmits everything as 32-bit/big-endian even when used on a CPU architecture that is 32-bit/little-endian (I consider this weird because it makes word-size matter to the CAN peripheral and CAN is simply byte oriented in the data section). Regardless, since this can’t be changed, it would make sense to parameterize serialization logic with word-size, CPU endianness, and wire-format endianness (native). This would allow the output of the serializer to be handed directly to hardware without further byte swapping and would allow deserializers to consume hardware buffers directly. The direction we are heading in today with libcanard and libuavcan would lead to a blanket byteswap for all TX/RX buffers by the peripheral.
This FlexCAN behavior is supremely weird and I am not aware of a single other CAN controller that would do such a thing. Given that this is such an extremely special snowflake, do we really want to pollute our platform-agnostic libraries with special cases just for it?
by volume this is not on outlier. This IP is in several different NXP product lines.
If we ended up supporting this, I would like this feature to be very optional, hidden somewhere in the advanced rarely-used sections of the user documentaiton. People are sometimes prone to misunderstanding things, I don’t want one to get the impression that the byte ordering of the protocol itself is configurable. This feature also leaks the abstraction maintained by the media layer to the DSDL layer across the transport layer; it is difficult to predict if there are any hidden maintenance costs in there.