企业官网建设流程全解析

Matter nRF Connect 平台架构解析：基于 nRF Connect SDK 的蓝牙、Thread、Wi-Fi 集成与 GN/CMake 混合构建体系

【免费下载链接】connectedhomeipMatter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.项目地址: https://gitcode.com/GitHub_Trending/co/connectedhomeip

导读

本文围绕 nRF Connect platform overview 展开，系统讲解 Matter 在 Nordic Semiconductor nRF Connect SDK 上的平台实现：包括蓝牙低功耗（BLE）配对配网、Thread（OpenThread）网状网络、nRF7002 Wi-Fi 6 连接的底层协议栈构成，以及 Matter 如何通过平台无关的 Manager 抽象层完成与 nRF Connect SDK / Zephyr 的对接。读完本文，你将理解 nRF Connect 平台上 Matter 应用的分层架构，掌握 GN 与 CMake 双构建系统协作生成固件的方式，并能结合仓库中的源码与配置（src/platform/nrfconnect/、config/nrfconnect/）定位对应实现。

上图为 nRF Connect 平台上典型 Matter 应用的简化结构示意，为便于阅读仅展示了对典型应用最重要的组件。

nRF Connect SDK 与 Zephyr RTOS 平台底座

nRF Connect SDK 是 Nordic Semiconductor 提供的软件开发套件，用于构建包括蜂窝物联网（LTE-M 与 NB-IoT）、蓝牙低功耗、Thread、Zigbee 以及蓝牙 mesh 在内的多种应用。该 SDK 面向 Nordic 的多个芯片系列提供：

• nRF9160：低功耗蜂窝物联网 SoC；
• nRF7002：Wi-Fi 6 协处理器；
• nRF5340：双核蓝牙 SoC；
• nRF52 系列：低功耗短距离无线 SoC。

nRF Connect SDK 以Zephyr RTOS为核心。Zephyr 是一个面向互联、资源受限设备的可扩展实时操作系统，支持多种硬件平台，并提供硬件驱动、应用协议、协议栈等能力。除 Zephyr 之外，nRF Connect SDK 还集成了以下关键组件：

• mbedTLS加密库；
• MCUboot引导加载程序；
• OpenThread—— Thread 协议栈的开源实现。

在 Matter 仓库中，nRF Connect 平台的适配层位于 src/platform/nrfconnect/，该目录下包含了平台配置头文件（如CHIPDevicePlatformConfig.h、CHIPPlatformConfig.h、BLEManagerImpl.h、ThreadStackManagerImpl.h等）以及 Wi-Fi 专用实现子目录wifi/；构建与配置脚本则统一放在 config/nrfconnect/ 下。其中 config/nrfconnect/README.md 对该目录进行了划分说明：

蓝牙 LE 协议栈：配对与网络配置的通道

在 nRF Connect 平台应用中，蓝牙 LE 接口用于在 Matter 设备与 Matter 控制器之间执行配对，以及 Thread 或 Wi-Fi 网络配置（provisioning）操作。完成配网后，设备即可在 Thread 或 Wi-Fi 网络内部与其他设备通信。

蓝牙 LE 通信所依赖的协议栈由两部分组成：

• 蓝牙 LE Host部分由 Zephyr RTOS 提供；
• SoftDevice Controller由 nRF Connect SDK 中的驱动实现。

nRF Connect SDK 的Multiprotocol Service Layer（MPSL）驱动允许在同一射频芯片上并发运行蓝牙 LE 与其他协议栈，这是 BLE 与 Thread 共存（concurrent）通信的底层基础。

从 Matter 侧的源码看，nRF Connect 平台的蓝牙管理器通过直接复用 Zephyr 通用实现完成对接——src/platform/nrfconnect/BLEManagerImpl.h 的主体仅是一行包含：

#include <platform/Zephyr/BLEManagerImpl.h>

也就是说，BLE Manager 的配对、广播、CHIPoBLE（chip-over-BLE）连接管理等具体行为由 Zephyr 平台实现承接。与之配套的配置项可在 config/nrfconnect/chip-module/Kconfig 中找到，例如：

