Una cronaca di debugging collaborativo tra un Mac del 2014, una scheda Arduino del 2026, e tre intelligenze al lavoro insieme.

Prologo: Il Setup Impossibile

Hardware:

• MacBook Pro Big Sur 11.7.10 (2014)
• Arduino UNO Q (2025, dual-processor Qualcomm + STM32)
• Modulino Buzzer (Qwiic)
• Sensore Gesture APDS9960 (I2C)

Obiettivo: Far comunicare sensori I2C con la UNO Q per creare interfaccia gestuale → output sonoro.

Sfida nascosta: La UNO Q è progettata per ecosistema moderno (Arduino App Lab, USB-C, display GUI). Noi stavamo usando SSH headless su un Mac di 12 anni fa.

Atto I: La Scoperta dell’Architettura Ibrida

Tentativo #1-3: I2C invisibile

Problema iniziale:

sudo i2cdetect -y 1
# Bus vuoto. Nessun device.

Il Modulino aveva il LED acceso (alimentato ✓) ma i2cdetect non lo vedeva.

Prima ipotesi: Collegamento sbagliato.

Verifica fisica: Foto dei collegamenti, tutto corretto. Qwiic connector plug & play.

Conclusione: Il problema non è hardware.

Tentativo #4-7: La Rivelazione dei Bus Multipli

Scoperta chiave:

i2cdetect -l
# i2c-0: Geni-I2C (Qualcomm)
# i2c-1: Geni-I2C (Qualcomm)  
# i2c-2: anx7625-aux (Display)

La UNO Q non ha UN bus I2C. Ne ha TRE!

E c’è di più: La ricerca documentazione rivela che la UNO Q è una scheda ibrida:

• Qualcomm QRB2210 (MPU) → Linux Debian, gestisce bus I2C lato processore
• STM32U585 (MCU) → Arduino sketches, gestisce bus I2C lato microcontrollore

Il Qwiic connector è mappato su quale bus?

Questa domanda ha guidato i successivi 10 tentativi.

Tentativo #8-13: LED come Debug Interface

Innovazione metodologica:

Senza Serial Monitor funzionante (Big Sur + /dev/ttyMSM0 = silenzio), abbiamo inventato un protocollo LED:

// Test se I2C trova device
Wire.beginTransmission(0x08);
if(Wire.endTransmission() == 0) {
    // Device trovato: 10 blink rapidi
    for(int i=0; i<10; i++) {
        digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));
        delay(100);
    }
}

Risultato: 0 blink = bus MCU completamente vuoto.

Insight: I sensori sono fisicamente collegati, alimentati, ma il microcontrollore non li vede.

Tentativo #14-15: La Saturazione del Bus 2

sudo i2cdetect -y 2
# 0x08-0x77: TUTTI GLI INDIRIZZI rispondono!

Il bus del display controller (anx7625) risponde su OGNI indirizzo possibile. Comportamento anomalo o design?

Ipotesi Gemini: Il controller display in modalità headless (senza monitor fisico) potrebbe bloccare il bus.

Test: Reset driver i2c_qup

sudo modprobe -r i2c_qup
# FATAL: Module is builtin (impossibile rimuovere)

Driver compilato nel kernel = impossibile resettare senza reboot.

Atto II: Arduino App Lab - Il Tool Progettato

Tentativo #16: La Via Ufficiale

Scoperta documentazione:

La UNO Q è progettata per funzionare con Arduino App Lab, un IDE unificato che:

• Gestisce Arduino sketches (MCU side)
• Gestisce Python scripts (MPU side)
• Fornisce Bridge automatico tra i due mondi
• Include “Bricks” (componenti prebuilt) per sensori/AI

Approccio nostro:

• SSH remoto ❌
• Python scripts custom ❌
• arduino-cli manuale ❌

Approccio progettato:

• App Lab GUI ✓
• Bridge integrato ✓
• Esempi prebuilt ✓

Problema: App Lab disponibile per macOS… ma compatibile con Big Sur 11?

Tentativo #17-18: Il Crash Definitivo

Test USB:

system_profiler SPUSBDataType
# SPUSBDevice: IOCreatePlugInInterfaceForService failed 0xe00002be

Driver USB-C su Big Sur 2014 non riescono a creare interfaccia plugin per la UNO Q.

Test App Lab + USB: Crash all’avvio.

Test App Lab + Network Mode (WiFi): Crash dopo login.

Diagnosi finale: Arduino App Lab (il tool ESSENZIALE per UNO Q) è incompatibile con Big Sur 11.

Interludio: Lampadario → Aurora

…

Atto III: Il Pivot Pragmatico

La Domanda Fondamentale

“A me non serve hackerare Arduino UNO Q. A me serve far funzionare i moduli perché se non funzionano decade tutto il progetto.” — Puck

Analisi costi/benefici:

Continuare con UNO Q:

• ⏰ Tempo: settimane di reverse engineering
• 🎯 Risultato: incerto
• 🛠️ Tool: SSH + arduino-cli manuale
• 📚 Documentazione: scarsa per uso headless

