> 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/ja/support/knowledge-base/mcu.md).

# マイクロプロセッサ(MCU)

マイクロコントローラー、ファームウェア、Bootloader とは何か

### MCU とは <a href="#mcu" id="mcu"></a>

MCU（Microcontroller Unit、マイクロコントローラー）はフライトコントローラー基板上の中核プロセッサで、ファームウェアの実行、センサーデータの読み取り、姿勢の計算と制御出力を担い、GPS、テレメトリー、受信機、ESC などの周辺機器と通信します。

MCU は、飛行制御システム全体の「リアルタイム制御の中枢」と考えることができます。ArduPilot やその他の互換フライトコントローラーファームウェアでユーザーが目にする機能のほとんど（センサーのキャリブレーション、姿勢推定、PWM/DShot 出力、Failsafe 判定、データ記録など）は、最終的にすべて MCU が調整して実行しています。

### フライトコントローラー上で MCU が担う役割 <a href="#mcu--morakot" id="mcu--morakot"></a>

フライトコントローラー上の MCU は、通常次のような処理を担当します。

* IMU、気圧計、磁気センサーなどのオンボードセンサーのデータを読み取る。
* フライトコントローラーファームウェアのメインループを実行し、姿勢推定、コントローラー演算、ミッションロジックを処理する。
* UART、I2C、SPI、CAN などのインターフェースを提供し、外部モジュールを接続する。
* モーター出力、ブザー、LED、その他のオンボード I/O を制御する。
* 起動プロセス、Bootloader、ファームウェア更新、デバッグ接続を処理する。

一般のユーザーは、MCU そのものを直接操作する必要は必ずしもありません。ただし、カスタムファームウェアのコンパイル、ピン割り当ての理解、通信異常のトラブルシューティング、ST-LINK による書き込みを行う場合には、MCU の基礎概念が重要になります。

### MCU を理解する理由 <a href="#mcu" id="mcu"></a>

MCU を理解する目的は、すべてのユーザーに低レイヤーの開発をしてもらうことではなく、次のような場面で問題の原因をより早く判断できるようにすることです。

* ファームウェアが正常に書き込めない、または起動しない。
* 特定の UART、I2C、CAN の周辺機器が動作しない。
* カスタムのボードレベル設定で、ピンやリソースの割り当てを照合する必要がある。
* 基板が Bootloader、DFU、または ST-LINK 書き込みプロセスに入ったときに、MCU の状態を確認する必要がある。

例：Mission Planner やその他のツールでフライトコントローラーに接続できるのに GPS のデータがない場合、問題は「ファームウェアの破損」ではなく、GPS が間違った UART に接続されている、シリアルポートのパラメータ設定が誤っている、またはその UART に対応する MCU のピンリソースが正しく構成されていない、といった可能性があります。

### MCU、CPU、フライトコントローラー SoC の違い <a href="#mcucpu--soc" id="mcucpu--soc"></a>

フライトコントローラーのドキュメントでは、MCU はリアルタイム制御能力を備えたマイクロコントローラーを指し、通常は処理コア、Flash、RAM、さまざまな周辺インターフェースを 1 つのチップに統合しています。

これは、一般的なデスクトップ PC や高性能コンピューティングプラットフォームでよく見られる CPU とは異なります。CPU は通常、外部メモリと OS に依存し、高度な計算に適しています。一方、MCU はリアルタイム性、低遅延、予測可能な動作、ハードウェア I/O の直接制御をより重視しており、これがフライトコントローラーのメインコントローラーとして MCU が選ばれる理由です。

### 飛行制御システムで MCU が接続される機器 <a href="#mcu" id="mcu"></a>

MCU は通常単独で動作するのではなく、さまざまな周辺機器とともに完全なシステムを構成します。

一般的な接続先は次のとおりです。

* IMU：SPI または I2C で加速度と角速度のデータを転送します。
* 気圧計、磁気センサー：高度と方位の情報を提供します。
* GPS / コンパスモジュール：多くの場合 UART、I2C、または CAN で接続します。
* RC 受信機：SBUS、CRSF、IBUS などのインターフェースで制御信号を入力します。
* ESC：PWM、DShot などのプロトコルでモーター制御コマンドを出力します。
* 地上局との接続：USB またはテレメトリー UART を介して Mission Planner / QGroundControl と通信します。

このため、MCU の周辺機能の数、通信ポートの割り当て、DMA/Timer などのリソース計画は、フライトコントローラー基板がサポートできる機能の数と拡張性に直接影響します。

### Bootloader とメインファームウェア <a href="#bootloader" id="bootloader"></a>

ArduPilot のカスタムボードを作成する場合、Bootloader のコンパイルと書き込みは省略できません。その後にメインファームウェアの構成とコンパイルを行います。

