Pico W基于C/C++ SDK適配RT-Thread Wi-Fi經驗總結

前言：

Pico W 作為 Raspberry Pi Pico 的衍生版本，主要增加了無線通信的功能，通過搭載 CYW43439 無線芯片，支持 2.4 GHz Wi-Fi 4 及藍牙5.0 ，其余和 Raspberry Pi Pico 基本相同，外部引腳也相互兼容。

也可以參考我之前文章中介紹的使用 Clion 搭建開發調試下載環境，同樣適用。這里需要注意的一點是，當你首次燒錄使板載 LED 閃爍的程序時，開發板可能沒有相應的現象，這可能不是你下載失敗了，也不是你的開發板是壞的，而是 Pico W 的板載 LED 由無線模塊控制

準備工作

開發環境搭建完成后，接下來就可以根據樹莓派官方的 SDK 和 Example 調一調程序，逐漸梳理清楚邏輯和各模塊之間的依賴關系。例如先運行一個最簡單的 Wi-Fi scan 的示例程序，其主要邏輯是先 cyw43_arch_init() 初始化模塊，再通過 cyw43_arch_enable_sta_mode() 使能為 STA 模式，最后使用cyw43_wifi_scan() 開始掃描并注冊掃描完成回調函數打印掃描結果，整體的邏輯和 API 還是很簡潔明了的。

開始開發

主要有以下三種類型：poll , threadsafe_background, freertos 。poll 是需要用戶定期調用的，并且不保證線程安全性；threadsafe_background 和 freertos 能夠保證線程安全性，threadsafe_background 不使用 RTOS，通過低優先級的 ISR 實現調度同步，freertos 是通過專門的線程處理調動同步。

一開始我選擇的是基于 threadsafe_background 進行開發，通過參照以上 Cmake 關系圖很快就成功在 RT-Thread 的 Bsp 中復現了 Wi-Fi scan 示例程序。但是開發后續需要使用 lwip 的功能時，與 RT-Thread 就產生了很多沖突。

想要更好的適配 RT-Thread 還是得按照 RTOS 的來，于是開始復現官方提供的基于 FreeRTOS 的，首先想到的是使用 RT-Thread 的 FreeRTOS 兼容層軟件包，在 menuconfig 中使能即可：

引入兼容層后大部分報錯消失了，但報錯沒有 portCHECK_IF_IN_ISR 的相關實現，在 FreeRTOS 的源碼中查找發現其為 RP2040 特有的實現。其是用于判斷上下文環境是否處于中斷中，改為 RT-Thread 中的檢測中斷 nest 是否大于 0 即可。

成功編譯下載程序后，卻因為定時器進入了 hardfault ，檢查發現 FreeRTOS 兼容層中的 portMAX_DEALY 對接錯了，不是 RT_TICK_MAX ，應該為 RT_TICK_MAX / 2 - 1（韋東山老師在rtt開發者大會上專門講解過 RTT 優雅的定時器算法，感興趣可以看看）這個問題目前已經修復了。

之后程序還是進入 hardfault ，一直 debug 對比代碼沒有發現問題，再次分析對比 FreeRTOS 和 RT-Thread 之間的差異，兩者的優先級等級和數值的關系是相反的，檢查發現 async_context_task 線程的優先級為 tskIDLE_PRIORITY + 4 在 FreeRTOS 中優先級比空閑線程高4，但在 RT-Thread 中因為優先級太低，得不到調度，造成死鎖問題。解決辦法是將其線程優先級提高。

移植 RT-Thread

以上的示例程序跑通以后，就開始將 wifi freertos 的相關的文件移植為 RT-Thread 。主要包含以下內容：

替換頭文件：

用 RT-Thread 的頭文件替換 FreeRTOS 的頭文件。

修改任務創建和管理：

使用 RT-Thread 的任務創建和管理 API 替代 FreeRTOS 的任務 API。

注意 RT-Thread 的任務入口函數參數和返回值的差異。

修改互斥鎖：

替換 xSemaphoreCreateRecursiveMutex 為 RT-Thread 提供的互斥鎖創建 API。

替換 xSemaphoreTakeRecursive 和 xSemaphoreGiveRecursive 為 RT-Thread 互斥鎖的 API。

替換定時器：

使用 RT-Thread 的軟定時器或者實時時鐘服務替代 FreeRTOS 定時器。

任務通知：

替換 FreeRTOS 的任務通知 API 為 RT-Thread 的事件和信號量等。

任務掛起和喚醒：

替換 FreeRTOS 的 vTaskSuspend 和 vTaskResume 為 RT-Thread 的任務掛起和喚醒 API
主要涉及 async_context_rtthread，cyw43_arch，cyw43_arch_rtthread，lwip_rtthread這些文件，基礎的移植完成后，就可以開始將其對接到 RT-Thread 的 Wi-Fi 設備驅動框架了，主要參考 rw007 和 cyw43012-RTT 的對接。需要使能 RT-Thread 的 lwip 和 SAL 等組件。
需要注意的一點是 RT-Thread 的 lwip 組件使能后，已經包含了 lwip 的初始化，cyw43_arch_init() 中的 lwip 初始化相關注釋即可，否則重復初始化會因為完成量無法獲取造成阻塞。

#if CYW43_LWIP
// ok &= lwip_rtthread_init(context);
#endif
// 重復初始化信號量無法獲取造成阻塞
bool lwip_rtthread_init(async_context_t *context) {
RT_ASSERT(!lwip_context);
lwip_context = context;
static bool done_lwip_init;
if (!done_lwip_init) {
done_lwip_init = true;
rt_sem_t init_sem = rt_sem_create("lwip_init_sem", 0, RT_IPC_FLAG_PRIO);
tcpip_task_blocker = rt_sem_create("tcpip_task_blocker", 0, RT_IPC_FLAG_PRIO);
tcpip_init(tcpip_init_done, init_sem);
// 阻塞在信號量獲取
rt_sem_take(init_sem, RT_TICK_MAX / 2 - 1);
rt_sem_delete(init_sem);
} else {
rt_sem_release(tcpip_task_blocker);
}
return true;
}

運行過程中可能會報錯提示 lwip 線程?？臻g不足，在 menuconfig 中適當改大即可

對接完成后測試功能，使能為 STA 模式，日志中顯示 mac 地址

掃描附近ap

連接ap并成功ping通

測試ap功能，使能為AP模式，設置名稱及pwd，可以使用手機成功連接。

注意事項

使用pico w的無線模塊需要使用一些相關的宏定義，如無線模塊的引腳定義等，其定義在 picow.h 中。但程序默認包含的是 pico.h ?？梢酝ㄟ^定義宏 PICO_CONFIG_HEADER=boards/pico_w.h 進行切換。

吞吐量還未進行測試。

目前基于 C/C++ SDK 的開發案例較少，推薦直接閱讀官方文檔。

在對接設備驅動框架 wifi_join 方法時苦惱于 ap 的 channel 和 bssid 沒有正常傳遞，查看源碼發現使能 RT_WLAN_JOIN_SCAN_BY_MGNT
這個宏可以先掃描ap，并傳遞包含 channel 和 bssid 的 info，但要將以下改為rt_memcpy

個人理解，沒有找到其他的說明和用例。（不過最后發現，連接ap沒有 channel 和 bssid 也行，直接設置為 RT_NULL )