• CONFIG_CHIP_CHIPOBLE_SINGLE_CONNECTION：默认开启，限制 CHIPoBLE 仅支持单连接，连接激活期间停止广播；
• CONFIG_CHIP_BLE_MULTI_IDENTITY_SUPPORT：支持多 BLE 身份，使设备可为不同用途维护独立的 BLE 广播与连接；
• CONFIG_CHIP_NFC_ONBOARDING_PAYLOAD：默认关闭，开启后可联动 NFC T2T/NDEF 相关配置，用于通过 NFC 携带配网载荷。

Thread 协议栈：OpenThread 与 IEEE 802.15.4 射频驱动

Thread 通信方面，nRF Connect 平台应用使用的 Thread 协议栈由多个项目分层协作构成：

• OpenThread是 Thread 协议栈的核心；
• IEEE 802.15.4 射频驱动（nRF 802.15.4 Radio Driver）由 nRF Connect SDK 提供；
• 网络层功能由 Zephyr 提供。

与 BLE 管理器类似，Thread 侧的管理器同样复用 Zephyr 实现——src/platform/nrfconnect/ThreadStackManagerImpl.h 通过以下包含语句接入 Zephyr 的 Thread Stack Manager：

#include <platform/Zephyr/ThreadStackManagerImpl.h>

在构建配置层面，Thread 的启用与否由 Kconfig 中的CONFIG_OPENTHREAD/CONFIG_OPENTHREAD_FTD控制，并在 config/nrfconnect/chip-module/CMakeLists.txt 中映射为 GN 参数：

chip_enable_thread <-- CONFIG_OPENTHREAD chip_openthread_ftd <-- CONFIG_OPENTHREAD_FTD chip_mdns_platform <-- CONFIG_OPENTHREAD

一个值得注意的选项是CONFIG_CHIP_USE_OPENTHREAD_ENDPOINT（默认开启，且仅支持不使用 Wi-Fi 的场景）：它让 Matter 直接使用 OpenThread 的 TCP/UDP 协议栈，而不再经过 Zephyr 的网络层，从而减少内存占用与报文转发路径。对应地，CMake 脚本会根据该选项决定是启用chip_system_config_use_openthread_inet_endpoints还是chip_system_config_use_sockets：

chip_system_config_use_sockets <-- NOT CONFIG_CHIP_USE_OPENTHREAD_ENDPOINT chip_system_config_use_openthread_inet_endpoints <-- CONFIG_CHIP_USE_OPENTHREAD_ENDPOINT

此外，当使用 Thread 时，Matter 的 mDNS 会采用platform实现（chip_mdns_platform），即借助 OpenThread 的 SRP/mDNS 能力进行设备发现。

Wi-Fi 协议栈：nRF7002 协处理器与 HostAP/WPA Supplicant

对于 Wi-Fi 通信，nRF Connect 平台应用使用以下两部分：

• Zephyr 移植版的 Host AP 与 WPA Supplicant：负责 Wi-Fi 管理帧处理与 WPA 认证；
• nRF Connect SDK 的 Wi-Fi 驱动（nRF700x）：实现主机 MCU 与nRF7002协处理器集成电路之间通过SPI 或 QSPI 总线的通信。nRF7002 符合 IEEE 802.11ax（Wi-Fi 6）标准。

在仓库源码中，Wi-Fi 相关的 Matter 适配实现集中在 src/platform/nrfconnect/wifi/，包括：

• NrfWiFiDriver.h/.cpp：面向 nRF700x 的 Wi-Fi 驱动适配；
• ConnectivityManagerImplWiFi.h/.cpp：Wi-Fi 连接管理实现；
• WiFiManager.h/.cpp：Wi-Fi 管理辅助逻辑。

从 Kconfig 可以看出 Wi-Fi 特性集的完整依赖关系。config/nrfconnect/chip-module/Kconfig 中的CHIP_WIFI选项会select WIFI_NRF70、WIFI、WIFI_NM_WPA_SUPPLICANT与NETWORKING，并imply NRF_SECURITY、NET_L2_ETHERNET、NET_IPV6_ND（邻居发现，用于处理路由器通告）等一系列网络选项。同时 config/nrfconnect/chip-module/CMakeLists.txt 将 Wi-Fi 相关 Kconfig 映射到 GN 参数：