Bootloader は「起動後に最初に実行される小さな起動プログラム」と考えることができます。その役割は通常次のとおりです。

* 最も基本的なハードウェア状態を初期化する。
* ファームウェア書き込みの入口を提供する。
* メインのフライトコントローラーファームウェアにジャンプして実行するかどうかを決定する。

基板が正常にメインファームウェアに入れない場合、一般的なトラブルシューティングの方向性は、まず Bootloader が存在するか、USB/DFU が認識されるか、ST-LINK で再書き込みする必要があるかを確認することです。

### 開発者が注目すべき MCU リソース <a href="#mcu" id="mcu"></a>

飛行設定だけでなく、自動操縦ファームウェア(Autopilot)のボードサポートやカスタムファームウェアを保守する用途の場合は、次の MCU リソースを重点的に理解することをお勧めします。

* Flash：Bootloader とメインファームウェアのイメージを格納します。
* RAM：実行時データ、バッファ、タスクスタック領域です。
* UART：GPS、テレメトリー、受信機、または外部コンピューターとの接続。
* SPI / I2C：オンボードセンサーと外部周辺機器との通信。
* Timer / PWM 出力：モーター、サーボ、ブザーなどの制御。
* USB / DFU / SWD：書き込み、デバッグ、復旧の用途。

ArduPilot のボード移植プロセスでは、これらのリソースが hwdef 設定とボード定義に反映されます。そのため MCU は単なるハードウェア名ではなく、ボードサポート全体の中核的な基盤です。

### MCU の仕様をどう捉えるべきか <a href="#morakot--mcu" id="morakot--mcu"></a>

一般のユーザーにとって、MCU の仕様で最も重要なのは「型番名そのもの」ではなく、それがミッションの要件と周辺機器の構成を支えるのに十分かどうかです。

次のように理解することができます。

| 注目項目           | ユーザーにとっての意味                                      |
| -------------- | ------------------------------------------------ |
| 演算能力           | 高周波制御、フィルタリング、ナビゲーション、複雑な機能を並行して実行する余裕に影響します。    |
| メモリ容量          | ファームウェアの機能領域、記録、将来の拡張性に影響します。                    |
| UART / CAN の数  | GPS、テレメトリー、受信機、DroneCAN 周辺機器を同時にいくつ接続できるかに影響します。 |
| SPI / I2C リソース | センサー構成と外部モジュール接続の柔軟性に影響します。                      |
| 書き込みとデバッグの方式   | ファームウェアのアップグレード、復旧、開発・保守の利便性に影響します。              |

### MCU を直接扱う必要があるのはどんなときか <a href="#mcu" id="mcu"></a>

通常の組み立てやチューニングの過程では、ユーザーが MCU を直接操作する必要はありません。

ただし、次のような場合は、通常 MCU 関連の作業に踏み込む必要があります。

1. ファームウェアを再コンパイルする必要があるとき。
2. ファームウェアが破損して USB が正常に認識されず、ST-LINK による復旧書き込みが必要なとき。
3. ある周辺機器がどの UART / SPI / I2C ピンに接続されているのかを確認する必要があるとき。
4. ボードレベルのカスタマイズ、機能の削減、またはデバッグを行うとき。

### よくある誤解 <a href="#undefined" id="undefined"></a>

**誤解 1：MCU が新しいほど、フライトコントローラーは必ず優れている。**\
必ずしもそうではありません。フライトコントローラーの性能は、基板の電源供給、センサー構成、配線品質、ファームウェアサポートの成熟度、I/O 計画にも左右されます。

**誤解 2：ファームウェアさえ書き込めれば、すべての周辺機器は必ず使える。**\
必ずしもそうではありません。周辺機器が正常に動作するかどうかは、MCU のピンマッピング、通信ポートの割り当て、パラメータ設定、配線方法が一致しているかにも左右されます。

**誤解 3：MCU の問題は基板を分解しないとわからない。**\
多くの問題は、地上局のセンサー状態、シリアルポート設定、起動時の挙動、書き込みモードから、まず初歩的に判断できます。

### 注意事項 <a href="#undefined" id="undefined"></a>

**注意：** 配線、電源供給、ファームウェアバージョンを確認する前に、MCU の故障と判断しないでください。フライトコントローラーが起動しない、接続できない、センサーが異常といった症状は、電源供給の不安定、配線ミス、パラメータ設定の不一致が原因であることもよくあります。

**注意：** ST-LINK、SWD を使用する場合や低レイヤーの書き込みを行う場合は、接続箇所、電圧条件、手順書を事前に整理し、配線ミスの状態で基板にさらなるリスクを与えないようにしてください。
