I can agree to an extent that API designers sometimes (often?) over engineer for imagined problems.

At the same time, I've been working on an embedded Rust project and trying Embassy for the first time and it is _amazing_.

First of all I've had good logging and debug support with probe-rs. Secondly, being able to do ergonomic DMA transfers with async/await syntax feels like cheating. The core goes to sleep until your transfer finishes and an interrupt fires which wakes up the core and continues your async state machine, which the compiler built for you from your async code.

Distinct tasks can be split up into separate async functions, the type system models ownership of singleton hardware well (you can't use Pin 8 for your SPI bus there, you already "moved" it to your I2S peripheral over there!), and it all comes together with pretty minimal RAM usage, efficient use of the hardware, and low power consumption if you're mostly waiting on data transfers.

I'd be happy to talk more about practical problems if you want to get specific.

Good observations! I think Embassy worked out because its creator built it with the goal of shipping smart door locks, so the components of it he uses for that workflow work well.

I think ownership sometimes works for the reason bring up: Catching errors. I suspect you will find cases where you are not as pleased you can't use something you moved elsewhere! In some cases the ownership semantics map smoothly to control over hardware; in others, it's not so good of a fit. I also suspect you are overestimating how difficult DMA and power management are without async. (In rust or otherwise) What you described is a ubiquitous embedded workflow, minus the state machine.