You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
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!
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.
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?
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.
Activity
hartkopp commentedon May 13, 2020
Yes. So far socketcand does not support CAN FD.
No user requests :-)
mocle commentedon May 14, 2020
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 commentedon May 14, 2020
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 commentedon May 14, 2020
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!
rawmode: support CAN FD frames
hartkopp commentedon May 15, 2020
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 commentedon May 20, 2020
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 commentedon Jul 7, 2020
Hi @mocle,
just pulled some other code and was wondering why I was on a different branch ...
Did you test the branch?
Lukasz-Juranek commentedon Aug 9, 2021
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 commentedon Aug 11, 2021
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 commentedon Sep 29, 2022
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 commentedon Oct 3, 2022
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 commentedon Oct 22, 2024
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?
MatinF commentedon Jan 6, 2025
We would also be interested in this - is there an update on the potential inclusion of CAN FD support in the master?