Generally, dice devices are freely programmable and the CAN bus can be used by the developer in any way it is desired. Nonetheless, the supplied libraries (e.g. CAN2SER protocol) and the bootloader use a common addressing scheme with the following features:
- Each node has one unique CAN-ID to send messages
- Each node has one unique LID (local ID) to be addressed
- Broadcast messages are supported
- Up to 4 communication channels between two nodes possible
The device addressing covers the layer 3 (network) of the OSI model and the bootloader- and CAN2SER-protocol are built on top of this.
Hint: Recommended device settings can be found here
Parameters / Settings
As mentioned each node gets a unique CAN identifier to send messages. This CAN-ID is part of the bootloader settings and stored in the protected area of the flash memory (see users manual) of the device. It can either be modified by the dice configTool or by the library provided.
fig1) Unique CAN ID per node
Now each node can send messages on the bus with its unique CAN-ID. All other nodes may listen on this particular ID to receive the messages knowing exactly who the sender was. The listening is normally done by means of hardware-based CAN filters. This has the advantage of not burdening the processor with this task.
fig2) Listening for a specific CAN-ID
If node 1 now sends out a message, how would the other nodes know if this message is addressed to themselves or for any of the other nodes?
fig3) several nodes listening for messages with the same ID
This is solved by the LID (local ID) which is coded into the first data byte of the message. Every node gets a unique LID which is its receive address. The sender has to ‘know’ the peers-LID he likes to send a message to. This makes it possible to maintain several peer-to-peer data links to different peers. The addressing scheme understands the LID 0 as broadcast messages. So messages with the LID 0 are addressed to all node that are listening for messages from this sender (CAN-LISTEN-ID).
The following figure shows a few example messages using this addressing method:
fig4) example messages
In the picture above, node 1 sends a message to node 2 and then a message to node 3. Node 3 then sends a message to node 1. This means node 1 communicates to node 2 and node 3, whereas node 2 and 3 talk to node 1.
The example illustrates the four values that are required to for each node to hold per communication link:
– CAN-ID (the node sends messages with this CAN-ID)
– CAN-LISTEN-ID (the node filters and listens for messages with this CAN-ID)
– LID (the own LID / address ID)
– PEERS-LID (the LID of the destination node)
Recommended settings
By default each dice-device will be delivered with the same default bootloader settings:
CAN-ID: 0x766
CAN-LISTEN-ID: 0x765 (CAN-ID of the PC)
LID: 1
PEERS-LID: 63 (LID of the PC)
These are the settings that are used by the bootloader and the auto-created CAN2SER object Serial to communicate to the PC tools. In case your application has more then one dice-device on the bus, it is recommended to modify theses settings as follows:
| Node | CAN-ID | LID (local ID) |
|---|---|---|
| Device / Node 1 | 0x766 (default) | 1 (default) |
| Device / Node 2 | 0x767 | 2 |
| Device / Node 3 | 0x768 | 3 |
| Device / Node 4 | 0x769 | 4 |
| and so on ….. |