nRF52840开发实战：低功耗蓝牙物联网应用全指南

做过几年低功耗蓝牙产品开发之后，我越来越觉得nRF52840是一颗绕不开的芯片。无论你是做可穿戴设备、传感器标签、医疗配件还是智能家居节点，它几乎都能覆盖。很多人一上来就问“这颗芯片怎么学”“用什么IDE”“能不能跑RTOS”，这些问题本身没有错，但如果你只盯着“点灯”和“跑DEMO”，很快就容易被协议栈、低功耗优化、OTA升级这些问题卡住。这篇东西我打算从硬件架构开始，一路讲到物联网落地实战，把真正有价值的东西拆开来讲。

这篇指南会覆盖nRF52840的核心架构、BLE协议栈的关键概念、开发环境搭建、低功耗设计思路，以及从传感器节点到云端的完整数据链路。适合刚接触低功耗蓝牙开发的嵌入式工程师，也适合正在做物联网产品选型和技术预研的团队。

1. 硬件架构与选型思路

1.1 核心架构：这颗芯片到底强在哪

nRF52840在Nordic的BLE产品线里属于高端型号。它基于ARM Cortex-M4F内核，主频64MHz，带浮点运算单元（FPU），这意味着你在做加速度计姿态解算或者简单音频处理时，不用像在M0内核上那样精打细算。存储方面，它内置1MB Flash和256KB RAM，这在低功耗蓝牙芯片里算很充裕的配置。我最早从nRF52832迁移过来时，最明显的感受就是RAM不再捉襟见肘——原来跑个协议栈加应用就剩几十KB，在52840上可以比较从容地塞下FreeRTOS、蓝牙协议栈和业务逻辑。

射频部分是这颗芯片的核心资产。它支持蓝牙5.0的2Mbps高速模式、长距离编码模式（Coded PHY），同时也支持802.15.4协议，也就是Thread和Zigbee的物理层。这意味着nRF52840不只是BLE芯片，还可以做多协议网关。除此之外，它还集成了NFC-A标签功能，可以用于近场配对，这个设计在耳机、手环类产品里非常实用——用户碰一下手机就完成蓝牙配对，体验比手动在设置里找设备好很多。再加上Arm CryptoCell-310加密单元，支持硬件加速的AES、SHA-256等算法，做安全升级和设备认证时有很大优势。

外设方面也很丰富。12位逐次逼近型ADC、多通道PWM、SPI/TWI/UART、PDM数字麦克风接口、USB 2.0全速控制器……基本上常见的传感器和外设接口它都有。特别是USB接口，这在BLE芯片里不多见。你可以直接用USB线给固件升级，不需要额外买调试器，这对做小批量产品或者DIY项目来说非常方便。

我整理了一张对比表，方便你快速理解nRF52840在nRF52系列和其他常用选型中的位置：

当然，ESP32的优势在于WiFi和更强的算力，但论低功耗无线链路的精细化控制，nRF52840要专业得多。ESP32做WiFi网关合适，做一个靠纽扣电池跑一年的BLE传感器节点，它的功耗模型并不合适。

1.2 选型时你需要想清楚的问题

很多人选芯片喜欢看参数表，但真正做产品时，我更建议你先回答几个问题。

第一，你的产品需要USB吗？如果需要，nRF52840是nRF52系列里为数不多支持USB的型号，可以做免驱的HID设备或者CDC虚拟串口。第二，你需要跑Thread或Zigbee吗？如果你只是做BLE，nRF52832其实也够用，成本更低。第三，你的代码量和数据缓存需求有多大？如果要跑FreeRTOS、OTA双Bank升级，还要缓存大量传感器数据，256KB RAM的优势就体现出来了。

还有一个经常被人忽略的点：开发生态。nRF52840的SDK文档、示例代码、社区讨论都很多，官方还提供了nRF Connect for Desktop、nRF Sniffer等工具链。我见过不少项目因为选了一颗“看起来很省电”但资料稀少的芯片，最后卡在协议栈底层调试上，开发周期翻倍。在这个问题上，生态成熟度比芯片本身的纸面参数更重要。

如果你在考虑“有没有比nRF52840更好的芯片”，我的看法是：要看“更好”的定义是什么。如果追求双核和高性能，nRF5340是更进一步的选项；如果追求极低成本，nRF52810这类精简型号也能满足基础BLE透传需求；如果追求更高无线数据吞吐量，可以考虑支持蓝牙5.4的新一代芯片。但就“低功耗蓝牙+物联网节点”这个典型场景而言，nRF52840是目前平衡性最好的选择之一，特别是它的文档和工具链能帮你把开发周期压缩很多。

