ESP32を使い始めるとき、最初に迷いやすいのが開発環境です。
ESP32について調べると、
「Arduino IDEが簡単」
「PlatformIOの方が本格的」
「製品開発ならESP-IDFを使うべき」
といった情報が見つかります。
しかし、初めてESP32を使う場合、
「結局どれを選べばいい?」
「Arduino IDEで作ったプログラムは後から移行できる?」
「PlatformIOとESP-IDFは何が違う?」
「ESP-IDFはコマンド操作ができないと使えない?」
と迷うこともあると思います。
結論から言うと、すべての人にとって最適な開発環境が一つあるわけではありません。
試作を素早く動かしたい場合と、長期間保守する製品Firmwareを開発する場合では、求められるものが違います。
この記事では、ESP32でよく使われる
Arduino IDE
PlatformIO + Visual Studio Code
ESP-IDF + Visual Studio Code
の3つを比較し、それぞれどのような開発に向いているのかを解説します。
最初に知っておきたい「IDE」と「Framework」の違い
3つを比較する前に、少し整理しておきたいことがあります。
Arduino IDE、PlatformIO、ESP-IDFは、厳密にはすべて同じ種類のものではありません。
たとえば、
Arduino IDEはプログラムを編集・ビルド・書き込みするための統合開発環境です。
PlatformIOはVS Codeなどと組み合わせて利用できる組み込み開発向けの開発エコシステムで、ESP32ではArduino FrameworkとESP-IDFの両方を扱えます。PlatformIOの公式ドキュメントでも、ESP32向けFrameworkとしてArduinoとEspressif IoT Development Frameworkの両方が用意されています。
そして**ESP-IDF(Espressif IoT Development Framework)**は、Espressifが提供するESP32向けの公式開発Frameworkです。
そのため、
Arduino IDE vs PlatformIO vs ESP-IDF
という比較は、厳密には同じ階層の製品同士を比較しているわけではありません。
しかし実際にESP32を開発するときには、この3つが「どの環境で開発するか」という選択肢として比較されることが多いため、この記事でも実際の使い方を基準に比較します。
まずは3つの違いを比較
大まかな特徴を整理すると、次のようになります。
| 項目 | Arduino IDE | PlatformIO + VS Code | ESP-IDF + VS Code |
|---|---|---|---|
| 始めやすさ | ◎ | ○ | △ |
| プロジェクト管理 | △ | ◎ | ◎ |
| Arduinoライブラリ | ◎ | ◎ | △※ |
| ESP32固有機能 | ○ | ○~◎ | ◎ |
| 複数環境管理 | △ | ◎ | ○ |
| 本格デバッグ | △ | ○~◎ | ◎ |
| 設定自由度 | ○ | ◎ | ◎ |
| 学習コスト | 低 | 中 | 高 |
| 小規模試作 | ◎ | ◎ | ○ |
| 大規模Firmware | △ | ○~◎ | ◎ |
※ArduinoをESP-IDF Componentとして利用する方法もあります。Espressifも公式にこの構成をサポートしています。
この表だけを見るとESP-IDFが最も高機能に見えますが、高機能=すべての用途で使いやすい、ではありません。
LEDを点滅させたり、センサーを一つ接続したりするだけなら、Arduino IDEの手軽さは大きなメリットです。
逆に複数人でFirmwareを管理したり、細かなESP32の設定を扱ったりする場合には、ESP-IDFやPlatformIOが便利になります。
Arduino IDE|まずESP32を動かしたいなら強い
Arduino IDEの最大のメリットは、始めるまでのハードルが低いことです。
ESP32用のArduino Coreを導入すれば、Arduinoと同じような書き方でESP32を開発できます。
代表的なのが、
void setup()
{
Serial.begin(115200);
}
void loop()
{
}
というおなじみの構造です。
GPIO、UART、I²C、SPI、Wi-FiなどもArduino APIや対応ライブラリを利用して比較的簡単に扱えます。
Arduino IDEのメリット
特に大きいのが情報量とライブラリの多さです。
ESP32で何かを動かそうとして検索すると、Arduino向けのサンプルコードが大量に見つかります。
センサー、LCD、モーター、クラウドサービスなどについても、Arduino対応ライブラリが用意されていることがあります。
そのため、
まずESP32を触ってみたい
短時間で試作品を作りたい
既存ライブラリを利用したい
という場合には非常に便利です。
Arduino IDEのデメリット
一方、プロジェクトが大きくなると管理面で物足りなさを感じる場合があります。
ソースファイルが増えたり、複数のビルド条件を管理したり、ライブラリやFrameworkのバージョンを厳密に固定したりすると、より高度なプロジェクト管理が欲しくなります。
また、ESP32固有の細かな設定を扱う場合には、ESP-IDFの方が直接的です。
Arduino IDEが「簡易版ESP32開発環境」という意味ではありませんが、プロジェクトの規模や要求が大きくなるにつれて別の環境を検討する余地が出てくると考えると分かりやすいでしょう。
PlatformIO + VS Code|Arduinoから一段進んだ開発環境
Arduino Frameworkを使いたいけれど、プロジェクト管理もしっかり行いたい。
そんな場合に有力なのがPlatformIO + Visual Studio Codeです。
PlatformIOでは、プロジェクトごとにplatformio.iniを持ち、
[env:esp32dev]
platform = espressif32
board = esp32dev
framework = arduino
のように使用するPlatform、Board、Frameworkなどを設定できます。ESP32ではArduino FrameworkだけでなくESP-IDFも選択できます。
PlatformIOのメリット
PlatformIOの大きなメリットは、開発条件をプロジェクトとして管理しやすいことです。
たとえば一つのプロジェクトでも、
- 使用Board
- Framework
- Build Option
- ライブラリ依存関係
- Upload設定
- Debug設定
などを管理できます。
さらに複数のEnvironmentを定義すれば、同じソースコードを異なるBoardや設定でビルドするといった使い方もできます。
Gitでソースコードを管理する場合にも相性がよく、別のPCへ開発環境を移すときにも構成を再現しやすくなります。
PlatformIOにはESP32向けのデバッグやUnit Testingなどの仕組みも用意されています。
PlatformIOのデメリット
Arduino IDEと比較すると、最初に覚えることは増えます。
特に、
platformio.ini
Environment
Build Flags
Library Dependency
など、PlatformIO独自の仕組みを理解する必要があります。
Arduino IDEならメニューからBoardを選択して書き込むだけだったところを、設定ファイルで管理する場面も増えます。
また、PlatformIO自身とFrameworkのバージョン関係を意識する必要が出ることもあります。
そのため、
ESP32を初めて触る人が必ずPlatformIOから始める必要はない
と思います。
Arduino IDEでESP32の基本を理解した後、「プロジェクト管理をもっとしっかりしたい」と感じた時点でPlatformIOへ移るのも十分現実的です。
PlatformIOはArduino専用ではない
ここは意外と誤解されやすい部分です。
PlatformIOは、
ArduinoをVS Codeで使うためだけのツールではありません。
ESP32では、
framework = arduino
だけでなく、
framework = espidf
としてESP-IDFを使用することもできます。PlatformIO公式のEspressif 32 Platformでも両Frameworkがサポートされています。
つまり、
VS Code
│
PlatformIO
├── Arduino Framework
│
└── ESP-IDF
という使い方ができます。
この点を理解すると、
Arduino IDE → PlatformIO → ESP-IDF
という一直線の「初心者→上級者」の関係ではないことが分かります。
PlatformIOを使いながらArduino Frameworkで開発することもできますし、ESP-IDFで開発することもできます。
開発環境とFrameworkを分けて考えることが重要です。
ESP-IDF + VS Code|ESP32を本格的に扱う公式環境
ESP-IDFは、Espressifが提供するESP32シリーズの公式開発Frameworkです。
ESP32の機能をより直接的に扱うことができます。
以前は、
「ESP-IDFはコマンドライン操作が多くて難しい」
というイメージを持っていた人もいるかもしれません。
現在はEspressif公式のVS Code Extensionが用意されており、VS Code上からESP-IDFプロジェクトを扱えます。
Build、Flash、Monitorだけでなく、GDB/OpenOCDを利用したデバッグも公式Extensionから利用できます。
そのため、
ESP-IDF=ターミナルだけで開発する環境
という理解は現在では正確ではありません。
もちろん内部ではCMakeやESP-IDFのBuild Systemが動いているため、それらの知識が必要になる場面はあります。
しかし普段のBuild・Flash・MonitorなどはVS Code上から操作できます。
ESP-IDFを使うメリット
ESP-IDFを選ぶ大きな理由は、ESP32が持っている機能を公式Frameworkから直接利用できることです。
Arduino FrameworkでもESP32の多くの機能を利用できますが、より細かな設定やESP32固有機能を扱うようになると、ESP-IDFの方が分かりやすい場合があります。
たとえば、
- FreeRTOS
- Wi-Fi / Bluetooth
- Partition Table
- NVS
- OTA
- Power Management
- Watchdog
- Heap管理
- Logging
- JTAG Debug
- Core Dump
などを本格的に扱う場合です。
ESP-IDFでは、これらが公式ドキュメントの中で体系的に整理されています。
特に製品開発では、「とりあえず動いた」だけでなく、
なぜ動いているのか
異常時に何が起きるのか
メモリをどれだけ使用しているのか
どのバージョンでビルドしたのか
といったところまで管理したくなります。
このような開発ではESP-IDFのメリットが大きくなります。
ESP-IDFのデメリット
一方、ESP-IDFはArduino IDEと比較すると学習する内容が多くなります。
たとえばESP-IDFのプロジェクトでは、
project
├── CMakeLists.txt
├── sdkconfig
└── main
├── CMakeLists.txt
└── main.c
のような構成を目にします。
さらに、
- CMake
- Component
- menuconfig
- sdkconfig
- FreeRTOS
- Build System
など、ESP-IDF独自の仕組みを理解する必要があります。
最初は、
「LEDを点滅させたいだけなのに、覚えることが多い」
と感じるかもしれません。
これはESP-IDFが難しいというより、ESP32が持っている機能を細かく扱える分、開発者が理解する範囲も広くなると考えるとよいでしょう。
そのため、ESP32を初めて使う人が必ずESP-IDFから始める必要はありません。
まずArduino IDEでESP32そのものに慣れ、必要になった段階でESP-IDFへ進む方法もあります。
ArduinoとESP-IDFでコードは流用できる?
ここは開発環境を変更するときに気になるポイントです。
結論として、すべてのコードをそのまま移せるとは限りません。
たとえばArduinoでは、
digitalWrite(LED_PIN, HIGH);
delay(1000);
digitalWrite(LED_PIN, LOW);
のように記述できます。
一方、ESP-IDFではGPIO DriverやFreeRTOSのAPIなどを使用して実装できます。
つまり、実現している機能は同じでも、使用するAPIが異なる場合があります。
ただし、
- 自分で作成した計算処理
- 通信Protocolの処理
- データ変換
- 状態遷移
- デバイスに依存しないC/C++コード
などは、設計次第で流用しやすくできます。
これはESP32に限った話ではありません。
Firmwareを作るときに、Hardware依存部分とApplication部分を分離しておくと、FrameworkやMCUを変更するときの移植が楽になります。
ArduinoからESP-IDFへ途中で変更できる?
変更すること自体は可能です。
ただし、
ArduinoプロジェクトをESP-IDFプロジェクトへ変換するボタンを押せば終わり
というものではありません。
Arduino固有APIやArduino向けLibraryを大量に使用している場合は、それらをどう扱うか検討する必要があります。
小規模なプログラムならESP-IDFで書き直すこともできますが、ある程度開発が進んだプロジェクトでは移行工数が大きくなる可能性があります。
そのため、製品開発では開発初期に、
最終的にどこまでESP32の機能を使うのか
をある程度考えておくことをおすすめします。
たとえば、
「Wi-Fiでデータを送るだけ」
という製品と、
「Wi-FiとBLEを同時使用し、OTA、NVS、複数Task、Watchdog、低消費電力制御まで行う」
という製品では、必要になる開発環境も変わってきます。
ArduinoをESP-IDFの中で使う方法もある
ここまで読むと、
ArduinoかESP-IDFのどちらかを選ばなければならない
ように見えるかもしれません。
実際には、その中間的な方法もあります。
Arduino-ESP32は、ESP-IDFのComponentとして利用することができます。 EspressifのArduino-ESP32公式ドキュメントでも、この構成が案内されています。
イメージとしては、
ESP-IDF Project
│
├── ESP-IDF Component
├── 自作Component
│
└── Arduino Component
└── Arduino API / Library
という構成です。
これによってESP-IDFをベースにしながら、必要な部分でArduinoのAPIやLibraryを利用できます。
ただし、当然ながら構成はArduino IDE単体より複雑になります。
また、ESP-IDFとArduino Coreには対応するバージョンの組み合わせがあるため、好きなバージョン同士を自由に組み合わせられるわけではありません。
単純なプロジェクトで無理に採用する必要はありませんが、
「ESP-IDFへ移行したいが、既存のArduino資産も利用したい」
という場合には選択肢になります。
PlatformIOとESP-IDF + VS Codeはどちらを選ぶ?
この2つも迷いやすいところです。
どちらもVS Codeを使えるため、画面だけを見ると似ています。
しかし、考え方には違いがあります。
PlatformIO + ESP-IDFでは、PlatformIOがプロジェクトやToolchainなどを管理し、そのFrameworkとしてESP-IDFを使用します。
一方、
ESP-IDF + 公式VS Code Extensionでは、Espressif公式のESP-IDF環境をVS Codeから操作します。
そのため、ESP-IDFそのものを深く扱いたいのであれば、私はESP-IDF + 公式VS Code Extensionを選択肢の中心に置くのが分かりやすいと思います。
Espressifの公式Extensionでは、Build・Flash・Monitorだけでなく、Debug、Core Dump、Heap TraceなどESP-IDF向けの機能も提供されています。
一方で、
ArduinoとESP-IDFをプロジェクトごとに使い分けたい
複数のMCU Platformを同じ開発環境で管理したい
という場合にはPlatformIOのメリットがあります。
どちらが優れているというより、何を中心に管理したいかの違いです。
結局どのESP32開発環境を選べばいい?
ここまでの内容を用途別に整理します。
| 用途 | おすすめ |
|---|---|
| ESP32を初めて触る | Arduino IDE |
| LED・センサーなどを試したい | Arduino IDE |
| Arduino資産を活用したい | Arduino IDE / PlatformIO |
| VS CodeでArduino開発したい | PlatformIO |
| 複数Board・Build条件を管理したい | PlatformIO |
| ESP32固有機能を深く使いたい | ESP-IDF |
| FreeRTOSを本格的に使いたい | ESP-IDF |
| JTAG Debugなどを活用したい | ESP-IDF |
| 長期保守するFirmware | PlatformIO / ESP-IDF |
| ESP32以外のMCUも同じ環境で扱いたい | PlatformIO |
ただし、この表は絶対的なものではありません。
製品開発でもArduino Frameworkを採用することはできますし、個人の電子工作でESP-IDFを使っても問題ありません。
重要なのは、
開発者のレベルではなく、プロジェクトに必要な機能と管理方法で選ぶ
ことです。
「製品開発ならESP-IDF」は本当?
ESP32について調べていると、
「趣味ならArduino、仕事ならESP-IDF」
という説明を見かけることがあります。
これは少し単純化しすぎています。
製品Firmwareで重要なのは、Frameworkの名前そのものではなく、
- 使用バージョンを管理できる
- Build環境を再現できる
- Source Codeを管理できる
- エラー処理が設計されている
- Watchdogなど異常時の動作を考慮している
- Update方法を管理できる
- 長期間保守できる
といった点です。
Arduino Frameworkを使っていても、これらを適切に管理できていれば製品開発は可能です。
逆にESP-IDFを使っただけで、Firmwareの品質が自動的に上がるわけではありません。
ただし、ESP32の機能を深く利用する製品では、ESP-IDFの公式APIやDebug機能、設定機能などが大きなメリットになります。
そのため、要求仕様が複雑になるほどESP-IDFを選ぶ理由が増えていく、と考えるのがよいでしょう。
迷ったらこの順番でもよい
ESP32を初めて使う場合、最初から将来のすべてを予測する必要はありません。
一つの考え方として、
まずESP32を動かしたい
↓
Arduino IDE
↓
プロジェクト管理が必要
↓
PlatformIO + Arduino
↓
ESP32固有機能を深く扱いたい
↓
ESP-IDF + VS Code
という進み方もできます。
ただし、これは「レベルアップの順番」という意味ではありません。
Arduino IDEで十分なら、そのまま使い続けても問題ありません。
PlatformIOが自分の開発方法に合っていれば、ESP-IDFへ移行する必要もありません。
必要になったときに環境を変える。
これくらいの考え方でよいと思います。
まとめ|ESP32の開発環境は用途で選ぶ
ESP32では、Arduino IDE、PlatformIO、ESP-IDFなど複数の方法でFirmwareを開発できます。
それぞれに特徴があります。
Arduino IDE
手軽に始められ、Arduinoの豊富なLibraryやサンプルを利用しやすい。
PlatformIO + VS Code
プロジェクトや依存関係、複数のBuild環境を管理しやすく、ArduinoとESP-IDFの両方を扱える。
ESP-IDF + VS Code
Espressif公式Frameworkを使用し、ESP32固有機能やDebug機能を本格的に扱える。
重要なのは、
「どれが一番高機能か」ではなく、「自分の開発に何が必要か」で選ぶこと
です。
ESP32を初めて触るならArduino IDEから始めてもよいでしょう。
Arduinoを使いながら開発環境を整理したくなったらPlatformIO、ESP32の機能をより深く扱いたくなったらESP-IDFという選択肢があります。
そして製品開発では、開発環境の名前以上に、バージョン管理・再現性・デバッグ・保守まで含めて開発環境を選定することが重要です。
ESP32シリーズそのものをまだ決めていない場合は、既存記事の**「ESP32シリーズの選び方」**へつなぎましょう。
また、ESP-IDFをこれから使う読者には、既存の**「ESP-IDF初心者がつまずく5つのポイント」**への内部リンクが非常に自然です。
今回の記事を間に置くことで、
ESP32シリーズを選ぶ → 開発環境を選ぶ → ESP-IDFを実際に使う
という流れができます。
関連記事
ESP32シリーズの選び方