可穿戴硬件创业最近出现了一条消息一位曾在前 META、XREAL 等公司做过产品线负责人的人创业做可穿戴硬件拿到了美国顶级 VC 的千万美金级别种子轮融资。对多数工程师来说这条新闻里的金额、机构和创始人背景都不是可复制的经验。真正值得拆解的是另一个问题一个人带着几个工程师怎样把一个可穿戴硬件项目从概念推进到原型再从原型推进到可以量产的阶段。可穿戴硬件和纯软件项目的区别在于物理世界的问题无法靠发版快速修复。外壳是否贴合、射频是否达标、电池是否够用、传感器在人体上是否准确、充电逻辑是否安全都要在真实样机和测试环节中验证。这个赛道到最后拼的不是创意而是工程系统的完整度从需求冻结、器件选型、固件架构、结构打样到测试认证和供应链爬坡任何一个环节断裂产品都会停在原型阶段。下面的内容不是融资评论而是一条面向研发团队的工程主线。适合三类人阅读想进入可穿戴领域的嵌入式工程师、准备做硬件创业的小型技术团队以及需要和硬件团队协作的 App 或算法工程师。文中的芯片型号、参数和代码只用于说明方法实际项目必须以真实芯片手册和最新 SDK 为准。1. 先把“可穿戴硬件创业”翻译成一组工程问题1.1 融资新闻背后的行业信号种子轮真正考验的是工程化先不急着评价这轮融资本身。种子轮项目通常还处在“验证产品方向和技术可行性”的阶段团队背景带来的优势是需求判断和行业资源但硬件量产能力并不会因为创始人来自大厂而自动具备。可穿戴硬件从图纸到用户手里通常要经过十几个月甚至更长的周期涉及电子设计、嵌入式软件、结构设计、射频调试、可靠性测试、合规认证、产线良率等多个专业。对研发团队来说融资消息带来的真实变化往往是团队人数从三个人扩到十个人而技术短板不会因为账上有钱自动补齐。那些能在原型阶段跑通的功能如果一开始没有按照量产约束来设计到试产阶段才暴露改版成本就会被放大几十倍。1.2 产品形态决定技术路线而不是反过来可穿戴硬件不是一个统一品类。手环、手表、智能眼镜、医疗级贴片虽然都叫可穿戴设备但主控平台、操作系统、功耗策略和供应链要求完全不同。立项时如果只说“我们要做一个智能可穿戴设备”后面所有选型都无法收敛。产品形态主控复杂度常见运行环境主要工程难点轻量手环/贴片Cortex-M 类 MCU裸机或 RTOS续航、传感器精度、佩戴舒适度手表类设备MCU 或应用处理器RTOS / 轻量 OSUI 交互、内存占用、发热与续航智能眼镜/XR 设备应用处理器加协处理器Android / Linux光学、散热、重量分配、显示功耗医疗级贴片/监测设备混合式 MCURTOS 加信号处理链实时性、数据可靠、认证周期长这张表只是示意。相同形态下是否带屏幕、是否需要摄像头、是否连续采集生物信号都会把技术路线拉到完全不同的方向。硬件选型的首要原则是先定“产品在什么场景下解决什么问题”再定“需要哪些外设和算力”最后才是“选哪颗芯片”。1.3 立项时必须先冻结的七类需求硬件项目最怕边做边改需求。改软件可能只是重新编译改硬件却意味着重新开板、重新测试、重新验证。所以正式原理图设计之前研发负责人至少要组织一次需求冻结评审把下面这些问题定下来。要回答的问题直接影响的技术决策一次充电或换电池能用多久电池容量、充电方案、整体功耗预算需要监测或采集哪些信号传感器类型、接口数量、MCU 算力是否需要屏幕、马达、扬声器功耗、主控型号、结构空间是否需要跟 Android/iOS App 联动无线协议、GATT 服务设计、数据格式目标出货量是多少PCBA 工艺、模具投入、器件选型等级要进入哪些国家和地区的市场认证周期、法规要求、频段支持可接受的目标单价范围BOM 成本、结构材质、测试方案上限这七类问题必须在芯片选型前达成一致。现实中最常见的翻车方式是先选了一颗功能很强但功耗很高的主控然后发现续航指标无法满足或者先定了佩戴形态之后发现留给天线的净空区和电池位置根本不够。需求冻结不是把所有事情都定死而是把决定技术路线的变量收敛到可控范围内。2. 硬件原型阶段主控、传感器、电源与连接怎么选2.1 主控平台MCU、应用 SoC 与专用平台的选择逻辑主控选型看的不只是主频更关键的是外设数量、低功耗模式、内存和可用 SDK。可穿戴设备的主控大致可以按运行平台分成几类。平台级别常见示例功耗与启动适用场景MCU RTOS/裸机nRF52/nRF54、STM32U5、EFR32微安级睡眠、毫秒级启动传感器采集、BLE 传输、简单逻辑应用处理器 Linux/Android手机端 SoC 或智能穿戴专用 SoC功耗较高、启动时间较长需要屏幕、摄像头、复杂 UI 的场景可穿戴专用 SoCTWS 耳机 SoC、低功耗手表 SoC集成度高、功耗经过专门优化音频、手表、融合处理器如果产品只需要采集加速度、心率再通过 BLE 把数据发给手机主流的 Cortex-M 级 MCU 就足够。选择它是因为睡眠功耗低、启动快、电池焦虑小。如果产品需要本地语音识别、视频拍摄或复杂界面MCU 跑不动这时才需要引入应用处理器同时接受功耗和散热带来的额外设计负担。这里最容易犯的错误是“先跑 Demo再定型”。很多低功耗 MCU 的开发板跑起来很流畅但进入量产时必须重新设计最小系统、电源树和天线区域。开发板和量产板之间的差距会在射频和功耗测试中被无限放大。2.2 传感器选型看得见的参数和看不见的坑可穿戴设备常用传感器包括 IMU惯性测量单元、PPG光电容积脉搏波、温度传感器、气压计、电极式生物电传感器等。传感器选型时不能只看量程和分辨率还要关注工作电流、数据就绪中断、FIFO 深度、抗干扰能力和校准复杂度。传感器类型常见用途选型关注点常见坑IMU步数、姿态、手势噪声密度、量程、零偏稳定性不校准就上产线静态漂移明显PPG心率、血氧发光二极管和光电二极管功率、环境光抑制佩戴松紧、肤色、运动都会干扰温度传感器皮肤或环境温度精度、热响应时间外壳导热影响读数气压计海拔、楼层精度、采样率气流孔被胶水堵住在嵌入式软件架构上传感器数据最好通过中断或 DMA 读取不要让 CPU 轮询等待。很多传感器的内部 FIFO 可以把多次采样缓存起来MCU 在数据积压到阈值后才被唤醒一次。合理利用 FIFO 是省电的关键。2.3 电源与功耗预算续航不是算出来的是设计出来的续航指标必须拆成功耗预算来回估算。常见做法是列出设备所有运行状态深度睡眠、传感器采样、BLE 连接、数据处理、充电状态然后给每个状态估算电流和占比。下面是一张用于说明方法的示意表。运行状态参考电流占用比例平均贡献RTC 唤醒的深度睡眠50 µA90%45 µA传感器一次采样4 mA1%40 µABLE 连接事件6 mA0.5%30 µAMCU 数据处理10 mA0.3%30 µA把各状态平均贡献相加得到约 145 µA。如果电池容量是 250 mAh放电深度按 85% 算可用容量是 212.5 mAh理论续航约为 212.5 / 0.145 1465 小时约合 61 天。这个数字仍然只是理想值电池自放电、温度、变压器漏电都会让实际数据偏低。但功耗预算的价值在于在画原理图之前就能判断方案是否靠谱而不是等到样机做出来之后才发现一天一充。电源部分还要考虑充电管理、电量计、电池保护板、过流保护和温度保护。可穿戴设备贴近皮肤锂电池的充电截止电压、充电温度和放电截止保护都要比普通消费电子更谨慎。原型阶段用固定电源可以量产阶段建议加入真正的电量计不要只靠电压估算电量。2.4 无线连接BLE 是默认选项但不是唯一答案可穿戴设备最常见的无线连接协议是 BLE原因在于低功耗、手机生态支持好、协议栈成熟。但 BLE 也有吞吐量限制不适合持续传输高码率数据。如果产品需要周期性传输大量数据可能要评估 WiFi 或其它方式但代价是功耗显著上升。连接方案优势代价典型场景BLE功耗低、手机兼容性好吞吐量有限、单次连接距离短手环、戒指、贴片WiFi吞吐量高、与路由器直连功耗高、需要入网配置室内固定监测私有 2.4G 协议延迟和协议可控手机无法直连需要网关多设备组网场景从长期维护角度看能不引入私有协议就不引入。BLE 的标准 GATT 结构已经能覆盖传感器上报、控制指令和固件升级手机端生态也成熟。只有当产品确实需要组网、低延迟或者极低功耗时才评估私有方案。注意选型阶段就要为主控的射频部分留出天线净空区并提前联系天线供应商。结构设计完成后才发现天线被金属件包围是原型转量产阶段最难解决的问题之一。3. 固件与数据链路从传感器到手机 App 的最简闭环3.1 固件分层与低功耗调度可穿戴设备固件通常按三层组织驱动与 SDK 层负责芯片外设、BLE 协议栈、传感器驱动。中间层负责电源状态管理、存储服务、数据上报协议、升级模块。应用层负责业务状态机判断何时采样、何时上报、何时进入睡眠。低功耗设计的核心不是把频率调低而是让系统在绝大多数时间处于睡眠状态只在需要处理的事件到来时醒来。所以固件应尽量采用事件驱动架构而不是轮询。每个传感器都启用数据就绪中断BLE 连接事件交给协议栈管理MCU 在忙完一件事之后立刻评估是否可以进入睡眠。下面这段代码展示的是“周期性读取数据并通过 BLE Notify 上报”的结构思路。真实工程要按你使用的 RTOS 和 SDK 版本调整 API不能直接拿来做量产编译。/* 说明性代码Zephyr 风格。 * 实际使用时函数签名、宏定义应参考当前 SDK 头文件。 */ #include zephyr/kernel.h #include zephyr/bluetooth/bluetooth.h #include zephyr/bluetooth/gatt.h #include zephyr/bluetooth/uuid.h static bool notifying; static void ccc_changed_cb(const struct bt_gatt_attr *attr, uint16_t value) { notifying (value BT_GATT_CCC_NOTIFY); } BT_GATT_SERVICE_DEFINE(sample_svc, BT_GATT_PRIMARY_SERVICE(BT_UUID_DECLARE_16(0xFF01)), BT_GATT_CHARACTERISTIC(BT_UUID_DECLARE_16(0xFF02), BT_GATT_CHRC_NOTIFY, BT_GATT_PERM_READ, NULL, NULL, NULL), BT_GATT_CCC(ccc_changed_cb, BT_GATT_PERM_READ | BT_GATT_PERM_WRITE), ); static void notify_worker(void *arg1, void *arg2, void *arg3) { uint8_t seq 0; while (1) { k_sleep(K_SECONDS(1)); if (!notifying) { continue; } /* 实际项目中在这个位置读取传感器值 */ uint8_t sample[4] { 0xAA, seq, 0x00, 0x00 }; seq; bt_gatt_notify(NULL, sample_svc.attrs[1], sample, sizeof(sample)); } } K_THREAD_DEFINE(notify_tid, 1024, notify_worker, NULL, NULL, NULL, 7, 0, 0); int main(void) { int err bt_enable(NULL); if (err) { return err; } /* 启动可连接广播参数根据 Zephyr 版本补齐 */ return 0; }这段代码要说明的关键点是BLE 的 Notify 机制需要手机端先订阅设备端通过 CCC 回调感知订阅状态。在手机没有订阅时持续调用bt_gatt_notify没有意义还会白耗电。线程用k_sleep控制周期实际产品会把这个周期改成由传感器中断或定时器驱动避免固定轮询。3.2 设备与 App 之间的协议设计设备端和手机端的通信协议决定了后续开发和排障复杂度。BLE 传输本身适合小包数据不建议在 BLE 通道上直接跑 JSON 文本。很多团队为了快速上线使用 JSON当设备量增长后才发现解析开销、包长和功耗都不合适。协议设计建议采用紧凑二进制格式并包含版本号、序号和校验字段。以一条传感器上报报文为例可以用下面的结构表示。字段长度含义包头1 字节固定魔数如 0xAA版本号1 字节协议版本用于兼容消息类型1 字节数据、控制、应答、错误序号1 字节防止丢包后无法对齐采样值N 字节按字节序排列的有效载荷CRC2 字节对整包做校验对应的示例结构体可以是#include stdint.h #define WEARABLE_HEAD_MAGIC 0xAA #define WEARABLE_MSG_SAMPLE 0x01 typedef struct __attribute__((packed)) { uint8_t head; uint8_t version; uint8_t msg_type; uint8_t seq; int16_t accel_x; int16_t accel_y; int16_t accel_z; uint16_t battery_mv; uint16_t crc16; } wearable_sample_report_t;报文里的head用来快速识别协议流version用来兼容未来扩展crc16校验保证传输过程中数据没有被破坏。App 端解析时看到包头不匹配或 CRC 错误应当直接丢弃而不是强行按格式解出脏数据。3.3 OTA 升级和本地日志不能放到量产后再补可穿戴设备出货后无法像手机 App 一样频繁修复问题OTA 能力必须早期规划。常见做法是 Flash 分区里保留两个固件区当前运行区和新固件写入区。升级过程中先把新固件写入备用区校验通过后切换启动标志重启后从新区启动启动失败时回滚到旧区。本地日志同样重要。样机阶段可以通过串口打印日志量产设备没有串口需要把关键日志写入 Flash 缓冲区再通过调试命令或特殊 BLE 通道导出。至少要记录启动原因、上次复位原因、传感器初始化失败码、OTA 版本号、充电异常状态。没有这些数据售后阶段排查问题只能靠猜测。4. 从原型机到量产结构打样、DFM 与试产节奏4.1 原型机与量产
可穿戴硬件创业最近出现了一条消息一位曾在前 META、XREAL 等公司做过产品线负责人的人创业做可穿戴硬件拿到了美国顶级 VC 的千万美金级别种子轮融资。对多数工程师来说这条新闻里的金额、机构和创始人背景都不是可复制的经验。真正值得拆解的是另一个问题一个人带着几个工程师怎样把一个可穿戴硬件项目从概念推进到原型再从原型推进到可以量产的阶段。可穿戴硬件和纯软件项目的区别在于物理世界的问题无法靠发版快速修复。外壳是否贴合、射频是否达标、电池是否够用、传感器在人体上是否准确、充电逻辑是否安全都要在真实样机和测试环节中验证。这个赛道到最后拼的不是创意而是工程系统的完整度从需求冻结、器件选型、固件架构、结构打样到测试认证和供应链爬坡任何一个环节断裂产品都会停在原型阶段。下面的内容不是融资评论而是一条面向研发团队的工程主线。适合三类人阅读想进入可穿戴领域的嵌入式工程师、准备做硬件创业的小型技术团队以及需要和硬件团队协作的 App 或算法工程师。文中的芯片型号、参数和代码只用于说明方法实际项目必须以真实芯片手册和最新 SDK 为准。1. 先把“可穿戴硬件创业”翻译成一组工程问题1.1 融资新闻背后的行业信号种子轮真正考验的是工程化先不急着评价这轮融资本身。种子轮项目通常还处在“验证产品方向和技术可行性”的阶段团队背景带来的优势是需求判断和行业资源但硬件量产能力并不会因为创始人来自大厂而自动具备。可穿戴硬件从图纸到用户手里通常要经过十几个月甚至更长的周期涉及电子设计、嵌入式软件、结构设计、射频调试、可靠性测试、合规认证、产线良率等多个专业。对研发团队来说融资消息带来的真实变化往往是团队人数从三个人扩到十个人而技术短板不会因为账上有钱自动补齐。那些能在原型阶段跑通的功能如果一开始没有按照量产约束来设计到试产阶段才暴露改版成本就会被放大几十倍。1.2 产品形态决定技术路线而不是反过来可穿戴硬件不是一个统一品类。手环、手表、智能眼镜、医疗级贴片虽然都叫可穿戴设备但主控平台、操作系统、功耗策略和供应链要求完全不同。立项时如果只说“我们要做一个智能可穿戴设备”后面所有选型都无法收敛。产品形态主控复杂度常见运行环境主要工程难点轻量手环/贴片Cortex-M 类 MCU裸机或 RTOS续航、传感器精度、佩戴舒适度手表类设备MCU 或应用处理器RTOS / 轻量 OSUI 交互、内存占用、发热与续航智能眼镜/XR 设备应用处理器加协处理器Android / Linux光学、散热、重量分配、显示功耗医疗级贴片/监测设备混合式 MCURTOS 加信号处理链实时性、数据可靠、认证周期长这张表只是示意。相同形态下是否带屏幕、是否需要摄像头、是否连续采集生物信号都会把技术路线拉到完全不同的方向。硬件选型的首要原则是先定“产品在什么场景下解决什么问题”再定“需要哪些外设和算力”最后才是“选哪颗芯片”。1.3 立项时必须先冻结的七类需求硬件项目最怕边做边改需求。改软件可能只是重新编译改硬件却意味着重新开板、重新测试、重新验证。所以正式原理图设计之前研发负责人至少要组织一次需求冻结评审把下面这些问题定下来。要回答的问题直接影响的技术决策一次充电或换电池能用多久电池容量、充电方案、整体功耗预算需要监测或采集哪些信号传感器类型、接口数量、MCU 算力是否需要屏幕、马达、扬声器功耗、主控型号、结构空间是否需要跟 Android/iOS App 联动无线协议、GATT 服务设计、数据格式目标出货量是多少PCBA 工艺、模具投入、器件选型等级要进入哪些国家和地区的市场认证周期、法规要求、频段支持可接受的目标单价范围BOM 成本、结构材质、测试方案上限这七类问题必须在芯片选型前达成一致。现实中最常见的翻车方式是先选了一颗功能很强但功耗很高的主控然后发现续航指标无法满足或者先定了佩戴形态之后发现留给天线的净空区和电池位置根本不够。需求冻结不是把所有事情都定死而是把决定技术路线的变量收敛到可控范围内。2. 硬件原型阶段主控、传感器、电源与连接怎么选2.1 主控平台MCU、应用 SoC 与专用平台的选择逻辑主控选型看的不只是主频更关键的是外设数量、低功耗模式、内存和可用 SDK。可穿戴设备的主控大致可以按运行平台分成几类。平台级别常见示例功耗与启动适用场景MCU RTOS/裸机nRF52/nRF54、STM32U5、EFR32微安级睡眠、毫秒级启动传感器采集、BLE 传输、简单逻辑应用处理器 Linux/Android手机端 SoC 或智能穿戴专用 SoC功耗较高、启动时间较长需要屏幕、摄像头、复杂 UI 的场景可穿戴专用 SoCTWS 耳机 SoC、低功耗手表 SoC集成度高、功耗经过专门优化音频、手表、融合处理器如果产品只需要采集加速度、心率再通过 BLE 把数据发给手机主流的 Cortex-M 级 MCU 就足够。选择它是因为睡眠功耗低、启动快、电池焦虑小。如果产品需要本地语音识别、视频拍摄或复杂界面MCU 跑不动这时才需要引入应用处理器同时接受功耗和散热带来的额外设计负担。这里最容易犯的错误是“先跑 Demo再定型”。很多低功耗 MCU 的开发板跑起来很流畅但进入量产时必须重新设计最小系统、电源树和天线区域。开发板和量产板之间的差距会在射频和功耗测试中被无限放大。2.2 传感器选型看得见的参数和看不见的坑可穿戴设备常用传感器包括 IMU惯性测量单元、PPG光电容积脉搏波、温度传感器、气压计、电极式生物电传感器等。传感器选型时不能只看量程和分辨率还要关注工作电流、数据就绪中断、FIFO 深度、抗干扰能力和校准复杂度。传感器类型常见用途选型关注点常见坑IMU步数、姿态、手势噪声密度、量程、零偏稳定性不校准就上产线静态漂移明显PPG心率、血氧发光二极管和光电二极管功率、环境光抑制佩戴松紧、肤色、运动都会干扰温度传感器皮肤或环境温度精度、热响应时间外壳导热影响读数气压计海拔、楼层精度、采样率气流孔被胶水堵住在嵌入式软件架构上传感器数据最好通过中断或 DMA 读取不要让 CPU 轮询等待。很多传感器的内部 FIFO 可以把多次采样缓存起来MCU 在数据积压到阈值后才被唤醒一次。合理利用 FIFO 是省电的关键。2.3 电源与功耗预算续航不是算出来的是设计出来的续航指标必须拆成功耗预算来回估算。常见做法是列出设备所有运行状态深度睡眠、传感器采样、BLE 连接、数据处理、充电状态然后给每个状态估算电流和占比。下面是一张用于说明方法的示意表。运行状态参考电流占用比例平均贡献RTC 唤醒的深度睡眠50 µA90%45 µA传感器一次采样4 mA1%40 µABLE 连接事件6 mA0.5%30 µAMCU 数据处理10 mA0.3%30 µA把各状态平均贡献相加得到约 145 µA。如果电池容量是 250 mAh放电深度按 85% 算可用容量是 212.5 mAh理论续航约为 212.5 / 0.145 1465 小时约合 61 天。这个数字仍然只是理想值电池自放电、温度、变压器漏电都会让实际数据偏低。但功耗预算的价值在于在画原理图之前就能判断方案是否靠谱而不是等到样机做出来之后才发现一天一充。电源部分还要考虑充电管理、电量计、电池保护板、过流保护和温度保护。可穿戴设备贴近皮肤锂电池的充电截止电压、充电温度和放电截止保护都要比普通消费电子更谨慎。原型阶段用固定电源可以量产阶段建议加入真正的电量计不要只靠电压估算电量。2.4 无线连接BLE 是默认选项但不是唯一答案可穿戴设备最常见的无线连接协议是 BLE原因在于低功耗、手机生态支持好、协议栈成熟。但 BLE 也有吞吐量限制不适合持续传输高码率数据。如果产品需要周期性传输大量数据可能要评估 WiFi 或其它方式但代价是功耗显著上升。连接方案优势代价典型场景BLE功耗低、手机兼容性好吞吐量有限、单次连接距离短手环、戒指、贴片WiFi吞吐量高、与路由器直连功耗高、需要入网配置室内固定监测私有 2.4G 协议延迟和协议可控手机无法直连需要网关多设备组网场景从长期维护角度看能不引入私有协议就不引入。BLE 的标准 GATT 结构已经能覆盖传感器上报、控制指令和固件升级手机端生态也成熟。只有当产品确实需要组网、低延迟或者极低功耗时才评估私有方案。注意选型阶段就要为主控的射频部分留出天线净空区并提前联系天线供应商。结构设计完成后才发现天线被金属件包围是原型转量产阶段最难解决的问题之一。3. 固件与数据链路从传感器到手机 App 的最简闭环3.1 固件分层与低功耗调度可穿戴设备固件通常按三层组织驱动与 SDK 层负责芯片外设、BLE 协议栈、传感器驱动。中间层负责电源状态管理、存储服务、数据上报协议、升级模块。应用层负责业务状态机判断何时采样、何时上报、何时进入睡眠。低功耗设计的核心不是把频率调低而是让系统在绝大多数时间处于睡眠状态只在需要处理的事件到来时醒来。所以固件应尽量采用事件驱动架构而不是轮询。每个传感器都启用数据就绪中断BLE 连接事件交给协议栈管理MCU 在忙完一件事之后立刻评估是否可以进入睡眠。下面这段代码展示的是“周期性读取数据并通过 BLE Notify 上报”的结构思路。真实工程要按你使用的 RTOS 和 SDK 版本调整 API不能直接拿来做量产编译。/* 说明性代码Zephyr 风格。 * 实际使用时函数签名、宏定义应参考当前 SDK 头文件。 */ #include zephyr/kernel.h #include zephyr/bluetooth/bluetooth.h #include zephyr/bluetooth/gatt.h #include zephyr/bluetooth/uuid.h static bool notifying; static void ccc_changed_cb(const struct bt_gatt_attr *attr, uint16_t value) { notifying (value BT_GATT_CCC_NOTIFY); } BT_GATT_SERVICE_DEFINE(sample_svc, BT_GATT_PRIMARY_SERVICE(BT_UUID_DECLARE_16(0xFF01)), BT_GATT_CHARACTERISTIC(BT_UUID_DECLARE_16(0xFF02), BT_GATT_CHRC_NOTIFY, BT_GATT_PERM_READ, NULL, NULL, NULL), BT_GATT_CCC(ccc_changed_cb, BT_GATT_PERM_READ | BT_GATT_PERM_WRITE), ); static void notify_worker(void *arg1, void *arg2, void *arg3) { uint8_t seq 0; while (1) { k_sleep(K_SECONDS(1)); if (!notifying) { continue; } /* 实际项目中在这个位置读取传感器值 */ uint8_t sample[4] { 0xAA, seq, 0x00, 0x00 }; seq; bt_gatt_notify(NULL, sample_svc.attrs[1], sample, sizeof(sample)); } } K_THREAD_DEFINE(notify_tid, 1024, notify_worker, NULL, NULL, NULL, 7, 0, 0); int main(void) { int err bt_enable(NULL); if (err) { return err; } /* 启动可连接广播参数根据 Zephyr 版本补齐 */ return 0; }这段代码要说明的关键点是BLE 的 Notify 机制需要手机端先订阅设备端通过 CCC 回调感知订阅状态。在手机没有订阅时持续调用bt_gatt_notify没有意义还会白耗电。线程用k_sleep控制周期实际产品会把这个周期改成由传感器中断或定时器驱动避免固定轮询。3.2 设备与 App 之间的协议设计设备端和手机端的通信协议决定了后续开发和排障复杂度。BLE 传输本身适合小包数据不建议在 BLE 通道上直接跑 JSON 文本。很多团队为了快速上线使用 JSON当设备量增长后才发现解析开销、包长和功耗都不合适。协议设计建议采用紧凑二进制格式并包含版本号、序号和校验字段。以一条传感器上报报文为例可以用下面的结构表示。字段长度含义包头1 字节固定魔数如 0xAA版本号1 字节协议版本用于兼容消息类型1 字节数据、控制、应答、错误序号1 字节防止丢包后无法对齐采样值N 字节按字节序排列的有效载荷CRC2 字节对整包做校验对应的示例结构体可以是#include stdint.h #define WEARABLE_HEAD_MAGIC 0xAA #define WEARABLE_MSG_SAMPLE 0x01 typedef struct __attribute__((packed)) { uint8_t head; uint8_t version; uint8_t msg_type; uint8_t seq; int16_t accel_x; int16_t accel_y; int16_t accel_z; uint16_t battery_mv; uint16_t crc16; } wearable_sample_report_t;报文里的head用来快速识别协议流version用来兼容未来扩展crc16校验保证传输过程中数据没有被破坏。App 端解析时看到包头不匹配或 CRC 错误应当直接丢弃而不是强行按格式解出脏数据。3.3 OTA 升级和本地日志不能放到量产后再补可穿戴设备出货后无法像手机 App 一样频繁修复问题OTA 能力必须早期规划。常见做法是 Flash 分区里保留两个固件区当前运行区和新固件写入区。升级过程中先把新固件写入备用区校验通过后切换启动标志重启后从新区启动启动失败时回滚到旧区。本地日志同样重要。样机阶段可以通过串口打印日志量产设备没有串口需要把关键日志写入 Flash 缓冲区再通过调试命令或特殊 BLE 通道导出。至少要记录启动原因、上次复位原因、传感器初始化失败码、OTA 版本号、充电异常状态。没有这些数据售后阶段排查问题只能靠猜测。4. 从原型机到量产结构打样、DFM 与试产节奏4.1 原型机与量产
