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

Besides the buffer and the length, you would also need to be able to specify
the 'zero' value for the padding bytes in your message.

So this would boil down to something like

void send(byte* buf, byte size, byte dlc, byte zero=0)
- buf = pointer to buffer
- size = size of buffer
- dlc = size to send [0-8,12,16,20,24,32,48,64,0xff] where 0xff means
autosize
- zero = value to use for padding if size is different from CAN FD frame
size

cheers,
Bram

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of John
Dammyer
Sent: woensdag 6 februari 2013 22:05
To: [email protected]
Subject: RE: [CANLIST] Using DLC or data byte count in frame in a CAN driver
API

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



--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[email protected]>