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

各位做嵌入式开发的同行，咱们开门见山。今天聊的这件事，几乎决定了你做的产品能不能省电、能不能实时响应。说白了，就是任务调度这件事，你到底是用轮询还是用事件驱动？

我刚开始做嵌入式那几年，一直用轮询。觉得简单、直观、好控制。直到有一次做一款电池供电的传感器节点，满电只能用 6 小时……嗯，从那以后，我彻底转向了事件驱动。今天就把这个转变过程掰开揉碎讲清楚。

1.1 轮询模式：为什么它不适合低功耗系统

先看一段典型的轮询代码：

void main(void) {
    while(1) {
        if (button_pressed())   handle_button();
        if (sensor_ready())     read_sensor();
        if (uart_has_data())    process_uart();
        /* 还有十几个 if... */
        delay_ms(10);  /* 怕跑太快？加个延时 */
    }
}

这段代码有什么问题？我列几个关键点：

• CPU 一直在跑 —— 哪怕没有任何事件发生，CPU 也在循环检查。电流降不下来。
• 响应延迟不确定 —— 如果轮询周期是 10ms，按键按下后最多要等 10ms 才能响应。有些场景根本不能忍。
• 扩展性差 —— 加一个新任务就要加一个 if，轮询列表越来越长，延迟越来越不可控。

1.2 中断思维：让 CPU 只在需要时工作

中断的思路其实很朴素：没事就睡觉，有事再干活。CPU 平时进入低功耗模式，当外部事件（按键、定时器、数据到达）发生时，中断把它唤醒，处理完再睡回去。

看一个简单的中断驱动模型：

void main(void) {
    init_peripherals();
    enable_interrupts();
    while(1) {
        __WFI();  /* 等待中断，进入睡眠 */
        /* 醒来后，中断服务程序已经处理了事件 */
    }
}

void EXTI0_IRQHandler(void) {
    /* 按键中断 —— 只做最必要的事 */
    set_event_flag(EVENT_BUTTON);
    /* 或者直接丢给调度器 */
}

这个模型的好处很明显：

• CPU 空闲时几乎不耗电（μA 级 vs mA 级）
• 响应延迟从「轮询周期」变成「中断延迟」，通常是微秒级
• 任务之间天然解耦，加新功能不影响已有逻辑

1.3 事件驱动模型的核心三要素

事件驱动架构听起来高大上，其实核心就三个东西：事件、调度器、任务。我画了一张图，你看完就明白了。

三个要素各自干什么，我简单说一下：

1.4 为什么低功耗系统必须用事件驱动

这个问题我直接给结论：轮询模式下，CPU 的功耗和事件频率无关，始终是满负荷。 事件驱动模式下，CPU 功耗 ≈ 事件频率 × 单次处理时间。

举个例子：

• 一个温度传感器，每 10 秒采集一次数据，每次处理耗时 1ms。
• 轮询模式：CPU 每 10ms 醒来检查一次，10 秒内醒来 1000 次，实际干活 1ms，浪费 999ms 在空转。
• 事件驱动模式：CPU 每 10 秒被定时器唤醒一次，干活 1ms，然后继续睡。功耗直接降到轮询的千分之一。

你想想看，一个纽扣电池容量大概 200mAh。4μA 平均电流能用 5 年，2mA 只能用 4 天。这就是为什么低功耗系统必须用事件驱动——不是选择题，是生存题。

1.5 从轮询到事件驱动的思维转变清单

最后，我列一个清单，帮你快速完成思维切换：