基于状态机的定时器按键扫描（短按/长按/连按）

1. 从传统按键扫描到状态机设计

第一次接触按键扫描是在大学电子设计课上，当时用while(key==0)这种简单粗暴的方式检测按键，结果整个程序卡死在循环里，数码管显示都变得一卡一卡的。后来改用定时器扫描算是解决了问题，但当我开始做智能家居遥控器项目时，发现传统方法在应对短按/长按/连按这种复杂交互时，代码会变得像意大利面条一样难以维护。

状态机就像给按键行为画了个流程图。想象你家的智能灯泡：短按开灯、长按调亮度、快速连按切换模式。用传统方法可能要写一堆if-else和计时变量，而状态机把这些行为拆解成明确的状态节点和迁移条件。我在开发红外遥控器时就深有体会——当产品经理第5次修改交互逻辑时，只需要调整状态图就能快速重构代码。

2. 状态机核心概念拆解

2.1 状态定义的艺术

在音量调节场景中，我通常定义这5个核心状态：

• IDLE（空闲）：按键未被触碰，相当于待机状态
• DEBOUNCE（消抖）：检测到电平变化后的20ms过滤期
• PRESSED（按下确认）：稳定按下状态的门卫
• HOLD（长按判定）：持续按下超过1秒的哨兵
• REPEAT（连发）：每隔200ms自动触发按键事件

实际项目中我发现，状态划分粒度直接影响代码复杂度。曾有个智能门锁项目，我把"指纹识别中"也设为独立状态，结果状态爆炸难以维护。后来合并成"生物识别处理"大状态后，用子状态机管理才解决。

2.2 状态迁移的触发条件

迁移条件就是状态切换的扳机，常见的有：

1. 定时器超时：比如消抖状态固定20ms
2. 电平变化：检测到按键释放
3. 持续时间：按下超过阈值进入长按
4. 外部事件：其他模块发出的信号

在智能温控器项目里，我遇到过条件冲突的坑：长按调温度时突然收到蓝牙指令，导致状态紊乱。后来加了event_queue队列才解决，这点后面会详细说。

3. 嵌入式实战代码解析

3.1 状态枚举与结构定义

先看我最常用的状态机骨架：

c复制typedef enum {
    STATE_IDLE,
    STATE_DEBOUNCE,
    STATE_PRESSED,
    STA