embedded_can Driver and no_std support

[pbert519]

Is it planned to support no_std, too? If yes, we should probably add the no_std flag as soon as possible, before to much std code is in place.

The embedded-can trait already provides a can driver abstraction and has some implementations, e.g. for socketcan and microcontrollers, like stm32 and similar, see https://crates.io/crates/embedded-can

I would be open to contributing a implementation if no_std is in scope for this project.

For the basics j1939, i created a very work in progress j1939 library in no_std rust. https://github.com/pbert519/j1939 Maybe some parts are reusable.

[Notgnoshi]

I had a conversation with @ad3154 about this before we started the project. One of my goals was to enable switching to rust for embedded micro ECUs within our organization.

We chose not to start with this goal in mind because:

• We only had two weeks to bootstrap the project
• @ad3154 is pretty new to Rust
• We thought it would be better to get to an MVP state sooner rather than later
• We thought it would be better to take advantage of the Open-Agriculture community excitement for a Rust ISO11783 CAN stack than it would be to go slow and make only little bits of progress
• Unsure if I'm missing anything?

While I want to have no_std support in the future, I think it introduces some pretty large design constraints.

---

I have a few questions / notes:

• Perhaps we should look into using the embedded-can traits/impls as soon as possible?
• I'm guessing that a no_std and a std CAN library would probably have different user APIs, because they adjust for different tradeoffs? What are those tradeoffs?
• I keep finding more and more projects working on CAN support in the Rust community, I think I want to reevaluate what's available, and what we can build off of
• @JannesBrands, @GwnDaan, @Thom-de-Jong, @ad3154, what do you all think about no_std support?

[pbert519]

Thank you for your detailed answer!

Concerning your remarks: embedded_can: The embedded_can is not widely used or final/stabilized yes, but it is very similar to the currently used abstraction by this project. And the abstraction is already maintained by the embedded rust working group. It would be beneficial for the ecosystem to use them and use existing drivers / upstream newly created can drivers instead of creating an new abstraction on the same level.

On the other hand with linux as target, since windows will not be in many production systems, it might be easier to directly use the j1939 abstraction of the linux kernel. No need to have an abstraction on CAN frame level.

no_std vs std : The main difference between no_std with alloc and std is mostly os services like time or file handling. File handling can probably be optional, e.g. Pools can be included in the binary with include_bytes!. But for time, e.g timeout handling, an abstraction would be necessary. An other import point is error handling, there is currently no std::error::Error equivalent in the core library. Besides that, no_std needs some attention on a lower memory footprint (code size and heap allocation).

If the Isobus functionality is split into multiple crates, higher level crates like file-server could be std again.

[JannesBrands]

From the beginning I always had the intention of a no_std variant for well-known reasons. In the meantime I've gotten more familiar with Rust and have come to the same conclusion as @Notgnoshi that this would significantly change the approach, structure and design of the project and especially with the current resources we have available would be too much to achieve progress as soon as possible. Additionally due to the fact (including myself) that many are not yet 100% familiar with Rust and this would generally slow down progress.

I had read through some information on how to use std on certain embedded systems. Of course, these also have very specific and different options, so that some support std alloc and others do not. Same with the file system. Here is an interesting article: blog article

I'll have a look at the embedded-can crate, but I agree that we should reuse official/renowned projects.

[JannesBrands]

44 first implementation of embedded-can (not done yet)