最近在给一个电池供电的智能传感节点做方案选型，又把 Nordic 的 nRF54L 系列从头到尾研究了一遍。这个系列对做低功耗物联网设备的老工程师来说应该不陌生：2024 年量产的 nRF54L15 以超低 RX/TX 电流、以及多协议并发的设计，把原先 nRF52840 时代很多"只能将就"的场景都变成了"可以好好做"。真正让我关注的是 Nordic 最近的持续拓展动作——在 nRF54L15 之外，又推出了 nRF54L10 和 nRF54L05 两颗面向高性价比物联网设备的多协议系统级芯片。
如果说 nRF54L15 是为了冲击能效上限，那么新增的两颗芯片就是为了把同一套低功耗多协议技术下放到更便宜的硬件上。做 IoT 产品的人都知道，一颗芯片的选型往往决定了整个 BOM 的成本、PCB 面积、电池寿命，甚至认证周期。所以这次把产品线摊开来看，我觉得值得写一篇拆解，从芯片本身的架构逻辑、多协议能力，到实际迁移开发会遇到的问题，一次性讲清楚。
1. nRF54L 家族版图补全：从旗舰到三档覆盖，系列化意味着什么
1.1 nRF54L15 先行，L10 与 L05 补上中间段
nRF54L15 是这一代架构的开路先锋，定位是"多协议低功耗旗舰"：一颗 128MHz 的 Arm Cortex-M33 核心，加上 1.5MB 非易失存储和 256KB RAM，2.4GHz 多协议无线电，支持蓝牙 5.4、Thread、Zigbee、Matter over Thread，也支持私有 2.4G 协议。它在 2024 年量产之后，已经成了不少高端可穿戴、智能门锁和传感器 Hub 项目的首选升级路线。
而我印象中 Nordic 随后做的动作非常有针对性：把同一套架构做了"阶梯式下放"，推出 nRF54L10 和 nRF54L05。
| 型号 | CPU | 非易失存储 | RAM | 封装参考 | 目标场景 |
|---|---|---|---|---|---|
| nRF54L15 | Cortex-M33 @128MHz | 1.5MB | 256KB | aQFN-40 / WLCSP | 高端可穿戴、复杂传感、Thread 边界路由 |
| nRF54L10 | Cortex-M33 @128MHz | 约 1MB | 约 128KB | aQFN-40 | 中档节点，带多点传感与 OTA 升级 |
| nRF54L05 | Cortex-M33 @128MHz | 约 500KB | 约 100KB | aQFN-40 | 低成本 Mass-market 节点，Matter/Thread/BLE 入门 |
注意，这里的存储容量是按我目前看到的官方资料整理的，芯片行业里量产阶段偶尔会有参数微调，做正式选型时一定以上市版本的 Product Specification 为准。但大方向已经很明确：nRF54L 从"一颗旗舰芯片"变成了一整个覆盖不同内存、不同价格段的家族。
1.2 共享架构带来的选型红利
很多厂商做"系列化"是简单砍配置：这颗少点 Flash，那颗去掉若干外设，然后重新写一套驱动、重新过一遍射频认证。但 nRF54L10 / L05 这么做，我的理解是它们和 nRF54L15 共享同一套芯片 IP、同一套无线电前端设计、同一套底层驱动，区别主要在非易失存储和 RAM 的容量，以及少量外设裁剪。
这对开发者是实实在在的红利：同一份 Zephyr 工程，在 L15 上调试好之后，切到 L05 上通常只需要调整内存相关配置和少量设备树内容，应用层代码、无线电配置、低功耗策略基本可以原样带过去。硬件设计上，L10 和 L05 的封装也都是 aQFN，引脚和供电方案如果设计得当，一块 PCB 甚至能同时承接三种芯片的贴片位。 这也解释了标题里的"持续拓展"——它不是在发布一款孤立的新品，而是把一个已验证的架构，批量转化为可以匹配不同价位产品的选项。
1.3 对老产品线 nRF52 / nRF53 的升级路径
nRF52832、nRF52840 在过去七八年里撑起了无数 IoT 产品的量产，很多工程师对它们的寄存器、API 甚至板子布线习惯都熟到闭着眼能画出来。但这两年做新项目，我越来越不推荐继续在新设计里用它们。理由很现实：nRF52 系列的单核 M4F 处理能力有限，Flash 虽然有 1MB，但跑 Thread/Matter 这类需要较大协议栈和 OTA 空间的应用时，经常要和外部 SPI Flash 做配合；另外它的待机电流和射频收发电流都比新一代明显偏高。
nRF53 系列是双核设计，能力很强，但对不少只需要"一颗 M33 + 多协议 + 低功耗"的应用来说，双核属于性能溢出，还带来更高的 BOM 成本和复杂度。nRF54L 系列正好卡在这个中间：单核 M33 频率上到 128MHz，存储和 RAM 给了充足余量，既不用像 nRF52 那样抠资源，也不用像 nRF53 那样承受双核调度负担。
2. 多协议与低功耗这两个关键词，放在物联网设备里到底指什么
2.1 功耗数字重新看：RX 2.2mA 意味着什么
做电池设备最关心的几个数字，无非是射频接收电流、发射电流、休眠电流，以及唤醒后的建立时间。nRF54L15 公布出来的典型值很亮眼：2.4G 接收电流约 2.2mA，发射 0dBm 时约 4.1mA，系统关断模式下的电流在 0.15uA 级别。对比 nRF52840 的 RX 大概 5mA 左右，RX 直接腰斩还不止。
但单看峰值电流容易忽视一个事实：IoT 节点绝大多数时间在睡觉，平均电流才是决定电池寿命的核心指标。我习惯用下面这种方式快速估算一颗芯片是否适合某个应用场景：
假设一个环境监测节点，每 300 秒唤醒一次，每次工作 100ms，其中 30ms 是 BLE 接收窗口，70ms 是传感器采样和数据处理。粗略等效一下：
- 工作态平均电流：nRF52840 方案按 5mA 算，100ms / 300s，均摊约 1.7uA；
- 休眠态电流：nRF52840 按 1.5uA 算；
- 总平均电流：约 3.2uA。
换成 nRF54L15 方案，工作态平均电流按 2.5mA 算，均摊约 0.8uA；休眠态如果做到 0.3uA 级别，总平均电流可以压到 1.1uA 上下。同样一颗 100mAh 的纽扣电池，理论寿命会从大约 3 年多拉到 8 年以上。当然实际还要算电池自放电、DC-DC 转换效率、温度降额，但方向是清楚的：低功耗数字每前进一小步，产品运营周期就多出肉眼可见的余量。
2.2 多协议不是"多个二选一"，而是并发与共存
"多协议 SoC"这个词听起来简单，但实际做到位并不容易。早年很多芯片虽然宣称支持 BLE 和 Zigbee，但运行时只能二选一，要么上电前烧录不同固件，要么运行时切换并断开当前连接。这对真实产品很痛苦——比如你有一个 Matter over Thread 智能门锁，日常挂在 Thread 网络上，但用户要用手机直接用蓝牙解锁，此时如果 BLE 和 Thread 不能同时工作，设备就得在网络之间"跳来跳去"，每次切换都是延迟和不稳定。
nRF54L 系列的无线电架构允许 BLE、Thread、Zigbee、私有 2.4G 并发运行，靠的是一个叫 MPSL 的多协议服务层做时间片调度。协议栈各自维护连接状态，底层射频轮流发射和监听，上层应用完全无感。实测下来，一个典型场景就是" Thread + BLE 同时在线"：Thread 负责 Matter 数据通道，BLE 负责本地配网或 OTA，两者互不打断。
这个特性对高性价比设备特别重要。过去想让一个低成本门锁同时支持 Matter 和蓝牙手机控制，要么加一颗单独的 BLE 芯片，要么选高价的旗舰平台。现在一颗 L10 级别的芯片就能搞定，省下的第二颗芯片成本、PCB 空间和天线隔离设计工作量，是实打实的降本。
2.3 安全与能效的平衡
低成本物联网设备的安全水平，过去普遍不高。很多产品为了省几毛钱，跳过硬件加密引擎，只在 MCU 里跑软 AES；密钥也随便存在 Flash 里。但这两年无论是运营商集采，还是海外渠道的要求，安全已经成了准入门槛。
nRF54L 系列在这点上没有因为定位低配而缩水：Arm TrustZone 做内存和执行隔离、CryptoCell-312 硬件加速加解密、安全启动与防回滚，还有篡改检测引脚和真随机数发生器。这些功能在低配的 L05 上也保留了。我的理解是，物联网设备一旦量上去，被批量提取密钥、伪造固件的风险就指数级上升，单纯的"加一把锁"不够，必须从启动链和密钥存储上做文章。把安全模块放到入门型号里，表面看增加了芯片成本，实际上帮产品省下了后续合规认证的功夫。
3. 高性价比物联网 SoC 的选型逻辑：别被型号和封装带着走
3.1 不同产品形态对应哪一颗
有了产品线之后，选型反而要更冷静。不能因为"L15 功能最强"就全用旗舰，也不能为了省几毛钱硬上 L05，结果 RAM 不够被迫砍功能。我一般按照产品的数据量和升级需求来分档：
- 智能门锁、门磁、烟雾报警器：这类设备需要较大的 Flash 存储 OTA 升级镜像、证书和本地事件日志，同时未来可能从单 BLE 升级到 Matter 协议。优先选 L10 或 L15，具体看团队计划支持的协议栈数量。
- 运动手环、戒指、健康监测贴片：传感器数据多在本地处理后丢弃，RAM 需求集中在算法缓冲区，L05 或 L10 都够。如果算法复杂到需要持续缓存原始波形，就上 L10。
- 温湿度计、空气质量传感器、智能按钮：这类简单节点资源需求很低，L05 就够跑 Matter over Thread 和 BLE 辅助配网，是典型的低成本 mass-market 场景。
- 工业状态监测振动传感器：要在本地跑 FFT 和异常判断，还需要可靠的远程升级与安全通信，L15 更稳妥，而且工业客户通常不差那 1 到 2 美元。
核心判断标准就三个：Flash 够不够放多版 OTA、RAM 够不够跑目标协议栈加应用缓存、以及是否需要同时在线多个无线协议。
3.2 同样是多协议芯片，和主流竞品差在哪
把视野放宽一些。市面上能跑 BLE + Thread/Matter 的低功耗 SoC，主要还有 Silicon Labs 的 EFR32 系列、TI 的 CC26x2 系列、NXP 的 K32W 系列，以及乐鑫的 ESP32-C6 这类偏 Wi-Fi 生态的芯片。每个都有自己强势的一面。
| 对比维度 | nRF54L 系列 | 主流竞品 | 我的看法 |
|---|---|---|---|
| 功耗 | RX 2.2mA 级别，业界第一梯队 | 多数在 4mA 到 6mA | 长续航场景优势明显 |
| 开发体验 | NCS + Zephyr，代码统一，例程丰富 | 各家有独立 SDK，学习成本不一 | Zephyr 生态的跨平台价值被很多团队低估 |
| Matter 支持 | 官方维护 Matter over Thread 轮子 | 多数支持，但适配深度差异大 | Nordic 在 Thread/Matter 上的投入算是老牌且持续 |
| 价格区间 | L05 面向大众市场，下探明显 | TI/Silabs 同档价格差距不大 | 最终看渠道供货和量产经验 |
| 国产替代 | 不适用 | ESP32-C6 价格低、资料多 | 如果产品需要 Wi-Fi 回传，乐鑫是另一套合理选择 |
说句公道话，做选型不用迷信任何单一品牌。如果你是纯 BLE 低功耗传感器，nRF54L 的功耗优势非常值得投入；如果产品必须既跑 Thread 又开 Wi-Fi，方案就得重新评估。芯片不是越强越好，匹配产品定义才是关键。
3.3 算一笔真实的 BOM 账
"高性价比"如果只盯单颗芯片采购价，很容易把方向带偏。我算过一笔相对完整的 BOM 账：
以一款电池传感标签为例：
- 存储成本：nRF52840 方案因为内置 Flash 有限，经常要外挂一颗 SPI Flash 存 OTA 镜像和证书。换成 nRF54L15 内置 1.5MB 后，这颗外部 Flash 可以去掉，直接省 0.1 到 0.3 美元，还少了布线长度过孔带来的 EMC 隐患。
- PCB 面积与层数：nRF54L15 的 WLCSP 封装面积明显比 nRF52840 的 QFN 小，天线下方走线的空间更宽松。很多项目可以从 4 层板压缩到 2 层板，单板制造费用直接下降 20% 到 30%。
- 匹配与外围元件：新一代射频前端集成度更高，匹配网络元件数量通常可以比上一代少一两个。元件单价不高，但贴片数量少了，良率和长期可靠性都会好一点。
- 认证复用：同一颗芯片的多协议能力意味着一个硬件版本可以进入 BLE 市场、Thread 市场和 Matter 市场，2.4G 频段的法规认证结果可以最大程度复用，省下的实验室测试工时和重新认证排队时间，对产品按期出货非常关键。
4. 迁移与开发实录：从 nRF5 SDK 到 NCS 会遇到的事
4.1 SoftDevice 退出历史舞台，Zephyr 成为主线
如果你是老一代 nRF 开发者，早年开发流程大概是：下载 nRF5 SDK，找来 SoftDevice 的 hex 烧录进去，然后调用一大堆ble_gap_、ble_gatt_开头的 API 写应用。这个模式在 nRF54L 时代已经彻底变了。现在 Nordic 主推的是 nRF Connect SDK（NCS），底层就是 Zephyr RTOS，协议栈不再是独立的 SoftDevice 固件，而是直接编译进应用镜像里。
这带来的变化是双面的。好处是版本管理统一、调试更顺，编译器能直接优化协议栈代码；坏处是学习曲线不一样了，Zephyr 的 Kconfig 配置、设备树覆盖、west 构建系统，每一样都需要时间适应。我见过不少团队迁移时卡在"找不到烧录文件"，实际上现在的产物就是zephyr.hex，协议栈已经合入其中，不需要再单独烧 SoftDevice。
4.2 一个最小工程的配置实践
用 nRF54L15DK 为例，创建一个最小 BLE 工程，流程大致是：
west init -m https://github.com/nrfconnect/sdk-nrf ncs cd ncs west update west build -b nrf54l15dk -d build/ble_hr samples/bluetooth/peripheral_hr west flash如果你的发行版没有对应的-d目录，先用west build -p always -b nrf54l15dk ...交叉编译。想确认当前 NCS 版本支持哪些板卡，直接跑：
west boards | grep nrf54l工程跑起来之后，prj.conf里最常用的配置长这样：
CONFIG_BT=y CONFIG_BT_PERIPHERAL=y CONFIG_BT_CTLR_MPSL=y CONFIG_NVS=y CONFIG_NVS_SECTOR_SIZE=4096CONFIG_BT_CTLR_MPSL这个开关是 nRF54L 系列启用多协议共存调度的关键。只有它打开，后续才能在 Zephyr 里同时拉起 BLE 和 802.15.4 协议栈。设备树层面，如果要把某个 GPIO 映射成 LED，就在 overlay 文件里写：
/ { leds { compatible = "gpio-leds"; led0: led_0 { gpios = < &gpio0 0 GPIO_ACTIVE_LOW >; label = "LED 0"; }; }; };很多刚迁移的同事会在这类细节上卡住：Zephyr 设备树的节点名、GPIO 控制器索引gpio0、以及label对应到devicetree里的路径，都需要和实际板卡原理图对齐。
4.3 实测踩坑：休眠电流、GPIO 漏电与射频匹配
迁移过程中，最容易出问题的反而不是射频，而是休眠电流和引脚配置。第一块自研板子上电后测休眠电流，发现比参考设计大了足足 40uA，排查一圈，问题出在一颗悬空的 GPIO 上——引脚没有在休眠前做下拉配置，内部结构通过上下拉路径产生了漏电。解决办法是在进入 System OFF 或 WFI 之前，统一把不需要保持电平的 GPIO 重新配置为输入下拉或模拟输入。
类似的经验还有：
- 串口调试口在休眠时如果外部接了 USB 转串口模块，TXD/RXD 会被外部设备拉成高电平，导致电流倒灌。量产固件里应确保休眠前
UART控制器进入禁用状态，或者在外部电路加电平隔离。 - 电源模式没选对。nRF54L 的 SMPS 模式如果没使能，供电效率会明显变差，直接影响整体功耗。这个要在工程初始化阶段就核对。
- 天线匹配不能照搬老设计。即使芯片换了，射频走线、匹配网络、天线型号也会影响发射电流和杂散指标。我测过一块板子 SWR 偏大，发射电流直接比参考设计高了 0.3mA 以上，最后换回规格匹配的天线才恢复正常，类似问题建议在打样时就用网络分析仪检查 S11，不要只看程序跑通就发版。
4.4 关于这个系列的一点点个人判断
如果把 nRF54L10 / L05 放在整个 IoT 市场里看，我认为它释放了一个明确信号：Nordic 想从"高端低功耗蓝牙之王"进一步渗透到大量出货的消费级、工业级基础传感器节点里。这个赛道的竞争者基本都在卷单芯片价格，但很少有人像它这样把多协议、低功耗、安全特性做成系列标配。
如果你现在的产品还在用 nRF52832 或 nRF52840，且近期有升级计划，我的建议是直接跨过 nRF53，认真评估 nRF54L 系列。先拿 L15 做原型验证，把功能跑通之后，再根据实际资源消耗换到 L10 或 L05 做量产降本。这个"先旗舰、后低配"的开发节奏，恰好是这个系列化产品线给项目带来的最大操作空间：从第一天就把高中低三档硬件规划放在同一个代码仓库里，后面切价格档位时，工作重心会从"重新写代码"变成"重新做资源预算"。我自己在下一轮方案选型里，大概也会按这个思路走。
