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.
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-asyncin 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.