ORANGE-ESPerで、MicroPython + FabGLを実現 ～ 準備編

 ①MicroPythonとFabGL

MicroPythonは、幅広い組込みマイコンで手軽にプログラミング可能な言語処理系です。今回ターゲットにしたESP32は、上海のEspressif Systems社から販売されている、米国のTensilica社の240MHz Xtensa LX6 dual CPUを搭載した普及価格のIoT用マイクロコントローラです。IoT用ですので、Bluetooth、WiFiなど機能も搭載されて、Micropythonから利用できます。

一方、ORANGE-ESPerは、ESP32-WROOM-32モジュールを搭載したESP32-DevKitC開発ボードを利用してVGAモニタ・キーボード・マウス・SDカードを接続でき、ESP32用Arudino上のFabGLライブラリを利用したライブラリ付属の懐かしいアプリケーションが楽しめます。

このFabGLライブラリは、イタリアのFabrizio Di Vittorioさんが開発し、SPI＋DMAでVGAビデオ信号を生成させ、IoT用マイクロコントローラをパソコンのように使えるようにした点が光ります。

また、ORANGE-ESPer発売元のピコソフト社からORANGE-OSも公開されていますが、アプリケーションは、限られています。そこで、今回は、ORANGE-ESPerで、Micropythonパソコンにチャレンジすることにしました。PCのTeraTermとORANGE-ESPerのキーボード＋VGAモニタ双方からMicroPythonを使えるようにしたいと考えています。

②Windows10上でMicroPythonのビルド

MicroPythonのビルドには、ESP-IDF開発環境が必要になります。まず ESP-IDF Tools Installer for Windows（V2.5）をインストール後、適当なディレクトリにMicroPythonをgithubからcloneします。ESP-IDFは、V4.2がインストールされ、MicroPythonは、V1.14でした。

早速、esp32用のビルドを行うと、Linuxのcatコマンドが無いため、ビルドエラーで先に進めることができませんでした。みなさん、Linuxでビルドしているみたいです。（涙）

Windows10で、VM上にLinuxをインストールしたことはありますが、今回のビルドのためにLinux全体の機能を管理するのも大変ですので、今回は、Linuxをお手軽なWindows Subsystem for LinuxのUbuntuを選択しました。利点は、Windows配下のファイルシステムを共用できるので、慣れたWindows用のツールが利用できる点が優れています。ただし、Windowsからファイルを書き込むと、Linuxのパーミッションがリセットされる点がありますので、注意が必要になります。

下記が、Windows Subsystem for LinuxのUbuntuインストール後の手順です。

sudo apt update && sudo apt upgrade
sudo apt update
sudo apt install \
gcc git wget make libncurses-dev flex bison gperf \
libffi-dev libssl-dev

cd
mkdir esp32
cd esp32
git clone --recursive https://github.com/micropython/micropython
git clone -b v4.2 --recursive https://github.com/espressif/esp-idf.git
git submodule update --init --recursive

cd /usr/bin
sudo ln -s /usr/bin/python3 python

cd
curl "https://bootstrap.pypa.io/get-pip.py" -o "get-pip.py"
python get-pip.py
sudo apt install cmake

cd ~/esp32/esp-idf
./install.sh

. ~/esp32/esp-idf/export.sh

cd ~/esp32/micropython/mpy-cross
make mpy-cross

cd ~/esp32/micropython/port/esp32
idf.py build

無事、MicroPythonのビルドに成功しました。WSLでは、CPUコアの割り当てが少ないようで、Windows上のESP-IDFに比べると遅い点が気になりますが、仕方がありません。

ORANGE-ESPerで、無事にMicroPythonのプロンプトが表示できました。ちなみに、MicroPythonの空きヒープサイズは、99KB程度でした。

③ESP32用のAruduino上で、FabGLのAnsi-Terminalサンプルプログラムをビルド

