Road to embedded-hal 1.0

[Finomnis]

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 (rust-embedded/embedded-hal#283)

Tasks for embedded-hal (applicable as of RC1):

• Traits for timers, timer adapters.
  • Already provided by rtic-monotonics.
• GPIO: embedded-hal 1.0 compatibility #148
• Add eh1 impl for LPI2C #153
• PWM
• LPSPI: embedded-hal 1.0 rework #145
• LPUART: embedded-io 0.6 compatibility #154

[mciantyre]

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.

[Finomnis]

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. :)

[Finomnis]

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.

[Finomnis]

@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)