imxrt-hal
imxrt-hal copied to clipboard
imxrt-rs
Road to `embedded-hal 1.0`
This is a tracking issue of our progress and tasks to integrate the ~~upcoming~~ 1.0 version of embedded-hal.
TODO: Link the migration guide here (https://github.com/rust-embedded/embedded-hal/issues/283)
Tasks for embedded-hal (applicable as of RC1):
- [x] Traits for timers, timer adapters.
- Already provided by
rtic-monotonics.
- Already provided by
- [x] #148
- [x] #153
- [ ] PWM
- [ ] #145
- [x] #154
No preference for or against breaking changes. Folks should feel free to explore new driver designs if they're warranted for embedded-hal 1.0. I'd still like to maintain some kind of embedded-hal 0.2 support. We could implement both traits with our drivers, or we recommend something like embedded-hal-compat.
It might also be nice to support the async embedded-hal traits. My past attempts with async embedded i.MX RT drivers taught me what not to do, so I'm looking for help here. I hope to see approaches that are decoupled from any async runtime, though I'm not sure if that's possible or a good idea.
My plan is currently to implement purely the async version and convert them to blocking with the cassette crate. I do have quite some experience with async (I'm the owner of tokio-graceful-shutdown and rewrote tokio's CancellationToken), and I'm motivated to answer questions if someone needs help. :)
I do agree with the plan to decouple from a specific runtime, and I don't think it's hard. So far for my lpspi rework I don't have anything that is specific to rtic or similar. E-h 1.0 seems well thought through.
@mciantyre For timer adapters, can't we use rtic-monotonics? While having rtic in its name, it's actually runtime agnostic and supports eh1 and eh1-async. (Disclaimer: I implemented it)
@mciantyre Would you mind an intermediate release, now that we implemented GPIO and UART for e-h 1.0? I need that for a project of mine and would like to official release it, but it depends on the github version of imxrt-hal because of this.