移植20萬行程式碼才發現樹莓派Pico雙核MCU竟是三無產品? 是真香還是真不香?

樹莓派

Pico雙核MCU來了，要跟嗎？參考下其他人移植程式碼後的經驗

點選載入圖片

樹莓派Pico系統不完善

樹莓派Pico雙核MCU釋出有一段時間了，在嘗試將20萬行程式碼移植到Pico系統後發現，這個系統有不少大坑，還未入手的小夥伴考慮好後再入。將過程中遇到的各種坑彙總，以饗讀者。

點選載入圖片

樹莓派Pico移植20萬行程式碼

移植到樹莓派Pico系統的幾大問題

無OS，沒有thread，也沒有event，純粹單執行緒阻塞

常見的的模組在嵌入式系統裡面為適配不同的OS和系統往往設計一個OSAL適配層，這個層一方面向業務功能模組提供標準API，另一方面針對不同的OS或者系統實現對應的API。

點選載入圖片

樹莓派Pico移植OSAL

Pico系統目前是沒有使用常見OS的，也就是它本身是一個獨立的OS，模組移植需要針對其單獨寫一個適配層，會顯著增加模組的移植工作量。

同樣的，因為其沒有使用常見OS，那麼現有的其他模組，也無法直接簡單使用，都需要針對性的移植，這大大增加了整體的工作量。

另外系統裡面沒有thread，也沒有event，純粹是一個單執行緒的概念，這個對於通訊類應用會是個災難。

現有API不健全及完善

模組中常常使用系統提供的基礎功能來支援業務的實現，如各類外圍介面操作、定時器、佇列等等。 Pico現有的API函式實現都是骨頭級別的，並沒有針對常見使用的API做完整對標實現。 移植功能模組時需自行多一層包裝和除錯。

以timer這個常見功能為例，常見的使用邏輯如下：

建立timer實體，此時timer本身是沒有開始工作的

在需要開啟timer時，開啟timer

在需要關閉timer時，關閉timer

功能完成後刪除timer

Pico 系統API裡面提供的只有repeating timer這個，而這個是建立就是開始，而且並沒有對應的成對的開啟/關閉timer的API，在使用時，還需要自行驗證封裝。

點選載入圖片

PICO API timer

點選載入圖片

PICO 重複定時器

在系統API裡面，其他的部分也或多或少有類似的情況。 這一套本應該是OS或者類似OS的API介面，被Pico 比較特立獨行的封裝，其穩定及健壯性有待考驗。

模組化系統不完善

開源系統往往可以很方便地整合各類模組實現最終的功能，Pico整個系統是完全的CMake 風格，透過包含其核心SDK的CMake系統即可實現對應的編譯CMake。

但是，各類當前的已有的模組在它目前的程式碼結構裡面是沒有，需要自行移植。 另外，針對模組之間的依賴、相互限制、引用、宏依賴等等 都沒有做特別處理，

這些都需要在移植時自行研究摸索。

如果一個功能模組需要依賴比較多的其他模組，那麼這個過程會比較痛苦和耗費工作量

樹莓派Pico當前系統的幾大挑戰

針對Pico系統目前的現狀，將產品或者功能模組移植到此係統上時，會面臨較大挑戰，建議先進行評估再開展：

無OS，移植工作量大

新增OS後，前序移植工作量浪費

API尚不健全，穩定健壯性有待考驗，介面變化的可能性比較大

樹莓派Pico的幾個推測

樹莓派Pico目前還剛剛開始，針對接下來可能的發展做幾個小的預測：

WiFi版Pico W， 可能性 > 99。99999%。 沒有WiFi的MCU不是好IoT系統。

Arduino > 80%機率能跑，官方估計會半支援

80%機率 RPI 要在FreeRTOS+LWIP等組合基礎上出自己的‘OS’