> For the complete documentation index, see [llms.txt](https://taiphoon-com.gitbook.io/taiphoon.com-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://taiphoon-com.gitbook.io/taiphoon.com-docs/knowledge-base/mcu.md).
# 微處理器(MCU)
### 什麼是 MCU
MCU（Microcontroller Unit，微控制器）是飛控板上的核心處理器，負責執行韌體、讀取感測器資料、計算姿態與控制輸出，並與 GPS、遙測、接收機、ESC 等周邊裝置通訊。
MCU 可以視為整個飛行控制系統的「即時控制中樞」。使用者在 ArduPilot 或其他相容飛控韌體中看到的大多數功能，例如感測器校正、姿態解算、PWM/DShot 輸出、Failsafe 判定與資料記錄，最終都由 MCU 協調執行。
### MCU 在飛行控制器上負責什麼
飛行控制器上的 MCU 通常會負責以下工作：
* 讀取 IMU、氣壓計、磁力計等板載感測器資料。
* 執行飛控韌體主迴圈，完成姿態估測、控制器運算與任務邏輯。
* 提供 UART、I2C、SPI、CAN 等介面，連接外部模組。
* 控制馬達輸出、蜂鳴器、LED 與其他板載 I/O。
* 處理開機流程、Bootloader、韌體更新與除錯連線。
對一般使用者來說，不一定需要直接操作 MCU 本身；但當你需要編譯自定義韌體、理解腳位分配、排查通訊異常或進行 ST-LINK 燒錄時，MCU 的基礎概念就很重要。
### 為什麼要了解 MCU
了解 MCU 並不是為了讓每位使用者都去做底層開發，而是為了在以下情境中更快判斷問題來源：
* 韌體無法正常刷寫或啟動。
* 某個 UART、I2C 或 CAN 周邊無法工作。
* 自定義板級設定時，需要對照腳位與資源分配。
* 板子進入 Bootloader、DFU 或 ST-LINK 燒錄流程時，需要確認 MCU 狀態。
範例：如果你在 Mission Planner 或其他工具中可以連線到飛控，但 GPS 沒有資料，問題可能不是「韌體壞掉」，而是 GPS 接錯 UART、序列埠參數設定錯誤，或該 UART 對應的 MCU 腳位資源未正確配置。
### MCU、CPU 與飛控 SoC 的差異
在飛控文件中，MCU 指的是具備即時控制能力的微控制器，通常整合處理核心、Flash、RAM 與多種周邊介面於單一晶片內。
它和一般桌機或高階運算平台常見的 CPU 不同。CPU 通常依賴外部記憶體與作業系統，適合高階計算；MCU 則更重視即時性、低延遲、可預測行為與直接控制硬體 I/O，這也是飛行控制器選用 MCU 作為主控的原因。
### 在飛控系統中，MCU 會連到哪些裝置
MCU通常不會單獨工作，而是與多種周邊形成完整系統。
常見連接對象包括：
* IMU：透過 SPI 或 I2C 傳輸加速度與角速度資料。
* 氣壓計、磁力計：提供高度與航向資訊。
* GPS / 羅盤模組：常透過 UART、I2C 或 CAN 連接。
* RC 接收機：透過 SBUS、CRSF、IBUS 等介面輸入控制訊號。
* ESC：透過 PWM、DShot 等協定輸出馬達控制命令。
* 地面站連線：透過 USB 或遙測 UART 與 Mission Planner / QGroundControl 通訊。
這也是為什麼 MCU 的周邊數量、通訊埠分配與 DMA/Timer 等資源規劃，會直接影響飛控板可支援的功能數量與擴充能力。
### Bootloader 與主韌體
在自定義 ArduPilot 板卡時，Bootloader 的編譯與燒錄不可跳過，之後才是主韌體配置與編譯。
可以把 Bootloader 理解成「開機後先執行的小型啟動程式」。它的工作通常包括：
* 初始化最基本的硬體狀態。
* 提供韌體刷寫入口。
* 決定是否跳轉到主飛控韌體執行。
當板子無法正常進入主韌體時，常見排查方向就是先確認 Bootloader 是否存在、USB/DFU 是否可辨識，以及是否需要透過 ST-LINK 重新燒錄。
### 開發者需要關注的 MCU 資源
如果你的用途不只是飛行設定，而是要維護自動駕駛韌體(Autopilot)板級支援或自定義韌體，建議重點理解以下幾項 MCU 資源：
* Flash：儲存 Bootloader 與主韌體映像。
* RAM：執行時資料、緩衝區與任務堆疊空間。
* UART：GPS、遙測、接收機或外部電腦連線。
* SPI / I2C：板載感測器與外部周邊通訊。
* Timer / PWM 輸出：馬達、舵機、蜂鳴器等控制。
* USB / DFU / SWD：刷寫、除錯與恢復用途。
在 ArduPilot 的板級移植流程中，這些資源會反映在 hwdef 設定與板卡定義中，因此 MCU 不只是硬體名稱，而是整個板級支援的核心基礎。
### 應該如何看待 MCU 規格
對一般使用者而言，MCU 規格最重要的不是「型號名稱本身」，而是它是否足以支撐你的任務需求與周邊配置。
可以用下面的方式理解：
| 關注項目 | 對使用者的意義 |
| ------------- | --------------------------------- |
| 運算能力 | 影響高頻控制、濾波、導航與複雜功能並行的餘裕。 |
| 記憶體容量 | 影響韌體功能空間、記錄與未來擴充能力。 |
| UART / CAN 數量 | 影響可同時接多少 GPS、遙測、接收機或 DroneCAN 周邊。 |
| SPI / I2C 資源 | 影響感測器配置與外接模組彈性。 |
| 刷寫與除錯方式 | 影響韌體升級、救援與開發維護便利性。 |
### 什麼時候需要直接處理 MCU
使用者在正常裝機與調參流程中，不需要直接操作 MCU。
但在以下情況，通常就需要進一步接觸 MCU 相關作業：
1. 需要重新編譯韌體時。
2. 韌體毀損，USB 無法正常辨識，需要 ST-LINK 救援燒錄時。
3. 需要確認某個周邊究竟接到哪組 UART / SPI / I2C 腳位時。
4. 要做板級客製、功能裁剪或除錯時。
### 常見誤解
**誤解 1：MCU 越新，飛控一定越好。**\
不一定，飛控表現還取決於板級供電、感測器配置、佈線品質、韌體支援成熟度與 I/O 規劃。
**誤解 2：只要能刷進韌體，所有周邊就一定能用。**\
不一定，周邊是否能正常工作，還取決於 MCU 腳位映射、通訊埠分配、參數設定與接線方式是否一致。
**誤解 3：MCU 問題一定要拆板才知道。**\
很多問題其實可以先透過地面站的感測器狀態、序列埠設定、開機行為與刷寫模式來初步判斷。
### 注意事項
**注意：** 在未確認接線、供電與韌體版本之前，不要直接判定 MCU 故障；飛控無法啟動、無法連線或感測器異常，常見原因也可能是供電不穩、接線錯誤或參數設定不符。
**注意：** 若需要使用 ST-LINK、SWD 或進行底層燒錄，請先整理對應接點、電壓條件與流程文件，避免在接線錯誤的情況下對板子造成進一步風險。