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]>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.