|
I think there are few things that need to be clarified on this KCAN:
1)I dont know if KCAN is utilizing some standard protocol I am not familiar with or if it is propretiary.
2)Is this purely a Master/Slave protocol or is there some peer-to-peer communications?
3)Something to consider when looking at the data field in the frame of the KCAN packet is the Endianess. I'm not entirely sure if they are using big or little in this case.
Ok, lets add some more for those who havent already nodded off:
There are some aspects mentioned in the previous reply that are typical of how most protocols use the CAN bus identifier (CAN ID) but we should be cautious in assuming that is what BMW has done here. They may not have implemented any form of message "typing" or classification within the CAN ID.
The CAN ID can contain information concerning direction (Master/Slave or TX/RX) but its left up to the protocol. I know Honeywell's old SDS protocol uses the most significant bit (MSB) for precisely this function and I believe CANopen does as well (havent worked with this one much), although a protocol like DeviceNet however does not.
Although it is possible for multiple nodes on a bus to use the same CAN ID, the one consistency throughout most CAN protocols is to define some bits in the CAN ID as a means to specify a unique address for all the nodes on the bus. This generally simplifies the hardware requirements (i.e processing power) necessary to process through the traffic on the bus, which in turn keeps the manufacturing costs down. In this case a global mask on the node's CAN controller is typically configured relative to that nodes "address" to filter out traffic that it is not interested in. As most protocols do use message classification, CAN controllers also typcially have a group of message boxes with their own programmable masks to simplify handling.
|