要約：前回はespupを入れずに環境を構築した。が、、espdemo等のビルド手順等では「espupでターゲットを切り替えろ」等と書かれいる
取り組み：前回のDockerファイルをベースに、espup版のイメージを作る
FROM debian:bullseye-slim RUN apt-get update \ && apt-get install --yes curl \ && curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs > /tmp/rustup-init.sh \ && chmod +x /tmp/rustup-init.sh \ && /tmp/rustup-init.sh -y \ && . "$HOME/.cargo/env" \ && rm /tmp/rustup-init.sh RUN apt-get install --yes clang python3 python3-pip git pkg-config libudev-dev libssl-dev \ && python3 -m pip install pip --upgrade RUN . "$HOME/.cargo/env" \ && cargo install espup \ && cargo install ldproxy \ && cargo install cargo-generate \ && cargo install espflash \ && cargo install cargo-espflash \ && espup install RUN . "$HOME/.cargo/env" \ && . "$HOME/export-esp.sh" RUN mkdir /app
後半のenv読み込みは効果ないとは思います（コンテナを使う時にenv読み込みを忘れないため）
docker run --volume /home/rustbld00/lang/rust:/app --device=/dev/ttyACM0:/dev/ttyACM0 -it rust_buld_espup:0.2 /bin/bash
Rust(ESP32) のstd demoをビルドしてみる
git clone https://github.com/ivmarkov/rust-esp32-std-demo . ./export-esp.sh rustup default esp cd rust-esp32-std-demo/ cargo build
環境設定が不足していると怒られるので対応
export RUST_ESP32_STD_DEMO_WIFI_SSID=<wifi_SSID> export RUST_ESP32_STD_DEMO_WIFI_PASS=<wifi_password>
ビルドが通ってFlashに焼く
espflash flash target/riscv32imc-esp-espidf/debug/rust-esp32-std-demo
焼き終わったが、espflash monitor等ではシリアル通信が正しく行えないようなのだが。。
以下のように、waiting for downloadで待ちが発生
root@e51a2bfcc424:/app/rust-esp32-std-demo# espflash monitor
✔ Use serial port '/dev/ttyACM0'? · yes
[2023-07-09T12:53:43Z INFO ] Serial port: '/dev/ttyACM0'
[2023-07-09T12:53:43Z INFO ] Connecting...
[2023-07-09T12:53:43Z INFO ] Using flash stub
Commands:
CTRL+R Reset chip
CTRL+C Exit
ESP-ROM:esp32c3-api1-20210207
Build:Feb 7 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0x7 (DOWNLOAD(USB/UART0/1))
Saved PC:0x40380832
waiting for download本件は以下に答えがありそうだ・・・
ESP32-C3 Stuck waiting for download - ESP32 Forum
上記のQAは、idf.py というツールを使った時の問題であった。
このツールを使った場合に、ESP32側がダウンロードモードに推移してしまう問題が発生しているとのことで、今回もESP32側がダウンロードモードに推移しため、ESP32側はダウンロードを待ち、espflash側はESP32からのシリアル出力を待つという、両方で待ち合いになってロックしたような状況と理解しました。
何か起動オプションがあれば、ダウンロードモードに推移するのを防げるかもしれません。
espflashのmonitor部のソースは以下。
espflash/espflash/src/cli/monitor/mod.rs at main · esp-rs/espflash · GitHub
espflash/src/cli/monitor/mod.rs
これを読むと、Ctrl-Rの時は、Reset後Flash書き込みのようであった。CI/CDを考えて、何度も焼いてテストすることを想定しているのか。
普通に起動するとシリアルから読み込み続けるのだろうけど、何も表示されないというのがなぜなのか・・・
KeyCode::Char('r') => {
reset_after_flash(&mut serial, pid)?;
continue;
}古いバージョンのespflash + RustBoard + デモプログラムの組み合わせで、シリアルデータを受け取れるか確認
下記の通り、Flash書き込み待ちに入る
$ espflash --version
New version of espflash is available: v2.0.0
espflash 1.7.0
$ espflash serial-monitor
New version of espflash is available: v2.0.0
Serial port: /dev/ttyACM0
Connecting...
Commands:
CTRL+R Reset chip
CTRL+C Exit
ESP-ROM:esp32c3-api1-20210207
Build:Feb 7 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0x7 (DOWNLOAD(USB/UART0/1))
Saved PC:0x4004c976
waiting for download別のボード＋古いespflash(ホスト環境)+別のプログラムの組み合わせはOK
$ espflash serial-monitor
New version of espflash is available: v2.0.0
Serial port: /dev/ttyACM0
Connecting...
Commands:
CTRL+R Reset chip
CTRL+C Exit
ESP-ROM:esp32c3-api1-20210207
Build:Feb 7 2021
rst:0x1 (POWERON),boot:0xc (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6100,len:0x172c
load:0x403ce000,len:0x928
load:0x403d0000,len:0x2ce0
entry 0x403ce000
I (30) boot: ESP-IDF v4.4-dev-2825-gb63ec47238 2nd stage bootloader
I (30) boot: compile time 12:10:40別のボード＋新しいespflash(コンテナ内)+別のプログラムの組み合わせはOK
ボードに関連しているのでは？と思えて、USBがESP32に直収か、USB/Serial変換ICを経由してESP32に接続しているか？に関係するだろうか。。
今後やるとしたら以下
- ボードの種類を変えて動作を確認
- Flashに焼くプログラムの種類を変えて動作を確認