Arduino V1.8.10にesp32 V1.0.6ボードマネージャと、FabGL V1.0.2ライブラリを追加し、FabGL付属のAnsiTerminalサンプルプログラムをビルド後、無事、VGA画面が立ち上がりました。

次に、ESP-IDF V4.2上で、Ansi-Terminalサンプルプログラムをビルドできる必要があります。esp32 V1.0.6ボードマネージャは、ESP-IDF V3.3.5ベースのようですので、V4.2に適合させることができれば、FabGLライブラリをMicroPythonのソースコードと統合できるはずです。

（再クロール更新：2022/12/22）

パソコン修理 ～ リチウムイオン電池パックの再生

 しばらく使用していなかった2010年製造の東芝 Dynabook ノートPCを修理していたところ、最後にリチウムイオン電池パックPABAS173(PA3533U-1BRS、10.8V、1790mAH）の充電をしようとしましたが、充電ランプがすぐに消灯して充電できないことがわかりました。

2010年製の電池パックですので、半分あきらめ気味でしたが、2パックありましたので、なぜ充電できないか分解して確認してみました。すると、電池電圧が6.8Vになっており、過放電防止のため、内部保護回路が電池を切り離しているようでした。これは、電池の劣化（寿命）ではなく、保護回路による充電不良と判断できます。

そこで、分解をしないで電池パックを再生する方法を紹介します。

下記の写真は、内部電池のプラス電極にアクセスするため、穴を開ける位置です。注意深くドリルで1.5mm程度の穴を開けていきます。

次の写真のように、電池パックコネクタ9ピン（または、8ピン）のGNDと穴奥の電極にピン立て、電圧を測定します。今回のパック定格電圧は、10.8Vですので、7.5V以下になっていると、過放電状態になりますので、補充電が必要です。

補充電は、12Vの電源に220Ω程度の直列抵抗を入れた状態で、GNDと内部電池のプラス電極に接続し、1時間程度充電すれば、50mAH程度充電ができると思います。補充電後、念のため電池の電圧が7.5V以上になっていることを確認できれば、ノートPCで充電が可能になります。補充電しても電圧が上がらない場合は、長い休眠期間から目覚めてもらうため、少し放電させた後、再度補充電すると良いようです。

この方法は、東芝の類似電池パックでも使えるのではないかと思いますが、自己責任でお願いします。

（再クロール更新：2022/12/22）

PCの不調を復旧する～見過ごされた破損ファイル～

 ほっとしたのもつかの間、12月の月次更新プログラムのWindowsUpdateが自動実行されましたが、なぜかインストール後の更新プログラムを構成で7%まで進行した後、リブートを経て「更新プログラムを構成できませんでした」となりました。エラーコードは、"0xE0000100" でした。PowerShellで"Get-WindowsUpdateLog" を実行して"WindowsUpdate.log" を抽出して確認しましたが、原因につながる詳細なログは、残っていませんでした。

世の中の事例を調べてはみましたが解決策は見つかりませんでしたので、まずは、WindowsUpdateカタログから個別の更新プログラム（kb4592438で検索）をダウンロードし、単独実行して、ログの採取を試みました。ログは、"C:\Windows\Logs\CBS\CbsPersist_2020xxxxxxxx.log" にありました。その内容を注意深く確認したところ、下記のように、"DriverUpdateInstallUpdates failed [HRESULT = 0xe0000100 - Unknown Error]"であることがわかりました。

2020-12-14 11:19:59, Info   CBS    Perf: Doqe: Install started.
2020-12-14 11:19:59, Info   CBS    Doqe: [Forward] Installing driver updates, Count 646
2020-12-14 11:19:59, Info   CBS    Progress: UI message updated. Operation type: Update. Stage: 0 out of 0. 
Percent progress: 7.
2020-12-14 11:20:01, Info   CBS    DriverUpdateInstallUpdates failed [HRESULT = 0xe0000100 - Unknown Error]
2020-12-14 11:20:01, Info   CBS    Doqe: Failed installing driver updates [HRESULT = 0xe0000100 - Unknown Er
ror]
2020-12-14 11:20:01, Info   CBS    Perf: Doqe: Install ended.
2020-12-14 11:20:01, Info   CBS    Failed installing driver updates [HRESULT = 0xe0000100 - Unknown Error]
2020-12-14 11:20:01, Error  CBS    Shtd: Failed while processing non-critical driver operations queue. [HRES
ULT = 0xe0000100 - Unknown Error]
2020-12-14 11:20:01, Info   CBS    Shtd: Rolling back KTM, because drivers failed.

このエラーに関するドライバーインストールのログが無いか調べてみると、"C:\Windows\INF\setupapi.dev.log" であることがわかり内容を確認すると、下記のようにinfファイル中のsignatureに問題があるとのエラーでした。対象のファイルを確認すると先頭のバイトが壊れて、正常なinfファイルになっていませんでした。infファイルは、sfcの対象になっていないようで、"Update Sequence Array" の不整合によるfixup処理によりで先頭のバイトが破損した可能性があります。MFTの構造上、1クラスタ内に収まる小さなファイルの場合、発生しやすいと考えられます。

前記で使用したmountされているWindowsイメージから同じファイルを見つけ、前記の手順で上書き復元をしたところ、無事更新プログラムが正常に実行できました。

>>>  [Install Driver Updates]
>>>  Section start 2020/12/10 15:41:19.614
      cmd: C:\WINDOWS\winsxs\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_10.0.19041.680_none_
      e72768c3263f99bc\TiWorker.exe -Embedding
     sto: Image State        = Specialized
     sto: Image Architecture = amd64
     sto: Image OS Version   = 10.0.19042
     sto: Image Product Type = WinNT
     sto: Transaction        = CbsDriversAndPrimitives
     sto: Driver Updates     = 646
!    inf: Unable to load INF: 'C:\WINDOWS\System32\DriverStore\FileRepository\kdnic.inf_amd64_6649425cdca
e9b5f\kdnic.inf'(e0000100)
!    inf: Error 0xe0000100: The style of the INF is different than what was requested.
!!!  inf: Invalid INF 'C:\WINDOWS\System32\DriverStore\FileRepository\kdnic.inf_amd64_6649425cdcae9b5f\kd
nic.inf', must contain [Version] section and have signature "$Windows NT$". Code = 1001
!!!  sto: Failed to get version info for driver update 'C:\WINDOWS\System32\DriverStore\FileRepository\kd
nic.inf_amd64_6649425cdcae9b5f\kdnic.inf'. Error = 0xE0000100
<<<  Section end 2020/12/10 15:41:22.020
<<<  [Exit status: FAILURE(0xe0000100)]

やっとPCの不調を復旧できたようです。

同じようなWindowsUpadeトラブル事例を検索してみた感想では、ログ解析方法が明らかにされていないのか、原因の特定が難しいのか、効果があるかもしれない対策方法を列挙したり、自動修復プログラムを紹介したりすることが散見されていました。当たるも八卦当たらぬも八卦状態です。パソコンメーカーのサポートでも同じレベルでした。特に日本のマイクロソフトのサポート情報は、エラーコードに対応した対策に言及せず、うまくいった事例を紹介しているだけが多いようで、役に立たないことが多いと感じました。米国のマイクロソフトのサポート情報ほうが有用な感じでした。

WindowsUpadeトラブルは様々な要因で頻発する傾向があり、マイクロソフトがエラーコードの意味やそのエラーコードに対応した対策を公開するか、修復可能範囲を広げるDISM等の機能強化を提供してくれたら多くのユーザが助かるかと感じたのは、私だけではないと思います。マイクロソフトのサポートが大変になるので、ユーザがあまりやりたくない新規再インストールに仕向けようとしているのではと、勘繰りたくもなります。

いずれにしても、今後はバックアップを頻繁に行いたいと思います。ログの解析方法など、参考にしていただければと思います。

（再クロール更新：2022/12/22）