Re: Standard CAN over IP

[Oliver Hartkopp <socketcan@hartkopp.net>]

On 23.02.2015 15:27, Maximilian Güntner wrote:

>> There can be CAN FD frames with <=8 bytes too.
>
> Sure. My intent was not to make a distinction between CAN and CAN FD
> based on the frame length but rather to check whether it is possible to send the
> data section on that particular bus.
> But I think dropping CAN FD frames on non CAN FD interfaces is the right choice
> in the long run.
>

Yep :-)

>> 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)
>
> Both flags make sense to me. Maybe we can use the MSB of LEN (so 0x80)
> to encode whether it is a CAN FD frame. The next byte is either
> the first DATA byte or FLAGS followed by the first DATA byte.

Yes. That was my intention too.

>> - Has error state (CANFD_ESI) enabled (for CAN FD)
>
> Do you think that this flag is necessary for two independent CAN buses?
> When sending the frame on a physical bus, the error state of that
> interface/node can be different compared to the original sender.
> If host A receives a frame on bus A where CANFD_ESI is set and
> transmits it to host B which in return writes it to bus B, the CANFD_ESI
> bit will represent the state of a different node (host B instead of the
> original sender).
> Maybe I am wrong, but I think that the CANFD_ESI flag needs to be
> masked prior to transmission on bus B.

Good catch. Indeed this was discussed at CAN in Automation too.
When you think of a gateway (in automotive) the original ESI bit can be 
interesting for the receiver placed behind the gateway.

Therefore the ability to set the ESI bit explicitly in an outgoing CAN FD 
frame is specified for CAN controllers.

So the ESI bit on the wire is an OR'ed value of the value set into the 
controllers registers and the internal state of the controller.
For your implementation this turns out to forward the ESI bit value transparently.

>
>>
>> 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.
>>
>> [...]
>> 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.
>
> Sounds good.
>

:-)

Regards,
Oliver