设计状态机时，先画转换条件，再画状态
一句话: 很多人设计状态机先枚举有哪些状态再想怎么转换容易漏掉转换路径。反过来先画条件矩阵——每个条件组合下应该发生什么——状态自然浮现。适合谁读适合嵌入式开发者、单片机初学者及遇到类似问题的工程师常规做法的问题拿到需求第一反应是列状态IDLE → STARTING → RUNNING → FAULT → ...然后想从 IDLE 怎么到 STARTING从 STARTING 怎么到 RUNNING这种做法容易漏正在 STARTING 时收到关断指令 → 没画这条线已经在 FAULT 了又收到关断 → 没画这条线关断后又收到开机 → 会不会重开不知道先枚举状态再想转换 从答案反推条件容易漏。反过来先列条件矩阵条件 1: 触发标志 0 还是 1 条件 2: 当前在什么状态两个条件的组合穷举触发标志当前状态应该发生什么0IDLE什么都不做0非 IDLE关断回 IDLE1IDLE启动序列第一步1非 IDLE继续当前序列状态名IDLE / STARTING / RUNNING是后来加的——条件矩阵先写好了状态只是给每个组合取的名字。为什么这样做先枚举状态先画条件矩阵2^4 16 种条件组合只覆盖了 4 种16 种全列出来每个都明确容易漏转换路径不可能漏——每个组合都有答案新增条件要改所有状态新增条件加一列就行穷举不是笨办法——嵌入式状态机的条件数通常 ≤ 3最多 8 种组合。全列出来比漏掉强。经验条件矩阵先写状态名后取。每个条件组合下的行为定了状态自然浮现。多标志方案的状态空间藏着非法组合。5 个标志 32 种组合只有 4 种合法。两个变量 4 种全部合法。变量越少越不容易出 bug。有用的话点个收藏下次调试直接用。有问题欢迎评论区交流看到了都会回。下一篇dead-code-chain-deletion——状态机、编码规范、编译链接——每个嵌入式新人都要过的三道坎
