2. nRF SDK与SoftDevice版本选型

在 Nordic nRF5 系列开发中，版本选型是项目启动阶段最容易埋下隐患的环节。它涉及三条相互约束的线：开发框架（nRF5 SDK 还是 nRF Connect SDK）、SoftDevice 协议栈型号（S132/S140/S113 等）、以及芯片系列（nRF52810/52811/52832/52840 等）。三者必须同时匹配，任何一条错位都会导致编译失败、烧录失败或运行期协议栈异常。

两代开发框架的本质差异

nRF5 SDK 是传统框架，SoftDevice 以预编译二进制形式提供，应用代码通过 SVC 软中断调用协议栈 API，二者通过 sdk_config.h 与链接脚本中的内存布局约定协同。nRF Connect SDK（NCS）则基于 Zephyr RTOS，协议栈以库形式与内核、驱动一起编译，配置通过 Kconfig 与 devicetree 完成，不再有独立的 SoftDevice 二进制和 sd_* API 体系。

这意味着：如果项目需要 BLE 外设 + 简单广播、团队熟悉裸机或 FreeRTOS、且使用 nRF52832/52840 等老芯片，nRF5 SDK 仍是成熟选择；如果项目需要 蓝牙 Mesh、Thread、Zigbee、Matter、多协议并发，或使用 nRF5340/nRF52840 的新设计，应直接选 NCS。二者不是版本高低关系，而是面向不同产品形态的两条技术路线。

SoftDevice 型号与芯片的匹配关系

SoftDevice 型号命名中的数字代表协议能力与资源占用。S132 是 BLE 外设+中心角色协议栈，支持 nRF52832/52840；S140 是功能更全的 BLE 协议栈，支持 nRF52840/52833/52811；S113 是精简版 BLE 外设协议栈，面向 nRF52810/52811 等 Flash/RAM 受限芯片。选型时先看芯片，再看需要的角色与连接数，最后核对 Flash/RAM 余量。

SoftDevice 型号 × 芯片系列 × 开发框架 匹配关系 芯片系列 nRF52810 192KB Flash / 24KB RAM nRF52811 192KB Flash / 24KB RAM nRF52832 512KB Flash / 64KB RAM nRF52840 1MB Flash / 256KB RAM nRF5340 SoftDevice 型号 S113 BLE 外设 · 精简版 S132 BLE 外设+中心 · 多连接 S140 BLE 全功能 · 长包/DFU S340 BLE + 802.15.4 并发 NCS 无独立 SoftDevice 开发框架与适用场景 nRF5 SDK + S113 低成本 BLE 外设 · 裸机/FreeRTOS nRF5 SDK + S132 经典 BLE 产品 · 成熟稳定 nRF5 SDK + S140 BLE 长包/DFU · nRF52840 旗舰 nRF Connect SDK Mesh/Thread/Zigbee/Matter · 多协议 nRF5340 仅支持 NCS 实线：nRF5 SDK 路径　虚线：仅 NCS 路径

版本迁移的关键注意点

从 nRF5 SDK 迁移到 NCS 时，最容易被低估的是内存布局与中断模型的变化。nRF5 SDK 中 SoftDevice 占据固定 Flash 起始区域，应用从 0x00026000（S132 典型值）开始，RAM 起始地址也需为协议栈预留；NCS 中这些由链接脚本和 Kconfig 自动管理，但应用不能再直接写 NRF_SDH_BLE_* 宏，而要改用 CONFIG_BT_* 配置项。

另一个高频问题是 API 语义差异。例如广播启动，nRF5 SDK 使用 sd_ble_gap_adv_start() 并传入 ble_gap_adv_params_t；NCS 使用 bt_le_adv_start()，参数为 bt_le_adv_param 结构体，且广播数据通过 bt_data 数组组织。连接参数更新、GATT 服务注册、DFU 流程的接口也全部不同，不能逐行移植。

迁移前必须确认：目标芯片是否被 NCS 支持（nRF5340 仅 NCS）；原有 SoftDevice 型号是否有 NCS 等价能力（如 S140 的 BLE 长包在 NCS 中对应 CONFIG_BT_CTLR_DATA_LENGTH_MAX）；DFU 方案是否从 nRF5 SDK 的 bootloader 切换到 NCS 的 MCUboot + SMP。

选型决策的实操顺序

建议按以下顺序锁定版本，避免反复返工：

  1. 先定芯片：根据产品功耗、Flash/RAM、是否需要 802.15.4 或 USB，确定 nRF52810/52832/52840/5340。
  2. 再定协议能力：纯 BLE 外设选 S113/S132；需要中心角色或多连接选 S132/S140；需要 BLE + 802.15.4 并发选 S340；需要 Mesh/Thread 直接进 NCS。
  3. 核对资源余量：以 S132 v7.2.0 为例，其 Flash 占用约 152KB、RAM 约 6KB（具体随配置变化），nRF52810 的 192KB Flash 在加入应用后余量紧张，应优先考虑 S113。
  4. 锁定 SDK 版本：nRF5 SDK 建议使用 17.1.0（最后一个主版本），NCS 建议使用当前 LTS 版本，并记录 west manifest 中的 revision，保证团队一致。
  5. 验证编译与烧录：用 nrfjprog --program softdevice.hex --chiperase 烧录协议栈，再烧应用；NCS 则用 west flash，确认分区表与 MCUboot 槽位正确。

经验判断：如果项目生命周期内可能增加 Thread 或 Matter 需求，即使当前只做 BLE，也建议直接选 NCS + nRF52840/5340，避免后期整体重写。反之，若产品已量产且仅需维护 BLE 功能，继续使用 nRF5 SDK 17.1.0 + 对应 SoftDevice 是风险最低的方案。

版本选型的本质是把芯片资源、协议能力、框架生态三者的约束提前对齐。先画清楚匹配关系，再动手建工程，比编译报错后再回头查手册要高效得多。

← 上一章 📖 返回目录 下一章 →