Stavamo lavorando su una valutazione di sensori per imaging medicale, e ci serviva caratterizzare un nuovo sensore CMOS bianco-nero ad alta velocità. Il kit di valutazione Arducam era la strada più rapida per metterlo sul banco, ma dopo i primi giorni di lavoro è diventato chiaro che gli strumenti software di serie non bastavano: andavano bene per dire “il sensore funziona”, non per capirlo davvero.
Il problema, in due righe
La GUI demo dell’SDK era basilare per design — apri il device, mostra un’immagine, salva. Per noi serviva altro. La parte difficile dell’imaging non è vedere se arriva un frame, è iterare sui registri del sensore: circa un centinaio, ognuno con vincoli reciproci che scopri leggendo il datasheet e poi verificando sul banco. Esposizione, gain analogico, gain digitale, finestratura, modalità di sincronizzazione.
Quello che ci mancava davvero era la combinazione di tre cose: editor registri guidato dal datasheet (non un campo di testo crudo), preview live mentre tocchi i valori (non “modifica → riavvia → vedi”), profili JSON salvabili e ricaricabili per ogni sensore.
L’iterazione che ci serviva era da minuti, non da decine di minuti.
Cosa abbiamo costruito
Una GUI desktop in Python con Tkinter. La scelta del linguaggio era pragmatica: rapidità di sviluppo prima di tutto, SDK Arducam già con bindings Python, Tkinter cross-platform sufficiente senza tirare in ballo un framework UI pesante. Per un tool interno da iterare giornalmente sul banco, era la combinazione giusta.
L’architettura l’abbiamo aperta da subito, pensando a usi futuri: ogni sensore è descritto da un profilo JSON con la sua mappa registri, i gruppi funzionali, l’help in stile datasheet. Aggiungere un nuovo sensore significa rilasciare il file .cfg prodotto dal tooling Arducam in configs/ e creare il profilo JSON corrispondente in sensors/ partendo da _template.json. Nessuna modifica al codice Python: la GUI lo rileva al riavvio.
Sopra a questo abbiamo costruito le funzioni che servivano davvero al lavoro di caratterizzazione: editor registri con barra strumenti per filtrare e raggruppare, vista per-byte alternabile a vista multi-byte combinata, help live dal profilo attivo. E un loop software di auto-esposizione con auto-gain opzionale — qualcosa che la GUI originale Arducam non aveva. L’abbiamo aggiunto perché ci serviva per separare il rumore del sensore dalle variazioni di illuminazione durante i test, ma l’abbiamo scritto generico, non legato al sensore che stavamo testando.
Quando il tool diventa moneta di scambio
A un certo punto il tool funzionava bene, copriva il nostro caso, e ci siamo trovati ad avere documentazione di un sensore specifico — mappa registri verificata sul banco, gruppi funzionali, vincoli operativi — che Arducam non aveva ancora condiviso pubblicamente per quel modello.
Abbiamo scritto a un contatto tecnico Arducam via email diretta. Non era un cold pitch né una richiesta di endorsement: era un’offerta concreta. Avevamo dei profili JSON di sensore curati e verificati; loro avevano informazioni sui registri ufficiali che a noi mancavano. Una proposta di scambio fra ingegneri.
La risposta è arrivata entusiasta in meno di due giorni. Hanno apprezzato il tool al punto di inserirlo nella loro documentazione ufficiale come strumento utile per chi lavora con i loro evaluation kit, e lo scambio si è concretizzato: ora abbiamo accesso a informazioni di configurazione più dettagliate dal loro lato, e loro hanno un tool open source curato a cui rimandare la propria community.
Quello che li ha colpiti, dai messaggi che ci hanno scritto, non era una singola feature: era l’architettura aperta. Il fatto che il tool non fosse legato a un sensore specifico ma a un modello dati — i profili JSON — significava che era estensibile a tutti gli EVK del loro catalogo senza riscrivere codice. Un’altra persona poteva aggiungere il proprio sensore in mezz’ora.
Il valore di un tool pubblico
Il tool è nato per noi, su un caso specifico, con i vincoli di tempo veri di un progetto — non pensando ad Arducam. Quello che è successo dopo — la mail, la risposta entusiasta, l’inserimento nei docs ufficiali, lo scambio tecnico continuativo — è stato la conseguenza di una scelta fatta a monte: aprire l’architettura fin dall’inizio, anche quando ci sarebbe bastato hardcodare il sensore che stavamo testando.
A volte la cosa più efficace che si possa fare per essere visti non è scrivere un post di marketing, ma rilasciare bene un tool che è davvero servito — e progettarlo in modo che possa servire anche ad altri.
Il tool è open source, MIT-licensed, e vive su GitHub: arducam-evk-gui. Per la documentazione tecnica completa c’è la pagina wiki dedicata, e la scheda del repository raccoglie i link. Il tool è citato nella documentazione ufficiale Arducam; aggiungeremo qui il link puntuale alla pagina.
Lavori sulla caratterizzazione di sensori CMOS B&W ad alta velocità, o su un caso d’uso simile? Parliamone.