📚 课程目录第3章异步编程模型

3. 异步编程模型：回调函数机制、事件驱动编程、异步任务设计模式、定时器与软件中断

说实话，很多做嵌入式开发的朋友，刚开始接触 ESP32 时最头疼的就是「异步」。大家习惯了单片机那种「顺序执行、死循环轮询」的思维，突然要面对回调、事件、任务调度，确实容易懵。我当年第一次用 FreeRTOS 时也踩过不少坑，尤其是回调函数里做延时阻塞，直接把系统干死机了。

这一章，咱们就把异步编程的四个核心概念掰开揉碎。你理解透了，后面写 SPIFFS 的驱动、搞网络通信，都会顺手很多。

3.1 回调函数机制：把「做什么」交给别人决定

回调函数，说白了就是「你告诉我怎么做，到时候我喊你」。你写一个函数，然后把它的指针注册到某个服务里。当特定事件发生时，服务自动调用你这个函数。

在 ESP-IDF 里，回调无处不在。比如 GPIO 中断、定时器到期、Wi-Fi 连接成功，都是用回调来通知用户代码的。

核心要点：回调函数是异步编程的「握手协议」。注册回调的一方（库）只负责触发，不关心回调里做了什么。但你要注意——回调函数运行在调用者的上下文里，不能做阻塞操作。

看个最简单的例子，GPIO 中断回调：

// 定义回调函数
static void gpio_isr_handler(void* arg) {
    int gpio_num = (int)arg;
    // 注意：这里不能调用 printf 等阻塞函数！
    // 通常只做标记，或者通过队列发送消息
    xQueueSendFromISR(gpio_evt_queue, &gpio_num, NULL);
}

// 注册回调
gpio_isr_handler_add(GPIO_INPUT_IO, gpio_isr_handler, (void*)GPIO_INPUT_IO);

我在项目中遇到过一个问题：有人在回调里调用了 vTaskDelay()，结果整个中断服务被卡住，系统直接崩溃。记住，回调函数里不要做延时、不要申请大内存、不要调用可能阻塞的 API。你只管「记下来」，然后交给任务去处理。

避坑指南：我曾经在回调里直接操作 SPIFFS 文件写入，结果文件系统频繁崩溃。后来才意识到，文件系统操作需要任务上下文，不能在 ISR 里做。正确的做法是用队列把数据传给一个专门的任务去写。

3.2 事件驱动编程：系统不再「傻等」

事件驱动，是异步编程的灵魂。传统轮询方式下，CPU 一直在问「你好了没？你好了没？」，浪费大量算力。事件驱动则是「你好了通知我，我先去干别的」。

ESP-IDF 里的事件驱动，最典型的就是 esp_event 库。它提供了一个事件循环（event loop），你可以注册感兴趣的事件类型，当事件发生时，对应的处理函数会被自动调用。

概念	说明	类比
事件循环	一个持续运行的消息泵，负责接收和分发事件	邮局的分拣中心
事件源	产生事件的模块（Wi-Fi、定时器、传感器等）	寄信人
事件处理函数	你注册的回调，事件发生时被调用	收信人
事件数据	伴随事件传递的参数	信件内容

举个例子，Wi-Fi 连接成功的事件处理：

static void wifi_event_handler(void* arg, esp_event_base_t event_base,
                                int32_t event_id, void* event_data) {
    if (event_base == WIFI_EVENT && event_id == WIFI_EVENT_STA_START) {
        esp_wifi_connect();
    } else if (event_base == IP_EVENT && event_id == IP_EVENT_STA_GOT_IP) {
        ip_event_got_ip_t* event = (ip_event_got_ip_t*) event_data;
        ESP_LOGI(TAG, "Got IP: " IPSTR, IP2STR(&event->ip_info.ip));
        // 连接成功，可以开始干活了
    }
}

// 注册事件处理
esp_event_handler_register(WIFI_EVENT, ESP_EVENT_ANY_ID, &wifi_event_handler, NULL);
esp_event_handler_register(IP_EVENT, IP_EVENT_STA_GOT_IP, &wifi_event_handler, NULL);

你想想看，如果没有事件驱动，你得在主循环里不断检查 Wi-Fi 状态，多累啊。事件驱动让代码结构清晰多了——每个事件对应一个处理函数，各管各的，互不干扰。

个人习惯：我一般会为每个功能模块创建一个独立的事件处理函数，而不是把所有事件塞到一个大函数里。这样后期维护时，改 Wi-Fi 逻辑不会影响到传感器逻辑。

3.3 异步任务设计模式：让多件事「同时」发生