2. 开发环境搭建：SDK选型与工具链配置

2.1 nRF5 SDK还是nRF Connect SDK

刚开始接触nRF52840的人，最容易困惑的就是SDK选择问题。目前市面上有两套主流方案：传统的nRF5 SDK，以及Nordic新一代的nRF Connect SDK（NCS）。

nRF5 SDK是Nordic多年积累的经典SDK，基于C语言、可移植性强、代码结构清晰，配套的示例非常多。它的优点是稳定、成熟、资料丰富，网上能找到大量基于nRF5 SDK的项目和教程。缺点是它已经进入维护模式，Nordic的新特性主要放在NCS上。NCS则是基于Zephyr RTOS的，它把驱动、协议栈、应用统一在了一套面向工程管理的框架里，支持设备树（Devicetree）、Kconfig配置，功能更现代，但学习曲线明显更陡。

我的建议很简单：如果你做的是量产产品、团队熟悉传统开发方式，直接上nRF5 SDK，开发和调试效率高；如果你是新产品、且未来要长期迭代，可以考虑NCS，它更面向未来。我自己目前的主力项目还跑在nRF5 SDK上，但会持续关注NCS的更新。不管选哪套，请务必保持在一个SDK版本上不要频繁升级，尤其量产阶段，不然一次API变更会让你重构一大片代码。

2.2 编译烧录与调试三板斧

nRF52840的编译工具链选择比较灵活。传统nRF5 SDK支持Keil MDK、IAR Embedded Workbench、SEGGER Embedded Studio（SES）。SES是Nordic官方推荐的IDE，对nRF5 SDK支持最好，免费版也能满足绝大多数开发需求。在新版NCS中，Nordic已经转向命令行CMake+Ninja的构建方式，可以用VS Code加nRF Connect for VS Code扩展来开发。

我自己用下来最顺手的组合是：SES做日常编辑编译 + nRF Connect for Desktop做烧录和调试 + 命令行nrfjprog做量产烧录。SES的调试器支持断点、变量查看、功耗分析，而且它的许可证对Nordic芯片免费，不折腾。

烧录调试硬件方面，nRF52840 DK开发板上自带J-Link OB调试器，插上USB线就能识别。如果你的板子是自研的，可以引出SWD接口，用外置J-Link或DAPLink连接。量产阶段可以用nrfjprog脚本烧录：

nrfjprog -f nrf52 --program firmware.hex --chiperase --verify nrfjprog -f nrf52 --reset

实测这套流程配合夹具，一个人一小时烧几百片没问题。值得一提的是，nRF52840的USB DFU也很方便，如果你不想买调试器，可以直接更新bootloader之后用USB拖拽固件文件完成升级。

3. BLE协议栈核心概念与连接流程

3.1 GAP与GATT：认识BLE的骨架

在BLE协议栈里，GAP和GATT是两个你必须理解透彻的概念。可以这么类比：GAP定义了“两个人如何认识、如何建立联系”——它负责广播、扫描、连接建立、连接参数管理。GATT定义了“认识之后如何交换物品”——它把数据组织成服务和特征值（Service/Characteristic），方便设备间读写、通知。

GAP层最核心的角色有Central（主机）和Peripheral（从机）。手环、传感器标签这类设备通常作为Peripheral，手机或网关作为Central。广播是Peripheral让外界发现自己的一种方式：它周期性地发送广播包，里面可以携带设备名、服务UUID等数据。Central扫描到设备后发起连接请求，双方进入连接态。

GATT层则是数据交互的基础。一个Service（服务）可以理解为一种功能分类，一个Characteristic（特征值）是具体的数据入口。比如电池服务（0x180F）里有一个电池电量特征值，手机读取或订阅它，就能拿到设备的电量百分比。实际项目中，大多数功能都需要自定义服务，UUID自己定义，然后在特征值里面放原始数据或结构化数据。

这里有一个新手容易犯的错误：以为BLE连接成功就能像串口一样随意发数据。实际上，BLE的数据交换必须通过GATT服务来操作，你得先把服务结构设计好，再规划数据格式和读写权限。我在项目中通常先用表格把服务、特征值、属性（读写/通知）、数据长度全部列清楚，再动手写代码。

3.2 广播数据设计