chip_enable_wifi <-- CONFIG_WIFI_NRF70

并且当启用 Wi-Fi（CONFIG_WIFI_NRF70）时，Matter 的 mDNS 会切换为minimal实现（chip_mdns_minimal/chip_mdns = "minimal"），因为 nRF7002 方案下没有 OpenThread 提供的 SRP 服务，需要通过最小化 mDNS 实现自行完成设备发现。此外，CHIP_WIFI_CRYPTO_BACKEND选项允许在 PSA 与 mbedTLS 两种 Wi-Fi 加密后端之间选择，前者在启用CHIP_CRYPTO_PSA时作为默认值。

Matter 集成层：平台无关的 Manager 抽象

从网络层次看，Matter 位于上述模型的顶层应用层。BLE LE、Thread 或 Wi-Fi 协议栈由 nRF Connect SDK 与 Zephyr 提供，它们必须通过一个特殊的中间层与 Matter 协议栈集成。

在实际实现中，这一层包含 Matter 协议栈中定义的抽象 Manager 接口的平台特定实现，例如：

• BLE Manager（蓝牙管理）；
• Thread Stack Manager（Thread 栈管理）；
• Connectivity Manager（连接性管理）；
• Configuration Manager（配置管理）；
• Platform Manager（平台管理）。

由于这些抽象接口的存在，应用只需使用 Matter 的平台无关接口，无需执行额外的平台相关操作即可通过 Matter 协议栈进行通信。src/platform/nrfconnect/目录下的适配文件即为这些 Manager 的落地实现，例如：

• PlatformManagerImpl.h：使用 Zephyr 的 PlatformManager 平台实现；
• ConfigurationManagerImpl.h：使用 Zephyr 的 ConfigurationManager 平台实现；
• ThreadStackManagerImpl.h：使用 Zephyr 的 ThreadStackManager 平台实现；
• BLEManagerImpl.h：使用 Zephyr 的 BLEManager 平台实现。

ConnectivityManager是一个比较典型的综合示例。src/platform/nrfconnect/ConnectivityManagerImpl.h 通过大量条件编译，按需组合通用实现基类：

class ConnectivityManagerImpl final : public ConnectivityManager, public Internal::GenericConnectivityManagerImpl<ConnectivityManagerImpl>, public Internal::GenericConnectivityManagerImpl_UDP<ConnectivityManagerImpl>, #if INET_CONFIG_ENABLE_TCP_ENDPOINT public Internal::GenericConnectivityManagerImpl_TCP<ConnectivityManagerImpl>, #endif #if CHIP_DEVICE_CONFIG_ENABLE_CHIPOBLE public Internal::GenericConnectivityManagerImpl_BLE<ConnectivityManagerImpl>, #else public Internal::GenericConnectivityManagerImpl_NoBLE<ConnectivityManagerImpl>, #endif #if CHIP_DEVICE_CONFIG_ENABLE_THREAD public Internal::GenericConnectivityManagerImpl_Thread<ConnectivityManagerImpl>, #else public Internal::GenericConnectivityManagerImpl_NoThread<ConnectivityManagerImpl>, #endif #if CHIP_DEVICE_CONFIG_ENABLE_WIFI public ConnectivityManagerImplWiFi #else public Internal::GenericConnectivityManagerImpl_NoWiFi<ConnectivityManagerImpl> #endif

该实现还提供了 IPv6 网络状态检查的聚合逻辑：IsIPv6NetworkEnabled()会依次检查 Thread 是否启用或 Wi-Fi 站点是否启用，IsIPv6NetworkProvisioned()则检查 Thread 或 Wi-Fi 是否已完成配网，从而让上层应用无需关心当前设备实际使用哪种无线技术。

src/platform/nrfconnect/中还有其他面向实际量产/调试场景的组件，包括FactoryDataProvider（CBOR 格式工厂数据读取）、OTAImageProcessorImpl（OTA 镜像处理）、DFUSync（DFU 同步）、DiagnosticDataProviderImplNrf（诊断数据）以及Reboot（重启控制）等，这些共同构成了完整的平台支撑。

构建系统：GN 与 CMake 的双轨协作

