Skip to content
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

[Discussion] Should sensor driver developers target embedded-hal-async only? #604

Open
asasine opened this issue May 27, 2024 · 0 comments

Comments

@asasine
Copy link

asasine commented May 27, 2024

Hello, and first of all, great work on this project. It has been phenomenal to work in the embedded Rust world. With the introduction of embedded-hal-async in v1, how should sensor driver developers approach targeting the three possibly HALs (sync, async, and polling)?

In the drivers I've developed, I've exclusively targeted the async version, as I reason it can function as a superset of the blocking and polling version, it's the version I utilize, and it would be infeasible to target all three for me, but I want to get some insight from the HAL maintainers. Not knowing a ton about exactly how the async HAL is implemented, is this assumption safe? I suspect it isn't implemented as "blocking calls async but blocks synchronously until the future completes," but I could see a world where that could be true, thus unifying the HALs into a single version, simplifying the process for sensor driver developers to reach as many users as possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant