第二章：系统架构设计——硬件选型、软件分层与功耗预算
好，咱们进入正题。上一章聊了产品定义和需求分析，说白了就是搞清楚「我们要做什么」。这一章，咱们得落地了——开始搭骨架。
系统架构设计，我个人的理解就是「把纸面上的需求，翻译成工程师能看懂的技术方案」。这里面有三个核心环节：硬件选型、软件分层、功耗预算。这三个东西是互相咬合的，你选什么样的MCU，直接决定了你的软件架构怎么搭，也决定了你的功耗能不能压下来。
我在做第一个医疗贴片项目时，就犯过一个低级错误——先拍脑袋选了传感器，结果发现MCU的ADC精度不够，又换MCU，最后整个软件架构推倒重来。嗯，那滋味不好受。所以咱们今天按顺序来，一步步捋清楚。
2.1 硬件选型：MCU、传感器、BLE
硬件选型，说白了就是「选芯、选眼、选嘴」。
- 芯（MCU）：负责算力和控制
- 眼（传感器）：负责采集生理信号
- 嘴（BLE）：负责把数据传出去
这三个器件选好了，项目就成功了一半。我见过太多团队，把大量时间花在算法优化上，结果硬件选型没做好，最后产品根本没法量产。
2.1.1 MCU选型——别只看主频
很多人选MCU，第一眼看主频。其实对于医疗贴片来说，主频真不是最重要的。你想想看，贴片大部分时间都在休眠，真正干活的时间很短。所以更关键的是：低功耗模式下的电流、唤醒时间、外设集成度。
我个人习惯用这几款：
| 型号 | 内核 | 休眠电流 | 唤醒时间 | 适合场景 |
|---|---|---|---|---|
| nRF52840 | Cortex-M4F | 1.3 µA | 3 µs | 集成BLE，适合单芯片方案 |
| STM32L4系列 | Cortex-M4 | 0.8 µA | 5 µs | 外设丰富，适合多传感器 |
| EFM32 Giant Gecko | Cortex-M3 | 0.6 µA | 2 µs | 超低功耗，适合电池极小场景 |
2.1.2 传感器选型——精度和功耗的博弈
传感器是贴片的「眼睛」。但眼睛不能太耗电，否则贴片撑不了24小时。
我遇到过最头疼的问题：某款心电传感器，数据手册上写着「典型功耗 50 µA」，结果实际测下来，加上滤波和放大电路，整路功耗飙到了 200 µA。为什么？因为数据手册给的是芯片本身的功耗，没算外围电路。
所以选传感器时，我建议你关注三个指标：
- 工作电流：包括传感器本身 + 外围电路（运放、ADC驱动等）
- 采样率：医疗级心电需要 250 Hz 以上，体温只需要 1 Hz
- 输出接口：I2C 还是 SPI？SPI 通常更省电，但占用更多引脚
常用的传感器方案：
- 心电（ECG）：ADS1292R（TI），集成右腿驱动，功耗约 335 µW
- 体温：MAX30205（Maxim），精度 ±0.1°C，功耗约 100 µW
- 血氧（SpO2）：MAX30102（Maxim），集成红光和红外LED，功耗约 1.2 mW（脉冲模式）
2.1.3 BLE选型——集成还是分立？
BLE芯片的选择，其实就两个方向：
- 集成方案：MCU自带BLE（如nRF52840、DA14695）
- 分立方案：MCU + 独立BLE芯片（如STM32L4 + DA14531）
我个人更倾向于集成方案，原因很简单：少一颗芯片，少一堆麻烦。分立方案虽然灵活性高，但你需要处理两个芯片之间的通信协议、电源管理、天线匹配...嗯，调试起来真的很痛苦。
但如果你对功耗有极致要求，分立方案也有优势。比如DA14531的休眠电流只有 0.2 µA，比很多MCU自带的BLE模块还低。
2.2 软件分层架构——别让代码变成一锅粥
硬件选好了，接下来就是软件。我见过很多团队，代码写到最后自己都看不懂。为什么？因为没有分层。
软件分层，说白了就是「各司其职」。每一层只关心自己的事，不越界。这样后期维护、升级、移植都方便。
我常用的分层架构是这样的：
+-----------------------------+
| 应用层 (App) | ← 业务逻辑、状态机、数据管理
+-----------------------------+
| 服务层 (Service) | ← BLE服务、传感器驱动封装、存储服务
+-----------------------------+
| 硬件抽象层 (HAL) | ← MCU外设驱动、传感器底层驱动
+-----------------------------+
| 实时操作系统 (RTOS) | ← 任务调度、中断管理、资源同步
+-----------------------------+
| 硬件层 (Hardware) | ← MCU、传感器、BLE芯片
+-----------------------------+2.2.1 硬件抽象层（HAL）——把硬件「藏」起来
HAL层的作用，就是让上层代码不直接操作寄存器。比如你要读一个温度值，上层只需要调用 HAL_Temp_Read()，至于底层是用I2C还是SPI，上层不关心。
这样做的好处是什么？你换传感器了，只需要改HAL层，应用层代码一行都不用动。我在项目中就遇到过，客户临时要求换一款体温传感器，我花了半天改完HAL层，应用层完全没动，测试一遍过。
2.2.2 服务层（Service）——封装「能力」
服务层是HAL层和应用层之间的桥梁。它把底层的「原始数据」加工成「有意义的信息」。
举个例子：
- HAL层返回的是ADC的原始值（比如 2048）
- 服务层把这个值换算成温度（比如 36.5°C）
- 应用层直接拿这个温度去做逻辑判断
服务层还负责一些「脏活累活」，比如数据滤波、异常检测、缓存管理。这些逻辑放在应用层会显得臃肿，放在HAL层又不够抽象，服务层是最合适的位置。
2.2.3 应用层（App）——只关心业务
应用层是代码的「大脑」。它负责状态机切换、数据上报策略、用户交互逻辑。
比如一个心电贴片的状态机：
typedef enum {
STATE_IDLE, // 待机
STATE_INIT, // 初始化传感器
STATE_MONITOR, // 监测中
STATE_ALERT, // 异常报警
STATE_LOW_BATTERY // 低电量
} AppState_t;应用层只关心「当前是什么状态，下一步该做什么」。至于传感器怎么初始化、数据怎么传输，那是服务层和HAL层的事。
2.3 功耗预算——把每一微安都算清楚
功耗预算，是医疗贴片设计中最容易翻车的地方。你想想看，一个贴片要贴在人身上24小时甚至更久，电池就那么一小块，功耗算不清楚，产品就废了。
我刚开始做功耗预算时，犯过一个低级错误：只算了「工作状态」的功耗，没算「休眠状态」的功耗。结果产品实测，休眠电流比预期高了 10 倍，因为有一颗传感器的使能引脚没拉低...
2.3.1 功耗预算的计算方法
功耗预算的核心公式很简单：
平均功耗 = (工作电流 × 工作时间 + 休眠电流 × 休眠时间) / 总时间但关键在于，你要把每个模块的「工作周期」算清楚。
举个例子，一个心电贴片的工作周期：
| 模块 | 工作电流 | 工作时间 | 休眠电流 | 休眠时间 |
|---|---|---|---|---|
| MCU (nRF52840) | 5 mA | 100 ms | 1.3 µA | 900 ms |
| ECG传感器 (ADS1292R) | 335 µA | 100 ms | 0.5 µA | 900 ms |
| BLE广播 | 8 mA | 5 ms | 0 µA | 995 ms |
算一下平均功耗：
MCU: (5 mA × 0.1s + 1.3 µA × 0.9s) / 1s ≈ 500 µA
ECG: (335 µA × 0.1s + 0.5 µA × 0.9s) / 1s ≈ 34 µA
BLE: (8 mA × 0.005s + 0 µA × 0.995s) / 1s ≈ 40 µA
总平均功耗 ≈ 574 µA如果电池容量是 200 mAh，理论续航时间：
200 mAh / 0.574 mA ≈ 348 小时 ≈ 14.5 天看起来不错？别高兴太早，这只是理想情况。实际项目中，你还要考虑：
- 电池自放电：纽扣电池每年自放电约 2-5%
- 温度影响：低温下电池容量会下降 20-30%
- 系统余量：建议留 20% 的余量
2.3.2 降低功耗的实战技巧
说几个我常用的「省电小妙招」：
- 降低采样率：心电 250 Hz 够用就别用 500 Hz，体温 1 Hz 就够
- 批量传输数据：攒够一批数据再通过 BLE 发送，别采一次发一次
- 关闭不用的外设：不用的 SPI、I2C 接口，记得关时钟
- 用 DMA 代替 CPU 搬运数据：DMA 不占 CPU 时间，CPU 可以多睡一会儿
- 选择合适的休眠模式：nRF52840 有 System ON 和 System OFF 两种模式，后者功耗更低但唤醒时间更长
小结
这一章咱们聊了系统架构设计的三个核心环节：
- 硬件选型：MCU 看休眠电流和外设集成度，传感器看精度和功耗的平衡，BLE 推荐集成方案
- 软件分层：HAL 层藏硬件、服务层做加工、应用层管业务，各司其职
- 功耗预算：算清楚每个模块的工作周期，实测验证，别光靠理论
下一章，咱们要开始动手了——搭建开发环境，写第一行代码。嗯，那才是真正「从零到一」的开始。