1. 事件驱动架构概述：从轮询到中断的思维转变

各位同学，咱们今天聊一个嵌入式开发里绕不开的话题——事件驱动架构。说实话，我早年刚入行时，写的代码全是轮询那一套。主循环里塞一堆 if 判断，挨个查标志位。那时候觉得，嗯，代码挺直观的，跑得也挺稳。直到有一次，一个多传感器数据采集的项目把我整崩溃了——CPU 忙得团团转，可按键响应就是慢半拍。从那以后，我才真正开始琢磨事件驱动这回事。

1.1 轮询的困境：CPU 在忙什么？

先看一段典型的轮询代码，你肯定见过：

while (1) {
    if (button_pressed())   handle_button();
    if (uart_data_ready())  handle_uart();
    if (adc_conversion_done()) handle_adc();
    // ... 还有十几个 if
    delay_ms(1);  // 怕跑太快？
}

这段代码有什么问题？我帮你数数：

• CPU 利用率极低——大部分时间在空转或延时，真正干活的时间不到 10%
• 响应延迟不可控——如果 ADC 处理函数执行了 50ms，按键就得等 50ms 才能被响应
• 扩展性差——每加一个新外设，主循环就多一个 if，代码越来越臃肿
• 功耗高——CPU 一直在跑，没法进入低功耗模式

1.2 中断：让 CPU 学会「按需响应」

中断的出现，说白了就是让 CPU 从「主动查」变成「被动等通知」。你想想看，这就像你坐在办公室里，与其每隔 5 分钟去门口看看有没有快递，不如让快递员到了给你打个电话——效率完全不一样。

中断的核心机制：

1. 事件发生——外设检测到特定条件（电平变化、定时器溢出、数据到达）
2. 硬件触发——外设向 CPU 发送中断请求信号
3. 上下文保存——CPU 暂停当前任务，保存现场（寄存器、PC 指针等）
4. 中断服务——跳转到 ISR（Interrupt Service Routine）执行处理
5. 恢复现场——ISR 执行完毕，CPU 恢复之前的工作

1.3 事件驱动模型的核心概念

事件驱动架构，就是把中断的思想上升到软件架构层面。它不再依赖硬件中断线，而是用一套软件机制来管理「事件的生产、分发、消费」。

我习惯把事件驱动模型拆成三个角色：

这三者的协作流程，我画了张图：

1.4 嵌入式系统中的落地价值

你可能会问：这套东西在资源受限的 MCU 上跑得动吗？我的回答是：不仅跑得动，而且特别适合。原因有三：

• 资源开销可控——事件队列可以用数组实现，不需要动态内存分配。一个 32 位的 Cortex-M0 内核，几百字节的 RAM 就能跑起来
• 实时性有保障——高优先级事件可以插队处理，低优先级事件排队等待。我做过测试，在 72MHz 的 STM32F103 上，事件从产生到处理完成的延迟可以控制在 10μs 以内
• 功耗优化利器——没有事件时，CPU 进入休眠模式。事件来了，通过中断唤醒。一个电池供电的传感器节点，用事件驱动架构能把平均功耗降到轮询方案的 1/10

1.5 从轮询到中断：思维转变的关键

最后我想聊聊思维层面的转变。很多从轮询转过来的工程师，初期会很不适应。为什么？因为轮询是「主动控制」——你清楚地知道 CPU 每一刻在干什么。而事件驱动是「被动响应」——你只定义事件来了该做什么，至于什么时候来、来几个，你控制不了。

这种「失控感」会让人焦虑。我当年也一样，总担心事件队列会不会溢出，高优先级事件会不会饿死低优先级任务。但后来我发现，只要做好这几件事，系统其实很稳定：

1. 合理规划队列深度——根据最坏情况下的事件产生速率计算队列大小，留 20% 余量
2. ISR 里只做最轻量的操作——置标志位、放队列，别在里面做复杂计算
3. 明确优先级策略——哪些事件必须立即响应，哪些可以排队等