去年我接了一个冷链温度记录仪的项目要求用一颗国产BLE SoC做温湿度采集手机App实时查看数据。当时对比了一圈最后选了富芮坤FR801xH。这颗芯片的蓝牙协议栈启动流程、notify上报机制非常典型搞明白之后不只是FR801xH其他国产BLE芯片比如泰凌微、奉加微、Nordic nRF52系列你都能很快上手。这篇文章就把FR801xH的协议栈启动流程和温度数据主动上传的完整思路拆开讲一遍适合刚接触BLE开发、被“回调满天飞”整懵的嵌入式工程师。很多兄弟从单片机转过来最不适应的就是BLE SDK里看不到一条简单的主流程全是注册回调、事件分发、状态机。而项目里最核心的诉求往往是“板子主动把温度传给手机”也就是notify机制这又牵扯到GATT服务、CCCD描述符、连接事件等一系列概念。我尽量用做产品的思路把“启动流程”和“主动上报”这两条主线讲透中间穿插实测中遇到的坑。1. 先用一段话定位FR801xH这颗国产BLE芯片适合做什么1.1 芯片资源盘点与竞品对比FR801xH是富芮坤面向低功耗物联网市场推出的一颗BLE SoC芯片内部集合了ARM Cortex-M系列内核、BLE射频收发器、协议栈以及常见的外设接口。从产品定位看它和Nordic nRF52810/nRF52832、泰凌微TLSR8258、奉加微PHY6222处于同一战场主打的是“够用、便宜、上手快”。拿我实际用的FR801xH来说外设资源里最常用的就是GPIO、UART、SPI、I2C、ADC和PWM做温湿度计、电子价签、体脂秤、智能灯、beacon、电动工具仪表盘这一类产品完全够用。BLE射频部分支持蓝牙5.x的广播和连接发射功率可调接收灵敏度在国产芯片里算中上水平。更重要的是它的协议栈是以库文件形式提供的你不用关心底层射频调度细节只需要在正确的位置调用初始化接口、注册服务、处理事件回调。从开发体验上FR801xH和Nordic有一个明显差异Nordic的SDK是模块化源码功能全但学习曲线陡光一个协议栈初始化就要翻半天文档FR801xH的SDK更“轻”代码路径短适合想快速出产品的团队。当然轻也意味着你要自己动手封装一部分逻辑比如断线重连、数据补发这些SDK默认不会帮你做。1.2 拿到SDK后第一件事工程结构与入口函数第一次拿到FR801xH的SDK不要急着看代码先看整个工程目录。通常SDK会给出Keil或IAR的工程模板里面分成几个区域应用层app、驱动层driver、协议栈库lib、启动文件startup和配置文件。你需要改的基本都在app目录驱动层偶尔需要改协议栈库基本不要碰。工程入口一般是一个类似app_main的函数由底层启动文件在完成最基本的内核初始化、堆栈设置、时钟配置之后跳转进来。在这里你会看到整个系统的生命周期初始化硬件资源、初始化协议栈、注册GATT服务、配置广播数据、启动广播最后进入一个死循环处理协议栈事件和应用层任务。我建议你拿到工程后先在app_main里点一个LED确认芯片能跑起来再逐步打开协议栈功能。这种“最小系统验证”的习惯能帮你把启动流程里“硬件问题”和“协议栈问题”快速隔离后面你往下追启动流程时会轻松很多。2. 协议栈启动流程逐段拆解从复位到主循环每一行都在干嘛2.1 上电初始化时钟、电压域与内存布局FR801xH上电后首先是启动文件接管。启动文件做的事情和STM32启动类似设置初始堆栈指针、初始化向量表、做必要的RAM清零或拷贝、然后跳到C环境。你不需要改这部分但要理解一个点BLE射频对时钟精度要求很高芯片内部一般有RC振荡器和外部晶振两个时钟源。若外部晶振没焊接或没起振协议栈初始化大概率会失败或者卡死。在app_main开头你通常会看到时钟初始化、电源管理初始化和GPIO初始化的代码。时钟初始化的作用是选择系统主时钟来源、配置分频系数确保CPU和外设工作在正确频率。电源管理初始化则会设置芯片的工作电压域、LDO/DC-DC模式这一步直接影响后续低功耗唤醒是否正常。这里有个容易踩的坑部分FR801xH开发板默认使用内部RC跑低频时钟在常温下BLE功能正常但到了低温环境频率偏差变大广播和连接会变得不稳定。做产品打样时我习惯在硬件上预留外部晶振的位置软件初始化也按外部晶振优先来配置而不是图省事直接用内部RC。2.2 协议栈初始化的核心逻辑它到底初始化了什么协议栈初始化是启动流程里最关键的步骤一般体现为SDK里的一个初始化函数比如ble_stack_init。这个函数内部做的事情远比名字看起来多。第一内存分配。BLE协议栈需要一大块RAM用来管理链路层缓冲、连接上下文、GATT表、L2CAP报文分段重组等。SDK通常会预留一块静态缓冲池或使用堆分配。如果RAM不足或配置的buffer数量偏小协议栈初始化可能直接断言失败。第二链路层调度器初始化。BLE的射频收发是有严格时序的协议栈内部维护着一个调度器负责安排广播事件、扫描事件、连接事件和睡眠唤醒。调度器在初始化时建立起时基后续所有射频活动都围绕这个时基展开。第三GAP和GATT层的初始化。GAP层负责广播、连接、安全相关的管理GATT层负责服务端和客户端的属性读写、通知、指示。协议栈初始化时会建立GATT库的工作区但服务定义是你后面手动注册的。一个很容易被忽略的点是协议栈初始化通常要求在系统时钟稳定、电源稳定之后进行且不能被打断。所以初始化代码一般关中断执行或者在进入低功耗之前完成。那些“初始化偶尔失败重启就好了”的现象很多时候就是时钟还没稳定就急着初始化协议栈导致的。2.3 服务注册与广播启动的先后顺序为什么不能乱协议栈初始化完之后紧接着要做两件事注册GATT服务和启动广播。这两件事的顺序是强依赖的不能颠倒。为什么必须先注册服务再启动广播因为手机端的App在扫描到设备并建立连接之后会立刻去发现服务Discover All Primary Services。如果这时候设备还没把GATT服务注册进协议栈手机端就会看到空的GATT表或者拿到过期的服务句柄。等到设备再注册服务时连接状态已经混乱了。在FR801xH的SDK里注册自定义服务通常是一个类似app_add_custom_service的函数里面指定服务UUID、包含的Characteristic、属性权限和初始值。比如做温度上传我会定义一个16位自定义服务UUID服务下挂一个“温度”特征特征属性为Notify并自动附带一个CCCD描述符Client Characteristic Configuration Descriptor。广播配置这一块需要设置广播间隔、广播载荷和设备名称。BLE广播包在传统广告信道里最多31字节如果你既要广播设备名称又要广播服务UUID还塞了厂商自定义数据很容易超长。建议把广播包做小扫描响应包放设备名。2.4 主循环与事件分发机制为什么应用代码都在回调里FR801xH没有跑操作系统它的事件处理是典型的“前后台”结构。前台是中断后台是主循环。BLE协议栈的中断发生后会把事件丢进一个队列主循环调用协议栈调度函数把队列里的所有事件分发到对应的应用回调。所以你写业务逻辑时看不到“主动接收”的代码而是大量switch-case处理回调。连接建立了你会收到连接事件连接断开了你会收到断开事件手机写入数据了你会收到写请求事件手机改变了CCCD你会收到订阅事件。我在项目里一般这样组织主循环while (1) { // 协议栈事件调度把底层事件分发给应用回调 ble_schedule(); // 应用层自定义任务例如周期采样温度 app_timer_poll(); // 看门狗喂狗 watchdog_kick(); // 进入低功耗等待中断唤醒 system_sleep_if_idle(); }主循环跑得越快事件处理越及时但功耗越高。实际产品里会在空闲时进入睡眠靠定时器或RF事件唤醒。3. notify上报的原理为什么“主动上传”必须靠GATT通知3.1 GATT层快速扫盲Service、Characteristic、Descriptor、CCCD如果你想做“温度主动上传”第一步是理解GATT这棵属性树。BLE的GATT逻辑模型从大到小是Profile规范- Service服务- Characteristic特征- Descriptor描述符。Service是一组相关功能的集合比如“温度服务”“电量服务”。Characteristic是具体的数据点它有属性比如只读、可写、可通知。Descriptor是对Characteristic的附加说明其中最特殊的一个描述符UUID是0x2902也就是CCCD客户端特征配置描述符。CCCD的作用就是“订阅开关”。手机端GATT客户端往CCCD里写0x0001表示“我要接收这个特征的Notify”写0x0000表示“取消订阅”。芯片端GATT服务端收到这个写入就知道该不该主动推送数据了。3.2 notify和indicate有什么区别为什么选notify同样是主动上报notify和indicate是两种方式。表面看都是服务端往客户端推数据但可靠性语义完全不同。Notify通知不需要确认。服务端调用发送函数把数据发出去了不会等客户端回复。它的优点是速度快、吞吐量高缺点是一旦链路因为干扰丢包应用层不会知道自己漏了一包。Indicate指示需要确认。服务端发出数据后客户端必须回一个确认包服务端收到确认才能继续发下一包。可靠性高但吞吐量会低很多因为每一包都在等确认链路往返一次的时间都花在等待上。对温度上报这种场景我推荐Notify。原因是温度是连续采样值偶尔丢一两包数据下一条数据马上又能采上来不会造成信息丢失。而且温度变化缓慢数据包又短没必要为每一次上传付出确认的带宽和功耗代价。我做了一个简单的对比表方便直观参考对比项NotifyIndicate确认机制无确认有确认吞吐量高低可靠性应用层不感知丢包应用层可感知背压适用场景温度、电量、IMU数据关键指令、文件传输实现成本低略高3.3 手机什么时候写CCCD订阅事件的正确处理方式很多第一次写BLE从机代码的人会有个困惑既然notify是“主动上报”为什么我在手机连接上之后立刻调用发送函数手机收不到数据原因就是CCCD没有被写入。手机连上从机后并不会自动订阅任何特征它必须先发现服务再找到CCCD描述符往里面写0x0001这个过程通常由手机App或调试工具比如nRF Connect、LightBlue完成。所以从机的“主动上报”是有前提的前提就是客户端已经完成订阅。在代码里正确的做法是拦截订阅事件。当协议栈收到CCCD写请求时会回调一个订阅事件里面包含连接索引和CCCD的新值。此时把“是否允许上报”的标志位置位或清除。我在写温度上报固件时用的逻辑大致是这样static bool s_notify_enabled false; void app_gatts_evt_handler(app_evt_t *evt) { switch (evt-type) { case APP_EVT_SUBSCRIBE: // 0x0001 订阅 notify0x0002 订阅 indicate0x0000 取消 s_notify_enabled (evt-cccd_value 0x0001); break; case APP_EVT_CONNECTED: // 连接建立但还不能确定客户端是否订阅 s_notify_enabled false; break; case APP_EVT_DISCONNECTED: s_notify_enabled false; break; default: break; } }后面所有发送温度数据的代码里第一件事就是检查ss_notify_enabled没订阅就直接返回省得白费力气。4. 温度数据从采集到出包的完整代码路子4.1 温度采集部分数字传感器最省事NTC方案更省钱FR801xH本身不带温度传感器需要从外部获取温度数据。根据产品定位有两种主流选型。数字传感器方案是最省事的比如常见的SHT30、SHT31、AHT20、HDC1080。它们通过I2C接口直接输出温度和湿度内部自带校准精度一般在±0.3摄氏度以内代码量小几乎不需要标定。做室内温湿度计、冷链温度记录仪直接选这个。热电偶/热敏电阻方案则更偏成本敏感型产品用NTC配合分压电阻接到FR801xH的ADC引脚通过查表方式换算温度。这种方案便宜但需要做校准而且NTC在低温段的非线性明显需要分段拟合或用多项式插值。还有一种是数字单总线方案比如DS18B20虽然只有一个引脚但时序要求比较严格需要在关中断的条件下操作时序反而比I2C更容易困扰新手。我做冷链记录仪时选的是AHT20I2C读取五分钟采样一次每次读取前不需要额外的唤醒命令AHT20需要约100us等待功耗和代码复杂度都很均衡。读取代码大致是uint8_t read_temp_humid(float *temp, float *humid) { uint8_t buf[6]; // 触发测量集成SDK里一般会有I2C驱动的封装 aht20_measure(buf[0]); // 根据数据手册解析原始值 uint32_t raw_temp ((uint32_t)buf[3] 16) | ((uint32_t)buf[4] 8) | buf[5]; uint32_t raw_humid ((uint32_t)buf[1] 12) | ((uint32_t)buf[2] 4) | (buf[3] 4); *temp raw_temp * 200.0f / 1048576.0f - 50.0f; *humid raw_humid * 100.0f / 1048576.0f; return 0; }4.2 数据封装与notify发送的SDK调用拿到温度原始值之后需要把它封装成字节流再调用协议栈的notify发送接口。BLE单包数据在默认MTU23字节下用户数据最多20字节因为要扣掉3字节的L2CAP头加1字节的ATT头。长度超过20字节的用户数据必须由协议栈做链路层分包或者应用层自行分片。好消息是温度值本来只有几字节一个包足够了。但是有一个容易被忽略的优化点FR801xH支持调整MTU大小默认MTU小收发效率低。如果手机端发起MTU协商从机端在GATT回调里应允许把MTU提到244字节左右这样单包可以发送244减3字节。对温度上报来说无关紧要但如果以后要传DMP姿态数据、OTA固件、或者大数据日志MTU的重要性立刻就能体现出来。温度发送代码我一般这么写void send_temperature(int16_t temp_x100) { if (!s_notify_enabled) { return; // 还没订阅别发 } uint8_t payload[3]; payload[0] 0x01; // 数据格式版本方便以后兼容 payload[1] (uint8_t)(temp_x100 0xff); payload[2] (uint8_t)((temp_x100 8) 0xff); uint8_t status ble_gatts_notify(conn_idx, temp_attr_handle, payload, sizeof(payload)); if (status ! 0) { // 通知发送失败可能是缓冲满或链路忙 } }这里有个细节温度值我用int16_t单位是0.01摄氏度。比如25.67摄氏度就用2567存储这样传输和比较都不会丢失精度比用浮点格式串好解析又比直接用float省字节。协议栈发送和手机端解析都只用整数运算效率高且没有浮点一致性问题。4.3 上报节奏怎么设计连续模式、变化触发、定时上报温度采集和上报是两回事采集频率和发送策略应该分开设计。常见的有三种模式。定时上报最简单每隔N秒采一次、发一次。优点是代码简单、数据完整缺点是即使温度没变化也会发造成无效功耗和无线干扰。变化触发上报只在上次上报温度和当前温度的差值超过某个阈值时才发。比如差0.5度才上报这样温度平稳的时候几乎不占无线资源适合需要长续航的温湿度计。但要注意如果一直没达到阈值手机端可能长时间拿不到数据心里没底所以一般会叠加一个“最大上报间隔”比如五分钟内无论如何都补一发。事件驱动上报适合带按钮或异常检测的产品比如冷链箱开门立刻上报一次配合定时上报兜底。这个模式对事件回调的实时性要求高如果主循环忙事件处理延迟增大数据“主动”的味道就不够浓。我实际做得最多的是“变化触发定时兜底”的组合1秒采样一次做滑动滤波温度变化超过0.3度立刻上报同时60秒强制上报一次。这个方案在功耗和实时性上平衡得比较好。5. 实测中踩过的坑首包丢失、连接间隔与低功耗冲突5.1 连接后第一包温度数据丢了的真凶我曾经在一个项目中遇到一个看起来很诡异的问题手机连接上设备后前几秒总是收不到温度数据断线重连后又能正常收到。排查了半天最后发现是两个原因的叠加。第一个原因是时序竞争。协议栈上报EVT_CONNECTED事件时只是表示连接已确立但手机端的GATT发现服务、写入CCCD都还没发生。如果我在连接事件里立刻设置一个“上电采集一次温度并上报”标志那么这次上报很可能会在CCCD写入之前发生发送端return掉了数据自然没有发出去。第二个原因是服务发现和订阅的顺序问题部分手机系统在服务发现完成前不会处理CCCD写请求导致订阅事件晚于连接事件很多。解决方式很简单无论是定时上报还是变化触发上报都必须在收到订阅事件之后再允许发送。为了工程上更稳我还会在订阅事件里回一条数据作为“上电握手包”手机端收到这包数据就知道链路已经就绪。5.2 连接参数更新请求为什么有时会被主机拒绝BLE的BLE连接参数包括连接间隔、从机延迟、监督超时理论上由主设备决定。从机可以发送连接参数更新请求Connection Parameter Update Request但主机有权拒绝。在FR801xH做从机时我踩过一个典型问题设置的连接间隔为7.5ms从机延迟为0请求参数更新后iPhone和Android都能正常接受但部分老款Android手机直接拒绝最后连接不成功设备一直断开重连。问题根源在于我请求的7.5ms连接间隔太激进。BLE协议允许7.5ms但实际手机蓝牙芯片的调度负担很重过于密集的连接事件会影响系统整体射频性能。不建议从机主动请求7.5ms的连接间隔建议的稳妥做法是间隔设到15ms到30ms从机延迟设1到2这样既保证了数据延迟可控又不会给主机带来太大的调度压力。如果是做低功耗传感器连接间隔设到100ms以上都可以因为数据量小延迟稍微大一点无感知但省电效果非常明显。5.3 低功耗模式下定时唤醒上报的注意点FR801xH这类BLE SoC在低功耗模式下CPU停止运行只有RTC和射频唤醒源在工作。如果你设定了1秒采样一次温度那么RTC会在1秒后唤醒CPU执行采样和上报然后又回到睡眠状态。这个机制看起来简单实际有坑。第一次踩坑是在定时器回调里做了太多事。I2C读取AHT20需要等待测量完成最长要80ms加上ADC滤波、数据打包整个回调执行了200ms以上。CPU醒了就一直在跑睡眠时间被压缩整机平均功耗比预期高了好几倍。优化方向很简单时间敏感的软件定时器不阻塞耗时长操作。正确做法是定时器只置一个标志位主循环轮询到这个标志位后才执行完整的采集和上报流程。这样即使I2C慢睡眠管理也能在主循环的合适位置进入低功耗保证功耗指标达标。5.4 看门狗与复位一个隐蔽的坑有一天测试同事告诉我设备隔几个小时就会自动重启一次而且完全没有规律。我一开始怀疑是硬件问题后来在日志里加了复位原因打印发现是看门狗复位。看门狗超时的根因也很典型。我的主循环里有一个Flash存储操作用来记录温度报警历史。Flash擦写是原子的几十毫秒内关中断执行偶尔还会因为等待Flash空闲而阻塞更久。当Flash擦写遇到RF事件密集的时刻主循环被拖慢喂狗间隔超过了看门狗阈值就触发了复位。解决方式有几个方向一是把看门狗超时时间适当放宽比如从500ms放宽到2s匹配最坏情况下的Flash阻塞时间二是Flash擦写前先关掉或延后非关键RF事件保证擦写过程不被无线中断干扰三是分批擦写避免一次擦除整扇区在中断关闭状态下停留太久。我最后采用的是第二种把Flash擦写逻辑放到协议栈事件较少的时段并做了一个复位原因记录。这样既提升了稳定性以后出了问题也能快速定位原因。5.5 调试工具的选择别只用串口打印做BLE开发串口打印能帮你看代码逻辑但看不透射频侧发生的事情。我强烈建议买一个nRF Connect Desktop或者用手机App抓包甚至搞一个BLE Sniffer硬件来看空中的广播包和连接事件。有一次设备离手机超过十米用户反馈时断时续。代码侧看一切正常但抓包后发现广播包里的设备名太长扫描响应包塞得满满当当轻度丢包就造成广播不可识别。缩短设备名之后连接距离明显改善。FR801xH的SDK里通常会提供一些调试宏可以把协议栈事件、错误码打印出来。开发阶段建议把这些日志全部打开但量产固件里最好关掉或者做成条件编译因为串口打印也是功耗和死机隐患的来源。6. 一些实操习惯供你少走弯路最后分享几条我自己的习惯不一定适合所有项目但至少能帮你避掉大部分麻烦。第一个习惯是任何上报数据都加一个数据格式版本号。现在的温度上报看起来只有两个字节以后如果产品要增加湿度、气压、或者固件版本信息没有版本号会非常难受。一个字节的版本前缀能让你在兼容老App和新增字段时从容很多。第二个习惯是手边常备nRF Connect和LightBlue。真机调试时这两个工具能快速验证服务发现、CCCD写入、notify接收判断问题出在固件还是App能省下大量联调时间。我遇到过不少“固件没有主动上报”的问题最后排查出来是App压根没有写订阅包工具一测就清楚了。第三个习惯是量产前看一遍功耗曲线。FR801xH的低功耗指标很好看但如果软件里某个定时器没有关闭、某个GPIO没有配成下拉、或者协议栈buffer配置过大实际电流可能比标称值高一个数量级。我习惯用功耗分析仪抓一个完整的上报周期的电流波形确认睡眠电流低于5uA再考虑进入下一个阶段。富芮坤FR801xH这套启动流程和notify上报机制基本覆盖了BLE从机侧最常见的工作路径。把这套逻辑理解扎实了换到其他芯片平台你只需要替换SDK接口名整体思路完全可以直接平移。
