嵌入式状态机与中断回调的趣味实践

1. 项目概述：用硬件思维解决拖延症的趣味实践

作为一名嵌入式开发者，我经常遇到这样的困境：早上明明该起床工作了，却总想再赖会儿床。直到某天突发奇想——既然能用单片机控制各种硬件设备，为什么不能用同样的逻辑来控制自己的行为？于是就有了这个"给自己写个标志位逼迫自己上班"的小项目。

这个项目的核心思路是：通过硬件开发中常用的状态机+中断回调机制，模拟人类行为决策过程。我们定义一个volatile全局变量want_work作为工作意愿标志位，再通过"喝水"这个日常行为触发状态变更。当满足特定条件（喝好了或加班状态）时，在中断回调中置位标志，主循环检测到标志位变化后执行上班动作。

提示：volatile关键字在这里至关重要，它告诉编译器这个变量可能被意外修改（比如被中断服务程序修改），避免编译器优化导致读取脏数据。

2. 核心代码解析与硬件思维映射

2.1 状态枚举设计

c复制typedef enum {
    OK       = 0x00,  // 正常状态
    ERROR    = 0x01,  // 异常状态  
    BUSY     = 0x02,  // 忙碌状态
    TIMEOUT  = 0x03   // 超时状态
} StatusTypeDef;

这个状态枚举的设计体现了嵌入式开发的典型思维：

• 使用十六进制值而非十进制，这是寄存器操作的惯例
• 状态值按0x00开始递增，预留扩展空间
• 每个状态都有明确的语义定义，类似硬件状态寄存器

2.2 中断回调机制

c复制void IT_Callback() {
    if(Drink() == OK || Drink() == BUSY) {
        want_work = 1;  // 原代码中的==是错误写法，应为=
    }
}

这里模拟了硬件中断的处理逻辑：

1. 中断触发后立即调用回调函数
2. 在回调中检查当前状态（类似读取中断状态寄存器）
3. 满足条件时修改全局标志位（类似置位中断标志）

注意：原代码中的want_work == 1是常见笔误，在回调函数中应该使用赋值操作=而非比较操作==。这种错误在实际开发中经常导致难以排查的bug。

2.3 状态判断函数

c复制St