在 RTOS 上实现状态机 [关闭]答案

【问题标题】：Implement a state machine over an RTOS [closed]在 RTOS 上实现状态机 [关闭]
【发布时间】：2018-08-25 07:24:07
【问题描述】：

我是初学者，我对 RTOS 和状态机中的任务之间的区别有点困惑。以我愿意实现的状态机为例：

enum states{
  READY_STATE
  RUNNING_STATE
  BLOCKED_STATE
  FINISHED_STATE
}STATES;

如果这个状态机可以在不使用任何 RTOS 的情况下用事件/中断枚举，那么使用 RTOS 和创建任务有什么好处？

【问题讨论】：

【解决方案1】：

RTOS 用于通过将不相关的任务放在不同的程序中来处理程序复杂性，以便它们可以看似同时执行。例如，将应用程序逻辑、GUI 和串行通信拆分为 3 个独立的进程可能是有意义的。

这是否提供真正的多处理或多处理模拟，取决于可用 CPU 内核的数量。传统上，大多数 RTOS 都是在单核上进行多处理仿真。

另一方面，状态机是一种程序设计规范，其目的可能是也可能不是为了分解复杂性。所以不一定和RTOS有关。

但是，您可以将“穷人的 RTOS”设计为一种有限状态机，您可以在其中给每个状态一个特定的时间片，并期望状态在它过去之前完成（或者看门狗会咬人）。这可以提供与 RTOS 相同的实时行为，但只有一个堆栈并且没有“真正的”上下文切换。

选择裸机或 RTOS 在很大程度上取决于程序的复杂性。除非原始程序设计是最先进的（很少是这样），否则当裸机程序发展到 50k-100k LOC 之间时，它们往往会变得很痛苦。在这些情况下，从一开始就选择 RTOS 可能更明智。

另一方面，如果您认为程序永远不会变得那么大，那么使用裸机会容易得多。 RTOS 引入了额外的复杂性，而额外的复杂性引入了错误。黄金法则是始终保持软件尽可能简单。

【讨论】：

任务不必是“不相关的”——如果事实上功能分区不需要 RTOS——一个简单的非实时、循环时间片或协作调度程序可以做到这一点。对于实时性能，任务划分是关于可调度性和保证响应时间的，因此“任务”由其执行的长度和确定性决定。它也不是关于“模拟”多处理 - 多处理和多任务是不同的概念。同样是关于调度而不是并发。