ESP32 ESP-IDF & PlatformIO高速化

カテゴリー: ESP32  タグ:

PCをグレードアップしたおかげで、開発環境も快適度が向上してますが、ESP32系のコンパイル、アップロードはまだまだ時間がかかります。(というより、どんなに速くなってもそれに慣れると満足しなくなる、という性)。

RamDiskの使用やアップロード速度Upを試した覚書です。

2022/6/1更新

 内容はESP32-WROOM-32Eについでです。

アップロード速度を上げる

USB-UART変換ICのMaxは3Mbaud

DEVKIT-CはCP2104、秋月書き込み器はFT232RQ、どちらも3Mbaudマックスなので、上げてみようと思います。

アップロード速度はplatformIO.iniで設定

「PlatformIO.ini」に[upload_speed = xxxxxx]を追加します。PlatformIOのSDKファイルを調べると921600の上は1M、1.5M、2M・・・0.5Mステップで指定できるようです。そこで順番に指定してロード時間を見てみました。

アップロード速度を2Mbaudに指定

2000000が最高でした。必ずしも最高のスループットが出るわけではない

結論から言うと私の環境での指定は2M(2000000)が最高で、2.5M以上にするとロードに失敗する確率が高くなりました。成功してもリトライを繰り返すようでかえって処理時間がかかっています。

また、メッセージを見ると実際速度は2000000より下です。信号を見てないので推測ですが、ボーレートを調整するのではなく、バイト送信のスループットが落ちているのでしょう。Flashのページ書き込み時間も影響しているようです。

というわけで結論。291792バイトのファイルのリビルドアップロード

○アップロード速度指定なし:15.33秒

○アップロード速度2000000 :13.98秒

以下は、その時のメッセージ抜粋です。「(effective 973.0 kbit/s)…」とあるようにビット速度として表示されます。これでも指定しない場合は「(effective 646.8 kbit/s)…」程度なので、少し速いです

Building in release mode
Retrieving maximum program size .pio\build\esp32dev\firmware.elf
Checking size .pio\build\esp32dev\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   4.4% (used 14512 bytes from 327680 bytes)
Flash: [==        ]  25.0% (used 262069 bytes from 1048576 bytes)
Configuring upload protocol...
AVAILABLE: cmsis-dap, esp-prog, espota, esptool, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa
CURRENT: upload_protocol = esptool
Looking for upload port...
Using manually specified: COM5
Uploading .pio\build\esp32dev\firmware.bin
esptool.py v3.3
Serial port COM5
Connecting....
Chip is ESP32-D0WD-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: c4:5b:be:94:3c:d0
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 2000000
Changed.
Configuring flash size...
Flash will be erased from 0x00001000 to 0x00007fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x00010000 to 0x00050fff...
Compressed 26256 bytes to 16031...
Writing at 0x00001000... (100 %)
Wrote 26256 bytes (16031 compressed) at 0x00001000 in 0.4 seconds (effective 468.6 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 103...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (103 compressed) at 0x00008000 in 0.0 seconds (effective 511.6 kbit/s)...
Hash of data verified.
Compressed 262464 bytes to 138240...
Writing at 0x00010000... (11 %)
Writing at 0x0001db0d... (22 %)
Writing at 0x000252f3... (33 %)
Writing at 0x0002b2d6... (44 %)
Writing at 0x00030a8c... (55 %)
Writing at 0x00039430... (66 %)
Writing at 0x00041c9f... (77 %)
Writing at 0x00047a18... (88 %)
Writing at 0x0004d5fe... (100 %)
Wrote 262464 bytes (138240 compressed) at 0x00010000 in 2.2 seconds (effective 973.0 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
================================================== [SUCCESS] Took 13.98 seconds ==================================================



速度指定での短縮は1.4秒程度

クリーンbuildは長時間かかるので、それに対してはわずかな短縮ですが、小変更時のbuildでは1割の短縮なので、この指定は今後毎回行うことにします。

プロジェクトをRamDiskに格納してクリーンビルド

通常のHDDでクリーンビルドで57秒かかったプロジェクト

PCには32GB搭載してあるので1GBほど確保。RamDiskは「SoftPerfect RAM Disk」Free版。Yドライブに割り当て。シャットダウン時と一時間に一回のバックアップを設定。

RamDiskは「消える」イメージですが、シャットダウン時にバックアップするので、電源オンでちゃんとフォルダが復活しています。(再起動では消えるかも…注意)

でも、何ぞのために、これに頼らずGitHUBにしっかりプッシュしておこう。

さて、いよいよRamDiskでクリーンビルド! 効果は2割強

上と同じオブジェクトサイズが291792バイトになるプロジェクトをクリーンビルドしてみました。HDDでのビルド時間は57秒です。

結果は44.64秒。57秒に比較して2割強の短縮です。

半分ぐらいを期待したのですが、思ったほど効果なかったです。

このプロジェクトのクリーンビルドはミドルスペックPC(例えばi7-8550U 1.8GHz SSD)では10分以上かかるので、今回の試みはこれで良しとします。

お気軽にコメントをどうぞ。

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)