广播包不是随便发一串字节就完事了，它有一套完整的AD Structure（AD Type + Length + Data）规则。广播包里常见的AD Type包括Flags（表明设备是否可连接、是否支持LE）、完整的设备本地名（0x09）、16位服务UUID列表（0x03）、厂商自定义数据（0xFF）等。广播包本身不能太长，传统广播通道最多31字节，扩展广播（Advertising Extensions）在蓝牙5.0中可以更长，但功耗也会增加。

在设计广播包时，我建议优先放入三类信息：Flags标识、设备名称（便于用户识别）、服务UUID（方便App扫描过滤）。如果空间富余，可以再放厂商自定义数据，比如设备状态、电量等。但要注意：广播内容越短，广播功耗越低。

static void advertising_init(void) { ble_advertising_init_t init; memset(&init, 0, sizeof(init)); init.advdata.name_type = BLE_ADVDATA_FULL_NAME; init.advdata.include_appearance = false; init.advdata.flags = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE; init.advdata.uuids_complete.uuid_cnt = 1; init.advdata.uuids_complete.p_uuids = &custom_service_uuid; init.config.ble_adv_fast_enabled = true; init.config.ble_adv_fast_interval = APP_ADV_INTERVAL; init.config.ble_adv_fast_timeout = APP_ADV_DURATION; ble_advertising_init(&m_advertising, &init); ble_advertising_start(&m_advertising, BLE_ADV_MODE_FAST); }

上面这段是nRF5 SDK里典型的广播初始化流程。核心思路是在配置好广播数据之后，指定广播模式、间隔和超时时间。广播间隔的选择很关键：太短会非常耗电，太长则设备发现太慢。比如产品需要用户“靠近即被发现”，我一般用50ms左右的快广播，持续30秒后自动进入慢广播或者停止广播，这样兼顾体验和功耗。

3.3 连接参数：决定功耗和链路质量的平衡点

BLE连接参数包括连接间隔（Connection Interval）、从机延迟（Slave Latency）和超时时间（Supervision Timeout）。连接间隔决定两个设备多久同步一次，间隔越短，数据延迟越小，但功耗越高。从机延迟允许从机跳过若干个连接事件，是省电的重要机制。比如你采集温度数据，每5秒才上报一次，完全可以让从机在间隔30ms的连接事件中跳过大部分，只在需要时唤醒。

iOS和Android对连接参数的限制也不太一样，iOS对连接间隔、从机延迟的组合有严格限制。这也是我在跨平台开发里踩过最大的坑：Android连接得好好的，iOS上经常断开。所以产品开发时，必须在最开始就确定目标平台，并严格使用平台允许的参数组合。

static void conn_params_init(void) { ble_conn_params_init_t cp_init; memset(&cp_init, 0, sizeof(cp_init)); cp_init.p_conn_params = &conn_params; cp_init.first_conn_params_update_delay = APP_TIMER_TICKS(5000); cp_init.next_conn_params_update_delay = APP_TIMER_TICKS(30000); cp_init.max_conn_params_update_count = 3; ble_conn_params_init(&cp_init); }

硬件设计上，射频部分要特别注意。nRF52840的天线匹配网络不能随便照搬参考设计，天线周边的铺铜、净空区、匹配元件位置都会影响发射功率和接收灵敏度。我做过一个项目，因为天线附近放了一颗大电容，导致实测灵敏度掉了将近10dBm，最终表现在手机上就是连接距离大幅缩短。所以Layout阶段一定要严格遵循Nordic的硬件设计指南，特别是天线净空和匹配网络。

4. 低功耗设计实战：从模块到系统

4.1 从“低功耗芯片”到“低功耗产品”的距离

很多人以为选了低功耗芯片，产品就自动低功耗了。这是最大的误解。芯片本身的睡眠电流确实很低，nRF52840在System OFF模式下可以做到亚微安级别，但最终整个系统的功耗取决于你的电路设计、代码架构和数据上报策略。

我见过一个产品，芯片休眠电流测出来只有2uA，但整机功耗却高达200uA。排查下来发现，问题出在板载电平转换芯片上——它一直处于使能状态，静静吃掉了200uA。还有一次是LED指示灯的限流电阻焊错了封装，导致指示灯常亮，续航直接从一年缩水到两个月。所以我一直建议，在原理图阶段就要逐个外设确认空闲状态下的漏电流，必要时候用MOS管或负载开关给不用的外设断电。

