embassy-nrf: migrate to embedded-hal 1.0, embedded-hal-async #552
Conversation
embassy-nrf/Cargo.toml
Outdated
| @@ -47,11 +47,14 @@ embassy = { version = "0.1.0", path = "../embassy" } | |||
| embassy-macros = { version = "0.1.0", path = "../embassy-macros", features = ["nrf"]} | |||
| embassy-hal-common = {version = "0.1.0", path = "../embassy-hal-common" } | |||
|
|
|||
| embedded-hal-02 = { package = "embedded-hal", version = "0.2.6" } | |||
| embedded-hal-1 = { package = "embedded-hal", version = "1.0.0-alpha.6", git = "https://github.com/embassy-rs/embedded-hal", branch = "async" } | |||
There was a problem hiding this comment.
I find this confusing having to depend on two flavours.
There was a problem hiding this comment.
You mean 0.2 and 1.0? This is so the HAL can be used with drivers using either 0.2 or 1.0 traits.
The alternative would be to completely drop 0.2 and tell users to use embedded-hal-compat if they want to use a 0.2 driver.
I prefer directly supporting both however, because 0.2 is massively widespread in the ecosystem, so it'll take years for everything to upgrade to 1.0, so this will be a major usability issue until then.
There was a problem hiding this comment.
At what point do you think we will let get of 0.2 support? Should we at least mark it as being deprecated?
There was a problem hiding this comment.
No idea about the timeline, but I guess years.
Not sure if you can mark a trait impl as deprecated, but even if you could it'd be ineffective: the user getting the warning can do nothing about it, it's the driver author that should do the work of updating it.
There was a problem hiding this comment.
Having gone through the embedded-hal-compat annoyance, I think the approach in this PR is much more helpful to end users 🚀
embassy-nrf/src/twim.rs
Outdated
| } | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
Such a pity to lose this fidelity of errors.
There was a problem hiding this comment.
It's how the EH ErrorKind is defined.
It makes sense though: These errors are very nrf-specific. Users of embassy-nrf can still check our Error enum, Hal-independent users via the traits can only check the kind, but it will have no idea about the nrf-specific errors, so there's nothing it can do anyway.
Dirbaio
force-pushed
the
eh1
branch
5 times, most recently
from
bb63909 to
a6f5299
Compare
FlexPin sounds like it's an owned pin singleton, like AnyPin or NoPin.
Dirbaio
changed the title
|
bors r+ |
|
Build succeeded: |
|
Seems like the only majority of changes for end-users here is the removal of some trait imports in their code. Nice! |
581: stm32: expose all functionality as inherent methods. r=Dirbaio a=Dirbaio This is the previous step to implementing both the embedded-hal 0.2 and embedded-hal 1.0 + embedded-hal-async traits. The equivalent in nrf was done in #552 - Removes need for `unwrap` in gpio. - Removes need for `use embedded_hal::whatever` in all cases. Co-authored-by: Dario Nieuwenhuis <[email protected]>
613: Rust stable support r=Dirbaio a=Dirbaio This PR adds (limited) stable Rust support! The drawbacks are: - No `#[embassy::task]`, `#[embassy::main]`. (requires `type_alias_impl_trait`). You have to manually allocate the tasks somewhere they'll live forever. See [example](https://github.com/embassy-rs/embassy/blob/master/examples/nrf/src/bin/raw_spawn.rs) - No async trait impls (requires GATs). Note that the full API surface of HALs is still available through inherent methods: #552 #581 - Some stuff is not constructible in const (requires `const_fn_trait_bound`), although there's an (ugly) workaround for the generic `Mutex`. So it's not that bad in the end, it's fully usable for shipping production-ready firmwares. We'll still recommend nightly as the default, until GATs and `type_alias_impl_trait` are stable. Co-authored-by: Dario Nieuwenhuis <[email protected]>
No description provided.