Re: Using DLC or data byte count in frame in a CAN driver API

Am Donnerstag, 7. Februar 2013, 11:44:48 schrieb Kees Zagers:
> Hello other CAN freaks,
> 
> In my "simple" opinion the driver is the interface between hardware and
> application software in general. On the hardware side we only have the DLC
> and the number of bytes available. On the application side in the first
> place it is the layer 7 protocol which decides how the data and DLC should
> be handled.
 
> As J1939 allready determines the DLC to be 8 for almost all messages, I can
> imagine that they decide for the CAN-FD it will remain 8 for the standard
> messages and 15 for the high density/high speed messages.
 
> CANopen offers a lot more of flexibility. You can define all kind of methods
> in the protocol to define a "flexible" data length, but if you bring this
> to the driver I think you will need another driver for every protocol. I
> would think of some kind of profile in CANopen for the flexible CAN FD data
> length and the source code vendors offer this as an option.

But CANopen drivers already have to handle the flexible dlc code.
All SDO are dlc=8, all nmt dlc=2.
But PDO can differ always, at run time, depending on the mapping.

At the moment I think using the the number of bytes would be better than dlc,
but I don't like to take care in the driver of the bytes which has to be 
filled to reach the physical end of the frame.
Let's wait for more comments.

 
> Other protocols which like to have a flexible data length should have a same
> kind of procedure.
 
> Just my 2ct (or should I send one of our new 2 Euro coins with the heads of
> our leaving queen and our coming king; only 20 million will be made of it
> :-)

Strange Number, you only have 16.730.632 million people. Who is getting the 
remaining 3.269.368 coins. If its you Kees, then please, send me one. 
 
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]>