nRF52840的供电选择也很关键。芯片支持DC-DC和LDO两种模式。DC-DC模式下，芯片内部会使用片外电感实现降压转换，功耗更低；LDO模式电路简单，成本低，但功耗略高。在纽扣电池供电的产品里，几乎都是标配DC-DC + 低功耗电感。官方典型数据是用nRF52840 DK板测量，DC-DC模式比LDO模式省电约30%到40%，这个差距在电池供电产品中的分量你懂的。

从软件层面看，低功耗设计本质上是一个事件驱动的调度问题。芯片平时处于睡眠模式，只在特定事件发生时唤醒执行任务，完成后立刻回到睡眠。比如一个温湿度传感器节点，典型的工作流程是：定时唤醒→采集温湿度→写入Flash→蓝牙广播或连接上报→继续睡眠。这个过程中，ADC采样、I2C读取、无线发送的时间越短，平均功耗就越低。

4.2 事件驱动与定时器架构

nRF5 SDK中提供了app_timer模块，它是基于实时定时器（RTC）实现的软件定时器，在系统睡眠时依然可以正常工作并唤醒CPU。我在项目中几乎不会主动轮询任何外设，一切行为都由事件触发：按键按下、定时器到期、蓝牙事件到达、传感器数据就绪……这样芯片可以尽量长时间停留在睡眠状态。

APP_TIMER_DEF(app_timer_id); static void sensor_read_timeout_handler(void *p_context) { read_sensor_data(); send_data_over_ble(); } static void timers_init(void) { ret_code_t err_code = app_timer_create(&app_timer_id, APP_TIMER_MODE_REPEATED, sensor_read_timeout_handler); APP_ERROR_CHECK(err_code); err_code = app_timer_start(app_timer_id, APP_TIMER_TICKS(MS_TO_TICKS(60000)), NULL); APP_ERROR_CHECK(err_code); }

空闲时调用sd_app_evt_wait()：

for (;;) { uint32_t err_code = sd_app_evt_wait(); APP_ERROR_CHECK(err_code); }

上面这个循环就是典型的“让芯片在没有任务时进入睡眠”的写法。sd_app_evt_wait()会触发处理器的WFE（Wait For Event）指令，芯片进入System ON空闲模式，直到有中断或事件到来才继续执行。注意，不要在应用循环里放nrf_delay_ms()这类阻塞延时，那会让睡眠机制完全失效。

我举一个实际的功耗估算例子：一个温度采集节点，每小时上报一次数据，每次唤醒工作时间约100ms，平均电流为5mA。那么每个周期消耗大约0.5mAs，算上睡眠电流2uA的累计，平均电流不到3uA。一颗230mAh的CR2032纽扣电池可以跑好几年。所以，低功耗产品的核心不是把唤醒时间压到绝对短，而是尽量减少唤醒次数，同时把非必要的活动全部关掉。

4.3 低功耗调试的隐藏坑

低功耗调试最烦人的问题是“看起来睡眠了但实际耗电很大”。我总结几个高频坑。

第一个坑是日志输出。开发阶段你可能会用UART打印调试信息调试完之后如果忘了关掉，UART外设一直处于工作状态，芯片根本睡不下去。量产固件里严禁任何无条件的调试打印。

第二个坑是GPIO悬空。未使用的GPIO如果被配置为输入且没有上拉/下拉，引脚会处于不确定电平状态，导致数字电路反复翻转，功耗明显偏高。所以空闲GPIO要统一配置为输出低电平或带上拉的输入。

第三个坑是Flash写入。nRF52840内部Flash的擦写操作会消耗较大电流，如果在短时间内频繁记录数据，不仅功耗高，还会加速Flash磨损。数据记录要采用“累积后批量写入”或“环形缓冲区”的策略。

还有一个很多新手不知道的坑：如果启用了FPU浮点运算单元但没有在睡眠前处理相关状态，某些情况下会导致唤醒后异常。项目里如果确实需要浮点计算，建议验证睡眠前后的稳定性，或者干脆用定点数替代。

测量功耗的正确姿势是用Nordic的Power Profiler Kit II这类专用工具，它可以高精度地记录电流曲线，对应到代码里的每一步操作。没有工具的话，至少也要用万用表测平均电流，别用“开发板工作时看起来挺正常”来判断功耗达标，那是自欺欺人。

5. 物联网应用实战：从传感器节点到云端

5.1 典型的物联网节点架构

