課題：MacにDocker＋Ubuntuを入れたがUSBがパススルーでないためESP32評価ボードに書き込みができない
取り組み：Macの素の環境にいろいろなアプリを入れたくない。だから、Parallelsで仮想環境を作る
結論：Parallels上のUbuntu はAMD64ではなく、ARM64が入る(VMではないと)。USBもパススルー(と言う表現が正しいのか)でUbuntu 環境から参照でき、ESP32の評価ボードのFlashへの書き込みも正常に行えた。自分のNotePC上のWindows環境と比べてはるかに速い。(１０年以上前のNotePCでメモリが6G・・)
詳細：
Docker上のUbuntuからMACのUSBが扱えたら苦労がなかったのだが、どうもM1 Mac?ではだめらしい。素の環境にいろいろ入れたくないので、コンテナ化した中で試行錯誤をやりたい。コンテナ化/仮想化の方法として、Prallelsは有料なのだが安定して、USBパススルーできるらしいのでこれを入れてみる（お試し版がある）。最初ParallelsってVMによる仮想化と思っていたが、ARM版Ubuntuが必要なのだった。自分はx86でもARM版でもどちらもいいのだが。。CPU 仮想化しないのならオーバーヘッドも少なく、高速なプログラム実行が期待できる。
インストール作業は省略、製品なのでトラブルなくサクッとUbuntuも入った。ネットワークをブリッジに設定すると、WindowsPCからMac上のUbuntu にsshで入ることもできる。これは便利。MACに評価ボードを接続すると、Parallelがどっちに接続する？と聞いてくるのでUbuntuに接続と選択する。すると、UbuntuからUSB Serialが見えるようになった。さすが商品なだけあって、設定もほとんど不要で、トラブルなくUSB経由で書き込みもできそうだ。
Parallels上のUbuntuを確認
$ uname -a Linux sumi 5.15.0-60-generic #66-Ubuntu SMP Fri Jan 20 14:34:57 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux $ ls -l /dev/ttyACM0 crw-rw---- 1 root dialout 166, 0 Feb 12 03:00 /dev/ttyACM0
再度Tutorialをやってみる。esp32用にビルドする際、esp-idf-sysのcompileに一番時間がかかるのだが、この時のUbuntuのリソースは以下の通り、Load Averageが2以下で動いている。メモリは、2Gとあまり多く割り当ててない。不足気味なのか、swapを40MB消費しているようだ。
top - 04:56:34 up 1:55, 3 users, load average: 1.75, 0.80, 0.48 Tasks: 126 total, 3 running, 123 sleeping, 0 stopped, 0 zombie %Cpu(s): 73.6 us, 25.0 sy, 0.0 ni, 1.2 id, 0.2 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 1967.5 total, 573.9 free, 175.1 used, 1218.4 buff/cache MiB Swap: 2048.0 total, 2008.0 free, 40.0 used. 1693.4 avail Mem
途中エラー対応等をやったけど、サンプルアプリのビルド完了まで１０分程度か。
課題：MacにDocker＋Ubuntuを入れたがUSBがパススルーでないためESP32評価ボードに書き込みができない
取り組み：Macの素の環境にいろいろなアプリを入れたくない。だから、Parallelsで仮想環境を作る
詳細：
Docker上のUbuntuからMACのUSBが扱えたら苦労がなかったのだが、どうもM1 Mac?ではだめらしい。素の環境にいろいろ入れたくないので、コンテナ化した中で試行錯誤をやりたい。コンテナ化/仮想化の方法として、Prallelsは有料なのだが安定して、USBパススルーできるらしいのでこれを入れてみる（お試し版がある）。最初ParallelsってVMによる仮想化と思っていたが、ARM版Ubuntuが必要なのだった。自分はx86でもARM版でもどちらもいいのだが。。CPU 仮想化しないのならオーバーヘッドも少なく、高速なプログラム実行が期待できる。
インストール作業は省略、製品なのでトラブルなくサクッとUbuntuも入った。ネットワークをブリッジに設定すると、WindowsPCからMac上のUbuntu にsshで入ることもできる。これは便利。MACに評価ボードを接続すると、Parallelがどっちに接続する？と聞いてくるのでUbuntuに接続と選択する。すると、UbuntuからUSB Serialが見えるようになった。さすが商品なだけあって、設定もほとんど不要で、トラブルなくUSB経由で書き込みもできそうだ。
Parallels上のUbuntuを確認
$ uname -a Linux sumi 5.15.0-60-generic #66-Ubuntu SMP Fri Jan 20 14:34:57 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux $ ls -l /dev/ttyACM0 crw-rw---- 1 root dialout 166, 0 Feb 12 03:00 /dev/ttyACM0
再度Tutorialをやってみる。esp32用にビルドする際、esp-idf-sysのcompileに一番時間がかかるのだが、この時のUbuntuのリソースは以下の通り、Load Averageが2以下で動いている。メモリは、2Gとあまり多く割り当ててない。不足気味なのか、swapを40MB消費しているようだ。
top - 04:56:34 up 1:55, 3 users, load average: 1.75, 0.80, 0.48 Tasks: 126 total, 3 running, 123 sleeping, 0 stopped, 0 zombie %Cpu(s): 73.6 us, 25.0 sy, 0.0 ni, 1.2 id, 0.2 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 1967.5 total, 573.9 free, 175.1 used, 1218.4 buff/cache MiB Swap: 2048.0 total, 2008.0 free, 40.0 used. 1693.4 avail Mem | 途中エラー対応等をやったけど、サンプルアプリのビルド完了まで１０分程度か。さすがにめちゃ早い。これなら試作アプリのビルドや試行錯誤がいくらでも行えそうだ。 Prallels上のUbuntu環境にRustを入れるメモ >|| # install rust # https://rustup.rs/ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh source "$HOME/.cargo/env" # install rust rustup install nightly-2022-03-10 rustup component add rust-src --toolchain nightly-2022-03-10 sudo apt install llvm-dev libclang-dev clang # error: failed to run custom build command for `libudev-sys v0.1.4` sudo apt install libudev-dev # to fix error, install libudev-dev sudo apt install pkg-config # to fix error, install libudev-dev cargo install cargo-espflash ldproxy # in fail, needed cc # build board test git clone "https://github.com/ferrous-systems/espressif-trainings.git" cd espressif-trainings date; cargo build --target riscv32imc-esp-espidf # to fix, set version for ignore V0.4.18 cargo update -p ignore --precise 0.4.18 # to fix, set version for ignore V0.4.18 sudo apt install python3-pip cargo espflash --release --monitor /dev/ttyACM1
