4. 固件架构风险：裸机与RTOS选型风险、模块划分与接口设计、代码复用与耦合度控制
固件架构这事儿，说大不大，说小不小。但一旦选错了，后面几个月你都得为这个决定买单。我见过太多项目，前期拍脑袋选了裸机，结果功能一多，调度乱成一锅粥；也有项目一上来就上RTOS，结果一个简单的传感器采集，被任务切换折腾得延迟超标。
说白了，架构选型没有绝对的对错，只有合不合适。这一章，我就把裸机和RTOS的选型风险、模块怎么切、接口怎么设计、代码怎么复用又不至于耦合死，这些坑一个一个给你掰开讲清楚。
4.1 裸机 vs RTOS：选型背后的隐性成本
先问个问题：你的系统到底需不需要“同时”做多件事？
注意，我说的是“同时”，不是“看起来同时”。裸机用超级循环也能轮询多个任务，但那叫分时切片，不是真正的并发。RTOS靠任务调度，能做到优先级抢占，实时性有保障。
我个人的习惯是：如果系统里只有1-2个周期性任务，且任务执行时间远小于周期，裸机完全够用。但一旦超过3个任务，或者有突发性高优先级事件，我就会认真考虑RTOS。
下面这张表，是我自己总结的选型对比，你可以直接拿去用：
| 对比维度 | 裸机（超级循环） | RTOS |
|---|---|---|
| 任务数量 | ≤3 个简单任务 | ≥3 个复杂任务 |
| 实时性 | 依赖循环周期，抖动大 | 优先级抢占，抖动可控 |
| 代码复杂度 | 低，容易理解 | 中高，需要学习调度机制 |
| 调试难度 | 低，单线程思维 | 高，竞态、死锁、优先级反转 |
| 内存开销 | 极小（栈+全局变量） | 较大（任务栈+内核对象） |
| 典型风险 | 轮询阻塞、中断嵌套失控 | 任务饿死、堆栈溢出、调度延迟 |
这里有个避坑指南：不要为了“用RTOS而用RTOS”。我曾经接手过一个项目，团队为了“显得专业”，给一个温度采集器上了FreeRTOS。结果呢？任务切换开销比采集本身还大，功耗也下不来。最后换回裸机，一切清爽。
4.2 模块划分与接口设计：别让代码变成一团乱麻
架构选好了，接下来就是怎么切模块。这块我吃过不少亏。早期我做项目，喜欢把功能都塞在一个文件里，觉得这样“方便”。结果项目一迭代，改一个地方，崩三个功能。嗯，这就是典型的耦合度失控。
模块划分的核心原则，我总结成四个字：高内聚，低耦合。
- 高内聚： 一个模块只做一件事，并且把这件事做好。比如驱动层就管硬件操作，业务层就管逻辑处理，别混在一起。
- 低耦合： 模块之间通过明确的接口通信，不要直接访问对方的全局变量。
接口设计这块，我建议你遵循一个“三不原则”：
- 不暴露内部实现： 接口只传递必要的数据，不要让对方知道你是怎么实现的。
- 不依赖全局变量： 能用参数传递就用参数，别搞一堆 extern 全局变量满天飞。
- 不跨层调用： 应用层不能直接调驱动层的寄存器操作，必须通过中间层（比如HAL或抽象层）。
举个例子，一个常见的错误写法：
// ❌ 坏写法：驱动层直接暴露寄存器地址
#define GPIO_BASE 0x40021000
void app_task(void) {
*(volatile uint32_t*)GPIO_BASE |= (1 << 5); // 应用层直接操作寄存器
}正确的做法是封装一个驱动接口：
// ✅ 好写法：驱动层提供抽象接口
void gpio_set_pin(uint8_t pin, uint8_t level);
void app_task(void) {
gpio_set_pin(5, 1); // 应用层只关心逻辑，不关心硬件
}这样做的好处是什么？哪天你换了MCU，只需要重写驱动层，应用层代码一行都不用改。这就是接口设计的价值。
4.3 代码复用与耦合度控制：别让“复用”变成“复制”
代码复用，听起来很美。但搞不好，就成了“复制粘贴改一改”。我见过最夸张的项目，一个I2C驱动在五个文件里各写了一遍，每个版本还略有不同。后来I2C时序要调整，改了一个，漏了四个，调试调了三天。
真正的复用，是通过抽象和分层来实现的。你想想看，如果能把通用的逻辑抽出来做成库，不同的项目只需要配置参数，是不是就省事了？
我常用的做法是“三层分离”：
| 层级 | 内容 | 复用方式 |
|---|---|---|
| 硬件抽象层（HAL） | MCU外设驱动（GPIO、UART、SPI） | 跨项目直接复用，换MCU时重写 |
| 中间件层 | 协议栈（Modbus、MQTT）、算法库（PID、滤波） | 跨平台复用，与硬件无关 |
| 应用层 | 业务逻辑、状态机、任务调度 | 按项目定制，尽量调用下层接口 |
耦合度控制，说白了就是让模块之间的依赖关系尽量简单。我有个小技巧：每次写完一个模块，问自己一个问题——“如果我要把这个模块移植到另一个项目，需要改几行代码？”如果超过5行，说明耦合度太高了。
下面这张SVG图，展示了固件架构中模块划分与接口调用的理想关系：
你看这张图，每一层只和相邻层通信，这就是分层解耦的核心思想。应用层不需要知道底层用的是STM32还是GD32，它只管调用中间件层的接口就行。
4.4 避坑指南：我踩过的三个典型坑
最后，分享三个我亲身经历过的坑，希望能帮你省点调试时间。
- 坑一：全局变量满天飞。 我曾经在一个项目里，为了图省事，把传感器数据放在全局变量里，结果三个任务同时读写，数据错乱得一塌糊涂。后来改成用消息队列传递数据，问题才解决。记住：共享数据一定要加保护（互斥锁/关中断/原子操作）。
- 坑二：接口设计太“胖”。 一个驱动接口函数，参数列表长达8个参数，调用者每次都要查半天手册。后来我改成用结构体传参，默认值用宏定义，清爽多了。接口设计要遵循“最少参数原则”，一般不超过3个参数。
- 坑三：复用代码不做配置隔离。 从旧项目复制了一个I2C驱动，忘了改引脚配置，结果新板子死活调不通。后来我在所有驱动模块里强制要求：硬件相关参数必须通过宏或配置文件定义，不能硬编码在代码里。