把nRF52840放进物联网系统里，通常不是让它直接连云端，而是通过网关或手机中转。这里面有两个原因：BLE本身是短距离无线协议，覆盖范围有限，不可能直接上云；另外，BLE设备通常不是一直在线，而云平台接入需要持续的网络连接。所以典型架构是：nRF52840节点采集数据→BLE上报给手机或网关→网关通过网络（比如Wi-Fi、以太网、4G）上传到云端平台。

在这个架构里，nRF52840承担的是“末梢感知与通信”的角色。它可以是一个温度标签、一个门磁传感器、一个空气质量监测仪，甚至是一串ibeacon信标。它的核心任务是把传感器数据准确、低功耗地送出去，同时接收云端的控制指令。如果节点数量多，还要考虑组网方案：星型结构下，多个Peripheral可以连接到一个Central网关。

在实际项目中，我碰到过很多人在纠结“要不要让BLE设备直接连路由器”。这个思路基本行不通，因为BLE和Wi-Fi是两套完全不同的协议。如果你希望设备直接上云，应该选择带Wi-Fi或蜂窝模组的芯片；如果你已经选定了nRF52840，就不要强行要求它联网，而是把网关设计纳入系统架构。

5.2 端到端数据链路示例

我们拿一个基于nRF52840的温湿度监测设备来举例。设备侧，板载SHT30温湿度传感器通过I2C接口连接到nRF52840。代码逻辑很简单：定时唤醒→通过I2C读取温湿度→将数据填入自定义GATT特征值→广播或连接后通过Notify发送给手机/网关。如果是连接模式，通常会先把数据缓存在RAM里，等到Central发起读取或Notify请求时才发送。

传感器数据格式方面，我建议在应用层做好结构化设计，而不仅仅是发一串字节。比如温度值放大100倍后以int16_t表示，湿度同理，再加上一个数据序号和时间戳。这样做的目的是统一数据格式，避免网关解析歧义。

