简介面向STM32初学者的按键状态机示例工程以单击、双击、长按三种事件为典型场景完整演示如何利用定时器中断与状态机思想处理单个按键的复杂操作。程序基于STM32F103C8T6自制开发板使用PA0作为按键输入、定时器3产生时基并通过串口1打印按键事件整体代码结构简洁规范、可读性和可移植性强。工程共79个文件包含33个头文件与32个C源文件覆盖标准外设库、系统延时、串口驱动、定时器及按键模块另有可烧录的HEX固件、Keil工程配置文件及辅助脚本等压缩包仅182KB轻量方便。目前已有6787人学习下载适合需要理解定时器中断、按键消抖与状态机建模的开发者参考。资料提供完整可编译的Keil工程从硬件初始化、定时器配置到按键扫描、单击与双击判定、长按超时处理均有清晰实现读者可直接烧录到开发板验证事件输出也可在此基础上扩展多按键或长按连发功能是嵌入式状态机入门和项目复用的实用素材。 按键处理这个东西看起来简单实际做起来是真的“阴间”。早几年我在一个项目里用最简单的延时消抖标志位方式做按键结果被测试同事连着提了三个bug单击偶尔变双击、长按触发了又立刻补发一个单击、双击的节奏怎么按都不对。从那之后我就把按键模块全部推倒重写换成现在的状态机方案用到现在快五年了不管是小家电、手持设备还是工业面板都没有再出过毛病。这篇文章就基于我实际量产过的STM32按键状态机方案把单击、双击、长按这套逻辑彻底讲透。这个方案能解决什么问题呢简单说就是用一颗定时器一套按键状态机替代以前那种“延时连续检测”的写法让按键响应稳定、可扩展、不阻塞主循环而且单击、双击、长按的判定窗口全部可配置。适合正在做嵌入式项目、被按键逻辑折磨过的开发同学也适合刚学STM32想把代码写得规范一点的初学者。1. 按键状态机的整体设计思路1.1 为什么非得用状态机普通写法差在哪大家最常见的按键写法是检测到IO拉低delay个10~20ms再去读一次确认是低电平就是真的按下了置一个标志位然后在主循环里去判断这个标志位该执行什么操作。还有更省事的直接在while循环里delay等待释放。这两种写法在小项目里确实能跑但只要按键一多、操作组合一复杂问题全出来了第一delay会卡住整个程序。按下按键的瞬间单片机还在延时消抖这时候中断来了处理不及时串口数据可能就丢了显示屏刷新也会卡顿。第二单击和长按的判定很尴尬。你想在同一个按键上实现“短按一下是确认长按三秒是关机”用普通写法就得在按下的时候开一个计时变量在释放的时候看计时值但还要防着用户按久了不松手的情况逻辑会越写越乱。第三双击基本没法做。双击要求检测两次按下而且两次之间间隔不能太长用普通标志位根本无从下手只能靠那种“硬等第二次按下”的阻塞式写法整个系统变得极其脆弱。状态机的好处就在于它把按键的行为拆成了“状态”和“事件”。每次扫描只做一件事根据当前状态和当前IO电平决定下一个状态是什么要不要触发某个事件。它不阻塞、不延时、所有时间判断都依靠一个统一的时基去推进代码结构非常清晰。1.2 这个方案的时间基准确立做按键状态机第一步不是写代码而是确定时基。我的习惯是开一个1ms的定时器中断专门用来给按键模块提供心跳。为什么不选10ms因为单击双击的判定窗口需要比较精细的控制1ms时基可以灵活地组合出5ms消抖、200ms双击窗口、1500ms长按超时这些参数而且误差可控。这里有一个关键点定时器中断里只做一件事就是对一个全局的tick变量加一然后把按键扫描函数放进去执行。扫描函数内部通过比较tick和上一次事件时间之间的差值来确定当前处于什么阶段。时基确定之后后面所有的超时判断、消抖时间、双击窗口、长按时间全都基于这个tick差值来算不用再依赖任何阻塞延时。2. 按键底层的扫描与消抖实现2.1 硬件连接与GPIO配置要点按键的硬件接线看起来简单实际踩坑的不少。我常用的接法是按键一端接GPIO另一端接地GPIO内部配置为上拉输入。这样按键按下时读到低电平释放时是高电平逻辑清晰。有一点需要特别提醒STM32的GPIO上拉电阻一般在30kΩ~50kΩ左右如果按键引线比较长或者工作环境电磁干扰比较强光靠内部上拉是不够的。我之前在产品上遇到过莫名其妙触发按键事件的情况后来用示波器一抓发现线上有几百毫伏的毛刺直接导致误触发。这种情况下要么外部加一个10kΩ上拉到VCC要么并联一个0.1μF电容到地硬件上把噪声滤掉软件上才能安心做消抖。GPIO初始化没什么特别的开时钟、配模式、设速度代码如下void key_gpio_init(void) { GPIO_InitTypeDef gpio_init {0}; __HAL_RCC_GPIOB_CLK_ENABLE(); gpio_init.Pin GPIO_PIN_0 | GPIO_PIN_1; gpio_init.Mode GPIO_MODE_INPUT; gpio_init.Pull GPIO_PULLUP; gpio_init.Speed GPIO_SPEED_FREQ_LOW; HAL_GPIO_Init(GPIOB, gpio_init); }2.2 消抖到底要不要做怎么做只要是机械按键就逃不过抖动。按下去的瞬间簧片会反弹好几次持续时间一般5~10ms。如果不做消抖一次按下可能被识别成好几次按下单击变双击就是这么来的。状态机方案里的消抖不是单独写一个delay而是利用连续扫描的思想当检测到IO电平变化后并不立刻确认状态改变而是要求同一个电平状态连续保持N次扫描每次扫描间隔1msN一般取10~15。也就是说10ms以上的稳定电平才认为是真正按下了或者释放了。这样处理的好处是消抖时间和状态机逻辑完全融合不需要额外编码也不会因为消抖阻塞其他代码。实测下来10ms消抖对于绝大多数按键都够用如果是那种非常劣质的按键可以把N适当调大但不要超过30ms否则手感会变“肉”按下去半天没反应。3. 单击、双击、长按的判定逻辑与状态跳转3.1 事件定义与状态划分按键状态机要管的事情其实就三件什么时候算一次按下什么时候算一次释放以及按下到释放之间的时间到底算单击还是长按。在这个基础上双击就是“两次完整的单击动作且间隔在窗口内”。我的代码里把按键划分为5个状态每个状态代表按键当前处于什么阶段状态名含义进入条件KEY_STATE_IDLE空闲等待按击初始化、事件处理完毕KEY_STATE_PRESS按下消抖中检测到IO低电平KEY_STATE_RELEASE释放消抖中检测到IO高电平KEY_STATE_WAIT单击确认等待检测到一次完整短按释放KEY_STATE_LONG长按已触发按下时间超过长按阈值事件则定义为以下几种typedef enum { KEY_EVENT_NONE 0, KEY_EVENT_SINGLE_CLICK, KEY_EVENT_DOUBLE_CLICK, KEY_EVENT_LONG_PRESS, KEY_EVENT_LONG_PRESS_RELEASE, } key_event_t;长按分为两个事件长按触发按下持续时间够了和长按释放长按之后松手。后者很重要因为长按结束后如果直接判定为一次单击就会导致误操作。我的做法是长按触发之后在释放时只会发出KEY_EVENT_LONG_PRESS_RELEASE不再发单击事件。3.2 核心状态机代码这是整个模块的灵魂部分。按下、释放、等待、判定都在这个函数里完成每个状态里都做了两件事判断是否满足跳转条件以及在跳转时是否产生事件。void key_scan(key_t *key, uint8_t level, uint32_t tick) { switch (key-state) { case KEY_STATE_IDLE: if (level KEY_PRESSED) { key-state KEY_STATE_PRESS; key-press_tick tick; } break; case KEY_STATE_PRESS: if (level KEY_RELEASED) { key-state KEY_STATE_IDLE; } else if (tick - key-press_tick KEY_LONG_PRESS_MS) { key-state KEY_STATE_LONG; key_event_callback(KEY_EVENT_LONG_PRESS); } break; case KEY_STATE_LONG: if (level KEY_RELEASED) { key-state KEY_STATE_IDLE; key_event_callback(KEY_EVENT_LONG_PRESS_RELEASE); } break; case KEY_STATE_WAIT: if (level KEY_PRESSED) { key-state KEY_STATE_PRESS; key-press_tick tick; } else if (tick - key-release_tick KEY_DOUBLE_CLICK_WINDOW_MS) { key-state KEY_STATE_IDLE; key_event_callback(KEY_EVENT_SINGLE_CLICK); } break; default: key-state KEY_STATE_IDLE; break; } }这段代码里还需要配合释放时的判断逻辑。在PRESS状态下检测到释放不直接回到IDLE而是进入RELEASE消抖消抖完成后再判断这次按压的时长到底在哪个区间。释放判定的完整逻辑我放在下面。注意只有当按压时间小于长按阈值才认为这是一次短按才会进入WAIT状态等待双击窗口。case KEY_STATE_RELEASE: if (level KEY_PRESSED) { key-state KEY_STATE_PRESS; } else if (tick - key-press_tick KEY_LONG_PRESS_MS) { key-state KEY_STATE_IDLE; } else { key-state KEY_STATE_WAIT; key-release_tick tick; } break;3.3 单击和双击为什么要一个WAIT状态很多初学者不理解为什么短按释放之后不立刻判定为单击而是进入一个WAIT状态因为双击本身就是两个连续的操作。第一次按下释放后你并不知道用户是打算停在这里单击还是会马上再按一下双击。如果第一次释放就立刻上报单击事件那么双击操作就会先产生一个单击事件上层逻辑就被破坏了。所以释放之后会开启一个时间窗口。在这个窗口内如果再次检测到按下就判定为双击如果窗口超时没有第二次按下则判定为单击。窗口时间我一般取200~300ms太长了双击判定变得迟钝太短了用户手速稍慢就会识别失败。WAIT状态的设计是整个方案的灵魂它牺牲了一点单击上报的实时性最多延迟300ms换来了双击判定的准确性。绝大多数实际产品都是可以接受这个延迟的。3.4 事件回调与上报机制事件产生之后怎么通知应用层我建议用回调函数。按键模块只负责识别事件不负责处理业务逻辑业务层挂一个回调进来即可。这样模块可以做到完全解耦通用性极强。typedef void (*key_event_callback_t)(uint8_t key_id, key_event_t event); void key_init(key_t *key, uint8_t key_id, key_event_callback_t callback) { key-state KEY_STATE_IDLE; key-key_id key_id; key-callback callback; } static void key_event_callback(key_event_t event) { if (key-callback) { key-callback(key-key_id, event); } }应用层的回调里就可以根据不同的按键ID和不同的事件执行不同逻辑。比如一个设备有两个按键一个负责翻页一个负责确认void app_key_callback(uint8_t key_id, key_event_t event) { if (key_id KEY_UP) { if (event KEY_EVENT_SINGLE_CLICK) page_next(); else if (event KEY_EVENT_LONG_PRESS) page_fast_forward(); } else if (key_id KEY_OK) { if (event KEY_EVENT_SINGLE_CLICK) confirm(); else if (event KEY_EVENT_DOUBLE_CLICK) cancel(); } }4. 多按键扩展与工程集成4.1 把单个按键封装成对象上面代码里的key_t结构体如果只定义一个实例那一个按键都不够用。实际项目里肯定是一块板子上有好几个按键所以我把每个按键都封装成一个独立对象包含各自的GPIO读取函数、状态、时间戳和回调。typedef struct { uint8_t key_id; uint8_t state; uint8_t active_level; uint32_t press_tick; uint32_t release_tick; uint8_t (*read_level)(void); key_event_callback_t callback; } key_t;每个按键在初始化的时候传入自己的GPIO读取函数扫描的时候统一调用。这样无论是8个按键还是16个按键都是在同一个key_scan函数里循环处理代码量不会膨胀。4.2 定时器中断里的扫描调度1ms的定时器中断里调用按键扫描扫描函数内部遍历所有按键实例依次执行状态机逻辑。这里需要注意一个性能问题如果按键数量多不要在一个中断里把所有按键都扫完而是每次中断只扫一个按键用轮询的方式分摊CPU占用。实际上对于绝大多数应用5个以内按键一次性扫完也就几微秒的事STM32完全扛得住不用过度设计。我一般是直接全部扫描只在按键数量超过8个时才考虑分时扫描。void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim-Instance TIM3) { tick_ms; for (uint8_t i 0; i KEY_MAX_NUM; i) { key_scan(key_table[i], key_table[i].read_level(), tick_ms); } } }4.3 应用层不用关心具体按键时长我把所有时间参数集中在头文件里定义应用层不需要知道长按到底是1500ms还是2000ms只需要接收事件就行。修改时间参数也只需要改宏定义不会动到业务代码后期调试调参非常方便。#define KEY_DEBOUNCE_MS 10 #define KEY_LONG_PRESS_MS 1500 #define KEY_DOUBLE_CLICK_WINDOW_MS 2504.4 长按的连发与分段回调扩展有的场景下长按需要“连续触发”比如长按音量键连续加减或者是长按快进。这个时候不能只在长按触发那一刻回调一次而是需要在长按过程中每隔一段时间回调一次。扩展方案是给每个按键加一个repeat_tick变量在LONG状态下每500ms产生一次KEY_EVENT_LONG_PRESS_REPEAT事件。这个扩展不会影响状态机原有的结构只在LONG状态的handler里增加一个时间判断就行。5. 实战中踩过的坑与调参建议5.1 双击和单击互相冲突的根源我遇到过最典型的误判场景双击总是不生效或者单击偶尔变成双击。排查下来发现是两个时间参数配合出了问题。双击窗口设得太大用户明明是想点一下停一下结果他第二次点的时候还在窗口内就变成了逻辑上的双击。而单击误判成双击通常是消抖时间太短一次按下产生的信号抖动被当成了两次按下。一个比较稳妥的搭配是消抖10ms、双击窗口250ms、单击判定在释放后150ms内无第二次按下即上报。这个组合在我做过的几个项目里表现都比较稳定大家可以作为起点微调。5.2 长按和双击千万别叠在一个按键上设计按键事件组合的时候要注意单击双击长按都放到同一个按键上使用体验会很差。因为长按本身会占用手指按下不放的那段时间如果用户长按之后又想双击状态机判定起来会很别扭。而且用户在操作时不一定会严格按照时序来。我的建议是单个按键最多分配两种事件比如“单击长按”或者“单击双击”。实在需要三个功能就用“单击双击长按释放”的组合——单击做最常见操作双击做快捷操作长按做危险操作比如关机、恢复出厂每个事件之间隔得非常远误触发概率小。5.3 长按触发了释放时一定不要再上报单击这个点是很多自己写按键逻辑的开发者会漏掉的。长按触发后用户松手这时候释放检测如果直接进入WAIT状态就会产生一次单击事件导致“长按关机但顺手又执行了一次确认”这种反人类操作。解决方式就是我前面代码里写的释放消抖完成后判断按压时长如果已经超过长按阈值直接回到IDLE不进入WAIT也就不会产生单击事件。这个逻辑在状态机RELEASE分支里已经体现要特别注意顺序不能反过来。5.4 低功耗场景的额外处理带睡眠唤醒的设备按键还需要承担唤醒功能。这种情况下定时器可能已经停了按键无法靠状态机扫描来检测。我的做法是用外部中断EXTI唤醒MCU唤醒后快速初始化定时器然后把当前时刻作为时间基准继续跑状态机。这里有一个坑外部中断唤醒时IO会被拉低MCU启动定时器需要几个ms如果不做处理这个按键释放时会检测不到按下状态。建议在唤醒中断里设一个标志主循环首次扫描时直接跳过消抖强行进入按下状态再按正常流程跑。5.5 用逻辑分析仪验证时序别靠猜调试按键状态机的时候强烈建议把按键的IO电平、tick时间、事件回调这三个信息通过串口或者逻辑分析仪抓出来对齐。我自己习惯在回调函数里打一条带毫秒时间戳的日志比如printf([%d] key%d event: %d\r\n, tick_ms, key_id, event);这样一眼就能看出事件是不是按预期时序触发而不是靠手感和肉眼去猜测。按键时序这东西一旦多次叠加人的感觉是不准的只有数据是准的。5.6 状态机的默认分支一定要写按键状态机运行中如果因为某种异常进入了未知状态default分支必须处理。我的习惯是default里把状态重置为IDLE并清空所有时间戳保证模块能自动恢复正常。别小看这几行代码它在极端情况下能救你一次。6. 这套方案的适用边界与扩展思考按键状态机这个思路不只适用于STM32任何单片机只要有定时器都能实现。甚至不依赖MCU平台在纯C环境下也能独立编译测试。我做项目的时候经常先在PC上搭一套模拟环境把IO读函数替换成命令行输入把按键逻辑全部在PC上调通再移植到板子上效率高很多。扩展方向上这套状态机还可以接入矩阵键盘、编码器按键、触摸按键。触摸按键的底层采集方式不同但上层的事件判定逻辑完全复用只需要实现各自的read_level函数就可以。我之前还把按键事件和系统事件总线对接过按键不直接调用业务函数而是往事件总线里发消息。这样即使在多线程系统里也能保证按键模块线程安全业务逻辑通过订阅事件的方式来响应按键。代码层面上完全解耦后期新增按键或者新增事件都不需要改动已有模块。按我这几年的经验按键模块看起来是嵌入式里最简单的东西但它是用户和设备交互最直接的通道。代码写得乱、时序没调好用户不一定说得出哪里不对只会觉得这个设备“有点难用”。用状态机这套思路把按键逻辑当成一个有规范的状态流转过程时间参数全部可配置整个模块后期几乎不用再动非常省心。最后再分享一个技巧当你把按键状态机调到满意之后最好做一遍“暴力测试”——就是拿手指头对着按键乱按每个节奏都按一遍看有没有误触发。这种测试能暴露出参数设置不合理的地方比按部就班的用例测试好用得多。我的经验是只要暴力测试下事件上报没有异常这套配置基本就能放心量产了。本文还有配套的精品资源点击获取
STM32按键状态机：搞定单击双击长按，彻底告别延时消抖
简介面向STM32初学者的按键状态机示例工程以单击、双击、长按三种事件为典型场景完整演示如何利用定时器中断与状态机思想处理单个按键的复杂操作。程序基于STM32F103C8T6自制开发板使用PA0作为按键输入、定时器3产生时基并通过串口1打印按键事件整体代码结构简洁规范、可读性和可移植性强。工程共79个文件包含33个头文件与32个C源文件覆盖标准外设库、系统延时、串口驱动、定时器及按键模块另有可烧录的HEX固件、Keil工程配置文件及辅助脚本等压缩包仅182KB轻量方便。目前已有6787人学习下载适合需要理解定时器中断、按键消抖与状态机建模的开发者参考。资料提供完整可编译的Keil工程从硬件初始化、定时器配置到按键扫描、单击与双击判定、长按超时处理均有清晰实现读者可直接烧录到开发板验证事件输出也可在此基础上扩展多按键或长按连发功能是嵌入式状态机入门和项目复用的实用素材。 按键处理这个东西看起来简单实际做起来是真的“阴间”。早几年我在一个项目里用最简单的延时消抖标志位方式做按键结果被测试同事连着提了三个bug单击偶尔变双击、长按触发了又立刻补发一个单击、双击的节奏怎么按都不对。从那之后我就把按键模块全部推倒重写换成现在的状态机方案用到现在快五年了不管是小家电、手持设备还是工业面板都没有再出过毛病。这篇文章就基于我实际量产过的STM32按键状态机方案把单击、双击、长按这套逻辑彻底讲透。这个方案能解决什么问题呢简单说就是用一颗定时器一套按键状态机替代以前那种“延时连续检测”的写法让按键响应稳定、可扩展、不阻塞主循环而且单击、双击、长按的判定窗口全部可配置。适合正在做嵌入式项目、被按键逻辑折磨过的开发同学也适合刚学STM32想把代码写得规范一点的初学者。1. 按键状态机的整体设计思路1.1 为什么非得用状态机普通写法差在哪大家最常见的按键写法是检测到IO拉低delay个10~20ms再去读一次确认是低电平就是真的按下了置一个标志位然后在主循环里去判断这个标志位该执行什么操作。还有更省事的直接在while循环里delay等待释放。这两种写法在小项目里确实能跑但只要按键一多、操作组合一复杂问题全出来了第一delay会卡住整个程序。按下按键的瞬间单片机还在延时消抖这时候中断来了处理不及时串口数据可能就丢了显示屏刷新也会卡顿。第二单击和长按的判定很尴尬。你想在同一个按键上实现“短按一下是确认长按三秒是关机”用普通写法就得在按下的时候开一个计时变量在释放的时候看计时值但还要防着用户按久了不松手的情况逻辑会越写越乱。第三双击基本没法做。双击要求检测两次按下而且两次之间间隔不能太长用普通标志位根本无从下手只能靠那种“硬等第二次按下”的阻塞式写法整个系统变得极其脆弱。状态机的好处就在于它把按键的行为拆成了“状态”和“事件”。每次扫描只做一件事根据当前状态和当前IO电平决定下一个状态是什么要不要触发某个事件。它不阻塞、不延时、所有时间判断都依靠一个统一的时基去推进代码结构非常清晰。1.2 这个方案的时间基准确立做按键状态机第一步不是写代码而是确定时基。我的习惯是开一个1ms的定时器中断专门用来给按键模块提供心跳。为什么不选10ms因为单击双击的判定窗口需要比较精细的控制1ms时基可以灵活地组合出5ms消抖、200ms双击窗口、1500ms长按超时这些参数而且误差可控。这里有一个关键点定时器中断里只做一件事就是对一个全局的tick变量加一然后把按键扫描函数放进去执行。扫描函数内部通过比较tick和上一次事件时间之间的差值来确定当前处于什么阶段。时基确定之后后面所有的超时判断、消抖时间、双击窗口、长按时间全都基于这个tick差值来算不用再依赖任何阻塞延时。2. 按键底层的扫描与消抖实现2.1 硬件连接与GPIO配置要点按键的硬件接线看起来简单实际踩坑的不少。我常用的接法是按键一端接GPIO另一端接地GPIO内部配置为上拉输入。这样按键按下时读到低电平释放时是高电平逻辑清晰。有一点需要特别提醒STM32的GPIO上拉电阻一般在30kΩ~50kΩ左右如果按键引线比较长或者工作环境电磁干扰比较强光靠内部上拉是不够的。我之前在产品上遇到过莫名其妙触发按键事件的情况后来用示波器一抓发现线上有几百毫伏的毛刺直接导致误触发。这种情况下要么外部加一个10kΩ上拉到VCC要么并联一个0.1μF电容到地硬件上把噪声滤掉软件上才能安心做消抖。GPIO初始化没什么特别的开时钟、配模式、设速度代码如下void key_gpio_init(void) { GPIO_InitTypeDef gpio_init {0}; __HAL_RCC_GPIOB_CLK_ENABLE(); gpio_init.Pin GPIO_PIN_0 | GPIO_PIN_1; gpio_init.Mode GPIO_MODE_INPUT; gpio_init.Pull GPIO_PULLUP; gpio_init.Speed GPIO_SPEED_FREQ_LOW; HAL_GPIO_Init(GPIOB, gpio_init); }2.2 消抖到底要不要做怎么做只要是机械按键就逃不过抖动。按下去的瞬间簧片会反弹好几次持续时间一般5~10ms。如果不做消抖一次按下可能被识别成好几次按下单击变双击就是这么来的。状态机方案里的消抖不是单独写一个delay而是利用连续扫描的思想当检测到IO电平变化后并不立刻确认状态改变而是要求同一个电平状态连续保持N次扫描每次扫描间隔1msN一般取10~15。也就是说10ms以上的稳定电平才认为是真正按下了或者释放了。这样处理的好处是消抖时间和状态机逻辑完全融合不需要额外编码也不会因为消抖阻塞其他代码。实测下来10ms消抖对于绝大多数按键都够用如果是那种非常劣质的按键可以把N适当调大但不要超过30ms否则手感会变“肉”按下去半天没反应。3. 单击、双击、长按的判定逻辑与状态跳转3.1 事件定义与状态划分按键状态机要管的事情其实就三件什么时候算一次按下什么时候算一次释放以及按下到释放之间的时间到底算单击还是长按。在这个基础上双击就是“两次完整的单击动作且间隔在窗口内”。我的代码里把按键划分为5个状态每个状态代表按键当前处于什么阶段状态名含义进入条件KEY_STATE_IDLE空闲等待按击初始化、事件处理完毕KEY_STATE_PRESS按下消抖中检测到IO低电平KEY_STATE_RELEASE释放消抖中检测到IO高电平KEY_STATE_WAIT单击确认等待检测到一次完整短按释放KEY_STATE_LONG长按已触发按下时间超过长按阈值事件则定义为以下几种typedef enum { KEY_EVENT_NONE 0, KEY_EVENT_SINGLE_CLICK, KEY_EVENT_DOUBLE_CLICK, KEY_EVENT_LONG_PRESS, KEY_EVENT_LONG_PRESS_RELEASE, } key_event_t;长按分为两个事件长按触发按下持续时间够了和长按释放长按之后松手。后者很重要因为长按结束后如果直接判定为一次单击就会导致误操作。我的做法是长按触发之后在释放时只会发出KEY_EVENT_LONG_PRESS_RELEASE不再发单击事件。3.2 核心状态机代码这是整个模块的灵魂部分。按下、释放、等待、判定都在这个函数里完成每个状态里都做了两件事判断是否满足跳转条件以及在跳转时是否产生事件。void key_scan(key_t *key, uint8_t level, uint32_t tick) { switch (key-state) { case KEY_STATE_IDLE: if (level KEY_PRESSED) { key-state KEY_STATE_PRESS; key-press_tick tick; } break; case KEY_STATE_PRESS: if (level KEY_RELEASED) { key-state KEY_STATE_IDLE; } else if (tick - key-press_tick KEY_LONG_PRESS_MS) { key-state KEY_STATE_LONG; key_event_callback(KEY_EVENT_LONG_PRESS); } break; case KEY_STATE_LONG: if (level KEY_RELEASED) { key-state KEY_STATE_IDLE; key_event_callback(KEY_EVENT_LONG_PRESS_RELEASE); } break; case KEY_STATE_WAIT: if (level KEY_PRESSED) { key-state KEY_STATE_PRESS; key-press_tick tick; } else if (tick - key-release_tick KEY_DOUBLE_CLICK_WINDOW_MS) { key-state KEY_STATE_IDLE; key_event_callback(KEY_EVENT_SINGLE_CLICK); } break; default: key-state KEY_STATE_IDLE; break; } }这段代码里还需要配合释放时的判断逻辑。在PRESS状态下检测到释放不直接回到IDLE而是进入RELEASE消抖消抖完成后再判断这次按压的时长到底在哪个区间。释放判定的完整逻辑我放在下面。注意只有当按压时间小于长按阈值才认为这是一次短按才会进入WAIT状态等待双击窗口。case KEY_STATE_RELEASE: if (level KEY_PRESSED) { key-state KEY_STATE_PRESS; } else if (tick - key-press_tick KEY_LONG_PRESS_MS) { key-state KEY_STATE_IDLE; } else { key-state KEY_STATE_WAIT; key-release_tick tick; } break;3.3 单击和双击为什么要一个WAIT状态很多初学者不理解为什么短按释放之后不立刻判定为单击而是进入一个WAIT状态因为双击本身就是两个连续的操作。第一次按下释放后你并不知道用户是打算停在这里单击还是会马上再按一下双击。如果第一次释放就立刻上报单击事件那么双击操作就会先产生一个单击事件上层逻辑就被破坏了。所以释放之后会开启一个时间窗口。在这个窗口内如果再次检测到按下就判定为双击如果窗口超时没有第二次按下则判定为单击。窗口时间我一般取200~300ms太长了双击判定变得迟钝太短了用户手速稍慢就会识别失败。WAIT状态的设计是整个方案的灵魂它牺牲了一点单击上报的实时性最多延迟300ms换来了双击判定的准确性。绝大多数实际产品都是可以接受这个延迟的。3.4 事件回调与上报机制事件产生之后怎么通知应用层我建议用回调函数。按键模块只负责识别事件不负责处理业务逻辑业务层挂一个回调进来即可。这样模块可以做到完全解耦通用性极强。typedef void (*key_event_callback_t)(uint8_t key_id, key_event_t event); void key_init(key_t *key, uint8_t key_id, key_event_callback_t callback) { key-state KEY_STATE_IDLE; key-key_id key_id; key-callback callback; } static void key_event_callback(key_event_t event) { if (key-callback) { key-callback(key-key_id, event); } }应用层的回调里就可以根据不同的按键ID和不同的事件执行不同逻辑。比如一个设备有两个按键一个负责翻页一个负责确认void app_key_callback(uint8_t key_id, key_event_t event) { if (key_id KEY_UP) { if (event KEY_EVENT_SINGLE_CLICK) page_next(); else if (event KEY_EVENT_LONG_PRESS) page_fast_forward(); } else if (key_id KEY_OK) { if (event KEY_EVENT_SINGLE_CLICK) confirm(); else if (event KEY_EVENT_DOUBLE_CLICK) cancel(); } }4. 多按键扩展与工程集成4.1 把单个按键封装成对象上面代码里的key_t结构体如果只定义一个实例那一个按键都不够用。实际项目里肯定是一块板子上有好几个按键所以我把每个按键都封装成一个独立对象包含各自的GPIO读取函数、状态、时间戳和回调。typedef struct { uint8_t key_id; uint8_t state; uint8_t active_level; uint32_t press_tick; uint32_t release_tick; uint8_t (*read_level)(void); key_event_callback_t callback; } key_t;每个按键在初始化的时候传入自己的GPIO读取函数扫描的时候统一调用。这样无论是8个按键还是16个按键都是在同一个key_scan函数里循环处理代码量不会膨胀。4.2 定时器中断里的扫描调度1ms的定时器中断里调用按键扫描扫描函数内部遍历所有按键实例依次执行状态机逻辑。这里需要注意一个性能问题如果按键数量多不要在一个中断里把所有按键都扫完而是每次中断只扫一个按键用轮询的方式分摊CPU占用。实际上对于绝大多数应用5个以内按键一次性扫完也就几微秒的事STM32完全扛得住不用过度设计。我一般是直接全部扫描只在按键数量超过8个时才考虑分时扫描。void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim-Instance TIM3) { tick_ms; for (uint8_t i 0; i KEY_MAX_NUM; i) { key_scan(key_table[i], key_table[i].read_level(), tick_ms); } } }4.3 应用层不用关心具体按键时长我把所有时间参数集中在头文件里定义应用层不需要知道长按到底是1500ms还是2000ms只需要接收事件就行。修改时间参数也只需要改宏定义不会动到业务代码后期调试调参非常方便。#define KEY_DEBOUNCE_MS 10 #define KEY_LONG_PRESS_MS 1500 #define KEY_DOUBLE_CLICK_WINDOW_MS 2504.4 长按的连发与分段回调扩展有的场景下长按需要“连续触发”比如长按音量键连续加减或者是长按快进。这个时候不能只在长按触发那一刻回调一次而是需要在长按过程中每隔一段时间回调一次。扩展方案是给每个按键加一个repeat_tick变量在LONG状态下每500ms产生一次KEY_EVENT_LONG_PRESS_REPEAT事件。这个扩展不会影响状态机原有的结构只在LONG状态的handler里增加一个时间判断就行。5. 实战中踩过的坑与调参建议5.1 双击和单击互相冲突的根源我遇到过最典型的误判场景双击总是不生效或者单击偶尔变成双击。排查下来发现是两个时间参数配合出了问题。双击窗口设得太大用户明明是想点一下停一下结果他第二次点的时候还在窗口内就变成了逻辑上的双击。而单击误判成双击通常是消抖时间太短一次按下产生的信号抖动被当成了两次按下。一个比较稳妥的搭配是消抖10ms、双击窗口250ms、单击判定在释放后150ms内无第二次按下即上报。这个组合在我做过的几个项目里表现都比较稳定大家可以作为起点微调。5.2 长按和双击千万别叠在一个按键上设计按键事件组合的时候要注意单击双击长按都放到同一个按键上使用体验会很差。因为长按本身会占用手指按下不放的那段时间如果用户长按之后又想双击状态机判定起来会很别扭。而且用户在操作时不一定会严格按照时序来。我的建议是单个按键最多分配两种事件比如“单击长按”或者“单击双击”。实在需要三个功能就用“单击双击长按释放”的组合——单击做最常见操作双击做快捷操作长按做危险操作比如关机、恢复出厂每个事件之间隔得非常远误触发概率小。5.3 长按触发了释放时一定不要再上报单击这个点是很多自己写按键逻辑的开发者会漏掉的。长按触发后用户松手这时候释放检测如果直接进入WAIT状态就会产生一次单击事件导致“长按关机但顺手又执行了一次确认”这种反人类操作。解决方式就是我前面代码里写的释放消抖完成后判断按压时长如果已经超过长按阈值直接回到IDLE不进入WAIT也就不会产生单击事件。这个逻辑在状态机RELEASE分支里已经体现要特别注意顺序不能反过来。5.4 低功耗场景的额外处理带睡眠唤醒的设备按键还需要承担唤醒功能。这种情况下定时器可能已经停了按键无法靠状态机扫描来检测。我的做法是用外部中断EXTI唤醒MCU唤醒后快速初始化定时器然后把当前时刻作为时间基准继续跑状态机。这里有一个坑外部中断唤醒时IO会被拉低MCU启动定时器需要几个ms如果不做处理这个按键释放时会检测不到按下状态。建议在唤醒中断里设一个标志主循环首次扫描时直接跳过消抖强行进入按下状态再按正常流程跑。5.5 用逻辑分析仪验证时序别靠猜调试按键状态机的时候强烈建议把按键的IO电平、tick时间、事件回调这三个信息通过串口或者逻辑分析仪抓出来对齐。我自己习惯在回调函数里打一条带毫秒时间戳的日志比如printf([%d] key%d event: %d\r\n, tick_ms, key_id, event);这样一眼就能看出事件是不是按预期时序触发而不是靠手感和肉眼去猜测。按键时序这东西一旦多次叠加人的感觉是不准的只有数据是准的。5.6 状态机的默认分支一定要写按键状态机运行中如果因为某种异常进入了未知状态default分支必须处理。我的习惯是default里把状态重置为IDLE并清空所有时间戳保证模块能自动恢复正常。别小看这几行代码它在极端情况下能救你一次。6. 这套方案的适用边界与扩展思考按键状态机这个思路不只适用于STM32任何单片机只要有定时器都能实现。甚至不依赖MCU平台在纯C环境下也能独立编译测试。我做项目的时候经常先在PC上搭一套模拟环境把IO读函数替换成命令行输入把按键逻辑全部在PC上调通再移植到板子上效率高很多。扩展方向上这套状态机还可以接入矩阵键盘、编码器按键、触摸按键。触摸按键的底层采集方式不同但上层的事件判定逻辑完全复用只需要实现各自的read_level函数就可以。我之前还把按键事件和系统事件总线对接过按键不直接调用业务函数而是往事件总线里发消息。这样即使在多线程系统里也能保证按键模块线程安全业务逻辑通过订阅事件的方式来响应按键。代码层面上完全解耦后期新增按键或者新增事件都不需要改动已有模块。按我这几年的经验按键模块看起来是嵌入式里最简单的东西但它是用户和设备交互最直接的通道。代码写得乱、时序没调好用户不一定说得出哪里不对只会觉得这个设备“有点难用”。用状态机这套思路把按键逻辑当成一个有规范的状态流转过程时间参数全部可配置整个模块后期几乎不用再动非常省心。最后再分享一个技巧当你把按键状态机调到满意之后最好做一遍“暴力测试”——就是拿手指头对着按键乱按每个节奏都按一遍看有没有误触发。这种测试能暴露出参数设置不合理的地方比按部就班的用例测试好用得多。我的经验是只要暴力测试下事件上报没有异常这套配置基本就能放心量产了。本文还有配套的精品资源点击获取
 导入同目录资源？)
