embedded-hal VS qemu_esp32

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.

Straight up UDP streaming might be faster, since there's no error detection involved. Something to consider here: https://github.com/Ebiroll/qemu_esp32/tree/master/examples/19_udp

Back in the day we used to have to break out the UV EPROM eraser which would take about 40 minutes to erase and then do the program and test cycle so to avoid that we would use an emulator and do the initial testing on that. Not sure how suitable it is but there are ways to simulator an ESP32 CPU also: https://github.com/Ebiroll/qemu_esp32