第1章 状态机与逻辑建模：Stateflow基础
各位同学，咱们今天聊聊Stateflow。说实话，我刚接触这个工具时，觉得它就是个画流程图的玩具。直到有一次，我在一个汽车电控项目里，用纯Simulink搭了200多个模块的状态切换逻辑，结果仿真跑起来像蜗牛一样慢。后来改用Stateflow，代码量直接砍掉一半，逻辑还清晰多了。嗯，从那以后，我再也不敢小看它了。
1.1 什么是状态机？
状态机，说白了就是描述一个系统在不同状态之间怎么跳来跳去的模型。你想想看，一个按键按下，它从「松开」状态变成「按下」状态，这就是最简单的状态机。
我个人的习惯是，只要遇到「模式切换」、「按键处理」、「协议解析」这类逻辑，第一反应就是用Stateflow。为什么？因为它天生就是干这个的。
核心概念：
- 状态（State）：系统在某个时刻的稳定情况
- 转移（Transition）：从一个状态跳到另一个状态
- 事件（Event）：触发转移的条件
- 动作（Action）：进入/退出状态时执行的操作
我在项目中遇到过一位同事，他把所有逻辑都写在Simulink的MATLAB Function里，结果代码生成出来有3000多行，维护起来简直要命。后来我帮他改成Stateflow，代码量降到800行，可读性还提升了。这就是状态机的威力。
1.2 Stateflow基础操作
打开Stateflow编辑器，你会看到一个空白画布。别慌，咱们一步步来。
1.2.1 创建状态
拖一个「State」方块到画布上，双击给它起个名字。比如叫「IDLE」（空闲）。再拖一个，叫「ACTIVE」（激活）。
这里有个小技巧：状态名称最好用大写字母，下划线分隔。这是很多汽车电子公司的代码规范。我习惯用「STATE_IDLE」、「STATE_ACTIVE」这种命名方式，生成代码时一目了然。
1.2.2 添加转移
从一个状态的边缘拖出一条线，连接到另一个状态。双击这条线，写上转移条件。比如：
button_pressed == 1意思就是：当按键按下时，从IDLE跳到ACTIVE。
我的经验：转移条件尽量写简单。如果条件太复杂，可以拆成多个中间状态。我曾经见过一个转移条件写了20多行，调试时自己都看不懂。后来拆成3个状态，问题迎刃而解。
1.2.3 添加动作
双击状态，在「entry」和「exit」里写动作。entry是进入状态时执行，exit是离开时执行。
entry: led_on = 1;
exit: led_on = 0;这样，进入状态就点亮LED，离开就熄灭。简单吧？
1.3 流程图与函数
Stateflow里除了状态，还能画流程图。流程图适合做「一次性」的逻辑判断，比如初始化、错误处理。
我一般在状态机外面放一个流程图，专门做初始化。等初始化完成，再跳转到主状态机。这样结构清晰，不会把初始化逻辑和运行逻辑混在一起。
1.3.1 图形函数
Stateflow支持图形函数，说白了就是在状态机里画一个子流程图，可以重复调用。比如：
function y = debounce(x)
// 这里画一个消抖逻辑的流程图
// 输入x，输出y
end我在做按键消抖时，就喜欢用图形函数。把消抖逻辑封装起来，主状态机里直接调用，干净利落。
1.4 事件驱动建模
Stateflow支持事件驱动。什么意思？就是不用每个周期都去轮询条件，而是等事件发生了再处理。
举个例子：
// 定义事件
event button_event;
// 转移条件
button_event当button_event发生时，状态机才执行转移。这样能大大降低CPU占用率。
注意：事件驱动虽然高效，但容易漏掉事件。我在一个项目中就吃过这个亏——事件触发太快，状态机还没处理完，下一个事件就来了。后来我加了事件队列，才解决这个问题。
1.5 经典案例：按键消抖
咱们来实战一下。按键消抖是嵌入式开发里最常见的需求。机械按键按下时，会有10-20ms的抖动，直接读取会误判。
用Stateflow实现消抖，思路是这样的：
- 检测到按键按下，进入「等待稳定」状态
- 等待20ms，再次读取按键
- 如果还是按下状态，确认有效
- 否则回到空闲状态
代码实现：
// 状态定义
enum {IDLE, WAIT_STABLE, CONFIRMED};
// 转移逻辑
IDLE:
if (key_read() == 0) // 按键按下
goto WAIT_STABLE;
endif
WAIT_STABLE:
if (timer >= 20) // 等待20ms
if (key_read() == 0)
goto CONFIRMED;
else
goto IDLE;
endif
endif
CONFIRMED:
// 输出有效按键信号
key_valid = 1;
goto IDLE;这个逻辑我用了好多年，从来没出过问题。你想想看，如果不用状态机，用纯C语言写，至少得加一堆标志位和定时器变量，维护起来多麻烦。
1.6 经典案例：模式切换
另一个常见场景是模式切换。比如一个设备有「正常模式」、「省电模式」、「诊断模式」。
用Stateflow实现：
// 状态定义
enum {NORMAL, POWER_SAVE, DIAGNOSTIC};
// 转移条件
NORMAL:
if (battery_low)
goto POWER_SAVE;
if (diag_request)
goto DIAGNOSTIC;
POWER_SAVE:
if (battery_charged)
goto NORMAL;
DIAGNOSTIC:
if (diag_complete)
goto NORMAL;这里有个坑：模式切换时，要注意资源的释放和重新分配。比如进入省电模式前，要关掉不必要的模块；退出时再重新打开。这些动作写在状态的exit和entry里，最合适不过。
避坑指南：我曾经在模式切换时忘记关掉一个定时器，结果进入省电模式后，定时器还在跑，功耗根本降不下来。后来我养成了习惯：每个状态的exit里，都把该关的东西关干净。
1.7 知识体系总览
下面这张图，是我自己总结的Stateflow知识体系。你可以把它当作学习路线图：
这张图把Stateflow的核心知识点都串起来了。你学的时候，可以按照这个结构，一个一个攻克。别贪多，先把「状态与转移」搞明白，后面的自然就通了。
好了，这一章的内容就到这儿。记住，Stateflow不是万能的，但处理状态逻辑，它绝对是最顺手的工具。下一章咱们聊聊更深入的话题——状态机的层次结构和并行机制。