Service and Data Identifier
Two key components of a Kvaser Management Interface CAN message are the Service Identifier (SID) and Data Identifier (DID). The SID identifies the action the message is requesting be performed and the DID, the parameter the action will be performed on. Together, they form the message’s intent.
SID
In total there are 5 available SID. Each are identified with a 4 bit SID code and relate to a general action that can be requested. They are as follows:
0x1: Reset – Represents various degrees of resetting the Air Bridge one-to-any device. This is executed after acknowledging the reset on the CAN bus.
0x2: Read Data – Reads various parameters as determined by the DID and returns the requested data via an acknowledgement frame.
0x3: Write Data – Writes to various parameters of an Air Bridge one-to-any. The parameter is determined by the DID.
0x5: Runtime Status – A User application can be notified via an event or request data with this SID.
0x6: Runtime Configuration – Used to configure properties of an Air Bridge’s behavior or performance during runtime. Changes are immediate or after power cycle depending on specific request.
The SID is combined with the Routing bit in the frame which denotes which device, the local Air Bridge one-to-any or the remote Air Bridge one-to-any our local device is connected to, is to act on the instructions given. With 0 denoting the local device, and 1 denoting the remote Air Bridge one-to-any. Because of this, in tables breaking down a Management Interface CAN frame, you will often see the segment containing the Routing bit and Service Identifier abbreviated together as RSID.
DID
While the available SID represent a few general action archetypes that cover a range of possible behaviors, the 2-byte Data Identifier works in combination to narrow the intent further and identify specific parameters or commands relating to the accompanying SID. Let’s take a look at a few examples now.
Changing bit rate via the Management Interface DID 0xE0D1
For this demonstration, let’s set our bit rate to 250 kbit/s. While the Air Bridge one-to-any does default to automatically attempting to detect the bit rate, there is a short delay, normally around 15 seconds, upon power on as the Air Bridge one-to-any attempts to detect the bit rate. For systems where every microsecond counts, it may be more convenient to simply assign a bit rate to the Air Bridge one-to-any rather than leave the device set to auto-baud.
To change the bit rate, we need to first select the SID. As we will need to write new parameters for the device, we need the Write Data SID which is 0x3, however we haven’t yet combined the SID with our Routing bit to denote whether we’re changing the bit rate of the local Air Bridge one-to-any or the remote device. As we want to change the bit rate of the local Air Bridge one-to-any, the Routing bit should be set to 0. This gives us the RSID of 0x03.
Next is to select our DID. Using the Management Interface Guide available on our Downloads page and looking under the list of DID available for the Write Data SID, I can see the DID for writing the CAN speed is 0xE0D1.
Finally, we need to include the new value for the parameter. CAN speed is 4 bytes and has five available options with the remaining values being reserved. These options are as follows:
0: Auto-baud
1: 125 kbit/s
2: 250 kbit/s
3: 500kbit/s
4: 1 Mbit/s
Now all that needs to be done is set the data field to 2 and our frame is complete. Remember to pad the unallocated bits with 0’s! An example of our frame can be seen below.
