embedded-can appears to be in limbo

[reneherrero]

Hi,

There's much confusion around the state and direction of embedded-can:

1. The stm32 fdcan project has commented it out
2. According to the stm32 bxcan project, the embedded-can crate is deprecated.
3. There's a mismatch in uniformity compared to embedded-hal
4. CAN FD is a pretty big thing as it bumps the payload size from 8 bytes to 64 bytes, but there's no word on that

Can anyone shed some light into the matter?

Thanks

IMHO, this is causing fragmentation in the ecosystem

[liamkinne]

@reneherrero @tristanguerragomez glad to see others share my concerns about the state of CAN in the ecosystem.

I've just gotten my PR merged (rust-embedded/embedded-hal#612) that adds defmt traits to embedded-can so I think there is appetite from the maintainers for improvement, there just isn't anyone to do it.

I'm hoping to work on CAN FD in the coming weeks which should pave the way for the fdcan crate to properly support the embedded-can traits.

[eldruin]

Any improvements are definitely welcomed and encouraged. However, this is a volunteer-based project where each person has specific interests.
In the past, there simply has been more interest in the traits included in embedded-hal, which is why that is more polished.
We rely on the whole community to engage in discussions and especially to make proposals for improvements and/or to solve problems that arise in the implementations across the ecosystem.
As I said, please feel encouraged to drive CAN support forward if you are interested in it. You are most welcome to.

[projectgus]

Raising my hand as interested in contributing to this as well. I've just popped up a draft PR to partially support existing embedded_can types in fdcan driver: stm32-rs/fdcan#56 but I'd be interested in expanding embedded_can further as well. (In particular: CAN FD support as per @liamkinne, and support for split controllers with separate CanRx and CanTx traits).