nRF Connect 平台使用两套构建系统来生成 ninja 构建脚本：

• GN：Matter 项目在绝大多数场景下使用；
• CMake：nRF Connect SDK 与 Zephyr 等 nRF Connect 平台相关组件使用。

其协作流程如下：

1. Matter 的协议栈与平台模块使用GN构建（见上文架构图），构建产物用于生成库文件；
2. 应用、nRF Connect SDK 与 Zephyr 使用CMake构建；
3. 编译过程中导入 Matter 的库文件。

由于 CHIP 本身并不原生提供 CMake 支持，config/nrfconnect/chip-module/CMakeLists.txt 借助 CMake 的ExternalProject模块，用 GN 元构建系统生成所需产物，再通过matter_build(chip ...)将 GN 输出封装为 CMake target（chip、matter-data-model），最终链接进 Zephyr 应用镜像。

GN 侧的入口配置位于 config/nrfconnect/chip-gn/args.gni，其中关键设定包括：

chip_device_platform = "nrfconnect" chip_crypto = "mbedtls" chip_external_mbedtls = true custom_toolchain = "${chip_root}/config/nrfconnect/chip-gn/toolchain:zephyr"

即：指定平台为nrfconnect、使用外部（Zephyr 侧）mbedTLS，并指向名为zephyr的自定义工具链（定义于 config/nrfconnect/chip-gn/toolchain/BUILD.gn），从而让 GN 构建出的 Matter 库与 Zephyr 编译环境保持一致。

从 Kconfig 到 GN 的参数映射

CMake 封装层承担着「Kconfig 配置 → GN 参数」的翻译职责。config/nrfconnect/chip-module/CMakeLists.txt 中的映射关系可以直接看作平台的「配置字典」，常见映射如下：

值得注意的是，Kconfig 侧还定义了若干面向 nRF 平台的内存与运行配置，例如 config/nrfconnect/chip-module/Kconfig 中的：

• CONFIG_CHIP_TASK_STACK_SIZE：Matter 线程栈大小，默认 8192 字节，启用 LTO 或 CC3XX PSA 驱动时为 10240 字节，使用 CRACEN 时为 9216 字节；
• CONFIG_CHIP_SYSTEM_PACKETBUFFER_POOL_SIZE：内部报文缓冲池的报文总数，默认 15；
• CONFIG_CHIP_MAX_FABRICS：设备可加入的最大 Matter fabric 数，默认 5；
• CONFIG_CHIP_FACTORY_DATA_WRITE_PROTECT：工厂数据分区写保护（依赖 FPROTECT，nRF54L 系列除外）。

此外，config/nrfconnect/chip-module/Kconfig.features 以「特性集」的形式聚合了 QSPI NOR、内存分析（CHIP_MEMORY_PROFILING）、蓝牙 SMP DFU（CHIP_DFU_OVER_BT_SMP）以及移除最后一个 fabric 后的动作（CHIP_LAST_FABRIC_REMOVED_ACTION，默认擦除 NVS 并重启）等功能选项，方便开发者按场景一键启用整套关联配置。

小结

nRF Connect 平台是 Matter 在 Nordic 硬件上的完整落地形态：底层以 Zephyr RTOS 为运行环境，蓝牙（SoftDevice Controller + MPSL）、Thread（OpenThread + nRF 802.15.4 驱动）、Wi-Fi（nRF7002 + HostAP/WPA Supplicant）三条无线链路分别承担配网与组网职责；中间通过复用 Zephyr 通用实现的各类 Manager 完成与 Matter 协议栈的解耦；构建侧则以 GN 产出 Matter 库、CMake 负责 Zephyr 应用整合，并由 Kconfig 统一驱动配置。开发者如需深入了解或修改平台行为，可优先阅读 src/platform/nrfconnect/ 下的适配源码与 config/nrfconnect/chip-module/ 下的 Kconfig/CMake 配置；若需在此基础上进一步配置示例应用、CLI 或工厂数据，可继续阅读 docs/platforms/nrf/ 目录下的配套文档。

【免费下载链接】connectedhomeipMatter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.项目地址: https://gitcode.com/GitHub_Trending/co/connectedhomeip