typedef struct { uint8_t seq; int16_t temperature; // 实际温度 * 100 uint16_t humidity; // 实际湿度 * 100 uint32_t timestamp; } sensor_data_t;

BLE侧通过Notify上报时：

static void send_sensor_data(uint16_t conn_handle) { sensor_data_t data; data.seq = m_seq++; data.temperature = (int16_t)(temperature * 100); data.humidity = (uint16_t)(humidity * 100); data.timestamp = app_timer_cnt_get(); uint32_t err_code = ble_custom_sensor_data_send(&m_custom_service, (uint8_t *)&data, sizeof(data), conn_handle); if (err_code != NRF_SUCCESS) { NRF_LOG_INFO("Send failed: 0x%08x", err_code); } }

网关收到数据之后，通过MQTT或者其他物联网协议上报到云平台。云平台侧的展示、告警和存储逻辑，可以根据具体业务需求定制。这里涉及的技术栈已经超出BLE本身，但整体链路的打通能力，恰恰是物联网工程师和普通嵌入式工程师拉开差距的地方。很多嵌入式工程师只关注“能把数据读出来”，却忽略了从设备到云端的完整数据链路闭环，结果做出来的东西只是个“开发板演示”。

5.3 OTA升级与量产那些事

物联网设备一旦部署到现场，最怕的就是“出了问题要拆回来改固件”。所以OTA（Over-The-Air）升级几乎是产品化的必备能力。nRF52840支持基于BLE的DFU升级，典型架构是：设备上跑一个独立的bootloader程序，应用固件通过蓝牙分块传输到设备，校验通过后切换执行新固件。

Nordic的DFU策略是双Bank方式，即Flash分为两个区域，一个存当前运行的应用，一个存待升级的新固件。升级完成后做一次切换，这样即使传输中断，设备也可以回退到旧固件，不会变砖。实际项目里，建议开发时就把OTA升级流程跑通，因为基础框架后期再嵌入会非常痛苦。

量产阶段有几个容易被忽视的点。第一，每台设备的MAC地址和蓝牙名称要唯一，不能所有设备烧同一个固件就完事。MAC地址可以烧录进UICR区域，应用启动时读取并设置给协议栈。第二，量产固件里不要开启过度调试功能，否则会增加设备间相互干扰的概率。第三，产品的APPROTECT安全锁定问题要特别留意。

这里我想详细说一下“nRF52840永久锁定”这个很多人踩过的坑，这也是被问得最多的问题之一。nRF52840可以通过配置APPROTECT寄存器来防止固件被非法读取和调试。这个特性本身很好，但如果你在开发阶段不小心开启了APPROTECT，又忘了关闭，很容易导致之后无法通过调试器连接，甚至无法擦除Flash。此时，不是真的“永久”锁定，但确实要用特殊手段恢复。

正确的处理方式是：在量产固件中明文启用APPROTECT前，确认你的烧录夹具支持通过恢复引脚或者使用特定的全擦除命令。更稳妥的方式是先把APPROTECT关闭，正常调试，只在最后发布版本时开启，并且把恢复操作写进产线指导书。如果你已经误开了APPROTECT导致无法连接，通常需要短接调试接口的复位脚，配合nrfjprog的恢复命令或者专用工具进行全片擦除，具体操作可以查Nordic的官方文档。总之，别在产品没有完整恢复方案前就开启这个功能，否则产线会哭的。

6. 抓包调试与常见问题排查实录

6.1 三件套：Sniffer、Wireshark与nRF Connect

BLE开发调试中，日志只能告诉你软件看到了什么，看不到空中的数据包长什么样。这时候就需要抓包工具：一个是Nordic官方的nRF Sniffer扩展，配合硬件比如nRF52840 Dongle或开发板使用；另一个是协议分析软件Wireshark。组合起来，你可以实时观察空中的所有蓝牙数据包，包括广播包、连接请求、数据通道包、配对过程中的加密握手，甚至可以抓到隐藏的数据错误和重传行为。

使用流程很简单：把nRF52840 Dongle刷成Sniffer固件，连接Wireshark的Nordic Sniffer插件，选择要观察的通信频率或设备，然后就能看到非常直观的数据流。我在排查“为什么设备时连时断”这类问题时，几乎都靠它定位。有一次线上反馈某个区域的设备连接成功率特别低，抓包后发现是广播信道被同频设备持续占用，换成更多广播信道后问题解决了。

抓包不是万能的，它只能覆盖协议栈之上的内容，也就是空中数据抓不到软件内部状态。所以更完整的调试三板斧是：App日志 + 硬件调试器断点 + Sniffer抓包。三层互相配合，能让你快速缩小问题范围。

6.2 高频问题速查表

我把自己和团队踩过的坑，以及大量用户反馈的问题整理成了一个表格，方便你排查问题的时候速查。

其中“Notify收不到”这个问题非常常见。在GATT协议中，Peripheral要主动向Central推送数据，必须使用Notify或Indicate属性，但Central必须先写入客户特性配置描述符（CCCD）来订阅这个通知。很多新手自己写完Service之后直接在Peripheral端调用发送函数，结果Central端什么都没收到，就是因为漏掉了CCCD处理环节。所以请务必确认你的代码里有处理Write CCCD事件的逻辑。

另外一个高频问题就是复位引脚浮空。nRF52840的复位引脚如果悬空，很容易被环境噪声干扰，导致芯片随机重启。在硬件设计上，复位脚要么直接拉高，要么接一个合适的RC复位电路，而且复位走线要远离电源和射频区域。这个问题我在几块自研板子上都碰到过，表现是“运行几分钟就掉线”，实际上是芯片在悄悄复位。

还有一件事需要提醒：如果你在做跨平台App开发时遇到iOS低功耗蓝牙问题，很多情况下不是iOS本身不行，而是协议栈对连接参数和后台模式的限制非常严格。比如App退到后台后，系统会暂停扫描和连接事件，导致数据收发中断。真机调试时要把“后台模式”和“蓝牙外设管理”权限配置好，同时建议在Central端设计好断线重连和缓存补发的机制。这个领域单独展开可以写一篇文章，但核心思想是：低功耗蓝牙是“低功耗+短连接+可靠重连”的组合拳，不是用起来像TCP长连接一样的东西。

最后再分享一个我个人在开发流程上的体会：拿到一块新nRF52840板子，先别急着写业务代码。先用官方例程把点灯、UART打印、BLE广播、OTA升级这几个基础链路全部跑通，并且记录下每项功能的功耗基准值。这些基础打得越扎实，后面做业务功能时就越不容易被底层问题绊住。很多人一开始就闷头写业务逻辑，等到外设不工作、连接不稳定、功耗爆炸时，再回头排查底层层层堆叠的问题，往往要花上几倍的时间。任何低功耗硬件产品，数据和功耗都是始终相伴的两条主线，跑通并不是结束，把“跑通”量化出来，是初学者进阶为工程师的第一道坎。