Posted on July 31, 2006 at 21:43I must disagree with your analysis of 29-bit CAN ID's.
I am working in a automotive environment where the ID values are pre-defined. I have to discover whether the car I am attached to is using 11 or 29 bit addresses by sending a packet with the defined ID and see whether I get a responce.
In both cases I have a table of 11 and 29 bit ID's in hex to use. My application does not care which bits of the 29 bit ID are the ''base ID'' bits and which are the ''extended ID'' bits. I want to be able to put the hex value from the specification (ISO 15765-4) into the Id field of the canmsg structure and have CAN_SendMessage send a packet with the correct ID.
As far as I am concerned the ''correct'' behavior is:
Code:
11 bit ID:
A2R [12:2] (ID [28:18]) <- canmsg.Id[10:0]
A2R [ 1:0] (ID [17:16]) <- 0
A1R [15:0] (ID [15: 0]) <- 0
29 Bit ID:
A2R [12:0] (ID [28:16]) <- canmsg.Id[28:16]
A1R [15:0] (ID [15: 0]) <- canmsg.Id[15:0]
This is also true for setting the mask and arbitration fields of RX messages.
My primary evidence is that I have a tool that reports activity on the CAN bus and it reports the ID value [28:0] without any of the shifting the library code is doing.
Implementing it this way should make the librarly code smaller because all you need are 2 masks and 1 bit shift to load or store a 29 bit ID.
For application where you need to explicitly deal with the base and extended ID values, you can add macros to the library to generate 29 bit ID's from the components.
