系统架构设计原则：模块化、高内聚低耦合、软硬件协同与实时性
各位同学，咱们今天聊点实在的。系统架构设计，说白了就是给嵌入式系统搭骨架。骨架搭得好，后面写代码、调硬件、改需求，都顺风顺水。骨架搭歪了，后期返工的成本，会让你怀疑人生。
我个人习惯，在动手画第一张框图之前，先拿这四条原则过一遍脑子。它们不是教科书上的教条，是我在项目里摔过跟头之后，才真正理解的。
模块化设计：拆得开，合得拢
模块化，就是把一个复杂系统，拆成若干个功能独立的模块。每个模块有清晰的输入、输出和接口。
为什么要拆？你想想看，一个几千行代码的单片机程序，如果全写在一个 main.c 里，出了 bug 你怎么查？改一个功能，会不会影响另一个？
我在项目中遇到过最典型的反面教材：一个同事把电机控制、传感器采集、通信协议、UI 显示全塞在一个任务里。结果每次改 UI，电机就抖一下。嗯，这就是没做模块化的后果。
模块化设计的具体做法，我建议遵循以下几点：
- 功能内聚：一个模块只做一件事，并且把它做好。
- 接口清晰：模块之间的交互，通过定义好的 API 或消息队列完成，不要直接访问对方的全局变量。
- 独立编译：每个模块可以单独编译、测试，不依赖其他模块的内部实现。
- 可替换性：换一个硬件外设，只需要替换对应的驱动模块，上层代码不用动。
高内聚低耦合：模块内部的凝聚力，模块之间的疏离感
这两个词，你肯定听过。但怎么落地？
高内聚，指的是模块内部的元素（函数、变量）之间，关联性要强。比如一个温度传感器驱动模块，所有与温度读取、转换、校准相关的代码，都应该放在这个模块里，别散落在各处。
低耦合，指的是模块与模块之间的依赖关系要弱。一个模块改了，其他模块尽量不受影响。
| 对比维度 | 高内聚 | 低耦合 |
|---|---|---|
| 关注点 | 模块内部 | 模块之间 |
| 目标 | 职责单一，代码集中 | 依赖最少，接口稳定 |
| 反面例子 | 一个模块既管显示又管通信 | 模块 A 直接调用模块 B 的内部变量 |
| 实现手段 | 按功能划分文件 | 使用接口、回调、消息队列 |
硬件与软件协同设计（HW/SW Co-Design）
这一点，是嵌入式系统独有的。纯软件项目可以等硬件出来再写代码，但嵌入式不行。硬件和软件是绑在一起的，谁等谁，项目都得延期。
我曾经在一个项目中，硬件工程师选了一颗 ADC 芯片，我等到板子打样回来才发现，它的 SPI 时序跟我的 MCU 不兼容。结果呢？要么改板，要么软件里用 GPIO 模拟时序，性能大打折扣。
协同设计，就是要避免这种悲剧。具体怎么做？
- 早期介入：软件工程师在硬件选型阶段就要参与，确认外设的接口、时序、电压是否匹配。
- 接口先行：先定义好硬件与软件之间的接口文档，包括寄存器地址、中断号、DMA 通道、引脚功能等。
- 虚拟原型：在硬件实物出来之前，用模拟器或开发板搭建软件测试环境。
- 联合调试：硬件和软件工程师坐在一起，用逻辑分析仪和调试器同步排查问题。
实时性与资源约束：戴着镣铐跳舞
嵌入式系统，尤其是实时系统，对时间有硬性要求。一个任务必须在 10 毫秒内完成，晚 1 毫秒就是事故。同时，你的 CPU 主频可能只有几十兆赫，RAM 只有几十 KB。
这就是资源约束下的实时性设计。说白了，就是怎么用有限的资源，在规定时间内把活干完。
我建议从这几个角度入手：
- 任务优先级划分：把紧急的任务（如电机控制、故障保护）设为高优先级，非紧急的任务（如日志记录、UI 刷新）设为低优先级。
- 时间预算：给每个任务分配最大执行时间，用逻辑分析仪或 RTOS 的跟踪工具验证是否超标。
- 资源复用：能查表就不计算，能用 DMA 就不占 CPU，能静态分配就不动态申请。
- 最坏情况分析：不要只测平均性能，要测最坏情况下的响应时间。比如所有中断同时触发时，系统还能不能扛住。
下面这张图，是我在项目中常用的架构设计原则关系图，帮你理清这四条原则之间的逻辑。
这四条原则，不是孤立存在的。模块化设计是高内聚低耦合的基础；软硬件协同设计决定了模块的边界；实时性与资源约束，则是贯穿始终的硬条件。你在做架构时，要同时考虑它们，而不是一条一条单独做。
嗯，今天就先聊到这里。这些原则，你可以在下一个项目里试着用起来。不用追求一步到位，先从模块化开始，慢慢你就会发现，架构设计其实是有章可循的。