最近在给一个电池供电的智能传感节点做方案选型又把 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 RAM2.4GHz 多协议无线电支持蓝牙 5.4、Thread、Zigbee、Matter over Thread也支持私有 2.4G 协议。它在 2024 年量产之后已经成了不少高端可穿戴、智能门锁和传感器 Hub 项目的首选升级路线。而我印象中 Nordic 随后做的动作非常有针对性把同一套架构做了阶梯式下放推出 nRF54L10 和 nRF54L05。型号CPU非易失存储RAM封装参考目标场景nRF54L15Cortex-M33 128MHz1.5MB256KBaQFN-40 / WLCSP高端可穿戴、复杂传感、Thread 边界路由nRF54L10Cortex-M33 128MHz约 1MB约 128KBaQFN-40中档节点带多点传感与 OTA 升级nRF54L05Cortex-M33 128MHz约 500KB约 100KBaQFN-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 SDKNCS底层就是 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_BTy CONFIG_BT_PERIPHERALy CONFIG_BT_CTLR_MPSLy CONFIG_NVSy CONFIG_NVS_SECTOR_SIZE4096CONFIG_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 做量产降本。这个先旗舰、后低配的开发节奏恰好是这个系列化产品线给项目带来的最大操作空间从第一天就把高中低三档硬件规划放在同一个代码仓库里后面切价格档位时工作重心会从重新写代码变成重新做资源预算。我自己在下一轮方案选型里大概也会按这个思路走。