搞可穿戴硬件的人应该都遇到过这个尴尬项目刚开始做原型验证老板说“先搞个能戴在手腕上的”你老老实实画了一块圆形PCB过了两周需求变了要改成胸贴式的主控、传感器、电池全得重新排再过一个月又说要做成头戴式得前面的设计基本全部推倒重来。一个项目周期里硬件改版三次以上是常态每次改版背后都是几周的layout、打样、贴片、调试。后来我意识到问题不是出在某一次设计上而是出在整个开发套件的架构思路上——我们缺的不是一块更小的板子而是一套Scalable Wearable Development Kit可扩展可穿戴开发套件。这套东西的核心思路是把可穿戴设备拆成几个逻辑清晰、物理可拆的模块主控计算、传感采集、电池供电、无线通信、人机交互。每个模块做成标准化的硬件单元通过统一的接口互联。原型阶段你可以像搭积木一样快速组合出不同形态的设备进入产品化阶段又可以直接把验证过的模块移植到一体化的PCB上软件几乎不用动。这篇文章我就把这套方法的架构思路、硬件选型、固件分层、接口设计、功耗调优整个串起来讲一遍特别是那些只有真正做过几轮改版之后才懂的坑一次性倒出来。1. 整体架构与设计思路为什么“可扩展”这么难做很多团队做可穿戴开发板第一反应是“把功能堆全”。传感器能挂的全挂上通信方式蓝牙WiFi LoRa全给电池接口、充电管理、屏幕、马达、按键一个不落。板子做出来很大资料写得很厚但真正拿去开发产品时发现哪哪都不顺手想省电没有一个干净的休眠路径想换传感器引脚冲突想改外形PCB得重画。这种开发板本质上是“功能演示板”不是“开发套件”。可扩展性的核心不是接口多而是边界清晰。我在这套方案里定了几条硬性设计原则1.1 模块化拆分接口统一一个典型的可穿戴设备无论形态怎么变功能上都跑不出这五个子系统的组合感知传感器、计算MCU、连接无线、供能电池电源管理、交互显示/触觉/按键。这套开发套件把每个子系统做成独立的硬件模块模块之间用统一的物理接口和电气协议连接。物理接口我用了两种一种是板对板的邮票孔Castellated Pad适合模块之间需要堆叠的场景另一种是1.0mm间距的FPC连接器适合需要分开布置的场景比如电池放手臂一侧、主控放另一侧。电气协议统一走I2C所有模块上预留中断线和电源控制线。I2C这个选择很关键它只需要两根线支持多主机几乎所有传感器和外围芯片都原生支持对可穿戴这种走线空间极其受限的场景是最优解。1.2 主控模块决定整套系统的边界主控是整个套件的大脑也是最不能妥协的模块。我对比过几款主流方案最终选了Nordic的nRF52840。选择理由有三条第一它自带蓝牙5.0支持BLE、ANT、Thread、Zigbee其中BLE是当前可穿戴设备的事实标准没有之一第二它有ARM Cortex-M4F内核带FPU主频64MHz跑传感器融合算法勉强够用第三它的外设资源丰富有多个SPI、I2C、UART、PWM、ADC还有PDM和I2S数字音频接口意味着它既能当运动手环的主控也能做助听器、语音交互设备的主控扩展性足够。选主控的一个经验不要只看算力和功耗要把外设资源的数量对应到你的目标形态上。很多可穿戴原型后期死掉不是因为算力不够而是因为外设不够用——SPI被屏占了I2C被imu占了ADC又不兼容你要用的传感器最后只能换主控软件推倒重来。1.3 传感器模块“热插拔”式设计传感器模块是可穿戴设备里最能体现“形态差异”的部分手环要PPG心率传感器胸贴要ECG电极头戴设备可能要EEG运动场景要IMU医疗场景要体温、血氧。如果每个传感器的电路都集成在主板上换个产品方向就换一块主板扩展性无从谈起。这套套件的做法是传感器模块全部按统一尺寸设计20mm x 20mm的子板双排邮票孔间距1.27mm。子板上除了传感器本身还集成其配套的电荷泵、电平转换、去耦电容、串联电阻等所有外围电路。主控板上只留标准接口和对应引脚的socket层。这样开发时换传感器不需要动主控板只需要把一块子板拔下来插上另一块。所有传感器模块都遵循同一个裸机驱动接口——一个初始化函数、一个单次读取函数、一个数据回调函数——上层应用完全不感知底层换了什么芯片。这种设计在实际使用中帮了大忙。我做过一个睡眠监测项目最开始用一款商用的PPG模块后面客户说想试试ECG方案我只需要把心率传感器子板换成ECG子板应用层的逻辑基本没改整个切换时间从原来的两周缩短到两天。2. 硬件核心细节电源管理、电池选型与充电方案的权衡可穿戴设备硬件上最容易翻车的一个是功耗设计一个是电池管理。这两个问题在原型阶段不突出因为大家都是插着调试器跑的一旦进入“真戴在手上跑一天”的阶段各种问题就现出原形了。2.1 电源架构设计模拟域和数字域要分开可穿戴设备的电源架构有个显著特点不同子系统对电源质量的要求差异极大。传感器里的模拟前端比如PPG的AFE、ECG的仪表放大器对电源纹波极其敏感纹波稍大一点心率波形上就会出现周期性干扰而数字部分MCU内核、无线射频反而对瞬态响应要求高蓝牙发射瞬间会有几十毫安的电流尖峰。因此套件里把电源分成两路一路是VDD_DIGITAL1.8V或3.3V由主控板上的DCDC降压输出专供MCU、Flash、无线射频等数字电路另一路是VDD_ANALOG3.0V由低噪声LDO输出专供各类传感器模拟前端和参考电压。两路之间用磁珠隔离。这个隔离在调试时可能看不出区别但当你把PPG信号放到FFT里看频谱时就会发现模拟电源域单独供电之后50Hz附近的干扰毛刺明显减少。2.2 电池选型容量、体积和放电能力的三角博弈可穿戴设备的电池选型本质是容量、体积、放电能力三个变量之间的平衡。具体到套件设计上我做了两个不同规格的电池接口一个是标准版适配80mAh到150mAh的软包电池适合手环、胸贴这类对重量敏感的场景另一个是扩展版适配300mAh以上的电池适合需要长续航或高功耗场景比如带屏幕连续音频处理的智能眼镜。选电池时有几个关键参数经常被忽略。一个是放电倍率C-Rate软包电池通常标称1C放电但很多可穿戴场景的峰值电流远不止这个BLE广播瞬间约10mA如果同时在刷屏和写Flash峰值可能到50mA以上对100mAh的电池来说就是0.5C还能顶住但如果系统里有震动马达启动瞬时电流可能到200mA这就是2C放电了普通软包电池的电压会被瞬间拉低导致系统复位。另一个是内阻内阻大的电池在低温环境下电压掉得特别快冬天户外使用时尤其明显。建议原型阶段就选内阻低于200mΩ的电池贵一点但能避免很多诡异的问题。2.3 充电管理不是所有线性充电器都适合可穿戴充电方案我建议分两档。第一档是常规的线性充电芯片比如TI的BQ25185支持150mA到500mA充电电流带电源路径管理Power Path适合电池容量在200mAh以内的场景。第二档是开关充电芯片比如BQ25618效率高适合大电池但外围电路复杂原型阶段不推荐。这套套件统一使用BQ25185理由是它有一个特别适合可穿戴的特性出厂模式Shipping Mode。在这个模式下电池到系统的通路被切断只保留极低的静态电流设备可以带着电池长期存放而不亏电。这个功能在产品化阶段非常实用——用户买到手开箱时电量还在80%以上体验完全不同。2.4 一颗电阻搞定电量监测避免被库仑计带偏电量监测是可穿戴设备里另一个容易过度设计的地方。很多方案一上来就上库仑计Coulomb Counter结果发现要校准、要学习电池曲线、要考虑温度补偿小项目根本玩不转。我的建议是原型阶段用电压法估算电量即可通过ADC实时采集电池电压查一张电压-电量SOC对照表精度大概在±15%左右。虽然不如库仑计准但对绝大多数原型验证来说完全够用——你只需要知道“电量是不是快见底了”而不需要知道“具体还剩多少毫安时”。等产品做大了、电池曲线摸清楚了再考虑换库仑计。这个取舍能省下大量调试时间。3. 固件分层设计把驱动、服务、应用拆干净硬件模块化是基础固件模块化才是这套套件真正省钱省时间的地方。我用一个四层固件架构这一年多迭代下来非常稳。3.1 四层架构驱动层、服务层、应用层、配置层第一层是驱动层Driver Layer每个传感器模块对应一个独立驱动的源文件负责最底层的寄存器读写、初始化序列、数据读取。例如max86141.cPPG传感器、lsm6dsv16x.cIMU、ads1292r.cECG每个驱动对外只暴露三个函数xxx_init()、xxx_read_one_sample()、xxx_set_register()。第二层是服务层Service Layer负责把底层驱动数据整合成有业务含义的信息。比如心率算法模块从PPG驱动取原始红光/红外数据经过滤波和峰值检测输出心率值姿态识别模块把IMU的三轴加速度和角速度融合成姿态角。这一层是算法密集区也是各大厂真正拉差距的地方。第三层是应用层Application Layer负责产品业务逻辑。比如睡眠监测应用它调度心率、体动、环境光三个服务组合出“入睡时间、深睡时长、翻身次数”等睡眠报告。这一层不直接接触硬件只调用服务层的接口所以换硬件时应用层代码完全不用动。第四层是配置层Config Layer通过一个结构体把整个系统的参数集中管理采样率、BLE广播间隔、中断优先级、电源策略等都在这里定义。这样调试功耗时改参数只需要改这一个文件不需要满工程找魔术数字。3.2 一套驱动设计兼容所有形态驱动层设计时有一个容易踩的坑传感器芯片虽然是同一颗但在不同形态的设备上引脚分配、中断触发方式、电源控制脚可能都不同。解决办法是在驱动层之上加一个“板级适配层Board Support Package”用宏定义把每个形态下的引脚映射集中管理。比如定义#define PPG_INT_PIN 11和#define PPG_PWR_EN_PIN 12换板子时只需要改这个头文件驱动代码一行不动。这个设计在光电容积脉搏波PPG传感器的调试中体现得特别明显。PPG的采样窗口、LED电流、采样率这些参数直接决定了信号质量——LED电流太小肤色深的人信号弱到无法检测电流太大功耗翻倍且容易饱和。我在套件里把这些参数全部做到了配置层针对不同肤色、不同佩戴部位手腕、耳垂、额头做几套预设切换只是改一个参数结构体的事情。3.3 日志系统可穿戴调试的命门原型阶段调试最痛苦的事情之一是设备戴在手上没法像开发板那样随时插串口看日志。我在这套固件里设计了一个三级日志系统平时日志只写进RAM环形缓冲不占功耗当检测到特定触发条件比如蓝牙连接建立、系统异常复位再把缓冲区的日志通过BLE批量发送出来。这个方案既满足了日常调试需求又不影响正常运行功耗。实测下来这套日志系统在蓝牙断开、设备异常复位这类问题排查上省了至少一半时间。异常复位后RAM缓冲里的最后几十条日志能告诉你设备死前在干什么。RAM日志还有另一个用途代码执行时间分析。在关键函数入口和出口打时间戳存进环形缓冲事后通过BLE拉出来就能看到每个任务实际占用的时间片比在调试器里单步执行靠谱得多。4. 无线通信选型与低功耗调优续航是体验的半条命可穿戴设备最核心的体验指标之一就是续航。功能做得再全电池撑不过半天用户照样不会用。而续航问题80%出在无线通信模块上。4.1 为什么BLE仍是可穿戴设备的第一选择这几年可穿戴领域无线方案出了不少新选项但BLE依然是最稳的主干通信协议。原因很简单功耗低、手机兼容性好、协议成熟。BLE的广播态平均电流约10μA左右连接态电流也不到毫安级这在电池容量普遍只有几十到几百毫安时的可穿戴设备里是唯一能接受的实时通信方式。WiFi的功耗是BLE的几十倍LoRa和NB-IoT虽然低功耗但在室内场景的手机直连能力很差UWB则更适合定位场景而不适合日常数据传输。所以套件的主无线模块选型很明确nRF52840内置的BLE 5.0支持2Mbps的物理层速率实际有效吞吐量可以达到1.3Mbps左右传输传感器原始数据足够用了。4.2 核心功耗调优手段不是只有“关掉蓝牙”BLE低功耗的核心是占空比控制。nRF52840在BLE连接态下如果连接间隔设为100ms平均电流约5μA到10μA如果设为500ms平均电流降到2μA左右。但连接间隔拉大带来的副作用是数据延迟变大——你发一条消息到手机最坏情况要等一个连接间隔。所以调优时有几个关键参数要权衡连接间隔Connection Interval可穿戴通常设100ms到250ms既要保证续航又要保证交互实时性。从机延迟Slave Latency允许跳过若干次连接事件而不监听能显著省电适合传感器周期性上报的场景。广播间隔Advertising Interval广播是临时性的只在配对阶段开启平时直接关掉。真正做到极致低功耗光靠BLE配置是不够的还要配合系统的整体电源管理。这套固件里实现了一个“事件驱动 睡眠/唤醒”的电源模型MCU空闲时进入System ON睡眠模式电流降至1μA以下传感器数据就绪触发中断唤醒MCUMCU处理完数据再次进入睡眠。这个模型的平均电流主要由唤醒频率和每次唤醒的工作时间决定实测下来PPG心率监测场景采样率25Hz整机平均电流能做到约50μA配合100mAh电池理论续航可达2000小时以上。4.3 天线布局最容易被忽视的硬件坑天线是无线模块里最容易出问题的部分。可穿戴设备体积小天线周围往往就是电池、马达、金属外壳、人体组织全是信号杀手。PCB天线的频偏、馈点匹配、净空区大小都会直接影响信号强度。我在套件设计中留了两种天线方案首选是板载PCB天线成本低、一致性高原型阶段够用另一种是外置IPEX天线座当PCB天线在特定外壳下效果不理想时可以外接FPC天线。实测中遇到过一个典型问题PCB天线旁边就是电池电池表面是铝塑膜会严重吸收辐射能量导致蓝牙信号衰减10dB以上。解决办法是把天线净空区最大化并将电池尽量远离天线区域或者把天线布置在PCB边缘且下方掏空铜皮再配合外壳的塑料部分做辐射窗口。5. 结构设计与快速迭代3D打印配合模块化外壳可穿戴设备的“穿戴”属性决定了它必须考虑形态和佩戴体验。而硬件工程师往往最头痛的就是结构设计——画电路板是专业画外壳是另一门手艺。5.1 三种标准外壳覆盖大多数可穿戴形态这套套件配套设计了三种标准外壳模型手腕戴式手环、胸贴式贴片、头戴式头箍。每个外壳都留有标准模块的安装槽和M2螺丝孔位内部空间根据模块堆叠高度做了预留。原型阶段直接用3D打印打出来一套外壳从建模到打印只要几个小时成本十几块钱。这个设计的好处是在功能验证阶段就能真实地戴在身上跑数据而不只是放在桌面上看波形。真实佩戴带来的问题和桌面测试完全不同——运动伪迹、皮肤出汗导致电极接触阻抗变化、手腕活动导致PPG信号漂移这些只有戴在身上才能发现。5.2 软硬结合柔性FPC连接器的正确用法可穿戴设备的形态自由度很大程度上靠柔性连接来保证。这套套件里模块和模块之间的连接有两种方式刚性堆叠用邮票孔直连需要柔性布局时用FPC连接器加软排线。有几个使用FPC的经验FPC连接器选型认准“掀盖式”不要用“抽屉式”——后者在空间紧凑的设备里非常难插拔。FPC排线折叠时折叠半径要大于排线厚度的10倍折太小容易断线。走过电流的FPC线宽要加宽比如300mA的电流至少需要0.5mm线宽否则压降明显。5.3 原型到产品怎么把“积木”变成“单板”模块化套件解决了原型开发效率问题但产品化阶段一定不能继续用模块堆叠——模块间的连接器会增加厚度、重量和成本。所以套件从设计之初就预留了一条“收敛路径”固件按模块化架构组织硬件则可以在原型验证结束后把各个模块的电路原理图直接合并到一块主板上删除连接器优化布局走线。这个收敛过程一般需要一到两周。因为固件是分层设计的应用层代码完全不用改只需要更新BSP引脚映射。我做过一个实际案例一套用模块搭出来的睡眠监测贴片约8mm厚收敛到单板后厚度压到了4mm重量减少一半电池容量还增加了30%。产品形态的竞争力就是靠这一步拉开的。6. 云平台与数据链路设计从设备到手机再到云端可穿戴设备如果只做本地数据展示价值会大打折扣。完整的链路应该是传感器采集→设备端处理→BLE传输→手机App展示→云端汇聚分析。这套链路里设备端只是起点但设备端数据格式的设计决定了后端的开发效率。6.1 数据帧格式设计别在数据结构上埋雷BLE传输数据时一次最多传20字节传统ATT MTU或244字节通过MTU协商扩展。如果不做数据协议设计直接在App端解析裸数据后期数据格式一改App、算法、云端全得跟着改。我的建议是在一开始就定义一套自描述的数据帧格式帧头2字节 消息ID1字节 数据长度1字节 数据体可变 校验1字节。消息ID定义了数据的类型比如0x01代表心率数据、0x02代表IMU原始数据、0x03代表电池电量。这样设备端、App端、云端都按照同一套协议解析新增数据类型时只需要在协议层增加一个消息ID不用动整个链路。6.2 设备端数据缓存与断点续传可穿戴设备经常脱离手机工作比如用户去跑步没带手机或者蓝牙连接因距离过远断开。为保证数据不丢失设备端需要有一定容量的本地缓存。nRF52840内置了1MB Flash我划出256KB作为数据缓存区按“环形覆盖水位线”策略管理数据写到缓存区BLE恢复连接后优先上传历史数据全部上传完成后才继续实时传输。如果缓存区快满了会覆盖最老的数据保证最近的数据可用。同时在App端做同样的设计——App收到数据后先存本地SQLite数据库再异步上传云端。这样即使手机短暂无网络数据也不会丢。整个链路做到双端缓存用户体验会好很多。6.3 手机App端的蓝牙连接管理App端开发有一个容易踩的坑Android和iOS的BLE行为差异很大。Android的BLE扫描是批量回调扫描机制在不同厂商ROM上表现不一iOS的BLE连接需要先配对服务制定连接断开后系统会自动重连。如果套件配套App从零开始写工作量不小。我的做法是App端用现有的跨平台框架比如Flutter flutter_blue_plus插件设备端保持标准的GATT服务和特征值设计一个服务用于设备信息一个服务用于数据收发一个服务用于OTA升级。凡是涉及通信协议的部分全部做成平台无关的Dart抽象层这样Android和iOS共用一套逻辑开发效率翻倍。7. 常见问题与排查技巧实录在使用这套套件的半年多时间里我踩了不少坑也总结了一些可复用的排查经验。挑几个典型的分享出来。7.1 问题一BLE连接不稳定总是掉线现象设备运行几分钟到十几分钟后BLE连接自动断开App无法自动重连。排查过程首先用nRF Connect工具抓包看是设备端断的还是手机端断的。结果发现是设备端主动断开的。查看日志发现设备在闪存写入时出现了较长的阻塞导致BLE协议栈的定时事件如连接事件、看门狗喂狗被延迟执行最终触发协议栈的错误处理导致断连。根因Flash写入特别是擦除操作耗时可达几十到几百毫秒期间MCU被阻塞BLE协议栈没有及时处理连接事件。解决方案把Flash写入操作放到低优先级任务中或者使用Flash的缓存提交模式nRF52840支持通过UICR配置写缓存将写操作拆成多个小步骤穿插在BLE事件之间。更简单的做法是在写入前主动广播一个“暂停数据”信号App收到后不发送数据等写入完成再恢复。7.2 问题二PPG信号质量差心率检测不准现象设备佩戴在手腕上时心率数值跳动大与实际心率偏差明显。排查过程通过RAM日志拿到PPG原始波形数据用Python画出来看。发现波形整体幅值偏低且存在明显的周期性波动——这个周期性恰好和走路频率接近判断是运动伪迹干扰。根因佩戴太松传感器与皮肤之间存在微小的相对位移导致PPG信号受运动干扰较大。另外LED电流设置偏小信号基线太低信噪比不足。解决方案把LED电流从4mA提高到8mA同时更换了凸透镜式的光学窗口设计让光和皮肤贴合更紧密。在算法端加了一级自适应滤波利用IMU信号检测运动强度运动强度大时自动降低PPG数据的权重。实测把心率检测的准确率从87%提升到94%。这里有个经验PPG信号调试永远要看原始波形不要只看算法输出的心率值。心率值是算法处理后的结果掩盖了大量原始信号的问题。波形能告诉你问题出在光学设计、佩戴方式还是算法参数。7.3 问题三待机电流异常电池一天就没电现象设备不使用时放在桌上电池仍然消耗很快待机电流实测远高于规格书标称值。排查过程用功耗分析仪或者普通万用表低电流档测量各模块的电流。先把主控设为最小系统关掉所有外设电源测量基础电流然后逐个打开外设观察电流变化。最后发现是IMU的电源没有真正切断——MCU虽然在睡眠模式但IMU还在以正常采样率运行其工作电流约180μA虽然不算大但对于标称待机电流只有几μA的系统来说这就是致命的。根因IMU的电源控制引脚PWR_EN没有配置对外设电源芯片的控制软件上只关掉了IMU的中断没有真正切断其电源。解决方案在BSP层统一用GPIO控制所有外设的电源包括传感器、LED、屏幕、马达睡眠前统一切断外设电源。实测待机电流从180μA降到了5μA以下。7.4 快速排查表格把常见问题整理成一个速查表方便现场排查现象可能原因快速排查方法解决方向设备无法开机电池电压过低/保护万用表测电池电压检查充电状态充电激活更换电池BLE搜索不到设备天线匹配问题/广播未开启用频谱分析仪或近距离测试检查天线净空区确认广播配置心率数据跳动大佩戴松动/光学窗口脏污重新佩戴清洁窗口调整佩戴方式增大LED电流待机电流异常外设电源未切断逐个测量各电源轨电流检查BSP电源控制逻辑设备运行中重启电池瞬时压降过大用示波器抓电池电压波形换低内阻电池降低峰值电流数据上传不完整BLE缓冲区溢出/连接断开查看设备端缓存水位加大缓存优化断线重传逻辑7.5 套件维护与版本管理最后说一个容易被忽略但极其重要的事情套件本身的版本管理。硬件开发套件和软件一样需要版本管理但硬件不像软件那样方便做CI/CD。我在这套套件里建立了Git仓库不但管固件源码还把PCB设计文件原理图、Gerber、BOM清单、外壳STL模型、文档全部纳入版本管理每次改版打一个tag。这样任何时候都能回溯到之前某个版本的完整状态极大减少了“改坏了想回退却发现回不去”的痛苦。写在最后的几条经验这套可扩展可穿戴开发套件做下来我个人最深的几点体会第一模块化的价值不在“省引脚”而在“省决策”。每个模块的边界清晰了你自己做设计决策时就轻松了只需要想“这个形态需要哪些模块”不需要纠结“这个传感器和那个传感器共享引脚会不会冲突”。第二固件分层是最值得投入的工作一次分层做好后续十年都受益。哪怕硬件改版很多次只要固件架构不变你的开发效率就不会掉下来。第三也可以说最重要的一点所有的“可扩展性”都需要代价。连接器有电阻、有厚度、有成本模块化设计的系统永远比一体化设计的系统更大更重更贵。聪明的做法不是追求“永远模块化”而是用一个清晰的分层架构让你能快速地从模块化原型收敛到单板产品。这才是Scalable真正的含义——不是一直做积木而是有路可退。
