📚 课程目录第1章嵌入式架构概述

一、嵌入式架构概述：什么是低耦合高内聚？为什么嵌入式系统需要这种架构？课程目标与学习路径

先讲个故事。几年前我做一款工业网关，代码量大概五万行。功能跑得挺好，直到客户要求加一个传感器协议。

我改了三个文件，编译通过，自测通过。结果呢？

Wi-Fi 连不上了。LED 指示灯乱闪。看门狗定时复位。

为什么会这样？因为代码里到处都是全局变量，模块之间你牵着我、我拽着你。改一个地方，炸一片。说白了，这就是典型的高耦合——模块之间依赖太强，像一团乱麻。

那次之后，我花了整整两周重构。把每个模块拆开，定义清晰的接口，内部自己管自己。再改协议？只动一个文件，其他模块纹丝不动。这就是低耦合高内聚带来的好处。

核心观点：低耦合高内聚不是学院派的空概念，是嵌入式工程师在项目里“被揍过”之后，自然学会的生存法则。

咱们用大白话拆开说。

耦合，就是一个模块对另一个模块的依赖程度。依赖越少，耦合越低。

内聚，就是一个模块内部各个元素之间的关联程度。关联越紧密，内聚越高。

我习惯用一个比喻：工具箱 vs 瑞士军刀。

在嵌入式系统里，我们追求的是工具箱式的架构。

概念	定义	嵌入式中的表现	坏味道
低耦合	模块间依赖少，接口清晰	驱动层不直接调用业务逻辑，通过回调或消息传递	一个模块改了，三个模块跟着改
高内聚	模块内部功能单一、完整	UART驱动只管收发，不负责协议解析	一个函数既读传感器又算平均值还发数据

我的判断标准：如果你改一个模块的代码，不需要看其他模块的源码，那就是低耦合。如果你能一句话说清这个模块是干什么的，那就是高内聚。

你可能会想：PC 软件也讲这个，嵌入式有什么特殊的？

嗯，这里要注意。嵌入式系统有几个“硬伤”，让低耦合高内聚变得不是“锦上添花”，而是“雪中送炭”。

资源受限：RAM 就几十 KB，ROM 几百 KB。高耦合的代码往往有大量冗余的全局变量和重复逻辑，浪费空间。低耦合的模块可以按需加载，甚至动态卸载。
实时性要求：高耦合意味着一个模块的延迟会传染给其他模块。我曾经在一个项目里发现，因为一个日志打印模块占用了太多 CPU，导致电机控制中断响应慢了 2ms——电机直接抖起来了。
硬件多样性：嵌入式项目经常换 MCU、换传感器、换通信芯片。低耦合的架构让你只需要换掉对应的驱动模块，业务逻辑完全不用动。我见过一个团队，换一次主控芯片要改 60% 的代码——就是因为耦合太高。
调试困难：嵌入式调试手段有限，没有 GDB 的大屏，很多时候靠串口打印和逻辑分析仪。高耦合的代码出了问题，你根本不知道是哪个模块的锅。

避坑指南：我曾经接手过一个项目，代码里有一个全局结构体，里面塞了 30 多个变量，从传感器数据到 UI 状态到网络配置全在里面。任何模块都可以随意读写。结果呢？一个中断服务程序改了其中一个变量，主循环里的另一个模块就崩了。查了三天才找到原因。这就是高耦合的典型“坑”。

下面这张图，是我对这门课知识结构的梳理。你可以把它当作一张地图，随时回来看看自己走到哪了。

这门课不是讲理论，是讲怎么在嵌入式项目里落地低耦合高内聚。我把它分成三个阶段：

学习建议：每章后面的代码示例，别光看。我建议你亲手敲一遍，然后试着改一改。比如把高耦合的版本改成低耦合的，看看编译时间、调试难度、扩展性有什么变化。你想想看，只有亲手踩过坑，才能真正理解架构的价值。

低耦合高内聚，说白了就是“各司其职，互不干扰”。嵌入式系统资源有限、实时性要求高、硬件变化快，这种架构不是可选项，是必选项。