第四章 中间件层：协议栈封装与数据缓存管理

中间件层，说白了就是连接硬件驱动和业务逻辑的那座桥。我做了这么多年嵌入式，发现很多项目出问题都出在这一层——要么协议栈写得死板，换个芯片就得重写；要么数据缓存设计不合理，跑着跑着就丢包了。

这一章，咱们就聊聊怎么把Modbus、CAN这类协议栈封装好，再配合上靠谱的数据缓存和队列管理。嗯，这些都是实战中绕不开的硬骨头。

4.1 协议栈封装的核心思想

协议栈封装，不是简单地把函数堆在一起。我个人的习惯是：把协议的处理逻辑和硬件接口彻底分开。你想想看，Modbus RTU走串口和走TCP，底层收发完全不一样，但协议解析的帧结构、校验算法是一样的。

4.1.1 分层封装模型

我一般把协议栈分成三层：

层级	职责	典型接口
应用接口层	提供业务调用的API，如读寄存器、写线圈	modbus_read_holding_registers()
协议核心层	帧封装/解析、校验、状态机管理	modbus_build_request()
物理适配层	抽象底层收发，通过函数指针注入	send_bytes()、recv_bytes()

这样做的好处很明显——换硬件时，只需要重写物理适配层那几十行代码。我曾经在一个项目里，把Modbus从串口迁移到以太网，只改了一个文件，测试都没怎么翻车。

4.1.2 接口隔离实战：Modbus RTU封装

来看一个具体的例子。这是物理适配层的接口定义：

/* 物理层适配接口 */
typedef struct {
    int32_t (*init)(void *config);
    int32_t (*send)(uint8_t *data, uint16_t len);
    int32_t (*recv)(uint8_t *buf, uint16_t max_len, uint32_t timeout_ms);
    void     (*deinit)(void);
} modbus_phy_t;

/* 协议核心层使用该接口，不直接调用HAL */
int32_t modbus_master_send_request(modbus_phy_t *phy, 
                                   uint8_t slave_addr, 
                                   uint8_t func_code, 
                                   uint16_t reg_addr, 
                                   uint16_t reg_count);

4.2 CAN协议栈封装要点

CAN协议比Modbus复杂一些，主要是帧类型多、ID过滤、DLC处理这些细节。我建议把CAN的封装重点放在消息路由和ID管理上。

4.2.1 CAN消息统一结构体

先定义一个通用的CAN消息结构，所有上层模块都用它：

typedef struct {
    uint32_t id;           /* 标准帧11位，扩展帧29位 */
    uint8_t  dlc;          /* 数据长度 0-8 */
    uint8_t  data[8];      /* 数据域 */
    uint8_t  is_extended;  /* 0:标准帧, 1:扩展帧 */
    uint8_t  is_remote;    /* 0:数据帧, 1:远程帧 */
} can_message_t;

嗯，这里要注意：很多新手会把ID和优先级混在一起处理。我个人习惯把ID过滤逻辑单独抽出来，做成一个可配置的过滤器模块。

4.2.2 过滤器配置抽象

不同MCU的CAN过滤器配置方式差异很大。我建议用一张配置表来抽象：

typedef struct {
    uint32_t filter_id;
    uint32_t mask_id;
    uint8_t  bank;
    void (*rx_callback)(can_message_t *msg);
} can_filter_entry_t;

/* 应用层只需注册回调，不关心硬件寄存器 */
can_filter_register(&filter_table[0]);

4.3 数据缓存与队列管理

协议栈封装好了，数据怎么在模块之间高效传递？这就轮到缓存和队列上场了。我见过太多项目因为缓存设计不合理，导致数据覆盖、死锁、内存碎片。

4.3.1 环形缓冲区（Ring Buffer）

环形缓冲区是嵌入式里最常用的数据结构之一。它适合单生产者-单消费者场景，比如串口中断收数据，主循环取数据。

typedef struct {
    uint8_t *buffer;
    uint16_t head;
    uint16_t tail;
    uint16_t size;
    uint32_t overflow_count;  /* 溢出统计，调试用 */
} ring_buffer_t;

int32_t ring_buffer_push(ring_buffer_t *rb, uint8_t data) {
    uint16_t next = (rb->head + 1) % rb->size;
    if (next == rb->tail) {
        rb->overflow_count++;
        return -1;  /* 缓冲区满 */
    }
    rb->buffer[rb->head] = data;
    rb->head = next;
    return 0;
}

int32_t ring_buffer_pop(ring_buffer_t *rb, uint8_t *data) {
    if (rb->tail == rb->head) {
        return -1;  /* 缓冲区空 */
    }
    *data = rb->buffer[rb->tail];
    rb->tail = (rb->tail + 1) % rb->size;
    return 0;
}

4.3.2 消息队列（Message Queue）

当数据需要在多个任务或模块之间传递时，环形缓冲区就不够用了。这时候需要消息队列——它支持多生产者、多消费者，还能携带消息类型。

我一般这样设计消息队列：

typedef struct {
    uint32_t msg_id;      /* 消息类型标识 */
    uint8_t  *data;       /* 指向实际数据 */
    uint16_t data_len;    /* 数据长度 */
    uint32_t timestamp;   /* 时间戳，用于超时判断 */
} message_t;

typedef struct {
    message_t *pool;      /* 消息池，预分配 */
    uint16_t   pool_size;
    uint16_t   head;
    uint16_t   tail;
    uint16_t   count;
    /* 可选：信号量用于任务同步 */
    void      *semaphore;
} message_queue_t;

4.3.3 缓存策略对比

缓存类型	适用场景	优点	缺点
环形缓冲区	串口/SPI数据流	实现简单，无动态内存	不支持多消费者
消息队列	任务间通信	支持多对多，带类型	需要预分配内存池
双缓冲	DMA传输、显示刷新	零拷贝切换	内存占用翻倍
链表缓存	变长数据包	灵活，无浪费	可能产生碎片

4.4 中间件层整体架构

把协议栈封装和缓存管理组合起来，就形成了中间件层的完整骨架。下面这张图展示了各模块之间的关系：

4.5 实战中的避坑经验

最后，分享几个我在项目中踩过的坑：

• 缓冲区大小拍脑袋定：我曾经在一个CAN网关项目里，把接收队列设成16，结果高负载时疯狂丢包。后来改成根据总线负载率和最大帧间隔计算，才稳定下来。
• 中断里操作队列不加保护：环形缓冲区在单生产者-单消费者场景下可以不加锁，但一旦涉及多任务，必须用关中断或信号量保护。我见过一个同事在中断里push，任务里pop，没加保护，跑了两天死机。
• 协议栈状态机不完整：Modbus的异常响应、超时重试这些边界情况，很多人只写了正常流程。建议用状态图把每个分支都画出来，再写代码。