1. 从一个真实场景说起：为什么“移植”这件事总在重复发生
做过嵌入式或者跨端开发的人，大概都有过这种体验：在A平台上跑得好好的代码，换到B平台就得推倒重来。FreeRTOS在STM32上跑得飞起，换到CH32V305就得重新配一遍中断向量；LVGL在Linux上渲染流畅，移植到裸机环境就得自己写tick和flush回调；一个Android Studio项目从一台机器搬到另一台机器，Gradle版本、SDK路径、NDK版本能让你折腾一整天。
这些场景背后其实是同一个问题：技能栈的标准化程度不够，导致跨框架移植时大量时间花在“适配层”而不是“业务层”。而路由机制，则是这个适配层里最容易被忽视、也最容易出问题的环节。
我前后做过十几次不同规模的移植工作，从RTOS到GUI库，从通信协议栈到完整项目工程，踩过的坑足够写一本小册子。这篇文章不打算讲某个具体芯片或某个具体库的移植步骤，而是想从方法论层面，把“标准化技能栈跨框架移植”这件事拆开揉碎，重点讲清楚路由机制在其中的角色，以及怎么设计一套可复用的移植策略。
如果你正在做或者准备做以下任何一件事，这篇文章应该能帮你省下不少时间：把FreeRTOS从一个MCU移植到另一个架构、把LVGL从带OS的环境搬到裸机、把某个协议栈（比如Modbus、EasyLogger）从一个工程迁移到另一个工程、把Android Studio项目在不同开发环境之间搬运、甚至把某个游戏或工具从一套系统搬到另一套系统。
核心关键词就四个：跨框架、路由机制、技能栈、移植。下面我会围绕这四个词，把整个方法论展开。
2. 标准化技能栈到底“标准化”了什么
2.1 技能栈的四个层次
很多人把“技能栈”理解成“我会用哪些工具”，这个理解太浅了。在移植场景下，技能栈应该被拆成四个层次：
- 硬件抽象层：芯片架构、外设驱动、时钟树、中断控制器。这一层决定了你的代码能不能在目标平台上“跑起来”。
- 系统服务层：RTOS、内存管理、日志系统、通信协议栈。这一层决定了你的代码能不能“稳定跑”。
- 框架接口层：GUI框架、网络框架、文件系统。这一层决定了你的代码能不能“按预期跑”。
- 业务逻辑层：真正实现功能的代码。这一层理论上不应该关心下面三层是什么。
移植工作的本质，就是保持业务逻辑层不变，替换或适配下面三层。而“标准化”的意思，就是让下面三层的接口尽可能统一，使得替换成本降到最低。
2.2 为什么路由机制是标准化的核心
路由机制这个词，在不同领域含义不同。在网络领域，它是数据包从源到目的的路径选择；在GUI框架里，它是事件从触发点到处理函数的传递路径；在RTOS里，它是中断到任务、任务到任务之间的消息传递路径；在Android项目里，它是Activity、Fragment、Service之间的跳转和通信路径。
不管哪个领域，路由机制都承担同一个职责：把“发生了什么”和“谁来处理”解耦。这个解耦做得越好，移植时就越不需要改动业务代码。
我举个具体的例子。假设你有一个基于FreeRTOS的项目，用队列（Queue）做任务间通信。现在要移植到另一个RTOS上，如果那个RTOS没有队列机制，你就得把所有xQueueSend和xQueueReceive替换成信号量加共享内存。但如果你的代码里有一层薄薄的路由封装，比如自己定义了一个msg_router_send()和msg_router_recv()，那么移植时只需要重新实现这两个函数，业务代码一行不用改。
这就是路由机制在移植中的价值：它是业务代码和系统服务之间的“插座”。插座标准化了，换电器（换平台）就不用重新装修（重写代码）。
2.3 标准化的边界在哪里
标准化不是万能的。有些东西你标准化不了，也不应该标准化：
- 中断向量表：每个芯片的中断号和优先级都不一样，这个必须针对具体平台配置。
- 时钟初始化：不同芯片的PLL配置、分频系数完全不同，必须单独处理。
- 内存布局：链接脚本、堆栈大小、内存映射，这些跟具体芯片强相关。
- 启动流程：从复位向量到main函数之间发生了什么，每个平台都有自己的故事。
标准化的边界应该划在：凡是业务逻辑需要调用的接口，都应该标准化；凡是平台特有的初始化细节，都应该隔离在标准化接口之下。
我个人的经验是：移植时最耗时的不是写新代码，而是找旧代码里哪些地方“偷偷”调用了平台相关的东西。所以标准化技能栈的第一条原则就是：平台相关代码必须集中放置，并且有明确的命名规范，比如所有平台相关函数都加
port_前缀，这样你搜索port_就能找到所有需要改的地方。
3. 跨框架移植的三种典型模式
3.1 模式一：同架构不同芯片的移植
这是最常见也最简单的一种。比如从STM32F103移植到STM32F407，或者从CH32V305移植到CH32V307。架构相同，外设寄存器布局类似，主要工作是：
- 修改时钟配置（主频不同）
- 修改中断向量表（中断号可能不同）
- 修改内存布局（Flash和RAM大小不同）
- 修改外设初始化参数（引脚、复用功能）
这种移植里，路由机制通常不需要大改，因为RTOS和中间件的接口基本一致。但有一个坑：不同芯片的DMA控制器和中断控制器可能有细微差别，如果你的路由机制依赖DMA传输完成中断来触发消息投递，就需要仔细核对。
我做过一次从STM32F103到CH32V305的FreeRTOS移植，两者都是Cortex-M内核，但CH32V305的中断优先级分组和STM32不太一样。FreeRTOS的configPRIO_BITS配置错了，导致任务调度异常。这个问题排查了很久，因为现象是“偶尔卡死”，不是每次都复现。
3.2 模式二：不同架构之间的移植
比如从Cortex-M移植到RISC-V，或者从ARM移植到x86。这种移植的难度上一个台阶，因为：
- 指令集不同，汇编代码需要重写
- 内存模型可能不同（大小端、对齐要求）
- 中断处理机制不同（RISC-V的PLIC vs ARM的NVIC）
- 编译器不同（GCC vs Clang vs 厂商专用编译器）
这种场景下，路由机制的设计就非常关键了。因为不同架构对原子操作、内存屏障、中断禁用的支持程度不同，你的路由机制必须把这些差异封装起来。
举个例子：在ARM上，你可以用__disable_irq()和__enable_irq()来保护临界区。在RISC-V上，对应的可能是csr_clear(mstatus, MSTATUS_MIE)和csr_set(mstatus, MSTATUS_MIE)。如果你的路由机制里直接调用了ARM的内联函数，移植时就得全部替换。但如果你的路由机制里用的是自己定义的router_enter_critical()和router_exit_critical()，那么只需要重新实现这两个函数。
3.3 模式三：带OS到裸机的移植
这种移植在嵌入式领域非常常见，比如把LVGL从Linux移植到裸机，或者把某个协议栈从FreeRTOS移植到裸机环境。难点在于：
- 没有RTOS的任务调度，需要自己实现时间片轮转或事件驱动
- 没有RTOS的同步机制，需要自己实现信号量或消息队列
- 没有RTOS的内存管理，需要自己实现动态内存分配或改用静态分配
这种场景下，路由机制需要从“基于RTOS原语”切换到“基于裸机原语”。比如原来用xQueueSend发送消息，现在需要改成一个环形缓冲区加中断触发。但如果你有一层路由封装，这个切换只需要改封装层，业务代码不用动。
我印象最深的一次是把一个基于FreeRTOS的Modbus协议栈移植到裸机环境。原代码里用了队列来传递Modbus帧，移植时我写了一个简单的环形缓冲区，用定时器中断来模拟“任务调度”，把队列操作映射成环形缓冲区的读写。因为原代码里所有队列操作都通过一个modbus_port_send()和modbus_port_recv()函数，所以改动量很小。
4. 路由机制的设计要点与实操细节
4.1 路由机制的核心要素
不管在哪个领域，一个可移植的路由机制都应该包含以下要素：
- 消息格式定义：消息头、消息体、校验方式。这部分应该与平台无关，用纯C结构体或类似方式定义。
- 发送接口：
router_send(msg)，负责把消息投递到目标。 - 接收接口：
router_recv(msg)，负责从源获取消息。 - 注册接口：
router_register(handler)，负责把处理函数绑定到消息类型。 - 临界区保护：
router_lock()和router_unlock()，负责保护共享数据。 - 超时机制：
router_send_timeout(msg, timeout)，负责处理发送失败的情况。
这六个要素里，前四个是业务逻辑直接调用的，应该完全标准化；后两个是平台相关的，应该隔离在移植层。
4.2 消息格式的设计技巧
消息格式设计得好不好，直接决定了移植时要不要改业务代码。我见过很多项目，消息格式里直接嵌入了平台相关的字段，比如：
typedef struct { uint32_t src_task_handle; // FreeRTOS的TaskHandle_t uint32_t dst_task_handle; void* payload; uint32_t payload_len; } msg_t;这种设计的问题在于，src_task_handle和dst_task_handle是FreeRTOS特有的类型。移植到其他RTOS时，这两个字段的类型和含义都得改。
更好的做法是用抽象标识符：
typedef struct { uint16_t src_id; // 逻辑ID，与平台无关 uint16_t dst_id; uint8_t msg_type; uint8_t flags; uint16_t payload_len; uint8_t payload[MSG_MAX_PAYLOAD]; } msg_t;然后在移植层里维护一个“逻辑ID到平台句柄”的映射表。这样业务代码只认逻辑ID，移植时只需要改映射表的实现。
4.3 临界区保护的移植策略
临界区保护是路由机制里最容易出问题的地方。不同平台对临界区的支持差异很大：
| 平台类型 | 临界区实现方式 | 注意事项 |
|---|---|---|
| 裸机 | 关中断 | 关中断时间要尽可能短 |
| FreeRTOS | taskENTER_CRITICAL() | 不能在中断里调用 |
| Linux | pthread_mutex_lock() | 注意死锁问题 |
| RISC-V | CSR操作 | 注意内存屏障 |
| Android | synchronized | 注意ANR |
移植时，你需要为每个平台实现一套router_enter_critical()和router_exit_critical()。这里有一个关键点：临界区的粒度要尽可能小。我见过有人在路由发送的整个过程中都关中断，结果导致系统响应变慢。正确的做法是只在修改队列指针或链表节点时关中断，数据拷贝可以在临界区外完成。
4.4 超时机制的设计
超时机制在跨框架移植时经常被忽略，但它是保证系统健壮性的关键。比如在FreeRTOS里，xQueueSend可以带一个超时参数；在裸机环境里，你可能需要自己实现一个软件定时器来检测超时。
我的建议是：在路由接口里统一提供带超时的版本，即使当前平台不支持硬件超时，也要用软件方式模拟。这样移植到支持超时的平台时，业务代码不用改。
// 统一接口，timeout为0表示不等待，UINT32_MAX表示永久等待 router_status_t router_send_timeout(msg_t* msg, uint32_t timeout_ms);在裸机环境里，这个函数的实现可能是：
router_status_t router_send_timeout(msg_t* msg, uint32_t timeout_ms) { uint32_t start = get_tick_ms(); while (ring_buffer_full()) { if (get_tick_ms() - start > timeout_ms) { return ROUTER_TIMEOUT; } } ring_buffer_push(msg); return ROUTER_OK; }在FreeRTOS环境里，实现可能是：
router_status_t router_send_timeout(msg_t* msg, uint32_t timeout_ms) { TickType_t ticks = pdMS_TO_TICKS(timeout_ms); if (xQueueSend(queue, msg, ticks) == pdTRUE) { return ROUTER_OK; } return ROUTER_TIMEOUT; }接口一样，实现不同，这就是标准化的价值。
5. 完整移植流程与关键环节实现
5.1 移植前的准备工作
在动手改代码之前，有几件事必须先做：
第一，梳理依赖关系图。把项目里所有模块画出来，标出哪些是平台相关的，哪些是平台无关的。我通常用一张纸就能画完，但这一步不能省。因为很多“隐藏依赖”只有在画图的时候才会暴露出来。
第二，确定移植边界。哪些模块要替换，哪些模块要保留，哪些模块要重写。这个决定会影响后续所有工作。我的原则是：能保留的尽量保留，能封装的尽量封装，必须重写的才重写。
第三，准备目标平台的开发环境。包括编译器、调试器、烧录工具、串口终端。这一步看起来简单，但经常出问题。比如CH32V305需要专用的WCH-Link调试器，如果你手头只有ST-Link，就得先解决这个问题。
第四，写一个最小可运行示例。在目标平台上跑通一个LED闪烁或者串口打印，确认工具链没问题。这个步骤能帮你排除掉很多“不是代码问题”的问题。
5.2 路由层的移植步骤
假设你要把一个基于FreeRTOS的路由机制移植到另一个RTOS（比如RT-Thread），步骤如下：
步骤一：提取路由接口。把原代码里所有路由相关的函数找出来，整理成一张表：
| 原函数名 | 功能 | 调用次数 |
|---|---|---|
| xQueueSend | 发送消息 | 23 |
| xQueueReceive | 接收消息 | 18 |
| xQueueCreate | 创建队列 | 5 |
| vQueueDelete | 删除队列 | 2 |
步骤二：定义新接口。根据上表，定义一套与平台无关的接口：
router_queue_t router_queue_create(uint32_t depth, uint32_t item_size); router_status_t router_queue_send(router_queue_t q, void* item, uint32_t timeout); router_status_t router_queue_recv(router_queue_t q, void* item, uint32_t timeout); void router_queue_delete(router_queue_t q);步骤三：实现新接口。在目标平台上用RT-Thread的API实现这些函数：
router_queue_t router_queue_create(uint32_t depth, uint32_t item_size) { return (router_queue_t)rt_mq_create("rtr_q", item_size, depth, RT_IPC_FLAG_FIFO); } router_status_t router_queue_send(router_queue_t q, void* item, uint32_t timeout) { rt_err_t ret = rt_mq_send((rt_mq_t)q, item, sizeof(item)); return (ret == RT_EOK) ? ROUTER_OK : ROUTER_ERROR; }步骤四：替换调用点。把业务代码里的xQueueSend替换成router_queue_send，以此类推。这一步可以用脚本批量替换，但替换后要仔细检查。
步骤五：验证。写一个简单的测试用例，发送一条消息，确认能收到。然后再逐步增加复杂度。
5.3 中断路由的移植
中断路由是移植中最容易出问题的部分。不同芯片的中断控制器差异很大，而且中断处理函数的命名和注册方式也不同。
以STM32和CH32V305为例：
- STM32的中断处理函数名是固定的，比如
USART1_IRQHandler，你只需要在stm32f1xx_it.c里实现它。 - CH32V305的中断处理函数名也是固定的，但中断号可能不同，而且需要配置
PFIC（可编程快速中断控制器）。
移植中断路由时，我的做法是：
- 在路由层定义一个统一的中断回调注册接口：
router_irq_register(irq_id, handler)。 - 在移植层为每个平台实现这个接口。STM32上可能是把handler存到一个数组里，然后在
USART1_IRQHandler里调用数组里的handler。CH32V305上类似，但需要额外配置PFIC。 - 业务代码只调用
router_irq_register()，不关心底层是NVIC还是PFIC。
这样移植时，只需要重新实现router_irq_register()，业务代码不用动。
5.4 内存管理的移植
内存管理是另一个容易出问题的地方。FreeRTOS有pvPortMalloc和vPortFree，RT-Thread有rt_malloc和rt_free，裸机环境可能只有malloc和free，甚至完全没有动态内存。
我的建议是：在路由层统一使用静态内存分配。也就是说，消息缓冲区在编译时就分配好，运行时只做读写，不做malloc/free。这样做的好处是：
- 移植时不需要考虑目标平台的内存管理接口
- 避免了内存碎片问题
- 实时性更好（malloc的时间不确定）
如果确实需要动态内存，就在路由层封装一层：
void* router_malloc(uint32_t size); void router_free(void* ptr);然后在移植层实现这两个函数。裸机环境可以用一个简单的内存池，RTOS环境可以直接调用RTOS的malloc。
5.5 实操现场记录：一次完整的移植过程
我最近做了一次从STM32F103到CH32V305的FreeRTOS+LVGL移植，这里把关键步骤和遇到的问题记录下来。
环境准备：
- 原平台：STM32F103C8T6，Keil MDK，FreeRTOS 10.4.3，LVGL 8.3
- 目标平台：CH32V305RBT6，MounRiver Studio，FreeRTOS 10.4.3，LVGL 8.3
- 调试工具：WCH-Link，串口助手
第一步：建立最小工程。在MounRiver Studio里新建一个CH32V305的工程，跑通GPIO和串口。这一步花了半天，主要是熟悉MounRiver的工程结构和WCH-Link的配置。
第二步：移植FreeRTOS。把FreeRTOS的源码复制过来，修改FreeRTOSConfig.h。关键配置：
#define configPRIO_BITS 4 // CH32V305的中断优先级位数 #define configLIBRARY_LOWEST_INTERRUPT_PRIORITY 15 #define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 5 #define configCPU_CLOCK_HZ (144000000) // CH32V305主频144MHz #define configTICK_RATE_HZ (1000)这里踩了一个坑：CH32V305的中断优先级分组和STM32不同，configPRIO_BITS设错了会导致任务调度异常。我一开始设成了4，但实际应该是4（CH32V305支持4位优先级）。后来查了手册才确认。
第三步：移植LVGL。LVGL的移植主要是实现三个函数：
void lv_port_disp_init(void); // 显示初始化 void lv_port_indev_init(void); // 输入设备初始化 void lv_tick_inc(uint32_t ms); // 心跳在FreeRTOS环境下，lv_tick_inc可以放在一个定时器任务里调用，也可以放在SysTick中断里。我选择放在SysTick中断里，因为这样更准确。
显示刷新我用的是DMA+SPI，把LVGL的渲染缓冲区通过DMA发送到屏幕。这里的关键是DMA传输完成中断里要调用lv_disp_flush_ready()，告诉LVGL可以渲染下一帧了。
第四步：路由层适配。原项目里用FreeRTOS的队列在LVGL任务和业务任务之间传递消息。移植到CH32V305后，FreeRTOS的队列接口不变，所以这部分代码不用改。但是中断优先级配置变了，导致队列在中断里发送消息时偶尔失败。后来把configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY从5改成4，问题解决。
第五步：整体测试。跑了一个简单的UI界面，按钮点击、页面切换都正常。然后跑了24小时稳定性测试，没有死机。
这次移植总共花了3天，其中第一天熟悉环境，第二天移植FreeRTOS和LVGL，第三天调试和测试。如果再做一次类似的移植，估计1天就能完成，因为流程已经跑通了。
6. 常见问题与排查技巧实录
6.1 移植后系统卡死或跑飞
这是最常见的问题，原因通常有以下几种：
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 上电就卡死 | 时钟配置错误 | 用示波器测晶振，检查PLL配置 |
| 运行一段时间后卡死 | 堆栈溢出 | 增大任务堆栈，检查configCHECK_FOR_STACK_OVERFLOW |
| 中断里卡死 | 中断优先级配置错误 | 检查configPRIO_BITS和configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY |
| 调用路由函数后卡死 | 临界区嵌套 | 检查是否在临界区里调用了可能阻塞的函数 |
| 随机卡死 | 内存越界 | 检查消息缓冲区大小，开启内存保护 |
我的经验是：先怀疑配置，再怀疑代码。移植时90%的问题都是配置问题，特别是时钟和中断优先级。
6.2 消息丢失或重复
路由机制里消息丢失或重复，通常是因为：
- 队列深度不够：发送速度大于接收速度，队列满了之后消息被丢弃。解决办法是增大队列深度，或者实现背压机制。
- 临界区保护不当：多个任务同时操作队列，导致数据竞争。解决办法是确保所有队列操作都在临界区内。
- 中断优先级问题：在中断里发送消息，但中断优先级低于
configMAX_SYSCALL_INTERRUPT_PRIORITY，导致xQueueSendFromISR失败。解决办法是调整中断优先级。
我遇到过一次消息重复的问题，原因是接收任务在处理完消息后没有正确清除标志位，导致同一个消息被处理了两次。后来在路由层加了一个消息ID机制，每条消息有唯一ID，接收端记录已处理的ID，重复的直接丢弃。
6.3 性能不达标
移植后性能下降，通常是因为：
- 临界区太大：关中断时间太长，导致中断响应变慢。解决办法是缩小临界区，只保护必要的操作。
- 内存拷贝太多：消息在路由层被多次拷贝。解决办法是使用零拷贝技术，传递指针而不是数据本身。
- 任务优先级不合理：高优先级任务频繁抢占，导致低优先级任务得不到执行。解决办法是调整任务优先级，或者使用时间片轮转。
我做过一次优化，把路由层的消息拷贝从3次减少到1次，系统吞吐量提升了40%。具体做法是：发送端直接把消息写入队列，接收端直接从队列读取，中间不做任何拷贝。
6.4 跨平台编译错误
跨平台移植时，编译错误通常是因为：
- 头文件路径不同：不同平台的编译器对头文件路径的解析方式不同。解决办法是使用相对路径，或者在Makefile里统一配置。
- 数据类型长度不同：
int在32位平台是4字节，在16位平台是2字节。解决办法是使用stdint.h里的uint32_t等固定长度类型。 - 编译器扩展不同：GCC支持
__attribute__，Keil支持__packed。解决办法是用宏定义封装。
#if defined(__GNUC__) #define PACKED __attribute__((packed)) #elif defined(__CC_ARM) #define PACKED __packed #else #define PACKED #endif6.5 独家避坑技巧
技巧一：在路由层加一个“移植检查”宏。在编译时检查关键配置是否正确：
#if configPRIO_BITS != 4 #error "configPRIO_BITS must be 4 for this port" #endif技巧二：用逻辑分析仪抓路由时序。在路由发送和接收的关键位置翻转一个GPIO，用逻辑分析仪看时序，能快速定位性能瓶颈。
技巧三：保留一个“移植日志”文件。每次移植时记录改了哪些文件、改了哪些配置、遇到了什么问题。下次移植时直接参考，能省很多时间。
技巧四：先移植最简功能，再逐步增加。不要一上来就移植整个项目，先移植一个LED闪烁，再移植串口，再移植RTOS，再移植GUI。每步都验证通过后再进行下一步。
7. 路由机制的可扩展设计
7.1 支持多协议的路由
在实际项目里，路由机制往往需要支持多种协议。比如一个车载系统，可能同时有CAN、LIN、以太网三种通信方式。如果每种协议都单独实现一套路由，代码会非常臃肿。
更好的做法是：定义统一的路由接口，不同协议作为不同的“路由后端”。
typedef struct { router_status_t (*send)(msg_t* msg); router_status_t (*recv)(msg_t* msg); router_status_t (*init)(void); } router_backend_t; router_status_t router_register_backend(uint8_t proto_id, router_backend_t* backend);这样，CAN、LIN、以太网各自实现一个router_backend_t，业务代码调用router_send()时指定协议ID，路由层自动选择对应的后端。
7.2 支持动态路由表
在复杂系统里，消息的路由路径可能需要动态调整。比如某个任务崩溃后，消息应该被路由到备份任务。这时候就需要一个动态路由表。
typedef struct { uint16_t src_id; uint16_t dst_id; uint8_t proto_id; uint8_t priority; } route_entry_t; route_entry_t route_table[ROUTE_TABLE_SIZE]; router_status_t router_add_route(route_entry_t* entry); router_status_t router_del_route(uint16_t src_id, uint16_t dst_id);动态路由表的好处是：移植时不需要改路由逻辑，只需要重新配置路由表。
7.3 支持优先级和QoS
在实时系统里，不同消息的优先级不同。比如安全相关的消息应该优先处理，日志消息可以延迟处理。路由机制应该支持优先级队列。
typedef enum { ROUTER_PRIO_HIGH = 0, ROUTER_PRIO_NORMAL, ROUTER_PRIO_LOW, ROUTER_PRIO_COUNT } router_prio_t; router_status_t router_send_prio(msg_t* msg, router_prio_t prio);在移植层，优先级可以用RTOS的多队列实现，也可以用单个队列加优先级字段实现。关键是接口要统一。
8. 从移植到“一次编写，到处运行”的思考
做了这么多次移植，我最大的体会是：移植的成本不在于代码量，而在于耦合度。耦合度越低，移植越容易。而降低耦合度的关键，就是路由机制的设计。
一个设计良好的路由机制，应该让业务代码感觉不到平台的存在。业务代码只调用router_send()和router_recv()，不关心底层是FreeRTOS还是RT-Thread，是STM32还是CH32V305，是有OS还是裸机。
当然，完全做到“一次编写，到处运行”是不现实的。硬件差异、编译器差异、RTOS差异总是存在。但我们可以做到“一次编写，适配层改动最小化”。这个“最小化”的程度，就取决于路由机制的设计质量。
我现在的做法是：每个新项目开始时，先花半天时间设计路由层。定义好消息格式、接口函数、临界区策略、超时机制。这半天的时间，在后续移植时能省下好几天。
最后分享一个我常用的路由层文件结构，供参考：
router/ ├── router.h # 统一接口定义 ├── router.c # 路由核心逻辑（平台无关） ├── router_port.h # 移植层接口定义 ├── port_stm32.c # STM32移植实现 ├── port_ch32v305.c # CH32V305移植实现 ├── port_freertos.c # FreeRTOS移植实现 ├── port_baremetal.c # 裸机移植实现 └── router_config.h # 配置参数移植时，只需要增加一个port_xxx.c文件，然后在router_config.h里选择对应的移植实现。业务代码一行不用改。
这个结构我在三个项目里用过，每次移植的时间从原来的3-5天缩短到1天以内。如果你也在做跨框架移植，不妨试试这个思路。
