企业官网建设流程全解析

1. 需求拆解：眼疗设备到底需要一颗什么样的主控

1.1 眼疗设备的形态与功能边界

先把这个项目讲清楚。所谓眼疗可穿戴设备，市面上常见的主要是智能眼罩、护眼仪、VR理疗终端这几类形态。我们做的这款，定位是“可居家使用的智能眼疗眼罩”，主要功能有三条线：一是物理理疗，比如恒温热敷、仿生振动按摩；二是生物刺激，典型的是低强度脉冲微电流刺激眶周穴位，这个在视疲劳缓解产品里已经比较成熟；三是数据闭环，通过传感器记录使用时长、温度曲线、佩戴姿态，上报到手机App，方便用户追踪每天的护眼情况。

这颗主控要干的事，比我最初设想的要多得多。控制加热丝和振动马达只是基本功，真正麻烦的是微电流发生器的控制——它需要产生特定频率（通常是几百赫兹以内）的低压脉冲波形，频率和占空比都要精准，否则到了人体上要么没感觉、要么不舒服。再加上温度传感器、环境光传感器、六轴姿态传感器、电池电量计这些外围，模拟量采集通道就有五六个。所以这颗MCU必须要有足够多的定时器、ADC通道和DMA资源。

另外一个绕不开的约束是无线。产品一定要跟手机连接，用户需要查看历史记录、调整个性化模式、升级固件。传统做法是MCU加一颗独立蓝牙芯片，两颗芯片通信，不但增加成本，还要解决两根天线、两套供电的干扰问题。这也是我们最终决定选择STM32W系列无线MCU的直接原因——它把主控和2.4GHz射频收发器集成在了一颗芯片里，一个开发环境、一套调试工具、一颗物料，整机厂商的BOM和研发成本都能压下来。

1.2 为什么是STM32W系列，而不是nRF52或ESP32

这颗芯片的核心是意法半导体的STM32WBA52，Cortex-M33内核，最高主频100MHz，可以从容跑完我们的控制算法和无线协议栈。这一代M33内核带了TrustZone，这在医疗健康类产品里是个加分项——固件里有些用户隐私数据，比如设备ID和加密密钥，可以用TrustZone隔离出来，后续申请一些医疗认证时，安全这块的材料会好写很多。

为什么不用nRF52832？不是说它不好，而是从团队熟悉度的角度看，我们整个团队都是STM32出身，CubeMX生成工程、HAL库开发，大家闭着眼睛都能写。如果换成Nordic，虽然BLE协议栈做得确实成熟，但团队要重新学习一套SDK和开发模式，项目周期撑不住。至于ESP32，它的Wi-Fi能力在智能家居场景很香，可做穿戴产品的核心痛点其实是功耗。ESP32在蓝牙模式下的工作电流比STM32W系列高一个数量级，而且封装尺寸和外围电路也更复杂，放在眼罩这种紧贴面部的产品里，发热和体积都过不了关。

选型的时候还考虑过双核方案，就是ST自家的STM32WB系列，一个Cortex-M4跑应用，一个Cortex-M0+专门跑射频协议栈。后来对比了一下，WBA系列把安全性和Cortex-M33内核的优势发挥得更明显，而且单核方案在低功耗调试的时候少很多麻烦——双核要处理两个核的唤醒同步、信号量分配，代码复杂度明显更高。对于我们这种产品形态，WBA52已经足够，没必要为了多核特性去增加开发成本。

2. 硬件设计：把传感器、执行器和无线模块揉进一副眼罩

2.1 传感器选型：与眼睛打交道要选哪几路传感器

眼罩和眼睛之间是人体最敏感的区域之一，传感器选型的第一原则是“不能干扰用户”，第二原则是“数据要有实际用处”。我们在硬件上最终留下了四路关键的传感器输入。

第一路是温度传感器，用贴片式NTC热敏电阻，贴在加热片附近，用于热敷闭环控制。NTC精度不需要太高，1%就够了，关键是响应速度要快，因为眼罩加热片离皮肤很近，温度过冲会直接让用户觉得烫。热敏电阻用100kΩ的B值3950规格，配合10kΩ分压电阻，在25-45摄氏度这个区间内灵敏度最好。

