-
Notifications
You must be signed in to change notification settings - Fork 195
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Asynchronous embedded-hal traits roadmap #356
Comments
Would it be worth cutting a 0.1.0-alpha (or just 0.1.0) release with the existing I2C, SPI etc async traits, while Serial is worked out? Given the higher complexity I also expect CAN might take a while longer to figure out than the others, so at least getting the basic traits onto crates.io would let people start using them without git dependencies. |
Could we have an alpha 1 release of this? I have a pending PR for embassy that depends on the new SPI transaction API in master. Cheers! |
I've started trying to port some of my code over to I'm wondering if there might be a procedural macro solution that would allow a single device driver to be compiled in both blocking and async modes. Has anyone explored that? Or is it more trouble than it's worth and we expect crates to quickly move over to the new traits? (Presumably that's blocked on the necessary features hitting stable.) |
there's a blocking to "fake async" adapter that you can use to get an async impl out of any HAL with only a blocking impl. It's "fake async" because it will block and never "async yield", but for many use cases that's fine (spi/i2c register reads/writes are fast). This allows maintaining just one version of the driver (async) but still using it with HALs that don't support async. You still need an "executor", but since there's no yielding/waking going on a very dumb one like |
I saw that adapter, but I feel like you wouldn't want to do "async only" until both these traits are stable and they can be compiled with stable Rust, and probably an |
i've spent way more time than i should have trying to achieve this with traits with no real success (though
i don't think we can expect folks to all move to async (or vice versa), so the story for compatibility and combining the two seems fairly important! |
I started writing something like this and then I discovered the I was able to very easily adapt my async device driver into something that compiles both sync and async versions side-by-side. I don't quite love the user ergonomics (it generates types named @ryankurte Maybe take a look at that crate and see what you think? |
I think the accepted naming convention for async modules is |
Hello everyone, Digital Pin (input, output, etc.) in the async hal should be added, until the traits get merged inside the |
Discussion point from #177: Should |
Another thing: Is |
my personal opionion is we should deprecate it (i.e never release embedded-hal-nb 1.0), but it's up to the HAL team as a whole to decide... It was discussed a while back and the conclusion was "don't deprecate, or at least not yet". Perhaps now that stable AFIT is here it's worth a second discussion? |
For what it's worth, I never encountered a library that actually implements the |
|
We have started a project to develop a asynchronous versions of the
embedded-hal
traits, at the moment championed by @Dirbaio.This will be developed as a separate crate called
embedded-hal-async
until it is ready for integration inside a module inembedded-hal
.This can be found in the subfolder
embedded-hal-async
Roadmap:
async fn
in traits (expected breaking change insideembedded-hal-async
).async fn
in traits are available in Rust stable (Tracking issue)Asynchronous execution holds great potential for embedded. Please join us!
The text was updated successfully, but these errors were encountered: