MicroPython在RP2平台上的WiFi与多线程兼容性问题分析

问题背景

在MicroPython的RP2平台（包括Raspberry Pi Pico W和Pico 2 W）上，开发者报告了一个关于WiFi连接稳定性的重要问题：当系统启动第二个线程时，主线程中的WiFi连接功能会出现异常。这个问题在MicroPython 1.24.0版本后变得尤为明显，影响了基于RP2040和RP2350芯片的所有WiFi型号设备。

问题现象

开发者在使用过程中发现，当代码中启动第二个线程后，主线程中的WiFi连接操作会出现以下一种或多种异常情况：

1. 连接超时，无法建立WiFi连接
2. 出现各种CYW43驱动相关的错误信息，如"F2 not ready"、"core not in reset"等
3. 系统抛出EPERM权限错误
4. 在较新版本中，错误信息可能消失但连接仍然失败

技术分析

经过深入调查，发现问题根源在于MicroPython的任务调度机制与CYW43 WiFi驱动之间的交互问题。具体表现为：

1. 中断处理冲突：CYW43驱动依赖于GPIO中断（CYW43_PIN_WL_HOST_WAKE）来维持WiFi连接，这个中断可能被错误地分配到第二个核心处理

2. 任务调度问题：PendSV中断处理程序（用于后台任务调度）在两个核心上都能运行，而CYW43驱动对核心亲和性非常敏感

3. 驱动稳定性：CYW43驱动在初始化阶段特别脆弱，任何中断处理延迟或错位都可能导致连接失败

解决方案

针对这一问题，社区提出了几种解决方案：

1. 核心亲和性修复：通过修改PendSV_Handler，强制所有中断处理都在核心0上执行。具体实现是在处理程序开始处添加核心检查：

void PendSV_Handler(void) {
    if(get_core_num() == 1) return;
    // 其余处理逻辑...
}

2. 异步编程模式：对于网络应用，推荐使用asyncio异步编程模型而非多线程，这能避免核心间的任务调度问题

3. 驱动优化：在Pico SDK 2.1.1版本中，包含了一些WiFi稳定性的修复，但需要手动集成到MicroPython构建中

实践建议

对于开发者而言，可以采取以下实践来避免或解决此问题：

1. 版本选择：如果必须使用多线程，可考虑使用MicroPython 1.23.0版本

2. 代码结构调整：

   • 将WiFi初始化放在主线程中
   • 确保关键网络操作不在辅助线程中执行
   • 在启动线程前完成WiFi连接

3. 替代方案：对于网络服务器等应用，优先考虑使用异步编程模式

总结

这一问题揭示了嵌入式系统中多核心调度与硬件外设驱动交互的复杂性。MicroPython社区正在积极解决这一问题，开发者可根据自身需求选择临时解决方案或等待官方修复。理解这一问题的本质有助于开发者更好地设计RP2平台上的网络应用架构，避免潜在的不稳定性。

对于资源受限的嵌入式设备，开发者需要权衡多线程带来的便利性与系统稳定性之间的关系，在多数情况下，事件驱动或异步模型可能是更可靠的选择。