第二路是六轴姿态传感器，用一颗低功耗的IMU，实时判断用户是躺着、坐着还是在前倾。为什么要这个数据？因为眼疗模式的参数应该随姿态调整——躺着的时候热敷时间可以长一些，坐着的时候振动强度要降低，避免因为身体姿势导致不适。IMU的数据还用来做佩戴检测：用户戴上眼罩的瞬间，加速度计的Y轴数据会有明显的角度跳变，用这个信号来自动启动设备，体验比按键开机自然得多。

第三路是环境光传感器，贴在眼罩内侧，判断是否完全遮光。这个数据有双重用途：一是确认佩戴正确，如果侧漏光严重就提醒用户调整绑带；二是夜灯模式下，根据环境亮度自动调节设备上指示灯的光强，避免熄灯后刺眼。

第四路是电极接触质量检测，这部分容易被人忽略。做微电流刺激功能时，电极和皮肤之间的接触阻抗直接决定电流是否有效作用于组织。如果接触不良，无论波形多准都是白搭，用户还容易产生刺痛感。我们在电极驱动输出端加了一个小信号采样电阻，通过ADC实时读电流值，换算成接触阻抗，一旦超出安全范围就自动切断输出，同时App端弹出提示。这个安全机制在生物刺激类产品里是底线。

2.2 执行链路设计：加热、振动和微电流的驱动方式

执行器这一块，三类负载的特性完全不同，驱动方式也要区别对待。

热敷加热片是纯阻性负载，额定功率大约2W，用一颗低压差MOS管做PWM开关控制就行。PWM频率选10kHz，既能避免加热片本身的机械噪声，又能让温度纹波足够小。控制算法用最常用的增量式PID就够了，温度目标值设为42摄氏度，上下0.5摄氏度的死区，实测可以稳定在正负0.3摄氏度以内。这里有两个细节需要注意：一是加热片的热惯性很大，PID积分项要设上限，否则温度超调会很严重；二是PWM的占空比要限制在5%到90%之间，过了这两个边界直接饱和处理，防止低占空比时MOS管工作在放大区发热。

振动按摩用的是偏心电机，就是手机里那种扁平振动马达，工作电流大概80mA。驱动用一颗简单的H桥芯片，可以控制正反转——正转是连续揉捏感，反转是脉冲敲击感，两种模式交替就有按摩节奏。控制上有个小技巧：不要直接用固定占空比供电，而是用PWM把电压逐步升上去，300ms内完成软启动，不然用户戴上的瞬间突然一震，体验非常差。

微电流刺激是这里面最精密的一路。我们用的是恒流源方案，目标电流范围0到2mA，步进0.1mA，输出波形是双相脉冲，脉宽200us，频率20Hz到150Hz可调。电路实现并不复杂——DAC输出参考电压，经过运放电压电流转换，输出端串联采样电阻闭环控制。DAC用的是MCU内部的12位DAC，输出精度足够。因为涉及到人体接触，这路输出做了两级隔离：第一级是模拟开关，主控不开信号时直接断开输出；第二级是mΩ级的限流电阻，即使MOS管击穿，流经人体的电流也被限制在安全范围内。

2.3 电源与电池管理：别让充电回路毁了整个产品

眼罩这种贴合佩戴的产品，电池只能选软包锂电池，容量做了350mAh——再大就太重了，戴在头上会有下坠感。正常使用模式下，每天两到三次、每次二十分钟，可以做到三天一充。

充电方案最初准备用一颗带路径管理的充电IC，后来评估了一下，眼罩这类产品并不需要在充电时工作，可以简化成“充电路径和放电路径完全隔离”的方式：充电时MCU检测到USB接入，直接关机进入充电模式，充完自动开机。这样一来充电管理只要一颗线性充电芯片加上一颗电量计就够了。

但这里有个容易忽略的坑：电池直接给电机供电的时候，启动瞬间会把电池电压拉低200mV以上，MCU的ADC基准源不是独立的，所以每次振动马达启动，温度采集值会跳一下。后来我们在ADC基准引脚上加了一颗大容量电容，再把振动启动时间拉长到软启动的300ms，这个问题才算压下去。所以做多负载系统时，电源轨的隔离和基准源的滤波要从一开始就考虑，等画完板子再补就很被动。