ESP32 是双核芯片，跑着 FreeRTOS 实时操作系统。异步任务，就是 FreeRTOS 里的线程（task）。每个任务有自己的栈空间和优先级，看起来像是「同时」在运行。

异步任务设计模式，核心就三个字：分、隔、通。

分：把不同功能拆成独立任务。比如一个任务读传感器，一个任务处理数据，一个任务负责网络通信。
隔：任务之间通过队列、信号量、事件组等机制通信，不共享全局变量（除非你加锁）。
通：用 FreeRTOS 的 IPC（进程间通信）机制传递数据，保证线程安全。

看一个典型的多任务结构：

// 传感器读取任务
void sensor_task(void *pvParameters) {
    while (1) {
        int data = read_sensor();
        xQueueSend(sensor_queue, &data, portMAX_DELAY);
        vTaskDelay(pdMS_TO_TICKS(100)); // 100ms 读一次
    }
}

// 数据处理任务
void process_task(void *pvParameters) {
    int data;
    while (1) {
        if (xQueueReceive(sensor_queue, &data, portMAX_DELAY)) {
            int processed = data * 2; // 简单处理
            xQueueSend(net_queue, &processed, portMAX_DELAY);
        }
    }
}

// 网络发送任务
void network_task(void *pvParameters) {
    int data;
    while (1) {
        if (xQueueReceive(net_queue, &data, portMAX_DELAY)) {
            send_to_server(data);
        }
    }
}

void app_main() {
    sensor_queue = xQueueCreate(10, sizeof(int));
    net_queue = xQueueCreate(10, sizeof(int));

    xTaskCreate(sensor_task, "sensor", 2048, NULL, 5, NULL);
    xTaskCreate(process_task, "process", 2048, NULL, 4, NULL);
    xTaskCreate(network_task, "network", 4096, NULL, 3, NULL);
}

这个模式我用了很多年。每个任务只做一件事，通过队列传递数据。调试时只要看队列里有没有数据，就知道哪个环节出了问题。

注意：任务栈大小要合理。我见过有人给网络任务只分配 1024 字节，结果一调用 SSL 库就栈溢出。网络任务建议至少 4096 字节，如果用到 JSON 解析或加密，可能要 8192。

3.4 定时器与软件中断：精确的时间控制

定时器和软件中断，是异步编程里「主动触发」的重要手段。硬件定时器由芯片外设实现，精度高；软件定时器由 FreeRTOS 管理，使用方便但精度稍低。

ESP-IDF 提供了两种定时器：

类型	精度	使用场景	注意事项
硬件定时器 (timer_group)	微秒级	PWM 生成、精确延时、脉冲计数	资源有限，只有 4 个
软件定时器 (esp_timer)	毫秒级	周期性任务、超时检测、心跳包	回调在任务上下文执行，可调用阻塞 API

我个人习惯用 esp_timer 做大部分定时任务。它基于 FreeRTOS 的定时器服务，使用起来很简单：

// 定义定时器回调
static void periodic_timer_callback(void* arg) {
    ESP_LOGI(TAG, "定时器触发，当前堆栈剩余: %d", uxTaskGetStackHighWaterMark(NULL));
    // 这里可以做非阻塞操作
    // 比如检查传感器状态、发送心跳包
}

void setup_timer() {
    const esp_timer_create_args_t timer_args = {
        .callback = &periodic_timer_callback,
        .name = "periodic"
    };

    esp_timer_handle_t timer;
    ESP_ERROR_CHECK(esp_timer_create(&timer_args, &timer));
    ESP_ERROR_CHECK(esp_timer_start_periodic(timer, 1000000)); // 1秒周期
}

软件中断呢？其实就是通过 gpio_isr_handler 或者 esp_event_isr_post 在中断上下文里发送事件。我常用的一种模式是：硬件中断触发 → 在 ISR 里发事件到事件循环 → 事件处理函数在任务上下文执行耗时操作。

经验之谈：我曾经做一个低功耗项目，需要每 10 秒唤醒一次采集数据。用硬件定时器唤醒，然后在 ISR 里发事件给主任务。主任务处理完数据后，再次进入休眠。这样既保证了定时精度，又最大化了休眠时间。

知识体系总览

下面这张图，把本章的四个核心概念串起来了。你可以看到，回调是基础，事件驱动是骨架，异步任务是血肉，定时器和中断是「心跳」。

嗯，到这里，异步编程的四个核心概念就讲完了。回调是基础，事件驱动是架构思路，异步任务是实现手段，定时器和中断是时间控制工具。把这四个东西用好，你的 ESP32 代码会变得非常优雅——不轮询、不阻塞、不浪费 CPU。