1. 课程导入
很多工程师第一次接触STM32时，往往从“点灯”开始：配置时钟、初始化GPIO、写一个延时循环，LED亮起，成就感十足。但当项目从实验板走向真实产品，问题会迅速暴露：代码越写越乱、外设互相干扰、中断优先级冲突、升级失败变砖、功耗降不下来、多人协作互相覆盖。这些并不是某个寄存器写错，而是工程架构缺失导致的系统性问题。
本课程要讲的“STM32产品级工程架构设计”，不是教你如何点亮某个外设，而是教你如何把一个能跑的Demo，组织成一个可维护、可测试、可扩展、可量产的嵌入式软件系统。它介于“芯片外设驱动”和“业务应用逻辑”之间，是产品从原型走向量产的骨架。
一、什么是产品级工程架构设计
产品级工程架构设计，是指在明确产品需求、硬件资源和量产约束的前提下，对STM32软件进行分层、分模块、定接口、定规则的整体设计。它至少回答四个问题：
- 分层：哪些代码属于硬件抽象层，哪些属于中间件，哪些属于业务逻辑？
- 解耦：模块之间通过什么接口通信，能否独立替换和测试？
- 约束：中断、内存、时钟、功耗、启动流程有哪些硬性边界？
- 演进：如何支持后续功能增加、芯片替换、固件升级和多人协作？
与“写驱动”不同，架构设计关注的是关系与边界。一个驱动函数写得好，只解决一个点；一个架构设计得好，能让几十个模块长期稳定协作。下面这张图展示了产品级STM32工程从硬件到应用的典型分层与数据流关系。
二、学习目标
完成本课程后，你应当具备以下能力：
- 能够为一个中等复杂度的STM32产品设计合理的分层架构和目录结构。
- 能够定义清晰的模块接口，使驱动、中间件和应用可以独立开发和测试。
- 能够规划启动流程、中断管理、内存分配、参数存储和固件升级等关键机制。
- 能够识别并规避常见的架构反模式，如全局变量泛滥、中断里做业务、驱动与应用强耦合。
- 能够建立基本的工程规范，包括编码风格、版本管理、构建配置和调试日志。
三、整体知识框架
本课程的知识框架可以概括为“一条主线、四个层次、多个横切关注点”。主线是产品从需求到量产的开发流程；四个层次是应用层、中间件层、驱动抽象层和硬件层；横切关注点包括启动、中断、内存、功耗、升级、测试和版本管理。下表给出各模块的核心关注点与典型产出。
| 模块 | 核心关注点 | 典型产出 |
|---|---|---|
| 工程结构 | 目录分层、模块边界、依赖方向 | 工程目录树、模块清单、接口头文件 |
| 驱动与BSP | 外设统一接口、引脚映射、错误处理 | hal_xxx.c/h、bsp_board.c/h |
| 中间件 | RTOS任务划分、队列、日志、参数存储 | 任务表、消息定义、参数分区表 |
| 应用逻辑 | 状态机、业务解耦、可测试性 | app_xxx.c/h、状态迁移图 |
| 横切机制 | 启动、中断、内存、功耗、升级、看门狗 | 启动流程图、中断优先级表、内存映射图 |
四、典型产品开发流程
产品级开发不是“写完代码就结束”，而是一个闭环流程。典型阶段如下：
需求分析 → 硬件选型与资源评估 → 架构设计 → 模块开发与单元测试
→ 集成联调 → 系统测试与稳定性验证 → 小批量试产 → 量产与维护升级其中，架构设计发生在硬件选型之后、模块开发之前，是承上启下的关键阶段。如果跳过这一步直接写代码，后期修改成本会成倍增加。一个常见的场景是：产品初期只用UART通信，后期要加CAN和低功耗模式，如果驱动层没有抽象、任务没有分层，几乎需要重写整个工程。
五、常见误区与复盘
- 误区一：把Demo当架构。Demo只验证功能，不处理错误、并发、升级和量产一致性。
- 误区二：所有代码放在main.c。短期快，长期无法维护，也无法多人协作。
- 误区三：中断里做复杂业务。会导致实时性下降、竞态难查、系统不稳定。
- 误区四：没有接口约定。模块之间直接访问对方变量，改一处牵动全身。
- 误区五：忽视启动和升级。量产产品必须考虑Bootloader、参数分区和回滚机制。
本节作为课程导入，目的是先建立全局视角：STM32产品级工程架构设计，本质上是用工程化方法管理复杂度。接下来的章节将围绕工程结构、驱动抽象、中间件、应用逻辑和横切机制逐步展开，最终形成一套可落地的产品级开发方法。