Support for embedded-hal about serialport-rs

[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.