[randusername]

Can you elaborate on this and how it would be different from signaling on interrupts and DMA?

Hardware-level async makes sense to me. I can scope it. I can read the data sheet.

Software async in contrast seems difficult to characterize and reason about so I've been intimidated.

[jamesmunns]

It's really not so different! In embassy, DMA transfers and interrupts become things that you can .await on, the process is basically:

  * The software starts a transaction, or triggers some event (like putting data in the fifo)
  * The software task yields
  * When the "fifo empty" interrupt or "dma transfer done interrupt" occurs, it wakes the task to resume
  * the software task checks if it is done, and either reloads/restarts if there's more to do, or returns "done"

It's really not different than event driven state machines you would have written before, it's just "in-band" of the language now, and async/await gives you syntax to do it.

Even if you don't know Rust, I'd suggest poking around at some of the examples here:

https://github.com/embassy-rs/embassy/tree/main/examples

And if you want, look into the code behind it.

[tatjam]

Precisely, I would say embassy is a satisfying middle-point between "baremetal" firmware and running something like FreeRTOS / NuttX that hides the event loop from you.

[ted_dunning]

In tinygo, the idiom is to catch an interrupt and put the info into a channel so that you can think about what is happening in go style.

I use that capability, for instance, in go-wspr [1] to get very nice low-jitter timing for frequency corrections.

[1] https://github.com/tdunning/go-wspr