Embassy: Modern embedded framework, using Rust and async

Original Article ↗ Hacker News Discussion ↗

Real-world usage and impressions

  • Used successfully for BLE and LoRa projects, USB video-to-OLED streaming, MQTT-based HomeAssistant nodes, and a guitar amp BLE controller.
  • Generally reported as stable; panics usually attributed to vendor softdevices rather than Embassy itself.
  • Strong praise for the overall Rust embedded toolchain around it: probe-rs, defmt, embedded-hal, and PAC crates.
  • Microsoft uses it in an embedded-controller project; Ariel OS is built on it, and it coexists with other ecosystems like RTIC and Xous.

Async vs blocking and ecosystem “split”

  • One concern: much new embedded Rust OSS is written assuming Embassy-style async, creating friction for those preferring synchronous or bare-metal styles.
  • Others counter that many Embassy HALs expose near-parity blocking APIs and still lean on embedded-hal, so you can mostly avoid async if desired.
  • Reimplementing simple drivers per framework is seen by some as acceptable and even desirable; skepticism expressed toward fully generic HALs.

Power, ergonomics, and concurrency model

  • Proponents highlight:
    • No-heap async, cooperative multitasking, and automatic CPU sleep at await points.
    • Dramatic ergonomic gains versus hand-written state machines and interrupt-driven globals, especially for multi-IO workflows (double buffering, timeouts, composition).
  • Critics argue async is not inherently more power-efficient; WFI/sleep and interrupts work just as well in non-async designs, and “async vs blocking” is a false dichotomy.

RTOS vs async and real-time guarantees

  • Embassy markets itself as obsoleting traditional RTOSes for many use cases; some users agree for general-purpose microcontroller firmware.
  • Others strongly object:
    • Async Rust provides cooperative concurrency, not hard real-time guarantees.
    • Traditional RTOS features—preemptive scheduling with bounded latency/jitter and strict timing guarantees—are not replaced.
    • Concern that README language overstates what async/Embassy provides.
  • Comparison with FreeRTOS and RTIC sparks debate; one link shows good latency numbers, but at least one commenter calls the comparison “apples to oranges.”

Hardware, getting started, and constraints

  • Recommended MCUs: RP2040, ESP32-C3/C6, STM32 Nucleo boards, Nordic nRF52/nRF54 (the latter still incomplete), with praise for integrated debugging and good docs.
  • Raspberry Pi SBCs are considered “embedded Linux,” not the typical microcontroller target for Embassy.
  • Some worry about large dependency graphs (100+ crates for a blinky) due to supply-chain and regulatory tracking; others see that as an acceptable trade-off for a modern embedded experience.