3、需求分析与架构规划：如何从功能需求、性能约束、硬件资源出发定义架构目标与边界

单片机软件架构设计的起点并非画框图或选RTOS，而是对需求的深度解构。许多项目失败并非源于编码能力不足，而是架构目标模糊、边界条件缺失，导致后期频繁返工。本章将围绕“功能需求—性能约束—硬件资源”三条主线，讲解如何将模糊的产品期望转化为可量化、可验证的架构输入，并最终定义出清晰的架构目标与系统边界。

3.1 核心原理：需求三元组与架构映射

单片机架构设计的本质是在功能需求（F）、性能约束（P）、硬件资源（H）构成的三维空间中寻找可行解。功能需求回答“系统要做什么”，包括外设控制、通信协议、数据处理、用户交互等；性能约束回答“做到什么程度”，包括实时性（响应时间、中断延迟）、吞吐量（数据率、采样率）、可靠性（故障恢复时间、误码率）；硬件资源回答“用什么做”，包括MCU型号、Flash/RAM容量、主频、外设数量、电源域、引脚分配。

架构目标不是凭空产生的，而是对这三类输入进行加权权衡后的产物。例如，一个需要同时处理CAN通信、电机控制和UI刷新的系统，若MCU主频仅72MHz，则架构上必须考虑时间片轮转或中断嵌套优先级设计，而非简单的前后台顺序执行。边界定义则是对“哪些功能必须实现、哪些可以裁剪、哪些允许降级”的明确承诺。

3.2 判断方法：需求分析四步法

从原始需求到架构输入的转化，建议遵循以下四步流程：

1. 需求采集与分类：将产品需求文档（PRD）中的描述拆分为功能条目、性能指标和隐含约束。例如“设备响应要快”应量化为“按键到LED亮起≤50ms”。
2. 硬件资源盘点：列出MCU选型的关键参数：Flash容量、SRAM大小、主频、定时器数量、DMA通道、ADC通道数、通信外设（UART/SPI/I2C/CAN）等。同时评估引脚冲突和电源约束。
3. 冲突识别与优先级排序：将性能指标与硬件能力对比，找出瓶颈。例如，若要求1kHz采样率且每个样本需做64点FFT，则需计算CPU负载率是否超过70%（安全阈值）。
4. 架构目标定义：输出可量化的架构目标，包括：模块划分粒度（如驱动层/中间层/应用层）、关键时序预算（如中断响应≤10μs）、资源占用上限（如RAM使用率≤60%）、扩展性预留（如预留30%Flash用于OTA）。

3.3 案例拆解：工业数据采集器的架构边界定义

某工业数据采集器项目，要求通过RS485总线以Modbus协议上报8路4-20mA模拟量，同时支持本地LCD显示和按键配置。初始需求描述为“采集精度0.5%，刷新率10Hz，支持断线重连”。

分析过程：

• 功能拆解：模拟量采集（ADC+DMA）、信号调理（滤波算法）、Modbus协议栈（CRC校验、异常处理）、LCD驱动（段码式）、按键扫描（去抖）、参数存储（EEPROM模拟）。
• 性能约束：10Hz刷新率意味着每100ms完成一轮采集+处理+上报。若ADC采样需1ms，滤波算法需5ms，Modbus帧发送需2ms（115200bps下约1.7ms），则总耗时约8ms，CPU负载约8%，可行。
• 硬件资源：选用STM32G030F6P6（Flash 32KB，RAM 8KB，主频64MHz）。8路ADC需2个ADC模块分时复用，DMA通道紧张，需合理分配。
• 边界定义：明确“断线重连”的边界——仅支持Modbus TCP重连，不处理RS485物理层故障；LCD刷新率降至2Hz以节省CPU；滤波算法采用滑动平均（窗口8），不引入浮点运算。

实施结果：架构采用“中断+主循环”模型，ADC完成中断触发DMA传输，主循环中处理滤波和协议栈。最终Flash占用28KB，RAM占用5.2KB，满足资源预算。若未提前定义边界，盲目增加浮点滤波或复杂UI动画，将导致资源超限。

3.4 常见误区与总结复盘

误区一：需求分析只关注功能，忽略性能约束。例如“支持OTA升级”未说明升级包大小和传输时间，导致Flash分区预留不足，需重新设计Bootloader。

误区二：硬件资源评估过于乐观。仅看Flash/RAM总量，未考虑外设复用冲突（如SPI与I2C共用引脚）或DMA通道不足，导致架构后期被迫调整。

误区三：边界定义过于刚性或过于模糊。刚性边界（如“必须支持所有波特率”）导致实现复杂；模糊边界（如“尽量降低功耗”）导致无法验证。

误区四：缺乏需求追踪机制。架构文档与需求脱节，需求变更后无法评估影响范围。

总结而言，架构目标与边界的定义是一个“收敛”过程：从模糊的产品愿景出发，通过需求量化、资源盘点、冲突消解，最终形成可执行的技术基线。这一基线不仅是开发团队的契约，也是测试验收的依据。建议在项目启动时即建立“架构决策记录（ADR）”，将关键取舍和理由存档，为后续维护和迭代提供上下文。