RE: Using DLC or data byte count in frame in a CAN driver API
"John Dammyer" <[email protected]>
| Newsgroups | gmane.comp.hardware.bus.can |
|---|---|
| Message-ID | <[email protected]> |
Heinz, I think it will be better to use a parameter for length of data to transfer and one for the DLC value. Probably the biggest reason is that the amount of data that is relevant in say a 48 byte message might only be 40 bytes. In the past, we sent CAN messages that had a Data Length Code that matched the number of bytes we wanted to send. But now we really want to specify the transport packet size and also how many bytes to transfer from the API into that packet. There's no point in moving an extra 8 bytes of what may well be undefined anyway into our 48 byte packet if all we want to send is 40 bytes. For example, CAN messages that have ASCII strings for logging state machine names and states could be up to 48 bytes long but might only occupy 13 bytes. A standard reporting module would just send 48 byte length packets with a null terminated string. The API to driver though can't assume the null termination so a string length is a good idea. John Dammeyer -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Heinz-Jürgen Oertel Sent: February-06-13 12:23 PM To: [email protected] Subject: [CANLIST] Using DLC or data byte count in frame in a CAN driver API Hello, currently some of us working already on integrating CAN FD in different CAN device driver software. In the past we had the Data Length Code DLC, which was a one to one translation to the number of bytes in a CAN frame. This was used in the API for receiving and transmitting CAN frames. With CAN FD that is more tricky. There is the following relationship: DLC bytes ------------------- 0 0 1 1 ... 8 8 9 12 10 16 11 20 12 24 13 32 14 48 15 64 The question is now: - should we still use the DLC when exchanging data between user application and driver - should we use a 'length' as number of bytes - or both, (but who takes care that both fit together?) Any suggestions and ideas are welcome. May be some of you are later working with such kind of software. It's on you to define the interface. Regards Heinz -- Archives and useful links: http://groups.yahoo.com/group/CANbus Subscribe and unsubscribe at www.vector.com/canlist/ Report any problems to <[email protected]> -- Archives and useful links: http://groups.yahoo.com/group/CANbus Subscribe and unsubscribe at www.vector.com/canlist/ Report any problems to <[email protected]>