For some time I am creating a CAN/Serial/Network protocol for equipment we are designing. After searching around to get some inspiration I found UAVCAN. The way UAVCAN is using the CAN transport is surprisingly similar to what I specified until now.
Therefore UAVCAN might be option for us to use in our products and contribute to the project. However there are a few things which holds us back.
- Having always a byte of overhead in the CAN payload. In CAN world this is a lot! Having, apart from the already high overhead of a CAN message, 50% overhead on the data part when sending 1 byte is huge. Therefore I would propose having a multi/single message bit in the CAN ID.
- Another ‘missing’ feature is to have a publish request. One could use a service request for it but this creates overhead in my opinion.
Combining these 2 points I made an example CAN ID field
This gives us 4 different message types:
- publish request
- service response
- service request
Furthermore it gives us a bit for single frame or multiple frame message. Single frame messages have 8 data bytes available. Multiple frame messages are similar as already described in your specification.
Are you willing to consider such changes?
By the way, I am very happy reading you switched using COBS for the UAVCAN/serial escaping. This is a big plus.