1. 事件驱动架构概述

各位同学，咱们今天聊聊嵌入式系统里一个绕不开的话题——事件驱动架构。说实话，我做了十几年嵌入式，见过太多因为架构选型不当导致项目返工的案例。今天这一讲，咱们就把事件驱动这事儿彻底说透。

什么是事件驱动架构

事件驱动架构，说白了就是：系统不主动干活，而是等事情发生了再响应。这里的「事件」可以是按键按下、串口收到一个字节、定时器溢出、传感器数据准备好——任何能引起系统状态变化的东西，都算事件。

我习惯把事件驱动系统比作一个「急诊室」：平时医生护士都在休息室待命，一旦有病人进来（事件发生），分诊台（事件分发器）根据病情严重程度（事件优先级）安排对应的医生（事件处理函数）去处理。处理完了，医生又回到休息室等下一个病人。

在代码层面，事件驱动架构通常包含三个基本要素：

• 事件源——谁产生事件？硬件外设、定时器、其他任务、用户操作
• 事件队列——事件暂存的地方，先进先出或按优先级排队
• 事件处理器——真正干活的部分，每个事件对应一个处理函数

举个最简单的例子，一个按键消抖程序：

// 事件驱动方式处理按键
void key_isr(void) {
    // 记录按键事件，不在这里做消抖
    event_post(EVENT_KEY_PRESS, get_key_value());
}

void key_event_handler(uint32_t event) {
    // 在事件处理器里做消抖和逻辑判断
    static uint32_t last_time = 0;
    uint32_t now = get_tick();
    if (now - last_time > 50) {  // 50ms消抖
        handle_key_action(get_key_value());
    }
    last_time = now;
}

你看，中断里只做一件事——把事件扔进队列。真正的处理逻辑放在事件处理器里。这样中断服务程序就能做到「快进快出」，系统也不会因为按键抖动而卡死。

为什么嵌入式系统需要事件驱动

这个问题我当年刚入行时也困惑过。那时候我做的第一个项目是智能家居网关，用的就是裸机轮询。结果呢？按键偶尔失灵，WiFi模块断连了要等好几秒才能检测到，用户投诉不断。后来改成事件驱动，问题全解决了。

嵌入式系统需要事件驱动的理由，我总结为以下四点：

痛点	轮询方式的问题	事件驱动的优势
响应实时性	CPU 忙等，高优先级事件可能被延迟	事件一来立即处理，延迟可控
CPU 利用率	空转轮询浪费大量算力	无事可做时 CPU 可以休眠省电
代码复杂度	状态机嵌套，逻辑耦合严重	事件与处理解耦，模块化清晰
扩展性	新增功能需要修改主循环	只需注册新事件和处理函数

我个人觉得，低功耗是事件驱动最被低估的价值点。物联网设备大多靠电池供电，如果 CPU 一直在轮询，功耗根本压不下来。事件驱动模式下，没事做就进休眠，有事件才唤醒——这才是嵌入式该有的样子。

事件驱动 vs 轮询 vs 中断

很多初学者会把这三者搞混。我画了一张对比图，咱们先看结构，再细说区别。

咱们一个一个说。

轮询（Polling）

轮询是最原始的方式。主循环里挨个问每个外设：「你有事吗？你呢？你呢？」。好处是代码简单，逻辑直观。坏处嘛——CPU 大部分时间都在做无用功。我记得有个项目，用轮询方式驱动 4 个 UART 和 2 个 SPI 设备，主循环跑一圈要 3 毫秒，结果 115200 波特率的串口数据经常丢字节。为什么？因为轮询周期太长，缓冲区溢出了。

中断（Interrupt）

中断解决了「CPU 空等」的问题。外设有事就主动拉中断引脚，CPU 暂停当前工作去处理。但中断有个致命缺陷——处理时间不能长。中断服务程序里如果做太多事，会导致其他中断被延迟，甚至造成系统抖动。我见过有人在 I2C 中断里做 EEPROM 页写入（一次写入要 5ms），结果系统滴答定时器中断被阻塞，系统时间直接跑偏。

事件驱动（Event-Driven）

事件驱动可以理解为「中断的升级版」。中断只做一件事——把事件登记到队列里，然后立刻退出。真正的处理逻辑在事件循环或任务里完成。这样做的好处是：

• 中断服务程序极短，不影响其他中断的响应
• 事件处理可以按优先级排队，高优先级事件先处理
• 处理函数里可以放心做耗时操作，不用担心阻塞系统
• 系统空闲时可以休眠，实现低功耗

你想想看，如果中断是「有人敲门你立刻去开」，那事件驱动就是「有人敲门你记下来，等手头事忙完了再去开」。后者显然更合理，尤其是当你有多个「门」要同时照看的时候。

什么时候选哪种模式？

没有银弹。我根据项目经验整理了一个选型参考：

场景	推荐模式	理由
LED 闪烁、数码管扫描	轮询	周期固定，实时性要求低，轮询足够
按键检测、编码器计数	中断	需要立即响应，但处理逻辑简单
UART 数据接收、网络协议栈	事件驱动	数据到达时间不确定，处理逻辑复杂
多传感器融合、复杂状态机	事件驱动	事件之间有关联，需要排队和优先级管理
低功耗物联网终端	事件驱动	需要深度休眠，事件唤醒是最佳方案

说白了，轮询适合「你知道什么时候有事」的场景，中断适合「有事必须立刻处理」的场景，事件驱动适合「事情多且杂，需要统筹管理」的场景。大部分嵌入式系统都是混合使用——中断处理紧急事件，事件驱动处理业务逻辑，轮询处理周期任务。

嗯，这一讲的内容就到这儿。事件驱动的概念其实不难，难的是在实际项目中用好它。后面的章节，我会带大家一步步搭建一个完整的事件驱动框架，从队列设计到调度器实现，再到实际项目应用。咱们下节课见。