1. 协议栈适配概述

协议栈适配，说白了就是让一套网络协议代码能在不同的硬件、操作系统或编译器环境下跑起来。听起来简单？我刚开始做这行时也这么想，结果第一个项目就栽了大跟头——代码在开发板上跑得欢，换到产品平台就各种崩溃。从那以后，我才真正重视起适配这件事。

什么是协议栈适配

协议栈适配，就是把原本为特定环境编写的网络协议栈（比如 TCP/IP、BLE、ZigBee 协议栈），通过一层中间代码，移植到目标平台上。这层中间代码就是适配层。

举个例子：你有一套在 Linux 上跑得很好的 LwIP 协议栈，现在要把它放到一个裸机 RTOS 上。Linux 有 pthread、socket API、内存管理，裸机啥都没有。怎么办？写适配层。

适配层的作用与边界

适配层到底该做什么，不该做什么？我见过不少团队把适配层写成了"垃圾堆"——什么代码都往里塞。结果适配层比协议栈本身还复杂，维护起来想哭。

适配层的职责很清晰：

• 操作系统抽象：任务创建、信号量、互斥锁、消息队列、定时器
• 内存管理抽象：malloc/free 的封装，或者提供静态内存池接口
• 硬件接口抽象：SPI、UART、I2C 等底层驱动的统一接口
• 时间相关抽象：获取系统 tick、毫秒级延时、微秒级延时
• 中断处理抽象：中断注册、使能/禁止、中断上下文判断

那适配层不该做什么？

• 不该修改协议栈的核心算法（比如 TCP 的拥塞控制）
• 不该包含业务逻辑（比如应用层的数据处理）
• 不该引入平台相关的头文件污染协议栈代码

常见适配场景

1. OS 移植

这是最常见的场景。协议栈原本依赖某个 RTOS 的 API，现在要换到另一个 RTOS 上。比如从 FreeRTOS 移植到 RT-Thread。

需要适配的内容：

功能	FreeRTOS 接口	RT-Thread 接口
创建任务	xTaskCreate	rt_thread_create
信号量	xSemaphoreCreateBinary	rt_sem_create
互斥锁	xSemaphoreCreateMutex	rt_mutex_create
消息队列	xQueueCreate	rt_mq_create
获取 tick	xTaskGetTickCount	rt_tick_get

适配层就是把这些接口封装成统一的宏或函数。我个人习惯用一组 osal_xxx 前缀的函数，比如 osal_task_create、osal_sem_create。这样协议栈代码里只调用 osal_xxx，换平台时只改适配层。

2. 硬件抽象

协议栈需要和硬件打交道，比如以太网 MAC/PHY、SPI Flash、UART 等。不同芯片的寄存器、中断、DMA 都不一样。

举个例子：以太网驱动适配。

// 适配层接口定义
typedef struct {
    int (*init)(void);
    int (*send)(uint8_t *data, uint32_t len);
    int (*recv)(uint8_t *data, uint32_t *len);
    void (*enable_interrupt)(void);
    void (*disable_interrupt)(void);
} eth_driver_t;

// STM32 实现
static int stm32_eth_init(void) {
    // 初始化 STM32 的 MAC 和 DMA
    HAL_ETH_Init(&heth);
    return 0;
}

// WCH 实现
static int wch_eth_init(void) {
    // 初始化 WCH 芯片的以太网模块
    ETH_Init();
    return 0;
}

// 适配层选择
const eth_driver_t *eth_get_driver(void) {
    #ifdef CHIP_STM32
        return &stm32_eth_driver;
    #elif defined(CHIP_WCH)
        return &wch_eth_driver;
    #endif
}

这种设计，协议栈只调用 eth_driver->init()，根本不关心底层是什么芯片。我在一个项目里用这种方式同时支持了 5 款不同厂家的 MCU，适配层代码只占整个工程的 3%。

3. 多平台支持

这个场景更宽泛。同一个协议栈要同时支持 Windows、Linux、macOS，或者同时支持 ARM、RISC-V、MIPS 架构。

多平台适配的常见问题：

• 字节序：大端 vs 小端。网络字节序是大端，但很多 MCU 是小端。适配层要提供 htons、htonl 等宏。
• 对齐访问：有些平台不允许非对齐访问（比如 ARM Cortex-M0），协议栈里如果直接操作指针可能会触发 HardFault。
• 编译器差异：GCC、IAR、Keil、ARMCC 的语法和内置函数不同。比如 __attribute__((packed)) 在 IAR 里是 __packed。
• 数据类型：int 的长度在不同平台可能是 16 位或 32 位。建议统一使用 uint8_t、uint16_t、uint32_t。

适配层的知识体系

下面这张图展示了适配层在整个协议栈中的位置和核心模块：

适配层设计的几个原则

做了这么多年适配，我总结了几条铁律：

1. 接口要薄：适配层接口越少越好，每个接口只做一件事。别搞出那种一个函数传 10 个参数的怪物。
2. 不改协议栈核心：协议栈的算法、状态机、数据流，一个字都不要动。动了就是给自己挖坑。
3. 测试先行：每适配一个接口，立刻写测试用例验证。我曾经因为一个 memcpy 的对齐问题排查了三天，后来发现是适配层里一个宏定义写错了。
4. 文档要跟上：适配层的接口说明、平台差异、已知问题，都要写清楚。别指望半年后你还能记得当时为什么那么写。

小结

协议栈适配不是高深的技术，但很考验工程经验。把适配层的职责边界划清楚，接口设计得简洁明了，就能避免很多后期维护的麻烦。嗯，这一章先聊到这儿，后面的章节我们会深入每个适配场景的具体陷阱和应对策略。