TFC1 飛行測試：RP2354B 上的 BetaFlight
TFC1 自訂飛行控制器的首次飛行 — 韌體挑戰、感測器啟動和實際懸停測試
TFC1 自訂飛行控制器的首次飛行 — 韌體挑戰、感測器啟動和實際懸停測試
TFC1 板子在 3 月中旬到貨，第一個任務是用 BetaFlight 韌體啟動硬體。方法是系統性的：從最基本的配置開始，然後逐步新增週邊設備。
分階段建構了四種韌體配置：
由於 RP2354B 尚未成為 BetaFlight 的原生目標，我們開始使用 RP2350x 影像。RP2350 和 RP2354 主要在內部閃存容量和少數週邊缺陷上不同 — 核心架構是相同的。這為我們提供了一個合理的起點。
第一個重大障礙是一個令人困惑的問題：燒錄韌體後，BetaFlight Configurator 中沒有出現 UART 端口。只有 USB/CDC 端口可見。
根本原因是 BetaFlight 的 EEPROM 配置系統。在 PICO 平台上，內部閃存的最後 64 KB 儲存配置資料。當板子啟動時，它加載之前寫入 EEPROM 的任何 UART 針腳配置 — 而初始燒錄中沒有任何配置。
與 STM32 平台不同，STM32 的 BootLoader 支援完全晶片擦除，PICO 的 BootLoader 只接受拖放到 USB 大容量儲存裝置上的 UF2 檔案。沒有內建方法可以清除配置部分。
臨時解決方案是在每次啟動時強制重置 EEPROM：
if (isEEPROMStructureValid()) {
return;
}
resetEEPROM();這可以運作，但副作用是在每次重新啟動時清除所有飛行參數。正確的解決方案應該是特殊的 UF2 來擦除配置部分，或改進的 BootLoader — 兩者都暫時延後，因為完整的硬體配置使得這個問題越來越少見。
另一個發現：RP2350B 有三個 PIO（可程式化 I/O）區塊，但只有兩條 IRQ 線可用。每個 UART 需要一個 RX IRQ，這意味著最多同時只能啟用兩個 PIO-UART 實例。
除錯 UART 必須使用硬體 UART0 或 UART1 — PIO-UART 無法作為 stdio，因為它在啟動序列中初始化得太晚。這需要重新分配 GPIO 針腳：除錯移到 GPIO20/21（UART1），而原始 UART1 針腳（GPIO4/5 用於 GPS）移到 PIO-UART2。
Waveshare RP2350B-CORE 開發板上的 MPU6000 被 BetaFlight 韌體正確偵測。後續測試確認所有三種 IMU 變體（ICM-45686、ICM-42688、MPU-6000）都被飛控堆疊正確偵測。
然而，BetaFlight Configurator 最初無法顯示 ICM-45686 感測器 ID — 這是另一個與 Configurator 應用程式如何解析感測器名稱相關的獨立問題。透過更新到更新的韌體構建解決了這個問題，其中感測器名稱列表透過 CLI 從飛行控制器動態查詢，而不是依賴硬編碼的枚舉表。
飛行控制器啟動完成後，下一步是組裝。元件安裝在 2S 框架結構上進行初始測試。TFC1 板子整合到機體中，與 ESC、接收器和電源分配並排。
BetaFlight 的 BlackBox 日誌記錄配置為 UART 輸出。由於 TFC1 沒有板載 microSD 插槽，飛行資料透過 UART 上的 OpenLog 相容協議寫入外部裝置。這可以是專用的 OpenLog/OpenLager 硬體模組，或運行輕量級 blackbox 日誌記錄服務的 Raspberry Pi。
BetaFlight Configurator 中的設定：
set blackbox_device = SERIAL
set blackbox_mode = ALWAYS將 blackbox_mode 設定為 “ALWAYS”（而不是預設的 “NORMAL”）啟用連續記錄以進行地面測試，無需武裝無人機和飛行。
首次飛行測試確認 TFC1 可以成功運行 BetaFlight 韌體、偵測感測器、接收 RC 輸入和控制馬達輸出。RP2354B 順利處理飛控迴路，BetaFlight Configurator 正常回應以進行調校和設定。
基礎堅實 — TFC1 已準備好進行更進階的測試，包括光學流整合、GPS 定位和自主飛行模式。