4、系统架构设计：模块化分层设计、硬件/软件划分、接口定义、数据流与控制流设计
嵌入式项目从需求到落地，系统架构设计是决定成败的关键转折点。架构设计的目标并非画出漂亮的框图，而是在成本、功耗、性能、可维护性与开发周期之间找到工程上的最优平衡。本章围绕模块化分层、软硬件划分、接口定义以及数据/控制流设计四个核心维度展开，帮助开发者建立一套可落地、可评审、可追溯的架构设计方法。
4.1 模块化分层设计：从混乱到秩序的工程约束
核心原理：模块化分层的本质是依赖方向控制。在嵌入式系统中，我们通常将软件划分为应用层、中间件层、驱动抽象层（HAL）和硬件层。每一层只能依赖其下层，禁止跨层调用或反向依赖。这种单向依赖关系使得代码可独立编译、单元测试和复用。例如，应用层调用中间件提供的 mqtt_publish()，中间件调用 HAL 的 hal_uart_write()，HAL 再操作具体寄存器。如果应用层直接操作寄存器，则分层失效。
判断方法：在架构评审时，可以检查以下三个问题：第一，是否所有模块都有明确的职责边界？第二，是否存在循环依赖（A→B→C→A）？第三，更换 MCU 或传感器时，需要修改哪些层？如果只需修改 HAL 层，则分层合理；如果应用层代码大面积改动，则说明抽象不彻底。
| 分层 | 职责 | 典型内容 | 依赖方向 |
|---|---|---|---|
| 应用层 | 业务逻辑、状态机 | 温控策略、告警管理 | → 中间件 |
| 中间件层 | 协议栈、文件系统、RTOS封装 | MQTT、LittleFS、FreeRTOS队列 | → HAL |
| 驱动抽象层 | 统一硬件访问接口 | hal_uart_send()、hal_i2c_read() | → 硬件层 |
| 硬件层 | 寄存器操作、中断处理 | STM32 HAL库、SHT30驱动 | 无（最底层） |
4.2 硬件/软件划分：成本、功耗与实时性的博弈
核心原理：软硬件划分决定了系统的物理形态和成本。硬件实现（如专用逻辑电路、DMA、硬件加密）速度快、功耗低，但灵活性差；软件实现（如算法、协议解析）灵活、可升级，但占用 CPU 和内存。划分的关键指标是实时性要求、功耗预算和单位成本。例如，一个需要 1ms 内响应的电流环控制，必须由硬件 PWM 模块完成；而一个温度滤波算法，则适合用软件实现。
操作流程：进行软硬件划分时，建议按以下步骤执行：
- 列出所有功能需求，标注实时性要求（硬实时/软实时/非实时）。
- 评估每个功能的计算量（如 FFT 点数、滤波阶数）和数据吞吐量。
- 对比 MCU 主频、DMA 通道数、外设资源（定时器、ADC 通道）。
- 对每个功能打标签：HW 实现、SW 实现或混合实现（如硬件触发+软件处理）。
- 估算成本差异：硬件方案增加 BOM 成本 vs 软件方案增加 Flash/RAM 需求。
4.3 接口定义：稳定契约与错误处理
核心原理：接口是模块间协作的契约。在嵌入式 C 语言项目中，接口定义通常包括：函数原型、参数范围、返回值含义、错误码枚举、超时策略和线程安全要求。一个良好的接口应该让调用者无需了解内部实现即可正确使用。例如，int hal_uart_send(uint8_t port, const uint8_t *data, uint16_t len, uint32_t timeout_ms) 明确规定了端口号、数据指针、长度和超时时间。
判断方法：接口设计是否合格，可以从以下维度评审：
- 完备性：是否覆盖所有操作（初始化、读写、控制、去初始化）？
- 错误处理：是否定义了错误码（如
HAL_OK=0、HAL_TIMEOUT=1、HAL_INVALID_PARAM=2）？ - 可测试性：接口是否便于打桩（Mock）进行单元测试？
- 资源管理：是否明确谁负责分配/释放缓冲区？
// 示例：HAL 层接口定义头文件（hal_uart.h）
#ifndef HAL_UART_H
#define HAL_UART_H
#include <stdint.h>
typedef enum {
HAL_UART_OK = 0,
HAL_UART_TIMEOUT = 1,
HAL_UART_INVALID_PARAM = 2,
HAL_UART_BUSY = 3
} hal_uart_status_t;
hal_uart_status_t hal_uart_init(uint8_t port, uint32_t baudrate);
hal_uart_status_t hal_uart_send(uint8_t port, const uint8_t *data, uint16_t len, uint32_t timeout_ms);
hal_uart_status_t hal_uart_receive(uint8_t port, uint8_t *buf, uint16_t len, uint32_t timeout_ms);
#endif4.4 数据流与控制流设计：系统行为的骨架
核心原理：数据流描述数据从采集、处理到输出的路径；控制流描述事件、命令和状态如何驱动系统行为。在嵌入式系统中，数据流通常采用生产者-消费者模型：传感器中断（生产者）将数据放入环形缓冲区，主循环或任务（消费者）取出数据进行处理。控制流则常以状态机为核心，例如设备从“初始化”→“待机”→“运行”→“故障”的状态迁移。
操作流程：设计数据流时，建议绘制数据流图（DFD）并标注每个节点的延迟预算。例如：传感器采集（10ms）→ DMA搬运（2ms）→ 滤波算法（5ms）→ 协议打包（3ms）→ 发送（1ms），总延迟 21ms，满足 50ms 的端到端要求。控制流设计则需定义事件优先级：硬件中断（最高）→ 系统 tick → 应用事件队列 → 低优先级后台任务。
| 设计维度 | 关键问题 | 常用机制 | 典型错误 |
|---|---|---|---|
| 数据流 | 数据是否丢失？延迟是否可接受？ | 环形缓冲区、DMA、双缓冲 | 在中断中做耗时处理 |
| 控制流 | 状态迁移是否完备？异常如何恢复？ | 状态机、事件队列、看门狗 | 状态机缺少默认分支 |
| 耦合度 | 模块间是否通过接口通信？ | 消息队列、回调函数 | 全局变量满天飞 |
4.5 常见误区与总结复盘
误区一：过度设计。为 8 位 MCU 项目引入完整的 RTOS 和多层抽象，导致 Flash 不足、调试困难。建议根据项目复杂度选择合适的分层粒度。
误区二：接口定义模糊。例如 void send_data(uint8_t *data) 没有长度参数，导致缓冲区溢出风险。所有接口必须包含长度和超时参数。
误区三：忽略控制流的异常路径。只设计正常状态迁移，未考虑通信超时、传感器故障等异常情况。状态机必须包含“故障”状态和恢复机制。
误区四：数据流未做背压处理。当生产者速率高于消费者时，环形缓冲区溢出导致数据丢失。应设计丢包策略（丢弃最旧数据）或流控机制（暂停采集）。