Async Rust 与 FreeRTOS 在 STM32 上的对决
Embedded Rust RTOS vs. C RTOS
我在 STM32F446 微控制器上，将 Embassy 异步 Rust 方案与经典的 FreeRTOS C 实现进行了直接对比。我们运行了包含多任务、中断处理和共享数据的相同程序，从中断延迟、程序大小、静态内存占用以及开发体验四个维度进行了实测。结果发现，虽然 RTOS 在抢占式调度上具有理论优势，但 Rust 的异步模型在内存效率上表现亮眼，且代码可读性更强。这次测试旨在抛开过度优化的极端情况，还原两者在常规开发场景下的真实表现，为嵌入式开发者提供一份客观的选型参考。
我们不是在寻找最极致的优化方案，而是希望构建一个相对正常的程序。
HN 评论区
56- _thejanus_
这是什么鬼 lol。一个测试，你的消费者比生产者慢了几个数量级，但你却聚焦于按键延迟，仿佛任务完成并不主要由那个慢得要死的 USART 打印所主导。打印 20 字节大约需要 1.7 毫秒。他们还在运行 FreeRTOS 的抢占模式，尽管这在这里毫无帮助。直接用协作模式就好。或者更好的是，直接写一个事件循环，因为所有的工作负载都非常有限。甚至更好的是，用个 555 定时器之类的东西，因为这个工作负载根本连处理器都不需要。我甚至不讨厌 Embassy 或 FreeRTOS，但这个对比达到了我原本以为不可能达到的愚蠢深度，除非你吸入了某种导致缺氧的混合气体。
- Animats
这是在非常轻的 CPU 负载下测得的。所以，没有抢占的异步方法确实能行得通。如果有任何显著的运算在进行，效果就不会那么好了。
在示波器上测量一个有用的数值是“最坏情况中断延迟”。如果存在硬实时约束，这才是关键。他们测量了标准差，但没有测量最坏情况。通常的测试设置是：一个输入信号（通常是方波）进入输入引脚，如果中断未被阻止则触发中断，任务启动，任务点亮一个输出引脚。你在示波器上观察从输入到输出的延迟，寻找异常值。
如果你完全是运行到完成（run to completion），那么异常值由最长的计算任务决定。如果存在计算任务，这就是个问题。
历史上 QNX 在这方面表现突出。中断被处理并调度一个线程。在中断级别发生的大约只有线程激活。线程点亮输出引脚。你可以在示波器上观察调度异常值。最佳情况延迟比在中断级别直接处理工作要高，但最坏情况延迟是恒定的，即使低优先级线程被计算任务阻塞。
这就是实时调度与“准实时”调度之间的区别。
- CupricTea
标题应该改一下。Async Rust ≠ RTOS。RTOS 是抢占式多线程的，而异步是通过让出点（yield points）协作完成的。
或许改成“嵌入式 Async Rust 对比 C 语言 RTOS”更好。
- joshchngs
这篇文章都快 5 年了，在 Embedded Rust 的语境下这简直算古董了。我觉得整体格局没太大变化，但我建议对其中任何细节都要谨慎对待。
- bfrog
与此同时，似乎没什么真正重要的了，除了 Zephyr，它的逃逸速度几乎让它变得像 Linux 一样。地球上每个厂商现在都支持它，而这些人只会跟着钱走。
Rust 在某些地方似乎只有适度的支持。
有了 AI，我都不知道语言是否还重要。