embedded-hal VS awesome-embedded-rust

What is the difference between this and https://github.com/rust-embedded/embedded-hal/tree/master/embedded-hal-async?

Maybe worth mentioning if you (or someone else) hasn't seen it before, the embedded-wg is also working on an async version of the embedded-hal traits, embedded-hal-async.

In that case you want to keep most of the unsafe in the HAL crate, and expose an interface as safe as possible. To give you an idea, is it since 2018 that a "generic" DMA safe implementation is in discussion https://github.com/rust-embedded/embedded-hal/issues/37

Does something like embedded hal exist in the C/C++ world? ( https://github.com/rust-embedded/embedded-hal )

worth mentioning also is embedded-hal but my understanding is this has absolutely nothing to do with arduino, so despite being embedded probably not what I want.

The ecosystem is great and growing, It really benefits from a language-standard embedded HAL which makes writing cross-platform drivers a cinch - e.g., you can write a bit-banged MDIO driver and use it on anything that has a timer and a two IO pins, from a Zynq Ultrascale to an arduino. Sure, this is possible in C - but Rust really benefits from a less fragmented ecosystem here.

Have you thought about writing/contributing to embedded-hal compatible crates (a sensor module driver for example)? It's always good to contribute to an eco system.

📝 At the time of writing this post, it came to my attention that there is an additional HAL that targets STM32 device families (the stm32-hal). From what I figure, right now there seem to be two approaches for developing HALs. The first approach is trait driven so to speak where the embedded-hal is used as a foundation. The second approach is more application-driven and provides a high-level API that targets several families of a device. However, this exists only for the stm32 through the stm32-hal. Right now, the first approach is what I found to be more widespread as it covers different microcontrollers and what this post is based on.

I can write a library for an OLED device that is driven by an platform agnostic I2C device that will run on any microcontroller that implements the necessary abstractions.

The `embedded-hal` (https://github.com/rust-embedded/embedded-hal) are these abstractions that allow this to happen

Yes but there needs to be appropriate libraries available such as HAL. Well it doesn't have to but it makes my life as a beginner in both much easier. But its probably matter of time because i predict that this chip will be very popular in Rust embedded.

Are you saying that this book is a hallucination? And this? And all of this?

Feel free to PR them to the awesome embedded rust list, and the matrix rooms for embedded rust and esp32 (linked on that page) are super active, so feel free to plug this there too :)

If you haven't already, feel free to PR it to the awesome embedded rust list!

list of curated rust microcontroller resources

embedded-hal trait-based HALs: There could be a better description than this. However, this category has the widest base of implementations with more options than can be mentioned here. A more comprehensive list can be found on the awesome embedded Rust repository.

For what it's worth, the ecosystem is definitely growing. See here: https://github.com/rust-embedded/awesome-embedded-rust, there are quite a few drivers for a pretty wide variety of sensors/periphs, and almost every large SoC line is supported.