event-handling - 基于事件或轮询的嵌入式 MCU 系统架构？

Question

我之前有编写基于事件和轮询的嵌入式系统的经验(适用于没有抢占式操作系统的微型 MCU)。

在基于事件的系统中，任务通常在队列上接收事件(消息)并依次处理它们。

在基于轮询的系统中，任务以一定的时间间隔轮询状态并响应变化。

你更喜欢哪种架构？两者可以共存吗？

更新:积分

基于轮询
- 与时序方面相关的紧密耦合(@Lundin)
* 可以使用队列与事件系统共存 (@embedded.kyle)
* 适用于较小的程序 (@Lundin)

基于事件
+ 从长远来看更灵活的系统 (@embedded.kyle)
- RTOS 版本增加了复杂性(@Lundin)
*小程序=状态机控制(@Lundin)
* 可以使用队列和“ super 循环”(内部 Controller /主)来实现(@embedded.kyle)
* 只有真正的“事件”是硬件中断(@Lundin)

相关问题
* Looking for a comparison of different scheduling algorithms for a Finite State Machine (@embedded.kyle)

相关信息
*“更喜欢使用事件对象而不是裸线程”(@Miro)
http://www.drdobbs.com/parallel/prefer-using-active-objects-instead-of-n/225700095
*“正确使用线程=隔离+异步消息”(@Miro)
http://www.drdobbs.com/parallel/use-threads-correctly-isolation-asynch/215900465

Answer 1

在裸骨 MCU 平台上确实没有“事件驱动”这样的东西，尽管流行语喷子试图告诉你什么。您可以接收的唯一真实事件是硬件中断。

根据应用程序的性质及其实时要求，中断可能适合也可能不适合。通常，使用轮询系统实现确定性实时要容易得多。但是，仅依赖轮询的系统很难维护，因为所有计时方面之间都存在紧密耦合。

假设您尝试启动速度较慢的 LCD。与其在空循环中燃烧 CPU 周期时反复轮询某个计时器，不如决定在此期间通过总线接收一些数据。然后你想把接收到的数据打印在 LCD 上。这样的设计在 LCD 启动时间和串行总线之间产生了紧密耦合，在串行总线和数据打印之间产生了另一种紧密耦合。从面向对象的角度来看，这些东西根本没有关联。如果您在将来的某个时候加速串行总线，那么您可能会突然遇到 LCD 打印错误，因为当您尝试在其上打印时它尚未完成启动。

在一个小程序中，像上面的例子一样使用轮询是完全没问题的。但是如果程序有增长的潜力，轮询会让它变得非常复杂，紧耦合最终会导致许多奇怪和致命的错误。

另一方面，多线程和 RTOS 增加了很多额外的复杂性，这反过来也会导致错误。在哪里划线并不容易确定。

出于个人经验，我想说，除了简单的状态机之外，任何小于 20-30k LOC 的程序都不会从调度和多任务中受益。如果程序变得更大，我会考虑多任务实时操作系统。

此外，低端 MCU(8 位和 16 位)远不适合运行操作系统。如果您发现需要一个操作系统来处理 8 位或 16 位平台上的复杂性，您可能一开始就选择了错误的 MCU。我对任何在小于 32 位的操作系统上引入操作系统的尝试持怀疑态度。