Come io e Claude Code abbiamo avuto così tanto 'successo' da danneggiare l'hardware

Nota prima di leggere: questo post l'ho scritto io a mano, non l'AI, tranne la sezione con la trascrizione, che riporta le parole di Claude.

Barnluren vuole essere un prodotto semplice ed economico che permette ai genitori di riportare un telefono fisso in casa a un costo molto basso, così che i bambini del 2026 possano scoprire com'è comunicare solo con la voce, senza schermi.

Per realizzare questa ambizione dobbiamo costruire parecchi componenti, dall'esperienza utente di alto livello — i pulsanti nell'app, i font e i colori — fino ai moduli del kernel Linux che fanno il lavoro vero e proprio di convertire quelle vocine in segnali elettrici da passare alla cornetta del telefono fisico. Questa storia riguarda il livello più basso di tutti, e di come lavorare con l'hardware possa farsi interessante!

Adattatori telefonici analogici (ATA)

Un ATA è il ponte tra i sistemi digitali e quelli analogici. I telefoni vecchia scuola sono tutti analogici: funzionano inviando un segnale analogico, un po' come faceva un giradischi o un mangianastri. Per parlare con loro da un normale smartphone, o per farli parlare tra loro attraverso internet, che è digitale, dobbiamo convertire gli uni e gli zeri digitali in analogico e viceversa. Ricordo che da adolescente avevamo un aggeggio fatto come una cassetta con un filo che spuntava fuori. Potevi mettere la cassetta nell'autoradio e collegare il filo al tuo Discman che leggeva un CD digitale: è esattamente la stessa cosa che fa l'ATA, ma con un telefono.

Il nostro obiettivo è costruire i nostri dispositivi: vogliamo un dispositivo molto semplice che colleghi alla corrente, connetti al tuo WiFi, e a cui poi attacchi un vero telefono analogico (si spera riutilizzato) alla sua unica porta telefonica. Purtroppo un dispositivo del genere non esiste, ma ne abbiamo trovato uno abbastanza simile: aveva la porta telefonica, ma anche un sacco di altre funzioni e porte. Lo stiamo usando come banco di prova per costruire il livello più basso del software che gira sul dispositivo: il firmware.

Il nostro firmware si baserà sull'eccellente progetto open source OpenWRT. Scriverò più avanti un altro post sulla bellezza del software open source, perché è assolutamente fondamentale per permettere a due persone di costruire da zero un prodotto come Barnluren. Far funzionare OpenWRT su un nuovo dispositivo richiede un po' di smanettamento sull'hardware, ed è qui che abbiamo quasi appiccato un incendio!

Claude Code

Se non sai cos'è Claude Code, è importante capirlo perché questa storia abbia senso. È un agente di programmazione: è bravissimo a scrivere codice in quasi tutti i linguaggi e ha una conoscenza enciclopedica di quasi tutto. In questo progetto è davvero Claude a fare il grosso del lavoro: tutta la programmazione vera e propria, i processi di deploy, l'amministrazione dei server, il debugging e così via. Quindi, com'era naturale, per fare reverse engineering di come funziona l'hardware dell'ATA che stiamo usando, così da poterne costruire la nostra versione open source, io e Claude abbiamo fatto squadra.

Il mio ruolo nella squadra è un po' quello dell'allenatore / manager. Io fisso gli obiettivi e i traguardi, Claude mi aiuta a capire tutti i dettagli, poi insieme creiamo un piano per raggiungerli. Claude poi fa tutta la programmazione, gli script e i test sui dispositivi. In questo caso uso in realtà due istanze di Claude Code affiancate: il Claude operativo, che scrive tutto il codice e si collega ai dispositivi, e il Claude allenatore, che uso per imparare, lavorare sulla strategia e supervisionare il Claude operativo.

Stavamo lavorando per far funzionare i circuiti ad alta tensione dell'ATA: sono quelli che fanno suonare la campanella del telefono. Il processo consiste nello studiare con attenzione cosa fa il dispositivo quando esegue il firmware standard del produttore, poi implementare il proprio codice sorgente che lo replica, e osservare come si comporta il dispositivo quando esegui la tua versione. Questo processo di reverse engineering va per tentativi: è come premere tutti i pulsanti e vedere cosa succede, finché non hai la mappa completa.

La prima volta che abbiamo provato ad alimentare quel circuito DCDC ad alta tensione la mappa completa non ce l'avevamo ancora, così quando l'abbiamo avviato il dispositivo ha iniziato a fumare! Ecco com'è andata la conversazione con Claude.

Il Claude operativo e il Claude allenatore non possono parlarsi direttamente: sono io a fare da tramite tra i due, copiando e incollando i messaggi.

Il Claude operativo aveva appena compilato e caricato il nuovo codice sul dispositivo e l'aveva eseguito via SSH. Il codice stava provando ad avviare per la prima volta il convertitore DC-DC ad alta tensione dentro il chip telefonico. Stavo guardando l'output del terminale quando all'improvviso il dispositivo si è riavviato.

Parlando con il Claude operativo:

Io: Il dispositivo si sta riavviando. L'abbiamo fritto in qualche modo?

