1. 模块化设计哲学：为什么嵌入式开发需要模块化？

嵌入式开发这行，干得越久，越能体会到一个道理：代码的组织方式，决定了项目的生死。我见过太多项目，前期跑得飞快，一到联调阶段就变成一团乱麻。为什么会这样？说白了，就是没把「模块化」当回事。

今天咱们就聊聊模块化的底层逻辑。不讲虚的，全是实战里摔打出来的经验。

1.1 为什么嵌入式开发尤其需要模块化？

你想想看，嵌入式开发和纯软件有个本质区别：硬件绑定。一个传感器驱动换了引脚，可能整个应用层都要跟着改。我早期做的一个智能家居项目，就因为温湿度传感器从 I2C 换成了 SPI，结果改了整整三天代码——那会儿还没模块化意识，驱动和业务逻辑全揉在一个文件里。

嵌入式系统的痛点，我归纳了三点：

痛点	表现	后果
硬件耦合	驱动代码与业务逻辑混写	换硬件等于重写
资源受限	RAM/Flash 有限，不敢分层	代码复用率极低
调试困难	一个 bug 查半天找不到根因	开发周期失控

模块化解决的就是这些问题。它让每个功能块独立、可替换、可测试。说白了，就是给代码上了「保险」。

1.2 模块化的核心原则：高内聚、低耦合

这两个词，你肯定听过。但真正理解的人不多。我用自己的理解给你拆开讲。

高内聚：模块内部要「拧成一股绳」

高内聚的意思是：一个模块里的东西，应该都是为了完成同一个目标。比如一个 UART 驱动模块，里面就只放 UART 初始化、发送、接收、中断处理。别把 LED 闪烁的逻辑也塞进去。

我在项目中遇到过这样的案例：一个同事把按键扫描和 OLED 显示写在了同一个文件里。理由是「按键按下要刷新显示，放一起方便」。结果后来要换 OLED 驱动，连按键逻辑都跟着崩了。这就是内聚度太低。

判断内聚度有个简单方法：如果你要改一个功能，需要改几个文件？理想情况是只改一个。

低耦合：模块之间要「保持距离」

低耦合的意思是：模块之间不要互相依赖太多。A 模块改了，B 模块不应该受影响。

我习惯用接口来解耦。比如一个传感器模块，对外只暴露三个函数：

/* sensor.h - 传感器模块接口 */
int8_t sensor_init(void);
int8_t sensor_read(float *temperature, float *humidity);
void sensor_deinit(void);

至于底层是 I2C 还是 SPI，外部调用者根本不需要知道。这就是低耦合的好处——换驱动就像换电池一样简单。

1.3 模块化设计的三个层次

模块化不是一刀切。我一般把它分成三个层次：

1. 物理层模块化：按文件/文件夹划分。一个 .c/.h 对就是一个模块。
2. 逻辑层模块化：按功能职责划分。比如驱动层、中间件层、应用层。
3. 架构层模块化：按子系统划分。比如通信子系统、传感子系统、控制子系统。

大多数项目做到逻辑层模块化就够了。只有大型项目才需要架构层。别过度设计。

1.4 模块化设计带来的调试红利

这一点我要重点说。模块化不只是为了「代码好看」，它直接降低调试成本。

我曾经接手过一个项目，系统跑着跑着就死机。没有模块化，所有代码都在一个 main.c 里，全局变量满天飞。我花了整整一周才定位到问题——一个中断服务函数里不小心改了全局定时器变量。

如果当时用了模块化：

• 每个模块有自己的私有变量（用 static 修饰）
• 模块间通过接口通信，不共享全局变量
• 每个模块可以单独测试

那个 bug 最多半天就能找到。

1.5 模块化设计知识体系

下面这张图，是我自己总结的模块化设计知识体系。你可以把它当作一个「检查清单」：

1.6 什么时候不该用模块化？

说了这么多好处，也得泼盆冷水。模块化不是银弹。有些场景下，过度模块化反而坏事：

• 原型验证阶段：快速出活比代码结构重要。先跑通，再重构。
• 极端资源受限：比如 1KB RAM 的 MCU，函数调用开销都要精打细算。
• 一次性项目：写完就扔的代码，没必要分层。

但话说回来，大多数嵌入式项目都不是一次性的。产品要迭代，代码要维护。前期多花半小时做模块化设计，后期能省下几天甚至几周的调试时间。这笔账，你自己算算。