embedded Hal for CanFdSocket

[tristanguerragomez]

I'm looking at the code but fail to understand why the embedded Hal interfaces are implemented for CanSocket but not CanFdSocket?

Can anyone shed some light onto the matter?

[tristanguerragomez]

FYI: posted an issue in the embedded Hal project to see if there are plans to add support for CAN FD

[fpagliughi]

What I do remember is that the Embedded HAL and CanFdSocket stuff were written by two different people and merged in that the same time. So some things may have been missed.

I had some mixed feelings about merging in Embedded HAL support. It seemed incomplete, didn't make for easy extensibility, and my one or two PR's there didn't move very quickly. Anyway, when I have a few moments, I can look back into all of this to refresh my memory.

[reneherrero]

I was involved during the initial CAN PRs, and yes, they move very slow... unfortunately, CAN seems to be a second class citizen in that area which is very unfortunate as it's a pillar in many industries (J1939, NMEA2000, UAVCAN, .....). The first PR included Filters, but that was canned.

In their defense, I have to say that HALs often come across the "lowest common denominator" problem. If memory serves me correctly, for something to get merged, they require at the very least two working examples: one with some micro-controller option (bxcan was used) and a version of SoketCAN I hacked (that was before you took it over).

Things didn't move fast enough for me to meet my deliverables and I simply wrote things in C with a Rust wrapper to circumvent the issue (I know, ugly, but it worked).

[tristanguerragomez]

Interesting...

I have to confess, I'm new to CAN FD and don't know all the details/differences. From what I've seen so far, the bit rate during data transfers and the payload size is all that changes. Can anyone confirm?

If that's the case, the current Embedded HAL API might work:

1. The bit rate is not part of the API
2. The payload size is not hard-coded

Thoughts?