3. 软件架构与无线通信实现

3.1 开发环境与工程组织

软件部分，我建议用STM32CubeMX生成底层初始化代码，应用层自己组织目录结构，不要直接在生成的main.c里堆功能，否则后面加功能、换硬件平台都痛苦。工程分成三个模块：

• 驱动层：外设初始化、传感器读取、PWM控制、ADC采集、Flash读写这类直接操作寄存器的代码，全部封装成接口，不跟业务逻辑混在一起。
• 服务层：温度PID控制、按摩波形生成、微电流波形调度、电量监测这些相对独立的功能模块。
• 应用层：状态机、命令解析、无线数据处理、App交互逻辑。

整个系统跑不跑RTOS？这里有一个可以分享的经验。最开始我为了省事，直接用裸机while循环加定时器中断，结果功能一多，逻辑就乱成一锅粥——加热控制要实时、无线数据要快速响应、传感器采集又要定时执行，在同一个循环里处理这些任务非常别扭。后来切到了FreeRTOS，用几个任务各干各的：

• 控制任务：2ms周期，处理PID控制和波形生成，这个任务优先级最高，是硬实时的。
• 采集任务：20ms周期，读取传感器数据、更新温度曲线、做姿态解算。
• 无线任务：由蓝牙协议栈的回调触发，处理接收到的命令和上报数据。
• 显示任务：500ms周期，刷新LED状态、处理按键事件。

任务划分好之后，整个软件的复杂度立刻降下来了，每个任务的文件都不超500行，改起来心里有底。有人担心FreeRTOS的调度开销，实际上在100MHz的M33上，2ms周期的任务调度开销完全可以忽略，整体CPU占用率只有不到30%。

3.2 无线协议栈与配网连接设计

STM32WBA的2.4GHz射频部分是ST自己封装好的协议栈，应用层直接调用接口就行。CubeMX里勾选BLE功能，协议栈的配置界面会生成一堆参数，比如连接间隔、从机延迟、广播间隔。这些参数直接决定连接功耗和响应速度，我做一个表格给大家参考：

连接策略上做了一件事：眼罩上电后不马上进入可连接广播状态，而是先进入不可连接广播，同时开启扫描，等待手机发来“连接请求”。这个流程的好处是避免多台设备同时开机时互相误连——同一间办公室里有好几台样机调试，大家各自用手机都能精准连上自己的那台。

GATT服务结构按功能拆成了三个Service：设备信息服务（设备名、固件版本、电量）、控制服务（加热开关、模式切换、参数设置）、数据服务（温度记录、使用时长、姿态事件）。其中控制服务用Write命令接收控制指令，数据服务用Notify主动上报事件，比如“热敷完成”“电极接触不良”这类实时提示，走Notify通道，手机端不用轮询等待。

3.3 传感器采集与数据处理：从裸数据到可用数据

ADC采集这一块，网上问“stm32 adc多通道扫描循环采样dma”的人很多，我在这个项目里用的就是这套方案的升级版。关键是三个要点：

第一，多通道扫描模式下，ADC要配置成“扫描连续模式+外部触发”，用定时器触发ADC启动，每到一个采样点就自动把多路通道轮流采一遍。千万不要用软件里循环切换通道的方式，那样每一路的采样间隔不均匀，振动马达带来的电源噪声会随机落进某一路的数据里，产生很难排查的毛刺。

第二，DMA用循环模式直接把所有通道的采样结果搬进内存数组，每个通道在数组里占连续的一段空间。这样CPU完全不用参与采集过程，等到DMA传输半满或者全满中断时，再去数组里取数据做平均滤波。我们每一路用16次采样取平均，等效采样率50Hz，温度数据平滑度已经足够好。

第三，采样时间要配合负载的开关周期。如果热敷加热片在PWM周期里频繁通断，ADC采样时刻恰好落在开通瞬间，采到的就是带着开关噪声的值。我们的做法是让ADC触发信号只在PWM关闭的时间窗口内启动，也就是和PWM信号反相，精准错开干扰源。这个方法比在软件里加数字滤波管用得多。

