- 公式ボード(ESP32-P4-Function-EV-Board・rev v1.3)で、公式サンプルを実機で動かした実録です。ディスプレイ・タッチ・カメラ・スマホ風UI・C6 無線まで到達しました
- 初期ロット(rev v1.x)は、既定設定のままだと焼けません。設定3行の追加や Windows 特有のビルド修正など、越えるべき壁を「症状 → 原因 → 対処」でまとめます
- 32MB PSRAM(200MHz)と MIPI の速さは本物。一方で「公式サンプルが公式ボードで素直に動く」とは限らない、というのが率直な実感でした
🧭 はじめに:これは「動かすまでの実録」です
ESP32 シリーズの中で、ESP32-P4 は演算と映像に振った異色のチップです。Wi-Fi マイコンとして知られる ESP32 の一員なのに、P4 自体には無線が載っていません。その代わり、RISC-V デュアルコアの演算力と、MIPI のカメラ・ディスプレイに思い切り振ってあります(P4 の立ち位置は ESP32 シリーズの選び方|S3・C3・C6・H2・P4 の違いと使い分け の P4 の項もあわせてどうぞ)。
この記事は、その P4 を実機で動かした記録です。使ったのは Espressif 公式の ESP32-P4-Function-EV-Board(7型タッチ液晶と 2MP カメラ付き)。公式サンプルを、公式ボードで、素直に動かせるはず——と思って始めたら、初期ロットならではの壁がいくつも待っていました。画面・タッチ・カメラ・スマホ風UI・C6 無線まで到達するまでの、症状と対処の実録です。検証はすべて 2026-08-01・Windows 11 で実機で行いました。
同じボードをこれから触る人が回り道せずに済むよう、先に「一発で動かす手順」を置き、そのあとで踏んだ壁と実測データを並べます。
🧱 検証した構成
| 区分 | 内容 |
|---|---|
| ボード | ESP32-P4-Function-EV-Board(基板リビジョン V1.5.2・付属:7型 1024×600 静電容量タッチ・2MP カメラ) |
| チップ | ESP32-P4 rev v1.3(初期ロット)/Dual Core + LP Core・アプリは 360MHz 動作 |
| 無線コンパニオン | ESP32-C6-MINI-1(2.4GHz Wi-Fi 6 / BLE 5) |
| ホスト環境 | Windows 11 / EIM 0.17.1 |
| ESP-IDF | v5.5.3(5.5 系) |
開封状態。EV-Board 本体・7型 MIPI-DSI パネル・2MP カメラと、Camera/LCD の各 FPC やスペーサ一式
⚡ まず結論:これで一発で動く
試行錯誤の順ではなく、結論からまとめます。ESP32-P4-Function-EV-Board(初期ロット・rev v1.x)で公式サンプルを動かすなら、次の5点を先に押さえておくと回り道しません。
1. ESP-IDF は 5.5.3 以上の 5.5 系を使う
公式サンプルが要求する最低バージョンは 5.5.3 です(5.5.2 では足りません。理由は後述)。ESP-IDF 6.0.2 では、2026-08-01 時点で公式サンプルがそのままビルドできません(LVGL アダプタが 6.0 の API 変更に未追随のため)。素直に 5.5 系を使うのが近道です。
2. 初期ロット(rev v1.x)は sdkconfig に3行足す
Chip rev: v1.3 のような初期ロットは、既定設定のままでは書き込めません。sdkconfig.defaults に次の3行を足します。
CONFIG_ESP32P4_SELECTS_REV_LESS_V3=y
CONFIG_ESP32P4_REV_MIN_100=y
CONFIG_SPIRAM_SPEED_200M=y
前2行で rev v1.x 系を対象にし、3行目で PSRAM 速度を 200MHz に落とします(250MHz は rev v1.x では選べません)。
3. Windows では AI モデルのパックを ${PYTHON} に直す
スマホ風UIデモ(esp_brookesia_phone)などは、ビルド中に AI モデルをパックします。その CMake が素の python を呼ぶため、Windows では 'python' is not recognized で止まります。ESP-IDF が渡す ${PYTHON} に直せば通ります(詳細は後述)。
4. C6 で無線を使うデモは PSRAM にバッファを逃がす
C6 と SDIO で通信するデモは、起動時に sdio_mempool_create で assert して落ちることがあります。次の1行で回避できます。
CONFIG_ESP_HOSTED_MEMPOOL_PREFER_SPIRAM=y
5. タッチが効かない・画面が出ないときは、電源を挿し直す
タッチ(GT911)の I2C 初期化に失敗して、画面すら出ないことがあります。ソフトが正しくても起きました。電源を一度抜き差しすると正常起動します。
以降はまず、環境構築からビルド・書き込みまでの再現手順を通しで示し、そのあとで、途中で踏んだ壁を「なぜ」とともに見ていきます。
🛠️ 環境構築(EIM・ESP-IDF・サンプル)
「壁」の話に入る前に、同じことを再現するための下ごしらえをまとめます。ここが分かれば、次章の hello_world 以降は「その手順のどこで、どう詰まったか」として読めます。すべて Windows 11 上で実際に実行したコマンドです(プロジェクトのパスは、自分の環境に置き換えてください)。
1. 開発環境を用意する(EIM と ESP-IDF 5.5.3)
環境は EIM(ESP-IDF Installation Manager)で入れます。Windows なら winget が手軽です(GUI 版が CLI 機能を内蔵。今回は 0.17.1)。
winget install Espressif.EIM
続いて ESP-IDF 5.5.3 を入れます(公式サンプルが 5.5.3 以上を要求するため。理由は後述)。
eim install --idf-versions v5.5.3 --non-interactive true
EIM は複数バージョンを併存できます(今回は 6.0.2 / 5.5.2 / 5.5.3 が同居)。一覧の確認と切り替えはこうです。
eim list
eim select v5.5.3
そしてひとつ大事な作法として、素のシェルに idf.py は存在しません。必ず eim run "idf.py ..." の形で呼びます(EIM が ESP-IDF 環境を有効化してから実行してくれます)。プロジェクトは、どこから呼んでも -C <プロジェクトのパス> で明示指定するのが安全です。
eim run "idf.py -C <プロジェクトのパス> --version"
2. サンプルを入手する(esp-dev-kits)
P4-Function-EV-Board 用の公式サンプルは、esp-dev-kits リポジトリの examples/esp32-p4-function-ev-board/examples/ 配下にあります。主なものは次のとおりです。
| サンプル | 内容・使う機能 |
|---|---|
lvgl_demo_v9 |
LVGL v9 の移植+ベンチマーク。MIPI-DSI を使う |
esp_brookesia_phone |
スマホ風UI。MIPI-DSI・MIPI-CSI・C6・SDカード・音声まで使う「全部入り」 |
lvgl_demo_v8 |
LVGL v8 版のデモ |
common_components |
上記が共有する部品群 |
このリポジトリには大文字小文字だけが違うファイル(ui_font_H2_bold.c と ui_font_H2_Bold.fcfg など)があり、大小を区別しない Windows では丸ごと clone すると衝突します。必要なボードのディレクトリだけを sparse checkout すると回避できます。
git clone --depth 1 --filter=blob:none --sparse https://github.com/espressif/esp-dev-kits.git
cd esp-dev-kits && git sparse-checkout set examples/esp32-p4-function-ev-board
なお公式サンプルの README は「ESP32-P4X-Function-EV-Board」向けと書かれていますが、今回の X なし(ESP32-P4-Function-EV-Board)でも、以降の手当てで動作しました。
3. sdkconfig.defaults の扱い(初期ロットの設定)
「まず結論」で挙げた rev v1.x の3行などは、プロジェクト直下の sdkconfig.defaults に書きます(公式サンプルに同梱。無ければ新規作成)。公式サンプルの既定値を書き換える形で、たとえば CONFIG_SPIRAM_SPEED_250M=y を CONFIG_SPIRAM_SPEED_200M=y に変えます。
CONFIG_ESP32P4_SELECTS_REV_LESS_V3=y
CONFIG_ESP32P4_REV_MIN_100=y
CONFIG_SPIRAM_SPEED_200M=y
sdkconfig.defaults は、sdkconfig を生成するときにしか読まれません。すでに sdkconfig がある状態で defaults を編集しても、ビルドには効きません。編集したら、いったん sdkconfig を削除してから再ビルドしてください(今回も、実際にこれで反映させました)。set-target をやり直しても sdkconfig は作り直されます。
🚀 まず hello_world を焼く(最初の一歩)
いきなり LVGL や全部入りデモに行くと、詰まったときに原因を切り分けられません。最初は hello_world で「焼ける・起動する」ことだけを確認します。実際の検証でも、最初の書き込みはこれでした。ここで初期ロットの壁に当たり、起動ログでチップ情報まで確認できます。
まず、ESP-IDF 同梱の examples/get-started/hello_world を作業用ディレクトリへコピーします(ESP-IDF 本体は直接編集しません)。
Copy-Item -Recurse "C:\esp\v5.5.3\esp-idf\examples\get-started\hello_world" "D:\esp-projects\hello_world_p4"
ターゲットを設定してビルドします(フルビルドは規模しだいで数分〜十数分)。
eim run "idf.py -C D:\esp-projects\hello_world_p4 set-target esp32p4"
eim run "idf.py -C D:\esp-projects\hello_world_p4 build"
最初の書き込みで、初期ロットの壁に当たる
ビルドは通りますが、この状態のまま書き込もうとすると、初期ロット(rev v1.3)では失敗します。
eim run "idf.py -C D:\esp-projects\hello_world_p4 -p COM6 flash"
A fatal error occurred: 'bootloader.bin' requires chip revision in range [v3.1 - v3.99]
(this chip is revision v1.3). Use --force to flash anyway.
対処は、プロジェクト直下の sdkconfig.defaults に rev 指定の2行を足すことです。
CONFIG_ESP32P4_SELECTS_REV_LESS_V3=y
CONFIG_ESP32P4_REV_MIN_100=y
前章のとおり sdkconfig.defaults は生成時にしか読まれないので、sdkconfig を削除してから再ビルドします(set-target のやり直しでも作り直されます)。
eim run "idf.py -C D:\esp-projects\hello_world_p4 build"
(この壁の詳しい理由は、後述の「踏んだ壁」で扱います。ここではまず、焼ける状態にするのが目的です。)
書き込みと、成功の確認
改めて書き込むと、今度は通ります。
eim run "idf.py -C D:\esp-projects\hello_world_p4 -p COM6 flash"
成功すると、bootloader・partition-table・アプリの3イメージすべてに Hash of data verified が出て、最後に Hard resetting via RTS pin が出ます。eim run は内側が失敗しても終了コード 0 を返すことがあるので、成否はこの出力で判断します。
起動ログの読み方(monitor)
monitor でリセット後のログを見ます。対話型のコマンドなので、ターミナルで実行します(終了は Ctrl+])。
eim run "idf.py -C D:\esp-projects\hello_world_p4 -p COM6 monitor"
実際に取れたログから、最初に見るべき行を抜き出します。
chip revision: v1.3
Min chip rev: v1.0
Max chip rev: v1.99
Chip rev: v1.3
cpu freq: 360000000 Hz
Hello world!
This is esp32p4 chip with 2 CPU core(s), , silicon revision v1.3, 2MB external flash
Minimum free heap size: 613272 bytes
chip revision: v1.3— 自分のチップが初期ロットかどうかが分かります。買ったら最初にここを見ておくと、以降の詰まりを先読みできますMin chip rev: v1.0 / Max chip rev: v1.99 / Chip rev: v1.3— 上限が v1.99 で止まっているのが、先ほどの2行が効いた証拠です(既定なら v3.1 以上になります)cpu freq: 360000000 Hz— アプリは 360MHz で動いていますHello world!以降 — ユーザーコードまで到達した証拠です。コア数・silicon revision・flash サイズ・空きヒープが続きます
- flash サイズのズレ —
W spi_flash: Detected size(16384k) larger than the size in the binary image header(2048k)という警告が出ます。実物は 16MB ですが、hello_worldの既定が 2MB 扱いのためです。CONFIG_ESPTOOLPY_FLASHSIZE_16MB=yを足せば解消します - PSRAM はまだ出てこない —
hello_worldは最小構成なので、PSRAM は既定で有効になっていません(起動ログに PSRAM の初期化行は出ません)。この記事で後述する 32MB PSRAM の実測ログは、PSRAM を使う LVGL/全部入りデモ側で確認したものです。ここは混同しないでください
この「最小構成で焼ける・起動する」を確認できたら、次は lvgl_demo_v9(LVGL)→ esp_brookesia_phone(全部入り)へ、と段階を上げます。以降のデモもコマンドは同じ3つ(set-target → build → flash)で、-C のパスを差し替えるだけです(全部入りデモは、Windows では後述の ${PYTHON} 修正が要ります)。
🚧 踏んだ壁:症状 → 原因 → 対処
上の手順を通す途中で、実際にはいくつもの壁を踏みました。ここからは、その一つひとつを「症状 → 原因 → 対処」で振り返ります。すべて実機で遭遇し、対処して越えたものです。憶測は書かず、根拠(エラー文や公式 Kconfig)のあるものだけを載せます。
USB ポートが3つある:書き込みは「USB SERIAL/JTAG」
EV-Board には USB-C が3つあり、実物のシルクは DEVICE (J15) / USB Serial/JTAG (IO24&IO25, J19) / USB FS (IO26&IO27, J20)。書き込みとモニタは USB Serial/JTAG に挿します(今回は COM6 として認識)。最初にどれへ挿すか迷うところなので、ここは覚えておくと早いです。
実物のシルク:DEVICE (J15) / USB Serial/JTAG (IO24&IO25, J19) / USB FS (IO26&IO27, J20)。書き込みは中央の USB Serial/JTAG
★ 初期ロット(rev v1.x)は既定設定で焼けない
いちばん最初にぶつかる壁です。書き込もうとすると、こう止まります。
A fatal error occurred: 'bootloader.bin' requires chip revision in range [v3.1 - v3.99]
(this chip is revision v1.3). Use --force to flash anyway.
原因は、ESP-IDF の既定が rev v3.1 以上を想定していることです。公式 Kconfig は、v3.0 未満と v3.0 以上を相互排他と明記しています。
NOTE! Support of ESP32-P4 rev. <3.0 and >=3.0 is mutually exclusive. … Revisions higher than 3.0 is not compatible with 0.x and 1.x.
対処は、前章の3行のうち rev 指定の2行です。
CONFIG_ESP32P4_SELECTS_REV_LESS_V3=y
CONFIG_ESP32P4_REV_MIN_100=y
これで起動ログが Min chip rev: v1.0 / Max chip rev: v1.99 / Chip rev: v1.3 となり、上限が v1.99 で止まる——相互排他が実機で可視化されます。なおこれは IDF 5.5.3 でも 6.0.2 でも同じで、バージョンの問題ではなくチップ(初期ロット)の問題です。
★ PSRAM 250MHz は rev v1.x では選べない
公式サンプルの既定は CONFIG_SPIRAM_SPEED_250M=y ですが、Kconfig 上は depends on !ESP32P4_SELECTS_REV_LESS_V3。つまり rev v1.x を選んだ瞬間、250MHz は選択肢から消えます。対処は CONFIG_SPIRAM_SPEED_200M=y。200MHz で 32MB PSRAM が正常動作しました(実測は後述)。
★ Windows で AI モデルのパックが失敗する
スマホ風UIデモの human_face_detect / pedestrian_detect のビルドで、こう止まります。
'python' is not recognized as an internal or external command
原因は、これらの CMakeLists.txt が素の python を呼んでいることです。ESP-IDF は venv の Python を使うため、python は PATH にありません。
COMMAND python ${pack_model_exe} --model_path ${models} --out_file ${packed_model}
対処は、ESP-IDF が渡す ${PYTHON} に置き換えることです。
COMMAND ${PYTHON} ${pack_model_exe} --model_path ${models} --out_file ${packed_model}
これはサンプル側の不具合です。$env:PATH を足しても eim run の子プロセスには引き継がれないため、根本対処はこの1文字の差し替えになります。
★ 起動時に sdio_mempool_create で assert する
C6 と SDIO で通信するデモで、起動直後にパニックします。
assert failed: sdio_mempool_create
原因は、C6 と通信する ESP-Hosted の SDIO ドライバが、既定で内部RAMからバッファプールを確保することです。P4 の内部RAM残量は約385KB と意外に少なく、確保に失敗します。対処は、26.8MB ある PSRAM 側へ逃がすこと。
CONFIG_ESP_HOSTED_MEMPOOL_PREFER_SPIRAM=y
「P4+C6 で無線を使う」構成なら誰でも踏みうる壁で、P4 を選ぶ動機そのものに直結します。
★ タッチ(GT911)の I2C が通らない → 電源の挿し直しで復旧
これはソフトではなく、電源側の話でした。タッチの初期化がこう失敗します。
W i2c.master: Please check pull-up resistances whether be connected properly.
E GT911: GT911 init failed
assert failed: (disp != nullptr && "Failed to init LVGL adapter")
ソフトは正しいのに初期化に失敗しました。電源を一度抜き差ししたら、そのまま正常起動(タッチもカメラも動作)。厄介なのは、このデモがタッチを必須扱いしていて、タッチが取れないと画面すら出ないことです(LVGL 単体のデモはタッチ無しでも動きます)。原因の確証までは取れていませんが、同じ症状が出たら、まず電源の挿し直しを試す価値があります。
必要な IDF バージョンは manifest で判明する
sdkconfig.defaults のヘッダには「ESP-IDF 5.5.2 Project Minimal Configuration」とありますが、これはdefconfig を生成した版にすぎません。実際の依存はこう出ます。
ERROR: Version solving failed:
- project depends on idf (>=5.5.3)
つまり 5.5.2 では足りず、5.5.3 が必要でした。先の「環境構築」で 5.5.3 を入れ、eim select v5.5.3 で切り替えておけば、ここは踏みません。
📊 実測:LVGL ベンチマークと PSRAM
LVGL ベンチマーク(1024×600・LVGL 9.4.0・PSRAM 200MHz)
lvgl_demo_v9 の結果です。全体平均は 45 FPS(1フレーム約31ms=render 25ms + flush 6ms)、CPU は全項目で 100% でした。
| 項目 | FPS | 時間(render + flush) |
|---|---|---|
| Empty screen | 64 | 11ms (6+5) |
| Moving wallpaper | 49 | 17ms (13+4) |
| Single rectangle | 66 | 8ms (0+8) |
| Multiple rectangles | 66 | 11ms (4+7) |
| Multiple RGB images | 66 | 10ms (2+8) |
| Multiple ARGB images | 48 | 16ms (7+9) |
| Rotated ARGB images | 51 | 16ms (8+8) |
| Multiple labels | 46 | 18ms (9+9) |
| Screen sized text | 7 | 121ms (117+4) |
| Multiple arcs | 28 | 30ms (23+7) |
| Containers | 65 | 10ms (3+7) |
| Containers with overlay | 24 | 36ms (33+3) |
| Containers with opa | 64 | 11ms (3+8) |
| Containers with opa_layer | 57 | 15ms (8+7) |
| Containers with scrolling | 19 | 49ms (45+4) |
| Widgets demo | 8 | 125ms (120+5) |
実機の LVGL ベンチ結果(1024×600・全体平均45FPS)
読み取り:flush(画面転送)は、どの項目も 3〜9ms で安定しています。つまり MIPI-DSI の転送は速く、ボトルネックは render(CPU)側です。単純な矩形や RGB 画像は 66FPS の上限に張り付く一方で、全画面テキストや複雑なウィジェットは 120ms 級まで落ちます。実務的には「画像・矩形が主体のUIは余裕、文字が多い密なUIは要チューニング」と読めます。
PSRAM(起動ログ実測)
esp_psram: Found 32MB PSRAM device / Speed: 200MHz
esp_psram: Adding pool of 26816K of PSRAM memory to heap allocator
mmu_psram: .rodata xip on psram / .text xip on psram
32MB を認識し、26.8MB がヒープに追加されました。.text/.rodata の XIP も PSRAM 上です。一方で内部RAM の空きは合計 約385KB(RETENT/RAM/RTC/TCM の合算)と少なめで、これが先の SDIO バッファ問題の遠因でした。大きなバッファは PSRAM に置く、という前提で設計するのが素直です。
✅ 実機で動いたもの
上記の手当てをしたうえで、次はすべて実機で動作を確認しました(2026-08-01)。
- hello_world のビルド・書き込み・起動
- 7型 MIPI-DSI ディスプレイ表示(EK79007・1024×600)
- LVGL ベンチマーク完走(上表)
- ESP-Brookesia Phone デモ(スマホ風UI)の起動
- タッチ操作(GT911)
- MIPI-CSI カメラ映像(SC2336・付属2MPモジュール)
- SPIFFS マウント(3.8MB)・音声コーデック ES8311・C6 との SDIO 通信
- AI による物体検出(顔・歩行者の検出)も動作を確認
ESP-Brookesia Phone デモ(スマホ風UI)が起動した画面
MIPI-CSI カメラの映像を画面表示(上部に時刻・Wi-Fi・Normal Detect の表示)。顔は写していません
顔検出は実際に動きましたが、本記事では顔が写る画面は掲載しません。動いた事実の報告にとどめます。
📡 前提のおさらい:無線は C6 が担う
実録の背景として、P4 の「無線を持たない」という前提を押さえておきます。Espressif は公式に、無線が要るなら ESP32-C/S シリーズを SPI/SDIO/UART 経由で P4 の無線コンパニオンとして使う(ESP-Hosted または ESP-AT)と案内しています。今回のボードも、C6-MINI-1 が SDIO で P4 とつながる構成でした。
MIPI-CSI と MIPI-DSI は、スマホなどで使われているカメラ・ディスプレイ専用の高速シリアル接続の規格です。
- MIPI-CSI(Camera Serial Interface) — カメラ側。P4 は ISP(画像信号処理)を内蔵し、センサからの生データを取り込めます
- MIPI-DSI(Display Serial Interface) — ディスプレイ側。数本の差動信号で高解像度パネルを駆動します
一般的な GPIO や SPI で LCD をつなぐより帯域が桁違いに大きいため、1080p 級の映像を扱えます。今回の LVGL ベンチで flush が数msに収まったのも、この帯域の恩恵です。
付属パネルの配線は公式 README のとおりで、実機でも確認しました。ディスプレイの FPC は MIPI DISPLAY、カメラの FPC は MIPI CAMERA の別コネクタに挿します。画面アダプタ基板の 5V/GND に加えて PWM を GPIO26、LCD_RST を GPIO27 へ配線し、最後に電源スイッチを ON にします。
ディスプレイは MIPI DISPLAY、カメラは MIPI CAMERA の別コネクタ。GPIO ヘッダへ PWM→GPIO26・LCD_RST→GPIO27 を配線し、電源スイッチを ON にする
P4 が隣のチップの無線を「借りる」ための、Espressif 公式の2つの方式です。
- ESP-Hosted — コンパニオンチップをネットワークアダプタのように使う方式。今回 SDIO バッファの assert を踏んだのは、この ESP-Hosted の SDIO ドライバでした
- ESP-AT — コンパニオンチップに AT コマンド用ファームを載せ、ホストが AT コマンドで無線を操作する方式
どちらも SPI・SDIO・UART のいずれかで2チップをつなぎます。自分で基板を起こす場合は、この配線と方式の選択が設計の要になります。
🛒 実機の選択肢:今買えるボード
今回は公式 EV-Board を使いましたが、P4 ボードは複数あります。いずれも無線用に C6 を同居させているのが共通点です(価格・在庫は変動=執筆時点の目安)。
| ボード | 無線(同居チップ) | 画面 | カメラ | メモリ | 特徴 |
|---|---|---|---|---|---|
| Espressif ESP32-P4-Function-EV-Board | ESP32-C6-MINI-1(Wi-Fi 6・BT 5 LE) | 7型 1024×600 MIPI-DSI タッチ | 2MP MIPI-CSI | 16MB flash・最大32MB PSRAM | 公式リファレンス。音声コーデック・Ethernet・USB-C×3・microSD |
| Waveshare ESP32-P4-WIFI6 系 | ESP32-C6 | MIPI-DSI 対応(構成による) | MIPI-CSI 対応 | 最大32MB PSRAM | PoE/Ethernet 版などバリエーションが豊富 |
| M5Stack Tab5 | ESP32-C6-MINI-1U(Wi-Fi 6・Thread・Zigbee) | 5型 1280×720 IPS MIPI-DSI タッチ | SC2356 2MP MIPI-CSI | 16MB flash・32MB PSRAM | タブレット型・バッテリ内蔵の完成品に近い |
- P4 の機能をひととおり試したい・公式資料を頼りたい → Espressif Function EV-Board(今回のボード。公式サンプルが最も揃う)
- Ethernet/PoE など特定の構成が要る・自分で組み合わせたい → Waveshare の該当構成
- 配線せずに、完成品に近い形で触りたい → M5Stack Tab5
🧩 どこで効いて、どこで効かないか
実機を触ったうえで、P4 の効き所を整理します。
- 効くところ — カメラ映像の取り込み・画面表示・重い処理。液晶付きの HMI、カメラを使う機器、画像を扱うガジェットなど、映像と演算が主役の工作で本領を発揮します。MIPI の帯域は、S3 までのチップでは届かなかった領域です
- 効かないところ — 「Wi-Fi でセンサ値を飛ばすだけ」の工作。この用途に P4 はオーバースペックで、無線を別に足す手間が増えるだけです。その場合は ESP32-C3 や C6 の単体が素直で安上がりです(用途からの選び分けは ESP32 シリーズの選び方 を参照)
なお、P4 の開発環境は ESP-IDF です。Claude Code から自然言語で idf.py を動かす方法は Claude Code × ESP32|ESP-IDF 6.0 の MCP サーバ活用ガイド にまとめてあります。
ここからは事実ではなく、筆者の主観的な受け止めです。
正直に言うと、「公式サンプルが、公式ボードで、素直には動かない」というのが最初の実感でした。初期ロット(rev v1.x)を買うと、最新の ESP-IDF では相互排他の壁に当たり、Windows では素の python 呼び出しでビルドが止まる。「買ってすぐ Lチカ」の気軽さとは、だいぶ距離があります。
一方で、壁さえ越えれば、ハードの実力は本物でした。32MB PSRAM(200MHz)を 26.8MB もヒープに積めて、MIPI-DSI の転送は数msで安定。カメラ・タッチ・スマホ風UI・C6 無線まで、ひとつのボードで一気に触れます。「映像と演算のための ESP32」という P4 の狙いは、実機で確かに感じられました。
結論としては、いま初期ロットに手を出すなら「詰まる前提で、5.5 系+設定の手当てをセットで」。それが受け入れられるなら、P4 は他の ESP32 では届かない領域を見せてくれるチップだと思います。
✅ まとめ
- 公式ボードで公式サンプルを動かすのは、初期ロットだと一筋縄ではいかない。rev v1.x は既定設定で焼けず、
sdkconfig.defaultsに3行の手当てが要ります - ESP-IDF は 5.5.3 以上の 5.5 系が無難。6.0.2 は現時点で公式サンプルが未対応です
- Windows 特有の壁(AI モデルパックの
${PYTHON}、大小同名ファイルの clone 衝突)に注意します - C6 で無線を使うなら SDIO バッファを PSRAM へ(
MEMPOOL_PREFER_SPIRAM)。タッチが効かないときは電源の挿し直しを試します - 実力は本物。32MB PSRAM・MIPI-DSI の転送速度・カメラ・スマホ風UI まで、映像と演算の主役として機能しました
型番の多い ESP32 の中でも、P4 は役割がはっきりしたチップです。壁は多いものの、映像と演算が要るなら、越える価値のある選択肢でした。
関連記事
- ESP32 シリーズの選び方|S3・C3・C6・H2・P4 の違いと使い分け:P4 を含む全系統を、作りたいものから選ぶガイド。本記事の親ページ
- Claude Code × ESP32|ESP-IDF 6.0 の MCP サーバ活用ガイド:Claude Code から自然言語でビルド・書き込みを動かす
- ESP32-S3 × ESP-IDF|cJSONとHTTP ClientでJSONをPOST送信:無線側(C6 など)から実際にデータを送るときの実装例