CAN-Bridge: Protocol enhancements
The protocol which defines CAN frame identifiers and payloads for inter-module µRT communication offers potential for optimization.
current definition
- frame ID
- bits 0-5: 6-bit frame counter for subsequent frames in case a message needs to be split in several 8 byte chunks.
- bits 6-21: 16-bit topic or service ID.
- bits 22-25: 4-bit transmission type (topic, xRT request or response).
- topic: 0b0000
- NRT request: 0b0001
- SRT request: 0b0011
- FRT request: 0b0111
- HRT request: 0b0101
- response flag: 0b1000
- bits 27-29: 3-bit board ID of the emitting module.
- payload
- arbitrary number of payload bytes
- eight additional payload bytes to hold the 64-bit timestamp
drawbacks
- CAN bitwise arbitration checks bits from MSB to LSB, so the first bits should hold the primary priority information, which is not the case right now.
- Only 8 board IDs (3 bits) supported.
- Transmission type definitions do not represent a sensibile hierarchy wrt. bitwise arbitration.
proposal
- frame ID
- Change order to (from MSB to LSB):
(order of 2. and 3. should be discussed or even made configurable)- transmission type
- board ID or topic/service ID
- topic/service ID or board ID
- frame counter
- Redefine transmission types:
(this would decrease this field to 3 bit)- 0b000: reserved for non-protocol, high-priority transmissions
- 0b001: publish-subscribe transmission (topic)
Time-based communication is typically most critical. - 0b010: HRT request
HRT denoted event-based communication has very high priority as well. - 0b011: response
This ensures that responses to HRT requests will not be suppressed by low-priority requests. - 0b100: FRT request
- 0b101: SRT request
- 0b110: NRT request
- 0b111: reserved for non-protocol, low-priority transmissions
- Increase board ID to 8 bit to allow for a reasonable number of modules in a system.
- Decrease topc/service ID to 11 bit (= standard CAN ID).
- Increase frame counter to 7 bit to allow for a maximum of 1024 byte payload per transmission (2⁷ frames á 8 bytes).
- Change order to (from MSB to LSB):
- payload
- Always transmit an additional frame containing the timestamp and meta information.
- Whether a request is flagged fire-and-forget is currently encoded in the frame ID via the response flag. Because those frame ID bits are very precious, this information should rather be encoded in the payload.
- Transmit the number of overall expected frames for the message.
- Transmit "incomplete" timestamp.
Since 58 bits (7 bytes) or even 52 bits (6 bytes) are still enough to represent reasonable time frames at microsecond precision (~9000 years and ~140 years respectively), one or two of the total 8 bytes could be saved for transmission and assumed to be 0. Since the frame counter is limited to 7 bits and only a single bit is required for the fire-and-forget flag, a single byte should suffice for meta information and 58 bits could be used for the timestamp.
- The timestamp & meta information frame should be prepended (not appended).
In case time or meta information is relevant during message parsing, this information should be available first.
- Always transmit an additional frame containing the timestamp and meta information.
- frame order
- time & meta information frame
Should use frame counter value of 0 for maximum priority. - payload frames
Frame counter should count downwards from n (total number of frames) to 1 (0 is reserved for the time & meta information frame).
- time & meta information frame
Edited by Thomas Schöpping