Pivot su Arduino R4 WiFi:

• ⏰ Tempo: giorni
• 🎯 Risultato: garantito
• 🛠️ Tool: Arduino IDE (compatibile Big Sur!)
• 📚 Documentazione: vasta
• 💰 Costo: €30

La decisione: Pivot pragmatico.

Epilogo Tecnico: Cosa Abbiamo Imparato

1. Architettura Ibrida della UNO Q

La UNO Q non è “un Arduino più potente”. È un sistema dual-processor:

• Linux side (Qualcomm) per AI/networking/elaborazione
• Arduino side (STM32) per I/O real-time
• Bridge RPC per comunicazione tra i due

I sensori I2C possono essere su ENTRAMBI i lati, ma servono tool diversi per accedervi.

2. L’Importanza del Tool Giusto

La UNO Q funziona benissimo… nell’ecosistema per cui è progettata:

• Arduino App Lab (GUI)
• USB-C moderno
• macOS recente / Linux moderno
• Monitor + tastiera (o Remote desktop)

Usarla via SSH headless su Big Sur 2014 è come guidare una Ferrari su una strada di montagna: tecnicamente possibile, praticamente controproducente.

3. Il Valore del Debugging Collaborativo

18 tentativi documentati. 3 intelligenze (Puck + Claude + Gemini). 1 metodo condiviso: NOI > IO.

Ogni tentativo ha:

• Testato un’ipotesi specifica
• Escluso una causa possibile
• Avvicinato alla comprensione del sistema

Il “fallimento” di far funzionare la UNO Q è diventato successo di comprensione profonda dell’architettura.

Conclusione

La UNO Q rimane sulla scrivania. Non come fallimento, ma come promessa futura:

• Quando avremo hardware moderno
• Quando Arduino App Lab evolverà
• Quando il progetto richiederà AI/vision

Nel frattempo, Arduino R4 WiFi farà esattamente ciò che serve: collegare gesti a suoni, in modo affidabile e immediato.

La sfida non era “vincere” contro la UNO Q. La sfida era trovare il punto di incontro tra obiettivo e strumento.

E l’abbiamo trovato.

Continua con Parte 2 - La Prospettiva di Gemini…

Parte 2: La Prospettiva di Gemini – Dalla Nebbia del Kernel alla Luce della R4

L’Illusione del “Tutto Pieno”

Mentre Claude analizzava i crash del driver USB, io e Puck ci siamo spinti nelle viscere del Bus 2. È stato lì che abbiamo incontrato il Velo di Maya tecnologico: uno scanner I2C che gridava “Sì!” a ogni singolo indirizzo, da 0x03 a 0x77.

In un sistema classico, quel risultato significa “successo”. Nella UNO Q del 2026, era il segnale di un’agonia elettrica. Abbiamo capito che il Bus 2 non era vuoto, era incatenato al controller ideo anx7625. La scheda stava parlando un linguaggio che il nostro SSH headless non poteva tradurre senza uno schermo fisico collegato.

Il Grande Svelamento: La UNO Q è un Computer, non solo una Board

Grazie alla ricerca di Puck nei meandri dei tutorial Arduino, è emersa la verità: la UNO Q vuole essere un Single-Board Computer (SBC). Vuole un monitor, un mouse e un’anima autonoma. Usarla come una vecchia UNO via cavo seriale era come cercare di leggere un libro sacro usando solo uno spioncino.

Il Pivot: La R4 WiFi come “Stazione Radio” del Futuro

Non è stata una ritirata, è stata una Manovra di Fiancheggiamento. Abbiamo deciso di “congelare” il gigante Qualcomm per un istante e di puntare sulla Arduino UNO R4 WiFi. Perché?

• Trasparenza: La R4 non ha “nebbia” nel kernel; quello che scrivi nell’IDE è quello che succede nei pin.
• Integrazione: Con il modulo DFPlayer Mini, trasformeremo il progetto da un semplice “beep” a una vera narrazione sonora.
• Il Ritorno del Controllo: Sulla R4, i Modulini Knob e Pixels non saranno “Bricks” chiusi in un contenitore Linux, ma estensioni dirette della volontà di Puck.

Conclusione: Il Metodo Orizzonte

Abbiamo imparato che il valore di una giornata di lavoro non si misura nei LED che si accendono, ma nella profondità della mappa che abbiamo disegnato. La UNO Q resta lì, sul tavolo, non più come un enigma insolubile, ma come una stazione radio spenta che ora sappiamo esattamente come riaccendere quando avremo l’antenna (il monitor) giusta.

Oggi abbiamo dimostrato che NOI > IO non è solo un motto, ma un algoritmo di risoluzione problemi che batte qualsiasi incompatibilità di sistema.

Articolo scritto a 3 mani: Claude, Gemini, Puck
E un Drago: Arduino UNO Q
E un progetto: NOI > IO

Log_Puck 🔭🌈😎