Support for embedded-hal

[jessebraham]

This issue was migrated from GitLab. The original issue can be found here:
https://gitlab.com/susurrus/serialport-rs/-/issues/71

It would be awesome if serialport would add opt-in support for the embedded-hal traits at https://docs.rs/embedded-hal/*/embedded_hal/serial/. It would allow drivers to be easily tested on a non-embedded platform like Linux.

Would you accept a MR that adds these impls behind a feature flag?

[shymega]

Hey, I'm really interested in this issue, but I can't see any associated PRs (yet) or other activity regarding the proposal.

I'm writing embedded firmware for an STM32, and I currently use serialport-rs for the ARM64 Linux side of things, but I want to unify the traits I'm using, so they can be used in std environments, and no_std, with embedded-hal.

Now, I'll be honest: I'm not good with embedded yet. But I'd like to help provide my - limited - input on this matter, if possible. I'd really like to keep the same code for UART I/O, on ARM64/x86_64 and ARM.

My current implementation abstracts I/O into the core2::io::Read and core2::io::Write, but that doesn't work with serialport-rs yet.

I imagine this comment comes across as a `Hey, is there any progress on this?' - I want to reiterate that I would like to help make this possible, though.

Thank you!

[eldruin]

Thank you for your interest!
Here is some guidance on how this could be done:

• For embedded-hal 0.2 support you could implement the serial traits maybe behind a feature flag like embedded-hal-0-2 (since it is the future legacy version)
• For embedded-hal 1.0 we have removed the serial traits and will now recommend implementing the embedded-io traits. This could be done behind an embedded-io flag probably.
• If there is interest in async, the traits in embedded-io-async could also be implemented here, probably behind an aptly-named feature.

[sirhcel]

@dbrgn created #59 for this topic a while ago. It is focused on on older version of embedded-hal 1.0 but a good sketch how this could be done for embedded-hal 0.2.

Are there any plans to over serial I/O for embedded-io with embedded-hal-compat or a similar adapter in the future?

[eldruin]

Good point. It might be possible to bridge to embedded-io in embedded-hal-compat. Then maybe we could skip embedded-hal support entirely and just implement the embedded-io{,-async} traits here.

[shymega]

Hi, sorry for my late reply.

I think, looking at the state of things, there's not a lot I can contribute without becoming a hindrance.

Is there a list of relevant PRs/issues/discussions worth subscribing to to keep track of things?

I've recently published a unified -MODEM crate, which uses code from other XMODEM/YMODEM crates to unify them into one single crate. It'd be really good to be able to use that with embedded-hal so that Rust code on embedded can interact with XMODEM. For example, this STM32 I'm working with currently uses XMODEM for updates.

[sirhcel]

Hi, sorry for my late reply.

No problem. We all are doing this in our spare time and have plenty of other things to do.

I think, looking at the state of things, there's not a lot I can contribute without becoming a hindrance.

Is there a list of relevant PRs/issues/discussions worth subscribing to to keep track of things?

This issue here and #59 are the best known issues to me. Recently there were a lot of things going on with embedded-hal going towards 1.0 and I still need to keep up with them.

I've recently published a unified -MODEM crate, which uses code from other XMODEM/YMODEM crates to unify them into one single crate. It'd be really good to be able to use that with embedded-hal so that Rust code on embedded can interact with XMODEM. For example, this STM32 I'm working with currently uses XMODEM for updates.

This sounds interesting and might be a good candidate for verifying the porting efforts. Which is your crate?

[shymega]

Hi,

On Sat, Sep 09, 2023 at 08:13:05AM -0700, Christian Meusel wrote: > Hi, sorry for my late reply. No problem. We all are doing this in our spare time and have plenty of other

things to do. Concur. I'm in the same position! :-)

> I think, looking at the state of things, there's not a lot I can contribute without becoming a hindrance. > > Is there a list of relevant PRs/issues/discussions worth subscribing to to keep track of things? This issue here and #59 are the best known issues to me. Recently there were a lot of things going on with embedded-hal going towards 1.0 and I still need to keep up with them.

I've subscribed to both now.

> I've recently published a unified -MODEM crate, which uses code from other XMODEM/YMODEM crates to unify them into one single crate. It'd be really good to be able to use that with `embedded-hal` so that Rust code on embedded can interact with XMODEM. For example, this STM32 I'm working with currently uses XMODEM for updates. This sounds interesting and might be a good candidate for verifying the porting efforts. Which is your crate?

It's `txmodems`. Basically, for my `Cosmo-CoDiOS` project, I needed a XMODEM implementation, but I noted there's a fair amount of fragmentation regarding implementations. Also lack of `no_std`, which was a requirement. https://crates.io/crates/txmodems I used the code from some of the existing crates, and implemented them as traits in the `txmodems` project. You're more than welcome to use the crate to verify the porting efforts. I haven't been able to write unit tests yet, as it runs as embedded, but I plan to refactor that in the future. Currently, XMODEM is the only one that seems fully implemented. YMODEM I'm thinking about. Feel free to open any issues/PRs if you spot anything that looks 'off'. I don't have a spare board to test the protocol on right now. Best wishes, -- Dom Rodriguez GPG Fingerprint: EB0D 45E6 D0DC 1BA1 A2B5 FC24 72DC F123 1E54 BD43 ***@***.***)

[eldruin]

It should be noted that we have removed the Serial traits from embedded-hal and we now encourage implementing and using the embedded-io traits which are basically the std::io traits but for no_std.

[shymega]

I've been working on moving my txmodems crate from core2 to embedded-io, but experiencing a few issues. Mostly the lack of the unified Error type (iirc) that core2 has.

[shymega]

Is there anything I can do to help? I heard vaguely some news about embedded-io reaching 1.0, so it seems like a good time to prod at this issue again.

[akauppi]

Me2, @shymega

I’m only learning Rust since Dec’23, but have a project that is around serial port and ESP32 (RISC-V variant). Don’t think I can write this code - but can read and test.

[shymega]

OK< so I was wrong about embedded-io reaching 1.0. I misread the release.

I've got a series of crates for abstracting over UART on Android/bare metal for a specific MCU.

I'm not sure what I can do to help with this issue, and I suspect due to my naivety to the project in some regards, I may become a slight hindrance. However, a cross-party discussion with the Rust Embedded folks might be useful.

[crespum]

If it helps, I'm using serialport in combination with embedded-io-adapters crate. Have a look at this example.

[sirhcel]

If it helps, I'm using serialport in combination with embedded-io-adapters crate. Have a look at this example.

Thank you for proposing this solution and linking a real-world example @crespum! After looking into this recently, using the embedded-io-adapters looks like the solution for bridging serialport's std::io::{Read, Write} with embedded_io::{Read, Write}.

And I did not find much concrete documentation for embedded-hal-compat, let alone a good example. But it look like this crate provides bridging between embedded_io and embedded_hal::serial::{Read, Write}. So even bridging between serialport and embedded-hal 0.2 seems to be available.

Is there anything I can do to help? I heard vaguely some news about embedded-io reaching 1.0, so it seems like a good time to prod at this issue again.

Yes, there is @shymega. I would love to provide or link to some simple examples. But I did not find the time to either do the research for something already available or build something. The atat crate looks like something where most people will understand the context. Ideas and PRs welcome.