IMU数据读取走的是SPI接口，速率设到1MHz就够了，因为六轴数据量不大。姿态解算没有用复杂的卡尔曼滤波，而是用一个互补滤波：加速度计数据通过低通滤波取长期趋势，陀螺仪数据通过高通滤波取短时变化，两者加权重构角度。在眼罩这种只需要粗略判断头姿、不需要精确姿态角的应用里，这个方法实现简单、计算量小，效果完全够用。

4. 低功耗设计：可穿戴设备的续命关键

4.1 功耗预算表：每个毫安都要有清楚去向

可穿戴设备的续航是用户体验的核心指标，350mAh的电池要撑够三天，平均功耗必须控制在5mA以下。我先做一个粗略的功耗预算表，再逐项落实：

这个表算下来约6.2mAh/天，实际上振动按摩和微电流刺激的耗电比加热要小，所以实测更接近5mAh/天，三天一充是足够的。

要特别强调一点：深度睡眠电流是整个续航的大头，但也是最容易出问题的地方。芯片手册上写的是10uA，这是纯MCU睡眠功耗，不包括外围电路的漏电。眼罩上如果有一颗传感器在睡眠时还持续供电，20uA的待机电流就流失了，直接把续航拉掉三分之一。所以我们在做睡眠模式时，所有传感器、执行器、充电管理芯片的供电都接了独立的MOS管开关，睡眠时一律断电，只保留MCU和RTC的供电。

4.2 停止模式与唤醒设计

STM32WBA52进入深度睡眠用的是STOP2模式，RAM数据保留、大部分外设时钟关闭，通过RTC定时事件或蓝牙唤醒事件退出睡眠。这里有一个要点：不要用按键这种外部中断直接唤醒MCU进正常模式，因为用户在睡眠时误触按键会导致设备意外开机，白白耗电。

我们的设计分了两级唤醒：第一级是RTC定时唤醒，每秒钟醒来一次，检查是否有蓝牙事件或者传感器触发；第二级才是用户操作引起的完整唤醒。眼罩戴上时通过IMU的加速度数据检测到佩戴动作，先唤醒采集任务，确认是真实佩戴后，再唤醒整个系统，进入工作模式。整个唤醒链路由硬件中断加软件确认组成，误唤醒的概率非常低。

BLE的连接管理也要配合低功耗：连接建立后，如果设备在非工作状态，就把连接间隔拉长到500ms，同时开启从机延迟。这样MCU大部分时间都在睡眠，只有连接事件到来时醒一下，无线待机电流能控制在30uA左右。实测下来，把BLE连接保持一晚上，耗电量比断开连接再重新连要省得多，因为重连过程的广播功耗非常高。

4.3 实测数据与调优过程

做完第一版样机，实测待机电流是45uA，比预算高了35uA。拿热成像仪和万用表查了一下，罪魁祸首是PMIC的I2C总线适配器在睡眠时挂着一路偏置电流。这个问题花了两天时间才排查出来——它不是MCU的锅，而是外围上拉电阻的漏电。

排查过程也挺有借鉴意义的：用示波器勾I2C的SCL线，发现睡眠时一直有1.65V的低电平，导致CMOS输入级的漏电流很大。解决方法是把I2C总线上拉电阻改成主控GPIO内部上拉，睡眠前把GPIO配置成模拟输入模式，彻底断开漏电路径。这样一调，待机电流从45uA降到了12uA，已经很接近芯片理论值。

再分享一个调功耗的心得：不要一上来就抱着示波器测电流曲线，先用功耗分析仪测一整夜的电流波形，把高亮时间段对应到工作状态，优先处理持续时间长、电流基数大的问题。像1ms的尖峰电流和50ms的背景电流，后者影响大得多，先解决背景电流，尖峰电流往往通过软件延迟就能躲开。

5. 常见问题与排查技巧实录

5.1 串口调试与日志系统

做无线可穿戴产品，最大的调试痛点是没有显示设备。我们的方案很土但很有效：把UART调试日志通过BLE Notify通道转发到手机端的调试助手，相当于一个“无线串口”。

这里遇到一个经典问题：日志打印速度太快，把蓝牙通道带宽占满了，导致控制指令发不出去。因为BLE一个连接事件只能发3个20字节的包，最高不超过300B/s，而我们日志输出动不动就几十KB/s。解决方法是给日志加优先级——普通日志只在采集任务里积攒，每500ms打包发送一次，只有错误和警告级别的日志才立即发送。这样既保证了问题定位的实时性，又不会影响控制指令的通信。

