3. 协议栈适配基础

事件驱动架构的核心，说白了就两个东西：队列和调度器。队列管的是“事件怎么存”，调度器管的是“事件怎么取出来执行”。这两块要是没设计好，整个系统就像堵车的早高峰——事件堆积、优先级反转、实时性崩溃，我见过太多项目栽在这上面。

这一章，咱们就把队列和调度器拆开揉碎了讲。我会结合自己踩过的坑，把环形缓冲区、优先级队列、协作式调度和抢占式调度的实现细节全盘托出。

3.1 事件队列的核心设计

事件队列是事件驱动架构的“血管”。所有事件都要经过它流转。设计队列时，我们最关心三个指标：入队延迟、出队延迟和内存效率。

3.1.1 环形缓冲区（Ring Buffer）

我个人习惯，在资源受限的MCU上首选环形缓冲区。为什么？因为它没有动态内存分配，没有链表节点开销，只需要一块连续内存和两个指针。

typedef struct {
    uint8_t *buffer;      // 缓冲区基地址
    uint32_t head;        // 写指针（生产者）
    uint32_t tail;        // 读指针（消费者）
    uint32_t capacity;    // 缓冲区容量（必须是2的幂）
    uint32_t mask;        // 掩码 = capacity - 1
} ring_buffer_t;

这里有个关键设计点：容量必须是2的幂。这样可以用位运算代替取模运算，速度能快一个数量级。我在一个电机控制项目里测试过，用 head & mask 代替 head % capacity，每次入队操作节省了大约 12 个 CPU 周期——对于 1kHz 的控制环路，这可不是小数目。

// 入队（生产者）
bool ring_buffer_push(ring_buffer_t *rb, uint8_t data) {
    uint32_t next = (rb->head + 1) & rb->mask;
    if (next == rb->tail) return false;  // 缓冲区满
    rb->buffer[rb->head] = data;
    rb->head = next;
    return true;
}

// 出队（消费者）
bool ring_buffer_pop(ring_buffer_t *rb, uint8_t *data) {
    if (rb->head == rb->tail) return false;  // 缓冲区空
    *data = rb->buffer[rb->tail];
    rb->tail = (rb->tail + 1) & rb->mask;
    return true;
}

我曾经在一个项目中，因为没处理好“满”和“空”的判断条件，导致缓冲区溢出后数据错乱，排查了整整两天。后来我养成了一个习惯：环形缓冲区永远留一个空位，用 (head + 1) % capacity == tail 判满，用 head == tail 判空。这样虽然浪费了一个存储单元，但逻辑清晰，不会出现歧义。

3.1.2 优先级队列

当系统需要处理不同紧急程度的事件时，环形缓冲区就不够用了。比如一个网络协议栈，收到 ACK 包和收到重传定时器超时，显然超时的优先级更高。这时候就需要优先级队列。

嵌入式环境下的优先级队列，我推荐两种实现方式：

多级环形缓冲区是我在工业控制项目中用得最多的方案。说白了就是给每个优先级分配一个独立的环形缓冲区。调度时从高优先级队列开始轮询，有事件就取。

typedef struct {
    ring_buffer_t queues[PRIORITY_LEVELS];
} multi_queue_t;

bool multi_queue_pop(multi_queue_t *mq, event_t *evt) {
    for (int i = 0; i < PRIORITY_LEVELS; i++) {
        if (ring_buffer_pop(&mq->queues[i], evt)) {
            return true;  // 从最高优先级队列取出事件
        }
    }
    return false;  // 所有队列都空
}

嗯，这里要注意：优先级反转。如果低优先级事件一直占着某个共享资源，高优先级事件等着这个资源，那就麻烦了。我曾经在一个多传感器融合项目里遇到过，一个低优先级的温度传感器事件锁住了 I2C 总线，导致高优先级的激光雷达数据一直取不到，系统直接判定“障碍物丢失”触发了急停。后来我加了一个超时抢占机制：高优先级事件等待资源超过一定时间，强制挂起低优先级事件。

3.2 调度策略：协作式 vs 抢占式

队列设计好了，谁来消费这些事件？这就是调度器的工作。嵌入式事件调度主要有两种流派：协作式和抢占式。

3.2.1 协作式调度

协作式调度，说白了就是“自觉”。每个事件处理函数必须主动让出 CPU，调度器才能处理下一个事件。它的核心是一个 while(1) 循环，不断从队列取事件并执行。

void cooperative_scheduler(void) {
    while (1) {
        event_t evt;
        if (event_queue_pop(&evt)) {
            evt.handler(evt.data);  // 同步执行事件处理函数
        }
        // 没有事件时，可以进入低功耗模式
        else {
            enter_sleep_mode();
        }
    }
}

协作式的优点很明显：没有任务切换开销，没有竞态条件，代码简单到极致。我最早做的一个智能家居网关，就是用协作式调度跑起来的，整个事件循环只有 30 行代码。

但协作式有个致命弱点：一个事件处理函数如果卡住了，整个系统就挂了。我记得有一次，一个同事写的网络重连函数里加了个 while(1) 等待，结果设备一断网就死机，用户投诉说“按开关没反应”。排查到最后，发现就是协作式调度下，事件处理函数阻塞了所有后续事件。

3.2.2 抢占式调度

抢占式调度，就是“强制”。高优先级事件可以打断低优先级事件的处理。这通常需要 RTOS 支持，每个事件处理函数运行在一个独立的任务（Task）中，由内核的调度器决定谁运行。

抢占式的核心是优先级抢占 + 时间片轮转。高优先级任务就绪时，低优先级任务立即被挂起，CPU 转去执行高优先级任务。

// 创建事件处理任务
xTaskCreate(network_event_task, "NET", 512, NULL, 3, NULL);  // 优先级3
xTaskCreate(sensor_event_task, "SEN", 256, NULL, 2, NULL);   // 优先级2
xTaskCreate(ui_event_task,     "UI",  384, NULL, 1, NULL);   // 优先级1

// 事件处理任务示例
void network_event_task(void *pvParameters) {
    event_t evt;
    while (1) {
        if (xQueueReceive(net_queue, &evt, portMAX_DELAY)) {
            evt.handler(evt.data);  // 高优先级任务可以抢占低优先级
        }
    }
}

抢占式的优势是实时性强、响应快。但代价也不小：任务切换有上下文开销，需要处理互斥锁、信号量等同步机制，调试起来也更复杂。

我个人经验是：能用协作式就别用抢占式。只有在以下场景才考虑抢占：

• 有硬实时要求的事件（如电机控制 PWM 更新，必须在 100μs 内响应）
• 事件处理函数执行时间不确定（如文件系统读写、网络请求）
• 系统需要同时处理多个独立的事件流

3.3 混合调度策略：我推荐的做法

在实际项目中，我很少只用纯协作式或纯抢占式。更常见的做法是混合调度：

1. 高优先级事件（中断级）：直接在 ISR 中处理，或者通过中断触发一个高优先级任务
2. 中优先级事件（实时任务级）：使用抢占式调度，由 RTOS 管理
3. 低优先级事件（后台任务级）：使用协作式调度，放在 idle 任务或低优先级任务中轮询

这种分层设计，既保证了实时性，又避免了过度使用 RTOS 带来的复杂性。我在一个无人机飞控项目里就是这么做的：姿态控制事件走中断级，导航事件走 RTOS 抢占式任务，日志记录事件走协作式轮询。整个系统跑了两年，没出过调度相关的问题。

3.4 本章知识体系

下面这张图总结了事件队列与调度器的核心设计思路，你可以把它当作一个快速参考框架：