做低功耗Wi-Fi传感器节点的时候我想过好几条路线ESP32方案上手快但原厂SDK风格太重单独用Linux加USB Wi-Fi网卡硬件体积和功耗又不合适手里正好有一块NUCLEO-U5A5ZJ-QCortex-M33核跑起来绰绰有余于是开始研究能不能挂一颗Nordic的nRF7002直接在vanilla Zephyr主线里把Wi-Fi接口打通。折腾了几天结果是可行的。这篇文章就是把整个NUCLEO-U5A5ZJ-Q与nRF7002的接口过程、设备树写法、Kconfig配置和实际踩坑完整记录下来给那些同样想用Zephyr原生驱动把“非官方组合”跑起来的人做个参照。1. 为什么把ST的板子和Nordic的Wi-Fi芯片凑到一起1.1 项目最初的场景诉求我手头这个项目要做的是一个电池供电的环境监测节点数据量不大但要求支持Wi-Fi连接、远程配置和OTA升级。MCU部分选定STM32U5A5ZJ-Q原因很直接160MHz的Cortex-M33带TrustZone有充足的安全存储和TrustZone配套的外设隔离能力而且这颗料在ST的生态里属于新一代低功耗主力合适的睡眠模式下电流非常低。板子就选了ST官方的NUCLEO-U5A5ZJ-Q把它当成验证平台用。Wi-Fi部分比较头疼。最常见的做法是选ESP32或者ESP32-C3这类SoC直接跑Wi-Fi协议栈但这样等于系统里多了一个主控要么双MCU通信要么把业务逻辑全部搬到ESP32上。后者意味着应用层被绑定在乐鑫的SDK里考虑到团队对代码的可移植性和长期维护性要求我更倾向于保留STM32作为唯一主控Wi-Fi只用一颗配套芯片通过标准接口挂在STM32的SPI/QSPI总线上。这样协议栈跑在Zephyr的网络栈里应用层和硬件解耦得干净。1.2 nRF7002这颗companion IC和其他Wi-Fi模组的差异nRF7002不是一颗SoC它是一颗Wi-Fi 6 companion IC中文叫法常见是“配套芯片”或“协处理器”。它的定位和ESP32完全不同nRF7002本身没有应用处理器所有Wi-Fi MAC层的控制、协议栈、网络栈逻辑都跑在主机MCU上nRF7002只负责物理层、MAC层里对实时性要求极高的部分以及射频前端相关功能。主机MCU通过SPI或者QSPI接口向nRF7002下发命令和数据nRF7002把802.11帧处理好之后通过同样的总线把收到的包交给主机。这种架构最大的好处是主机MCU可以完全掌控Wi-Fi协议栈。Zephyr里面对nRF7002的驱动实际上就是一个基于Zephyr net stack的上层驱动配合底层的SPI/QSPI传输把nRF7002抽象成一个普通的IEEE 802.11网络接口。应用代码只需要用Zephyr标准的socket API、net_mgmt接口或者直接使用wifi_shell之类的工具连接网络不需要关心nRF7002内部寄存器怎么操作。另一个优势是功耗。nRF7002在休眠状态下的功耗非常低支持WPA3、Wi-Fi 6的多个特性对电池供电设备来说很有吸引力。相比之下很多Wi-Fi模组跑起来之后空闲功耗就摆在那边对低功耗场景不太友好。1.3 “vanilla Zephyr”对于这个组合意味着什么标题里“vanilla Zephyr”这个词翻译过来就是“原味Zephyr”意思是完全使用Zephyr上游主线代码不打私有补丁、不用Nordic私有SDK、不走厂商闭源BSP直接依赖Zephyr官方仓库里已经合入的nRF7002驱动和设备树支持。为什么会强调这一点因为如果走Nordic自家nRF Connect SDK (nRF Connect SDK简称NCS)nRF7002的开箱体验要顺畅很多Nordic在NCS里把驱动、固件、示例、shield定义都配好了。但NCS是基于Zephyr的一个长期维护分支里面加入了不少Nordic自己维护的模块跨厂商芯片组合的灵活性并没有那么高。vanilla Zephyr则更接近“社区通用主线”任何厂商的板子只要驱动合入主线理论上都能用相同的机制跑起来。这次把ST的板子和Nordic的Wi-Fi芯片在vanilla Zephyr里接起来正是要验证这种跨厂商组合在主线生态下的可行性。实际做下来主线Zephyr对nRF7002的支持确实已经可以用了。驱动入口在drivers/wifi/nrf700x设备树compatible是nordic,nrf7002只需要在板级overlay里把节点挂到合适的SPI总线上再把供电、中断、固件加载相关GPIO配好就能被驱动识别。整条链路不需要改任何Zephyr源码。2. 硬件搭线NUCLEO-U5A5ZJ-Q与nRF7002的连接方式2.1 nRF7002的接口协议与引脚功能nRF7002对外主要提供SPI和QSPI两种总线接口具体用哪种由外部引脚配置决定。实际调试我建议先从SPI开始因为SPI的引脚数量少、接线简单、调试门槛低等SPI链路完全跑通之后再考虑切换到QSPI提升吞吐量。从nRF7002模组/芯片引出的关键信号大致如下信号名方向功能说明SPI_CLK / QSPI_CLK输入时钟信号SPI_MOSI / QSPI_IO0输入主机到nRF7002的数据线SPI_MISO / QSPI_IO1输出nRF7002到主机的数据线SPI_CS / QSPI_CS输入片选信号低有效IRQ输出中断请求通知主机有事件需要处理RESET输入复位信号VIO电源IO电平参考电源决定SPI接口电平VDD电源芯片主电源ANT_CTRL1 / ANT_CTRL2输出外部天线开关控制FEM_CTRL输出外部前端模块控制如果用的是成品nRF7002模块可能还会引出BUCK、VIO_REGulator等引脚用于控制内部DC-DC和IO电压。这些引脚在Zephyr设备树里会有对应的GPIO属性需要正确接好否则驱动初始化时电压或供电状态不对芯片根本起不来。2.2 在NUCLEO板上挑选合适的SPI外设与GPIONUCLEO-U5A5ZJ-Q的Arduino排针上自带一组SPI接口对应关系如下D13 - PA5SPI1_SCKD12 - PA6SPI1_MISOD11 - PA7SPI1_MOSID10 - PA4可用作SPI1_CS这组引脚直接连到STM32U5的SPI1外设能少走很多线非常适合飞线调试。我最后选择的信号映射是nRF7002信号NUCLEO-U5A5ZJ-Q引脚备注SPI_CLKPA5SPI1_SCKSPI_MOSIPA7SPI1_MOSISPI_MISOPA6SPI1_MISOSPI_CSPA4SPI1_CSIRQPA1中断输入低延时可触发RESETPA0复位控制VIO_REGulatorPA2用于控制nRF7002的VIO电源BUCK_REGulatorPA3用于控制nRF7002的DC-DC使能ANT_CTRLPC0天线开关可选FEM_CTRLPC1外部前端控制可选这块板子的Arduino排针上还有5V和3.3V电源引脚nRF7002模块的VDD可以直接接到3.3V排针。接线时尽量把信号线剪短面包板上的长跳线在SPI时钟频率稍高时容易引入干扰我最后全部换成了杜邦线直接对插接触更可靠。2.3 供电、电平转换和天线部分要注意的事nRF7002的IO电平由VIO引脚决定并不是固定3.3V。不同厂家出的nRF7002模组VIO默认电压可能不同有的模组厂把VIO固定到1.8V有的固定到3.3V有的留了跳线可以切换。接STM32的SPI引脚之前一定要确认两边电平一致。如果nRF7002模组的VIO是1.8V而STM32的IO配置成3.3V输出长期使用有损坏风险最好加一级电平转换芯片。我手上的模组VIO可以调到3.3V所以直接连NUCLEO板的3.3V没问题。天线部分同样不能大意。nRF7002是Wi-Fi 6芯片工作在2.4GHz频段天线周围的布局和走线直接影响灵敏度。如果只是调试连通性可以用模组自带的PCB天线如果要测试真实吞吐尽量把模组放在远离大块铜皮和金属外壳的位置。使用外置天线时ANT_CTRL引脚要接对否则天线开关选错通路信号会非常弱。另外nRF7002的RESET不是简单的上电复位。Zephyr驱动在初始化阶段会通过GPIO控制RESET如果RESET引脚被其他外设复用或者悬空驱动可能会卡在“等待芯片响应”这一步。安全做法是把RESET接到MCU的一个普通GPIO并在设备树里明确声明让驱动自己管理复位时序。3. Zephyr项目初始化和内核选项配置3.1 获取Zephyr并切换到适配的版本nRF7002驱动在主线上已经存在但版本差异影响很大。太老的版本驱动不完整太新的版本可能又改变了Kconfig选项。建议先固定到一个经过验证的版本我使用的是Zephyr v3.7.0这个版本里drivers/wifi/nrf700x已经能比较稳定地工作。初始化工程时标准流程是west init -m https://github.com/zephyrproject-rtos/zephyr v3.7.0 cd zephyr west update west zephyr-export python3 -m pip install -r scripts/requirements.txt这里有一个值得注意的地方west update会拉取所有manifest里列出的模块包括hal、cmsis、crypto等时间比较长网络不好时容易中断。如果中断了重复执行west update就好west会断点续拉。3.2 创建工程基于board模板推荐的做法是先直接使用Zephyr官方提供的wifi_shell示例作为起点在它上面叠加自己的overlay文件验证硬件链路没问题之后再把工程复制出来改造成自己的应用。west build -b nucleo_u5a5zj_q zephyr/samples/net/wifi/wifi_shell不过为了让后面的工程结构更清晰我最终是新建了一个独立应用目录my_nrf7002_app/ ├── CMakeLists.txt ├── prj.conf ├── boards/ │ └── nucleo_u5a5zj_q.overlay └── src/ └── main.cCMakeLists.txt内容很简单cmake_minimum_required(VERSION 3.20.0) find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE}) project(my_nrf7002_app) target_sources(app PRIVATE src/main.c)main.c一开始甚至不用写任何业务逻辑只留一个打印即可。Wi-Fi连接功能全部通过Zephyr shell完成这样验证链路最简单。3.3 开启nRF7002驱动与网络栈的关键Kconfigprj.conf是决定系统行为的关键文件。下面是我反复调整后最终使用的核心配置CONFIG_NRF7002y CONFIG_NRF7002_FW_LOADERy CONFIG_NRF7002_SPIy CONFIG_WIFIy CONFIG_WIFI_SHELLy CONFIG_NETWORKINGy CONFIG_NET_L2_WIFI_MGMTy CONFIG_NET_IPV4y CONFIG_NET_DHCPV4y CONFIG_NET_SHELLy CONFIG_SHELLy CONFIG_SHELL_BACKEND_SERIALy CONFIG_SERIALy CONFIG_WPA_SUPPy CONFIG_WPA_SUPP_CRYPTOy几个配置的用途我重点说一下。CONFIG_NRF7002_SPIy决定使用SPI作为nRF7002的底层传输。如果后续改用QSPI需要打开CONFIG_NRF7002_QSPIy并关闭SPI。这里容易踩坑的是新版Zephyr里NRF7002配置项的位置在drivers/wifi/nrf700x/Kconfig下不同版本可能还会拆出一些子选项如果编译时发现CONFIG_NRF7002_SPI未定义就去west build -t menuconfig里搜一下确认。CONFIG_NET_L2_WIFI_MGMTy是Zephyr Wi-Fi连接管理的核心wifi shell、wifi管理事件都依赖它。CONFIG_WPA_SUPPy则是启用wpa_supplicantZephyr里Wi-Fi连接、密钥协商、WPA3这些能力都走这个组件。CONFIG_NET_DHCPV4y要注意很多Zephyr示例默认只开静态IP不开DHCP。如果不在prj.conf里打开连接路由器后不会自动获取IP后面ping外网会很不方便。CONFIG_NRF7002_FW_LOADERy负责在驱动初始化时把nRF7002固件下载到芯片内部。固件文件本身不在Zephyr源码里需要从Nordic的固件仓库单独获取下一节会和设备树一起说。4. 设备树overlay把nRF7002挂到SPI总线上4.1 理解nordic,nrf7002 compatible节点Zephyr的驱动和设备树是绑定关系nRF7002驱动在设备树中对应的compatible是nordic,nrf7002。驱动在初始化时会从设备树节点读取SPI总线的配置、中断GPIO、电源GPIO、天线GPIO等属性然后初始化内部状态机尝试向nRF7002下载固件。这意味着设备树节点几乎决定了整个硬件抽象层能否正确工作。属性名长什么样直接决定驱动能不能找到对应的GPIO和电源控制。以Zephyr主线驱动为准常见属性包括irq-gpiosnRF7002的中断输出引脚vio-regulator控制VIO电源的regulator phandlebuck-regulator控制DC-DC转换器的regulator phandleant-gpios天线开关控制引脚fem-gpios外部前端模块控制引脚wifi-fw-load固件加载控制引脚txn-gpios传输事务控制引脚如果你的模组没有某些引脚对应的功能属性可以不写驱动会跳过对应逻辑。但irq-gpios是必须的没有中断驱动无法感知nRF7002的初始化完成事件会一直等下去。4.2 一份最小可用的overlay文件我的boards/nucleo_u5a5zj_q.overlay内容如下/ { aliases { wifi nrf7002_spi; }; vio_reg: vio-regulator { compatible regulator-fixed; regulator-name VIO; regulator-always-on; enable-gpios gpioa 2 GPIO_ACTIVE_HIGH; }; }; spi1 { pinctrl-0 spi1_sck_pa5 spi1_miso_pa6 spi1_mosi_pa7; pinctrl-names default; cs-gpios gpioa 4 GPIO_ACTIVE_LOW; status okay; nrf7002_spi: nrf70020 { compatible nordic,nrf7002; reg 0; spi-max-frequency 8000000; irq-gpios gpioa 1 GPIO_ACTIVE_HIGH; vio-regulator vio_reg; buck-regulator vio_reg; wifi-fw-load gpioa 3 GPIO_ACTIVE_HIGH; status okay; }; };这段overlay做了几件事。第一在根节点定义了一个固定电压regulator名为vio-regulator实质是把PA2引脚拉高作为VIO电源使能。regulator-always-on表示这个regulator在上电后一直保持使能省去驱动里额外的上电序列逻辑。如果你希望驱动完全接管供电顺序可以把regulator-always-on去掉但调试初期没必要给自己找麻烦。第二把SPI1外设的引脚复用配置为PA5/PA6/PA7并指定PA4作为片选。这里的spi1_sck_pa5这种pinctrl名不是随便写的它必须存在于该板子的pinctrl定义文件里。NUCLEO-U5A5ZJ-Q的pinctrl节点定义在boards/arm/nucleo_u5a5zj_q/目录下编不过时去那里找可用的节点名就行。第三在SPI1总线下添加了nordic,nrf7002子节点。reg 0对应片选序号0也就是SPI1的cs-gpios数组里的第一个片选。spi-max-frequency初始设为8MHz对飞线调试来说比较保险。实际调试通过后我试着把频率调到16MHz短距离飞线下也能稳定工作再高就开始出现偶发固件加载失败。4.3 如果走QSPI而不是SPI设备树差异在哪QSPI的接线比SPI多两根数据线吞吐量却能提升不少。nRF7002在QSPI模式下使用四线IO理论上频率可以更高实际吞吐会明显优于8MHz SPI。不过STM32U5A5ZJ-Q的QSPI外设在Zephyr里通常以ospi1的形式暴露设备树挂载方式类似但pinctrl和父总线节点名完全不同。如果后续要切换QSPIoverlay大致长这样ospi1 { pinctrl-0 ospi1_clk_pb2 ...; pinctrl-names default; status okay; nrf7002_qspi: nrf70020 { compatible nordic,nrf7002; reg 0; spi-max-frequency 32000000; irq-gpios gpioa 1 GPIO_ACTIVE_HIGH; ... }; };这里我没有把完整pinctrl写出来因为不同板子的ospi引脚定义差别很大需要根据实际原理图去查。调试策略上我强烈建议先把SPI模式跑通确认nRF7002固件加载、Wi-Fi连接、网络通信都没问题了再迁移QSPI。如果一开始就上QSPI硬件问题、设备树问题、驱动问题混在一起很难定位。5. 编译、烧录与Wi-Fi连接验证5.1 west build的完整命令与常见告警在应用目录下执行west build -b nucleo_u5a5zj_q如果是从零开始加上-p always强制pristine构建west build -p always -b nucleo_u5a5zj_q编译过程如果出现undefined reference或者设备树节点找不到多半是overlay里的pinctrl名不对或者某个设备树属性写错。Zephyr有一个很有用的调试手段在编译命令后面加-t ram_report或-t rom_report可以查看内存占用west build -t menuconfig可以可视化查看所有Kconfig选项的实际状态。烧录直接使用板上ST-LINKwest flash烧录完成后打开串口终端波特率115200screen /dev/ttyACM0 115200如果使用的是Linux系统注意有的发行版会默认被brltty服务占用USB串口导致设备无法打开这个坑我在后面专门说。5.2 开机日志里应该看到什么上电后main.c的打印会出现之后Zephyr会初始化网络栈和Wi-Fi驱动此时串口日志大致会包含以下关键信息[00:00:00.000] *** Booting Zephyr OS build v3.7.0 *** [00:00:00.140] [0B;33m[00:00:00.140] inf wifi_nrf7002: nRF7002 initialized[0m看到nRF7002 initialized就说明驱动已经成功初始化固件也已经加载完成。如果卡在这里或者直接报failed to load firmware优先检查spi-max-frequency是否太高以及IRQ引脚的GPIO配置是否正确。之后输入uart:~$ wifi status如果驱动正常会返回类似Disconnected或者扫描到的网络列表。wifi scan可以扫描附近热点uart:~$ wifi scan扫描结果会列出AP的SSID、信道、信号强度、加密方式等信息。能够扫描到热点说明nRF7002的射频链路和固件都在工作。5.3 通过shell连接Wi-Fi的路由状态连接Wi-Fi的基本命令是uart:~$ wifi connect MySSID MyPassword连接成功后shell会打印连接状态和分配的IP地址。如果需要手动查看网络接口和路由信息uart:~$ net iface uart:~$ net route如果启用了DHCPnet iface里能看到IPv4地址自动获取成功。接着可以ping一下网关或者外网uart:~$ net ping 192.168.1.1在连上Wi-Fi的同一段网络里也可以用手机上安装的ping工具从外部ping一下nRF7002节点获得的IP验证双向通信正常。还有一点值得留意Zephyr的网络栈默认对IPv6的支持程度因配置而异。如果路由器发布了IPv6前缀并且CONFIG_NET_IPV6y已经开启可以用net ping测试一下IPv6地址这对后续做IPv6物联网方案有参考价值。6. 真实调试中踩过的几个坑6.1 Linux下USB串口被brltty抢走插上NUCLEO板打开/dev/ttyACM0screen启动后黑屏或者直接报Device or resource busy这是一个非常经典的Linux环境问题。dmesg里能看到类似这样的信息usb 1-3: usbfs: interface 0 claimed by ch341 while brltty sets config #1原因很直接Ubuntu/Debian系发行版默认安装的brltty盲文终端服务会识别某些USB串口设备并绑定导致普通用户无法打开。解决方法是停用并禁用这个服务sudo systemctl stop brltty sudo systemctl disable brltty然后再重新插拔USB线即可正常打开。这个问题不是ST板子独有的很多带USB转串口的开发板都会遇到遇到“打不开串口”先查这个。6.2 SPI速率与固件加载失败我最初把spi-max-frequency设在32MHz结果日志里反复出现[00:00:00.100] err wifi_nrf7002: nRF7002 failed to load firmware [00:00:00.200] err wifi_nrf7002: initialization failed排查过程比较痛苦。先检查了供电3.3V正常VIO_regulator也正常检查了IRQ引脚示波器上看不到nRF7002的响应脉冲最后怀疑到SPI速率上。把spi-max-frequency降到8MHz之后一次通过。飞线和面包板对高速SPI来说是灾难。nRF7002的SPI接口可以支持几十MHz但那是在PCB走线合理、阻抗匹配的情况下。手工飞线时信号完整性完全靠不住。我的建议是初始8MHz起步每一根信号线尽量短CS/CLK/MOSI/MISO四根线不要并行捆在一起如果接地点离得远SPI总线容易振铃可以考虑在CLK上串联一个33欧姆电阻QSPI模式对信号要求更高飞线调32MHz基本不现实这也是我一直建议先SPI后QSPI的原因。6.3 提示“connected”但IP始终ping不通连接Wi-Fi成功后wifi status显示Connected但net iface里IPv4地址是空的或者地址显示为0.0.0.0。这个坑最常见的原因是CONFIG_NET_DHCPV4没有打开或者路由表为空。还有一次地址获取成功但局域网内其他设备ping不通。查了很久最后发现是路由器开启了AP隔离无线客户端之间不能互访。这个问题和Zephyr无关但很隐蔽容易让人误判驱动有问题。验证时可以先ping网关网关通了说明上行链路正常再ping同一局域网内的其他设备如果网关通而设备不通大概率是路由器的隔离策略。另外如果连接的是企业级WPA2-Enterprise网络wifi connect命令需要额外指定EAP参数不能直接套用家庭网络的连接方式。这一步在Zephyr文档里有详细的说明我就不展开了。6.4 偶发复位后连接不上调试中遇到一个比较诡异的现象正常运行一段时间后nRF7002突然不响应了重新打开shell执行wifi connect也没反应只能断电重启。后来发现是nRF7002的固件加载流程和MCU的复位时序存在竞争关系。nRF7002作为外设它的复位和主机MCU的复位不是完全同步的。如果MCU重启太快nRF7002还处于上一次会话的某个状态驱动发送固件加载命令时nRF7002没有正确响应可能卡死。这种情况下驱动需要能够对nRF7002进行一次完整的外部复位。解决思路比较朴素给nRF7002的RESET引脚接一个GPIO在设备树里声明并让驱动初始化时先拉低RESET再释放。Zephyr驱动对RESET引脚的支持版本差异比较大如果当前版本不支持可以在自己的应用层通过GPIO操作来完成复位。我最后是在应用启动时手动操作一次RESET GPIO确保nRF7002处于干净状态再让驱动初始化问题得到缓解。6.5 低功耗模式下Wi-Fi模块睡死项目目标毕竟是电池供电所以我在完成基础连通后尝试让STM32U5进入低功耗模式。结果发现nRF7002在宿主MCU进入睡眠后也不会主动唤醒Wi-Fi连接。因为nRF7002的中断线只有在Wi-Fi事件发生时才会拉高而睡眠模式下的MCU如果没有配置成GPIO唤醒源根本无法响应。正确的做法是在设备树和驱动中把IRQ GPIO配置成可唤醒源并且让Zephyr的电源管理子系统感知到nRF7002处于活动状态。这部分功能依赖具体的Zephyr版本真正做产品时建议单独评估功耗需求而不是简单把MCU睡眠。现在Zephyr主线里nRF7002驱动的电源管理支持还在持续完善测试时需要多打日志观察。7. 性能测试与后续进阶方向7.1 吞吐量测试方法连接稳定后可以测一下实际吞吐量。简单方法是在Zephyr里跑一个iperf服务端或客户端。Zephyr有个示例叫samples/net/sockets/iperf把它集成进工程后在shell里启动iperf服务器然后用电脑上的iperf3客户端去连。我实测下来SPI 8MHz模式下nRF7002的UDP吞吐大约在2Mbps左右TCP吞吐略低。这个数值已经足够应对传感器数据上报、远程配置、OTA等场景。切换到32MHz QSPI后理论上能跑出更高吞吐但飞线条件下我没有测出明显改善可能信号完整性限制了速率上限。如果你的应用有大量视频或音频传输需求建议直接用PCB板级设计来解决SPI走线问题不要指望飞线。7.2 低功耗实测思路低功耗验证我建议分两步走。第一步先测静态功耗。让nRF7002进入sleep模式观察整个系统的待机电流。NUCLEO板自带的ST-LINK、LED灯、电平转换芯片都会消耗额外电流得到的数值只能作为相对参考不能代表最终产品功耗。第二步再做动态功耗评估。Wi-Fi通信本身是突发性的连接状态下在Beacon间隔内的睡眠窗口nRF7002的功耗会显著低于传输状态。如果要真正优化需要统计一个完整上报周期内的平均电流而不是只看峰值或只盯着某个瞬态。7.3 后续方向WPA3、多节点组网与自定义应用跑通wifi_shell只是第一步实际产品里不可能每台设备都靠人工输入命令连接网络。Zephyr提供net_mgmt事件机制应用层可以监听NET_EVENT_WIFI_CONNECT_RESULT、NET_EVENT_WIFI_DISCONNECT_RESULT等事件在代码里完成自动重连、失败告警、状态上报等功能。这也是从“板子能连Wi-Fi”走向“节点能用Wi-Fi”的关键一步。安全方面nRF7002支持WPA3Zephyr里通过CONFIG_WPA_SUPP_CRYPTOy和相关配置启用。如果搭建的测试路由器支持WPA3建议实际验证一下连接流程确保后续产品不会因为路由器安全策略升级而失效。再往后还可以考虑多节点组网。Zephyr对Wi-Fi Mesh的支持力度在增加如果设备数量多又没有独立网关Mesh方案会比每个节点直连路由器更方便管理。不过nRF7002驱动对Mesh的支持目前还在发展中做之前需要仔细确认所用Zephyr版本的能力边界。这次把NUCLEO-U5A5ZJ-Q和nRF7002在vanilla Zephyr里接起来的整个过程最深的体会是厂商SDK不是必需品主线Zephyr的跨厂商硬件抽象能力已经足以支撑“ST主控加Nordic射频”这种组合。但也不要指望它百分百零成本——设备树属性、Kconfig选项、固件加载路径这些环节仍然需要自己摸索和验证。如果你也准备做类似的跨厂商平台建议先固定一个已验证的Zephyr版本按照“SPI起步8MHz起步先跑通再优化”的节奏往前走。最后再分享一个实用小技巧在overlay里给所有required regulator加上regulator-always-on排查问题时可以少花很多时间在电源时序上。