This protocol let you to ‘tunnel’ serial data over the CAN bus. Since it is build on top of the addressing scheme, it allows to maintain numerous independent serial connections between all devices on the same CAN-bus.
The CAN2SER protocol is implemented in the CAN2SER – Library for embedded devices and in the CAN2SER-monitor tool on PC-side. It features:
- up to 4 serial peer to peer/PC channels between the same two devices
- handshake mechanism to prevent data to get lost or the buffer to overflow
- rotating message counter to ensure complete data reception and in the right order
- alive and status signalling between the peers
- peer discovery and identification mechanism
As a developer of applications there would normally not be any reason to get involved with the details of thís protocol, because it is all encapsulated in the library . The following is for the ones who like to look under the hood or like to write an implementation for a different target architecture etc.
The CAN2SER protocol basically consists of the definition of only one CAN message (simple -> beautiful) as the following figure shows:
The components:
– CAN-ID
– LID (local ID)
– Channel
are part of the addressing scheme (see Device addressing ) and will not be discussed here any further.
DB1: this byte is 0x20 – and thus identifies the CAN2SER protocol.
DB2: xxxx yyyy
xxxx: status nibble
yyyy: rotating message counter
Status (xxxx):
0x0y – it is a data message
0x8y – (re)Start
0x9y – OK (ready to receive)
0xBy – NOK (not ready to receive)
0xCy – Stop handshake
If handshake is active then we send out statues (xxxx != 0):
– at start
– whenever the status changes (eg. status NOK if our input buffer is full)
– each time the counter reaches 0x0F and
– each 500 ms (to signal being alive)
Counter (yyyy): Message counter that will be incremented by 1 by the sender with each message [0 … F].
The receiver validates the incoming messages accordingly.