嵌入式软件架构概述
各位同学好，我是老张。做嵌入式这行快十五年了，从最早的8位单片机一路做到现在的多核处理器。今天咱们聊聊嵌入式软件架构——说白了，就是怎么把代码组织得既好写又好改。
你可能觉得，一个剃须刀而已，能有多复杂？嗯，我当年也是这么想的。直到有一次，我负责的项目因为架构设计不合理，导致产品上市推迟了三个月...那滋味，真不好受。
什么是嵌入式软件架构
嵌入式软件架构，其实就是一套规则和约定。它告诉你：
- 代码该怎么分层
- 模块之间怎么通信
- 资源怎么管理
- 错误怎么处理
我习惯把架构比作房子的骨架。没有骨架，砖瓦堆得再漂亮也立不住。嵌入式软件也一样，没有好的架构，功能再多也是空中楼阁。
核心要点：架构不是写出来的，是设计出来的。它决定了你的代码能活多久、能跑多稳。
为什么需要架构
你想想看，一个剃须刀产品，从立项到量产，少说也要半年。这期间：
- 需求会变——今天加个电量显示，明天改个充电逻辑
- 人员会换——老员工走了，新来的得能看懂代码
- 硬件会改——换个MCU、加个传感器，都是常事
没有架构，每次改动都像拆炸弹。我曾经接手过一个项目，前任工程师把所有代码都写在main函数里，整整3000行。改一个bug，能引出三个新bug。你说崩溃不崩溃？
好的架构能带来几个实实在在的好处：
- 可维护性——改一处，不影响其他地方
- 可移植性——换个芯片，改改底层就行
- 可测试性——每个模块都能单独测
- 可复用性——这次写的模块，下个项目还能用
我的经验：架构设计花的时间，会在后期十倍百倍地省回来。别急着写代码，先想清楚怎么搭架子。
剃须刀产品的特殊性
剃须刀看着简单，其实是个挺特殊的产品。我做了几个项目后，总结出这么几个特点：
| 特点 | 说明 | 对架构的影响 |
|---|---|---|
| 成本敏感 | MCU选型受限，RAM/Flash都很小 | 代码必须精简，不能浪费资源 |
| 实时性要求 | 电机控制、传感器采样都有时间窗口 | 任务调度要合理，中断响应要快 |
| 低功耗 | 电池供电，待机电流要uA级 | 休眠唤醒机制要设计好 |
| 用户体验 | 按键响应、LED显示都要流畅 | UI逻辑不能卡顿 |
| 安全性 | 防水、防过热、防堵转 | 异常处理机制必须完善 |
这些特点加在一起，对架构提出了很高的要求。你不能像做手机那样，随便上个RTOS就完事。也不能像做玩具那样，全写在中断里凑合。
注意：剃须刀产品的代码量虽然不大，但逻辑复杂度一点不低。我见过太多项目，因为架构没设计好，最后死在「小问题」上。
一个典型的架构分层
我个人习惯把剃须刀的软件分成这么几层：
应用层
├── UI管理（按键、LED、蜂鸣器）
├── 工作模式（剃须、清洗、旅行锁）
└── 用户设置（档位、记忆功能）
服务层
├── 电机控制（PWM、堵转检测）
├── 电池管理（电量、充电、保护）
├── 传感器管理（霍尔、温度、压力）
└── 通信管理（蓝牙、NFC）
抽象层
├── 硬件抽象（GPIO、ADC、Timer）
├── 操作系统抽象（任务、信号量、队列）
└── 存储抽象（Flash、EEPROM）
驱动层
├── MCU外设驱动
├── 传感器驱动
└── 执行器驱动
这个分层的好处是：
- 底层换了，上层不用动
- 每个层只关心自己的事
- 出了问题，能快速定位
我记得第一次用这个架构做项目时，硬件工程师把电机驱动芯片换了。我花了两个小时改完驱动层，应用层一行代码没动。那种感觉，真爽。
架构设计的几个原则
说了这么多，最后分享几个我踩坑踩出来的原则：
- 模块化——每个功能都是一个独立模块，接口清晰
- 层次化——上层依赖下层，下层不依赖上层
- 可配置——通过宏或配置文件，而不是改代码
- 可扩展——加功能时，尽量不修改现有代码
避坑指南：我曾经为了省事，把电机控制和电池管理写在一个文件里。结果后来要加个新功能，改得我头皮发麻。从那以后，我再也不把不同职责的代码混在一起了。
好了，这一章就聊到这儿。下一章咱们会深入讲讲具体的架构模式，比如状态机、分层架构、事件驱动这些。你想想看，一个剃须刀，其实藏着不少嵌入式设计的门道呢。