Re: Standard CAN over IP

[Oliver Hartkopp <socketcan@hartkopp.net>]

On 23.02.2015 13:25, Maximilian Güntner wrote:

> 2015-02-20 12:43 GMT+01:00 Oliver Hartkopp <socketcan@hartkopp.net>:
>> I would suggest to implement CAN FD from the beginning.
>>
>> When creating the CAN RAW socket just try to switch it into CAN FD mode:
>>
> thank you for the input. CAN FD is now (1ef0769900b) supported :)

Great!

>
> Each instance determines whether it is possible to write CAN FD frames
> to the socket, a configuration is not necessary.
> In a setup where a host that uses CAN FD is connected to a host that
> uses traditional CAN, frames with a payload of under 9 Bytes can also be
> bridged using cannelloni - only frames that exceed 8 Bytes will be dropped.

Hm. This is not the correct distinction for CAN and CAN FD.

There can be CAN FD frames with <=8 bytes too.

You need to make sure that the difference between CAN FD with 8 bytes and 
CAN2.0 with 8 bytes does not get lost. So I would suggest to add an additional 
attribute to each transfered CAN frame which tells you:

- Is a CAN FD frame (or not)
- Has bitrate setting (CANFD_BRS) enabled (for CAN FD)
- Has error state (CANFD_ESI) enabled (for CAN FD)

My suggestion would be to add a single byte for each frame that contains 
CANFD_BRS and CANFD_ESI as-is and e.g. 0x80 when this is a CAN FD frame.

> Here is how a cannelloni frame looks like:
>
> [ VERSION | TYPE | SEQ_NO | COUNT | COUNT * [ CANID |
> LEN | LEN * DATA ] ]

You would have COUNT * [ CANID | FLAGS | LEN | LEN * DATA ] ]

then with a single FLAGS byte.

On the sender side 0x80 is OR'ed when the read frame length was CANFD_MTU.
And on the receiver a CAN or CAN FD frame is created based on 0x80 in FLAGS.

Regards,
Oliver