CAN FD support

[mocle]

Is it correct that socketcand does not support the data-communication protocol CAN FD (CAN Flexible Data Rate)? Or did I miss something?

CAN FD frames created with can-utils are not displayed in raw mode.

[hartkopp]

Yes. So far socketcand does not support CAN FD.
No user requests :-)

[mocle]

Thanks for the confirmation @hartkopp .

Then this issue should be the first official request for CAN FD.

I would see the support of CAN FD as a great added value for this great project.

[hartkopp]

Would the < rawmode > support be sufficient for you?

E.g. by receiving something like < fdframe 03B 1589476062.377071 7D1FDF312DD0DE1CAABBCCDD > ?

Or do you need BCM support too?

[mocle]

In my specific case, I would have to be able to receive CAN FD Frames, as well as send them.

As this is currently possible in < rawmode > with the "normal" CAN frames, this would be sufficient for me and probably for most applications.

Like in your example, receiving an FD frame with something like < fdframe 03B 1589476062.377071 7D1FDF312DD0DE1CAABBCCDD >.
And an equivalent for sending FD Frames, like < sendfd 03B 1589476062.377071 7D1FDF312DD0DE1CAABBCCDD >.
This would be awesome!

[hartkopp]

Hey @mocle ,
I created a branch https://github.com/linux-can/socketcand/tree/rawmode-canfd which contains a simple extension, which is not really optimized but implements the discussed approach.
You are invited to take a test drive :-)

[mocle]

Thanks @hartkopp for your effort and the super fast implementation.
I will test your implementation and give feedback on the weekend.
Thanks a lot already!

[hartkopp]

Hi @mocle,
just pulled some other code and was wondering why I was on a different branch ...
Did you test the branch?

[Lukasz-Juranek]

I've tested this works well, only wondering how to transfer additional CAN_FD flags like BSR and ERR in raw mode, but for now seems ok.

[hartkopp]

The ESI bit is not really a hot topic in CAN FD - I've never seen a real-world use-case for it, did you?

And the BRS bit is not provided on this abstraction level also. The setting of BRS is done in the CAN interface configuration (if you enable two data rates) and transparent on the CAN frame data representation.

[AndyHuska]

Up vote for merging this branch to master, or at least have a conversation about how to finish this branch off so it is ready. I'm willing to help!

[hartkopp]

Hi @AndyHuska ,

looking at the patch and my comment at #12 (comment) I'm finally not that sure whether ignoring BRS & ESI bits was that good idea ;-)

I was thinking about adding the flags as a single ASCII hex value (here '3') behind the timestamp:
Current patch: < fdframe 03B 1589476062.377071 7D1FDF312DD0DE1CAABBCCDD >
With FD flags: < fdframe 03B 1589476062.377071 3 7D1FDF312DD0DE1CAABBCCDD >

So when there's still demand, would you like to do some testing of the upgraded patch before getting this to the main branch?

@mocle @Lukasz-Juranek : Are you working with the original PoC patch in a production environment or would if be fine for you to enhance the protocol as described above?

[DL4OCE]

Hi,

great to see that a requirement for CAN FD has already been addressed. :-)

One of the big advantages of socketcand is that the user doesn't have to take care of the timing of cyclic messages being delivered to the CAN bus. Sending single FD frames is a good start, but I'd need a cyclic FD messages feature just like the "< add" command for standard messages.

Are there any plans to implement this, as well?