5.2 ADC采样数据漂移的排查

网上关于“stm32 adc多通道扫描循环采样dma”的帖子很多，但很少有人提到参考电压对ADC精度的影响。我们碰到的一个现象是：振动马达转起来的时候，温度读数突然升高了5摄氏度，停转后又恢复正常。不是热传导，而是马达启动瞬间拉低了VDDA，ADC基准电压跟着抖动，导致采样值偏大。

解决思路分两层：硬件上在VDDA引脚用一个10uF钽电容加一个0.1uF陶瓷电容并联，把电源阻抗降下来；软件上把ADC采样点错开到马达启动完成之后，也就是马达启动后延时50ms再启动DMA传输。这两招加起来，温度波动从5摄氏度压到了0.3摄氏度。

5.3 无线连接不稳定的几个隐藏因素

BLE连接不稳定是最难排查的，因为它经常是间歇性复现。我们遇到过三个典型的坑：

第一个是天线周围的地平面被破坏了。眼罩的PCB面积小，天线净空区放了一个固定螺丝，螺丝是金属导电的，直接改变了天线的谐振频率，导致发射功率下降。排查方法是用频谱仪看天线的S11参数，明显看到谐振点偏移了接近200MHz。后来把螺丝位置挪走，S11恢复到了-15dB以下，连接稳定性大幅改善。

第二个是电池电压低于3.3V时，射频输出功率会下降，在信号弱的环境里就容易断开。这个问题最后通过软件控制解决：电池电量低于15%时，自动关闭蓝牙广播，只保留连接保持。优先保证设备的核心功能（热敷和按摩），无线功能退居其次。

第三个是2.4GHz频段在办公环境里的干扰非常严重，微波炉一开会把整个频段都污染掉。所以蓝牙跳频算法要启用，连接参数也要设短一点的重传超时，这些在CubeMX里都有配置项，最容易被遗漏。

5.4 每个固件工程师都会碰到的Flash存储问题

眼罩需要保存用户的模式偏好、校准参数、使用记录，这些数据量不大，用片内Flash模拟EEPROM就够。这里有一个常见的坑：ST的Flash写入前必须擦除扇区，而扇区大小通常是以8KB为单位的，频繁擦写会加速Flash磨损，同时擦除过程中发生掉电会导致整块数据丢失。

解决思路是做一个简单的磨损均衡层：定义两个逻辑扇区，轮流写，每次写入前先检查当前扇区的剩余空间，写满就切换到另一个扇区。每个扇区的头4字节存一个序号，用来判断哪边是最新数据。这套方案在512KB Flash上可以跑十年以上，可靠性和稳定性都很不错。

写Flash的时候还有一个极其容易踩的坑：HAL库自带的HAL_FLASH_Program函数在擦除期间会占住CPU，如果此时蓝牙中断到来，整个系统就会卡死在Flash操作里。网上搜“stm32延时函数delay卡死”相关的帖子，很多都是这个原因导致的。我们的做法是先把要写的数据缓存到RAM，然后关中断执行Flash写入，整个过程控制在几十毫秒内，写完再恢复中断。这个细节直接影响产品在固件升级过程中的稳定性。

最后再分享一点实践经验

整个项目做下来，我最满意的不是某个技术点的攻关，而是整个系统方案的平衡感。眼疗可穿戴设备的技术难点不在某一个环节，而在于把温度控制、精密刺激、无线通信、低功耗设计这四件事同时做对，任何一个环节掉链子，用户体验都会打折扣。

如果大家也在做类似的可穿戴产品，我非常建议在一开始就做一次完整的技术评审，把功耗预算、无线协议、传感器布局全部画在纸上，而不是急着画板子调代码。因为可穿戴设备的小体积、低功耗、高集成度特性决定了硬件改版成本极高，一次评审省下来的时间和经费，比什么都值。

特别是主控选型这件事，STM32WBA52这颗芯片给我们省的麻烦远比它本身的价值要大。一颗芯片解决了主控和无线两件事，意味着你只需要维护一个工程、一套工具链、一份BOM，对于资源紧张的创业团队来说，这个价值怎么强调都不过分。