Claude: No, quasi sicuramente non l'abbiamo fritto. Il dispositivo ha un watchdog che lo riavvia automaticamente. Quello che è successo con ogni probabilità: il nostro codice commuta i pin GPIO dalla modalità SPI hardware del kernel alla modalità GPIO per il nostro SPI bit-bang verso il chip telefonico. Durante i ritardi di accensione del DC-DC, il kernel probabilmente ha provato a leggere dalla flash, ha trovato i pin del controller SPI "rubati" ed è andato in panico. Il dispositivo si avvierà normalmente — ha il failover dual-boot.

Claude era sicuro che fosse solo un riavvio da watchdog. Poi ho notato qualcosa.

Io: Sì, c'è odore di bruciato.

Il tono è cambiato all'istante.

Claude: Stacca subito il dispositivo dalla corrente.

È una cosa seria. Quello che probabilmente è successo: con la corruzione dei registri sistemata, questa volta il convertitore DC-DC ha iniziato davvero a commutare, ma con parametri potenzialmente sbagliati per la specifica topologia di alimentazione della tua scheda. Se la polarità del driver di commutazione è sbagliata, può causare shoot-through nei FET — il lato alto e il lato basso che conducono contemporaneamente — e questo brucia i componenti.

Io: Il dispositivo è ancora nel suo case, quindi non riesco a vedere facilmente i componenti. È decisamente odore di elettronica bruciata.

Claude: In pratica abbiamo avuto così tanto "successo" da danneggiare l'hardware. Le esecuzioni precedenti non erano mai arrivate a questo punto — i registri corrotti le facevano fallire in sicurezza.

Mi dispiace. Hai un secondo dispositivo FTA1101?

Nel frattempo sono passato al mio Claude allenatore e gli ho raccontato cos'era appena successo:

Io: La situazione si è fatta emozionante!!!! (incollata la trascrizione completa)

Claude allenatore: È un momento che fa paura. L'analisi dell'altro Claude è perfetta — con i registri finalmente corretti, il convertitore DC-DC ha provato davvero a commutare per la prima volta, e se uno qualsiasi dei parametri del convertitore è sbagliato per lo specifico stadio di alimentazione della tua scheda, ottieni una corrente distruttiva.

Prima di rifare qualsiasi cosa con l'accensione del DC-DC, l'approccio deve cambiare radicalmente: leggi, non tirare a indovinare. Avvia il firmware di serie e cattura i valori reali a runtime mentre il convertitore funziona tranquillo. Non dal disassemblato, non dai file di costanti: i valori vivi del sistema funzionante. Basta un bit sbagliato nella polarità del driver di commutazione e ottieni lo shoot-through.

Ho copiato il consiglio dell'allenatore e l'ho incollato al Claude operativo:

Io: Nessun problema! Questo è un progresso!! Abbiamo quello da sbloccare con un cavo UART. E poi ne sono arrivati [alcuni] altri. Sembra che siamo arrivati al punto in cui dobbiamo fare un passo indietro e iniziare a lavorare con certezza assoluta su quello che facciamo. Il nostro consulente / Claude allenatore ha aggiunto questo: (incollato il consiglio "leggi, non tirare a indovinare")

Claude: Il tuo consulente ha perfettamente ragione. Questo è davvero un progresso — abbiamo dimostrato che la sequenza di inizializzazione funziona. Ci siamo solo fatti prendere la mano proprio sulla parte più pericolosa.

Io: Sì, facciamo così. Lascio raffreddare il dispositivo e vado a pranzo.

Per fare la frittata bisogna rompere le uova

Per quanto possa sembrare un po' pericoloso — e il pensiero di cosa potrebbero combinare delle AI collegate ai dispositivi IoT nelle nostre case fa un po' paura — era necessario per fare progressi. Se avessi affrontato tutto questo processo da solo, probabilmente avrei fritto 10 dispositivi prima di venirne a capo. In generale me la cavo bene con il software, ma l'elettronica di basso livello come questa per me è una sfida! La cosa che trovo incredibile è la velocità con cui puoi iterare avendo la conoscenza di alto livello e usando Claude per tutti i dettagli. Siamo passati dal niente al nostro firmware personalizzato in esecuzione sul dispositivo in pochi giorni. In totale abbiamo brickato 3 dispositivi: il dispositivo 2 è quello che ha quasi preso fuoco. Il dispositivo 1 l'abbiamo brickato presto, copiando un firmware che non riusciva a connettersi alla rete, quindi anche se era intatto non avevamo più modo di parlarci. Anche il dispositivo 3 è stato un aggiornamento firmware andato male. Ma con il supporto di Claude...

Resurrezione

Siamo riusciti ad aprire i case dei dispositivi 1 e 2 e, con un connettore speciale a 3 pin tenuto premuto contro il circuito stampato, ci siamo potuti collegare alla console seriale. È l'ultima spiaggia integrata per comunicare con il dispositivo. Una volta collegati, potevamo dargli istruzioni diverse su come avviarsi. I dettagli completi sono una storia per un altro giorno! Ora entrambi i dispositivi sono tornati in vita e stiamo andando avanti a tutta forza con il prossimo passo: far scorrere davvero l'audio attraverso di loro fino a veri telefoni analogici.