search

serialport / serialport-rs

A cross-platform serial port library in Rust. Provides a blocking I/O interface and port enumeration including USB device information.
Other
446 stars 107 forks source link

Support for embedded-hal #5

Open jessebraham opened 2 years ago

jessebraham commented 2 years ago

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 commented 11 months ago

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 commented 11 months ago

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

sirhcel commented 11 months ago

@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 commented 11 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 4 months ago

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 commented 3 months ago

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.