STM32矩阵键盘扫描模式优化：中断与轮询的平衡之道

1. 从“卡死”到“灵动”：为什么我们需要优化矩阵键盘扫描？

大家好，我是老张，在嵌入式这行摸爬滚打十几年了，从51单片机一路玩到现在的STM32，各种外设都折腾过。最近带几个新人做项目，又遇到了那个经典的老朋友——矩阵键盘。新人小伙吭哧吭哧写了个轮询扫描的程序，跑起来一看，好家伙，CPU利用率直接飙高，其他任务跟幻灯片似的。他一脸懵地问我：“张工，这键盘扫描怎么这么‘吃’CPU啊？”

这场景是不是特别熟悉？我相信很多刚开始接触STM32矩阵键盘的朋友都踩过这个坑。轮询扫描，也就是原始文章里提到的“循环扫描”，思路确实直白：我不断地、一遍遍地检查每一行每一列，看看有没有按键被按下。这就好比一个尽职尽责的保安，每隔一秒就拿着手电筒把整个停车场（键盘矩阵）的每个车位（按键）都照一遍。好处是，只要保安够勤快（扫描频率够高），任何车辆进出（按键按下）他都能立刻发现，响应速度看起来很快。

但坏处也显而易见：这个保安除了巡逻，啥也干不了。对应到我们的STM32上，CPU的绝大部分时间都陷在那个while循环里，执行着GPIO_ReadInputDataBit这类读取引脚状态的操作。如果你的系统只是显示个按键值，那没问题。可一旦系统复杂起来，需要同时处理屏幕刷新、传感器数据采集、网络通信等任务时，这个“保安”就成了瓶颈，整个系统的实时性和流畅度都会大打折扣。

所以，单纯用轮询，在简单的教学Demo里没问题，但一上实际项目，往往就得“优化”。优化的核心目标就两个：降低CPU的无谓消耗和保证按键响应的实时性。这就引出了我们今天的主题：在中断和轮询之间，找到那个最适合你项目的平衡点。别把它想得太玄乎，说白了，就是让CPU既能及时知道键盘的“呼叫”，又不用一直傻等着。

2. 深入原理：轮询与中断到底差在哪？

要找到平衡点，我们得先摸清这两位“候选人”的底细。咱们抛开枯燥的理论，用更生活的例子来理解。

2.1 轮询扫描：那个勤快但“一根筋”的保安

轮询，就像我上面说的，是主动查询。它的代码结构通常长这样：

while(1) {
    key_value = MatrixKey_Scan(); // 扫描函数
    if(key_value != 0) {
        // 处理按键
        printf("Key Pressed: %d\n", key_value);
    }
    // 这里可能还想做点别的，但扫描函数耗时长了，别的任务就卡
    // Other_Tasks();
}

MatrixKey_Scan()这个函数内部，就是原始文章里描述的双循环行列扫描过程。它的优点非常直接：

• 实现简单：逻辑直观，几行代码就能跑起来，对新手极其友好。
• 扫描周期稳定：只要我的循环时间固定，按键检测的周期就是固定的，理论上没有随机延迟。

但它的缺点在项目实践中往往是致命的：

• CPU占用率高：这是最大的问题。即便没有按键，CPU也在不停地执行扫描代码，做无用功。我用示波器抓过GPIO波形，在扫描瞬间会有密集的脉冲，CPU根本闲不下来。
• 响应时间受扫描周期限制：假设你整个扫描函数执行一遍要2ms，那么在最坏情况下，按键刚好在一次扫描结束后被按下，它需要等将近2ms才能被检测到。对于人机交互来说，2ms或许感觉不出，但对于某些需要快速响应的控制场合，这可能就是瓶颈。
• 阻塞式运行：它严重破坏了程序的并发性。你想在while(1)里同时做其他事？除非你把扫描函数拆得非常碎，或者引入实时操作系统（RTOS）来调度，否则很难。

2.2 中断扫描：那个“按铃呼叫”的智能管家

中断的思路就完全不同了。它不再是让CPU主动去查，而是给键盘一个“呼叫铃”。当有按键按下时，这个“铃”（中断信号）会直接打断CPU当前的工作，CPU马上来处理按键事件。

通常的做法是，将矩阵键盘的所有行线（或者所有列线）通过一个与门逻辑芯片连接到一个外部中断引脚（如EXTI）上。平时所有行线被上拉为高电平，一旦有任何按键按下，对应的行线就会被列线拉低，从而触发下降沿或低电平中断。

// 中断服务函数中的处理
void EXTI0_IRQHandler(void) {
    if(EXTI_GetITStatus(EXTI_Line0) != RESET) {
        // 1. 清除中断标志
        EXTI_