Blog compares Embassy/Rust async executor with FreeRTOS on STM32F446

The blog post sets up a side-by-side experiment where Embassy's async Rust executor and FreeRTOS run identical applications on an STM32F446ZET6 microcontroller at 180Mhz. It measures interrupt latency, program size, RAM consumption, and the subjective effort required to write the code. The hardware is paired with a Rigol DS1054Z oscilloscope for timing captures. Both implementations are built with normal compiler optimizations and default RTOS or executor settings.

Embassy builds tasks as statically allocated futures that cannot rely on a heap allocator. A nightly compiler and the type_alias_impl_trait preview feature are required to enable this model. Each task’s future holds a waker that is registered in a global EXTI array; when an interrupt fires the waker resumes the task. Because Embassy does not implement preemption, a task only yields control when it awaits another future, giving cooperative multitasking.

FreeRTOS creates independent threads that execute ordinary C functions without special syntax. When the scheduler decides to switch threads, it saves the complete processor context and restores it for the next thread. This preemptive approach can introduce variable latency due to context-switch overhead but guarantees that a higher-priority thread can interrupt a lower-priority one at any point. The RTOS kernel also manages task stacks, which contributes to RAM usage.

Adopting Embassy requires moving to a nightly compiler and designing all tasks to be known at compile time, which eliminates dynamic task creation. Developers must learn the async/await model and waker-based interrupt handling, which can increase initial learning effort. The cooperative nature means Embassy may not meet hard real-time deadlines that demand immediate preemption, limiting its use in certain control loops. FreeRTOS, while incurring higher RAM and possible latency from context switches, offers deterministic preemption and works with stable C toolchains.