嵌入式系统状态模式:存储与异步事件相关的信息

Embedded System State Pattern: Storing information related to asynchronous events

我有一个嵌入式系统软件,我在其中完成了一系列硬件初始化步骤,然后根据发生的事件历史转到模式 1 或模式 2。即使在某种模式下,我也会根据事件的历史做某些事情

例如 如果我的显示器关闭,那么在模式 1 中,我采用的流量与显示器打开时的流量不同。并且显示通知异步到达,我没有明确查询该信息。

很少有其他类似的异步到达的事件可以改变我将在流程中进一步采取的行动过程。

我正在尝试了解如何存储与过去发生的这些事件相关的信息。我倾向于将它们存储为标志,但这样就违背了使用状态模式的目的(而且它也容易出错)。

我的另一个选择是将这些信息存储在状态本身中,例如 Mode1_DisplayOff_Atrribx、Mode1_DisplayOff_Atrribx、Mode2_DisplayOff_Atrribx、Mode2_DisplayOff_Atrriby。但我担心这会使状态机变得复杂。

正确的方法应该是什么?

(问题不一定与嵌入式系统有关)

针对这种情况或任何具有复杂状态处理的情况的一般设计建议:

  • 总体设计建议:尽可能简单。力求简单,而不是复杂。

  • 根据您拥有的“模式”、“事件”、“标志”等组合的数量创建一个状态机。这可以根据需要简单或高级 - 有时您可能需要实现子状态(例如在状态“错误”中,有子状态“错误显示”和“错误 adc”等)。

  • 避免旗帜丛林:你必须从众多来源收集旗帜已经够糟糕了。如果您还把它与本地决策者结合起来,您将不得不在整个程序中编写复杂的代码,而本地决策者会导致状态发生变化。跟踪程序流和代码覆盖率很快就会变得不可能。

    这也往往会导致许多本来可以相互独立的模块之间的紧密耦合,这总是一件非常糟糕的事情。

  • 使用标准错误数据类型(错误编号、错误来源等)为所有状态实施标准化错误处理程序。

  • 将异步信息收集与状态机分开。也就是说,如果异步事件独立于程序当前执行的状态而发生。如果没有,您必须将它们集成到状态机中。

  • 在程序的一个地方集中决定下一步做什么。最好结合错误处理器。

你的主循环看起来像这样:

for(;;)
{
  state_result = state_machine[current_state]();
  event_result = gather_event(); // might need several of these

  current_state = evaluate_results (state_result, event_result);
}

其中 evaluate_results 是程序中 唯一 允许发生状态更改的地方。该函数只关心接下来执行什么状态,不做任何实际工作。