Matter nRF Connect 平台架构解析:基于 nRF Connect SDK 的蓝牙、Thread、Wi-Fi 集成与 GN/CMake 混合构建体系 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配对配网、ThreadOpenThread网状网络、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低功耗蜂窝物联网 SoCnRF7002Wi-Fi 6 协处理器nRF5340双核蓝牙 SoCnRF52 系列低功耗短距离无线 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 对该目录进行了划分说明目录/文件内容chip-gn用于以nrfconnect平台集成层构建选定 CHIP 库的 GN 工程chip-modulechip-gn工程的 CMake 封装以及让 CHIP 作为 Zephyr 模块使用的其他组件app可供 nRF Connect 应用使用的公共及可选 Kconfig 配置文件蓝牙 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 LayerMPSL驱动允许在同一射频芯片上并发运行蓝牙 LE 与其他协议栈这是 BLE 与 Thread 共存concurrent通信的底层基础。从 Matter 侧的源码看nRF Connect 平台的蓝牙管理器通过直接复用 Zephyr 通用实现完成对接——src/platform/nrfconnect/BLEManagerImpl.h 的主体仅是一行包含#include platform/Zephyr/BLEManagerImpl.h也就是说BLE Manager 的配对、广播、CHIPoBLEchip-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_socketschip_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.11axWi-Fi 6标准。在仓库源码中Wi-Fi 相关的 Matter 适配实现集中在 src/platform/nrfconnect/wifi/包括NrfWiFiDriver.h/.cpp面向 nRF700x 的 Wi-Fi 驱动适配ConnectivityManagerImplWiFi.h/.cppWi-Fi 连接管理实现WiFiManager.h/.cppWi-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-FiCONFIG_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 ManagerThread 栈管理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::GenericConnectivityManagerImplConnectivityManagerImpl, public Internal::GenericConnectivityManagerImpl_UDPConnectivityManagerImpl, #if INET_CONFIG_ENABLE_TCP_ENDPOINT public Internal::GenericConnectivityManagerImpl_TCPConnectivityManagerImpl, #endif #if CHIP_DEVICE_CONFIG_ENABLE_CHIPOBLE public Internal::GenericConnectivityManagerImpl_BLEConnectivityManagerImpl, #else public Internal::GenericConnectivityManagerImpl_NoBLEConnectivityManagerImpl, #endif #if CHIP_DEVICE_CONFIG_ENABLE_THREAD public Internal::GenericConnectivityManagerImpl_ThreadConnectivityManagerImpl, #else public Internal::GenericConnectivityManagerImpl_NoThreadConnectivityManagerImpl, #endif #if CHIP_DEVICE_CONFIG_ENABLE_WIFI public ConnectivityManagerImplWiFi #else public Internal::GenericConnectivityManagerImpl_NoWiFiConnectivityManagerImpl #endif该实现还提供了 IPv6 网络状态检查的聚合逻辑IsIPv6NetworkEnabled()会依次检查 Thread 是否启用或 Wi-Fi 站点是否启用IsIPv6NetworkProvisioned()则检查 Thread 或 Wi-Fi 是否已完成配网从而让上层应用无需关心当前设备实际使用哪种无线技术。src/platform/nrfconnect/中还有其他面向实际量产/调试场景的组件包括FactoryDataProviderCBOR 格式工厂数据读取、OTAImageProcessorImplOTA 镜像处理、DFUSyncDFU 同步、DiagnosticDataProviderImplNrf诊断数据以及Reboot重启控制等这些共同构成了完整的平台支撑。构建系统GN 与 CMake 的双轨协作nRF Connect 平台使用两套构建系统来生成 ninja 构建脚本GNMatter 项目在绝大多数场景下使用CMakenRF Connect SDK 与 Zephyr 等 nRF Connect 平台相关组件使用。其协作流程如下Matter 的协议栈与平台模块使用GN构建见上文架构图构建产物用于生成库文件应用、nRF Connect SDK 与 Zephyr 使用CMake构建编译过程中导入 Matter 的库文件。由于 CHIP 本身并不原生提供 CMake 支持config/nrfconnect/chip-module/CMakeLists.txt 借助 CMake 的ExternalProject模块用 GN 元构建系统生成所需产物再通过matter_build(chip ...)将 GN 输出封装为 CMake targetchip、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 中的映射关系可以直接看作平台的「配置字典」常见映射如下GN 参数对应 Kconfig说明chip_enable_threadCONFIG_OPENTHREAD启用 Thread 支持chip_config_network_layer_bleCONFIG_BT启用 BLE 网络层配网通道chip_enable_wifiCONFIG_WIFI_NRF70启用 nRF700x Wi-Fichip_inet_config_enable_ipv4CONFIG_CHIP_IPV4启用 IPv4chip_enable_nfc_onboarding_payloadCONFIG_CHIP_NFC_ONBOARDING_PAYLOADNFC 配网载荷chip_enable_ota_requestorCONFIG_CHIP_OTA_REQUESTOROTA 请求方chip_enable_icd_serverCONFIG_CHIP_ENABLE_ICD_SUPPORT间歇性连接设备ICD支持chip_enable_factory_dataCONFIG_CHIP_FACTORY_DATA_NRFCONNECT_BACKEND启用 nRF Connect 工厂数据后端chip_crypto/chip_crypto_spake2pCONFIG_CHIP_CRYPTO_PSA使用 PSA 加密后端默认 mbedTLSchip_mdnsCONFIG_WIFI_NRF70/CONFIG_OPENTHREADminimalWi-Fi/platformThread/nonechip_system_config_use_openthread_inet_endpointsCONFIG_CHIP_USE_OPENTHREAD_ENDPOINT直连 OpenThread TCP/UDP 栈值得注意的是Kconfig 侧还定义了若干面向 nRF 平台的内存与运行配置例如 config/nrfconnect/chip-module/Kconfig 中的CONFIG_CHIP_TASK_STACK_SIZEMatter 线程栈大小默认 8192 字节启用 LTO 或 CC3XX PSA 驱动时为 10240 字节使用 CRACEN 时为 9216 字节CONFIG_CHIP_SYSTEM_PACKETBUFFER_POOL_SIZE内部报文缓冲池的报文总数默认 15CONFIG_CHIP_MAX_FABRICS设备可加入的最大 Matter fabric 数默认 5CONFIG_CHIP_FACTORY_DATA_WRITE_PROTECT工厂数据分区写保护依赖 FPROTECTnRF54L 系列除外。此外config/nrfconnect/chip-module/Kconfig.features 以「特性集」的形式聚合了 QSPI NOR、内存分析CHIP_MEMORY_PROFILING、蓝牙 SMP DFUCHIP_DFU_OVER_BT_SMP以及移除最后一个 fabric 后的动作CHIP_LAST_FABRIC_REMOVED_ACTION默认擦除 NVS 并重启等功能选项方便开发者按场景一键启用整套关联配置。小结nRF Connect 平台是 Matter 在 Nordic 硬件上的完整落地形态底层以 Zephyr RTOS 为运行环境蓝牙SoftDevice Controller MPSL、ThreadOpenThread nRF 802.15.4 驱动、Wi-FinRF7002 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创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考