CircuitPython

Ciao, sono Alex di DEV STORIES DOT EU. CircuitPython, episodio 1 di 7. Se vieni dal mondo dei sistemi embedded tradizionali, configurare una toolchain di solito richiede più tempo che scrivere il primo programma. Passi ore a lottare con compiler, device driver e flashing utility dedicate solo per testare una singola riga di logica. Il drive CIRCUITPY bypassa completamente tutto questo. Gli sviluppatori embedded spesso cercano istintivamente un flash tool, un compiler o uno specifico Integrated Development Environment quando iniziano un nuovo progetto. Con CircuitPython, non ne hai bisogno. Non c'è alcuno step di compile. Il file system del sistema operativo gestisce il processo di deploy. Quando colleghi un microcontrollore compatibile con CircuitPython al computer tramite un cavo USB, la board si presenta al tuo sistema operativo come un dispositivo USB mass storage standard. Questo drive rimovibile si monta automaticamente e si chiama CIRCUITPY. Per il tuo computer, che tu usi Windows, macOS o Linux, sembra esattamente una normale chiavetta USB. Puoi aprirlo nel tuo file explorer, visualizzare i contenuti e modificarli. All'interno di questo drive, il file più importante è un file di testo tipicamente chiamato code dot py. Questo file fa da entry point per la tua applicazione. Puoi aprirlo in qualsiasi text editor standard. Non richiede un'applicazione specializzata; un text editor di base funziona perfettamente. Quando scrivi un programma semplice, magari un loop che stampa del testo o interagisce con la board, e premi salva, il ciclo di deploy inizia automaticamente. Ecco il punto chiave. Non hai bisogno di cliccare un pulsante di build o eseguire una utility da command line per fare il push del codice sull'hardware. Nel momento in cui salvi il file, il microcontrollore rileva l'attività del file system tramite la connessione USB. Questo comportamento è guidato da un meccanismo chiamato auto-reload. CircuitPython monitora attivamente lo stato della connessione USB mass storage. Quando avvii un'operazione di salvataggio nel tuo text editor, il computer scrive i dati sul drive CIRCUITPY. CircuitPython aspetta finché la scrittura sul file system non è completa. Una volta finita la scrittura del file, il sistema di auto-reload innesca un soft reboot del microcontrollore. Questo soft reboot è estremamente veloce. Interrompe qualsiasi cosa il microcontrollore stesse facendo, smonta in modo sicuro lo stato corrente e cancella completamente la memoria. Poi, fa immediatamente il parse ed esegue il file code dot py appena salvato, partendo dall'inizio. Il meccanismo di auto-reload crea un iteration loop molto stretto. Modifichi il codice, salvi il file e guardi l'hardware rispondere in meno di un secondo. Se c'è un syntax error nel tuo codice appena salvato, l'esecuzione si ferma in modo sicuro. Puoi visualizzare l'output dell'errore tramite una connessione seriale. Correggi il typo, salvi di nuovo il file e la board fa un reboot all'istante per provare il codice aggiornato. Il drive CIRCUITPY è anche il meccanismo per gestire le dipendenze. Se il tuo progetto richiede dell'helper code esterno per dell'hardware specifico, non usi un package manager da command line. Fai semplicemente drag and drop dei file di libreria necessari direttamente in una cartella designata chiamata lib sul drive CIRCUITPY. Il sistema di auto-reload traccia i cambiamenti anche in questa directory. Prima di concludere, se ti piacciono questi episodi tecnici e vuoi supportare lo show, puoi cercare DevStoriesEU su Patreon. Il cambiamento fondamentale qui è che il file system stesso fa da deployment pipeline, trasformando qualsiasi macchina con un text editor di base e una porta USB in una workstation di sviluppo embedded completa, senza installare un singolo driver. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. CircuitPython, episodio 2 di 7. Scrivi uno script per accendere una luce, salvi il file e la luce lampeggia per una frazione di secondo prima di spegnersi immediatamente. Il tuo codice è perfetto. Il problema è che quando uno script raggiunge la fine ed esce, il sistema resetta automaticamente lo stato dell'hardware. Per mantenere un dispositivo in funzione, devi impedire che lo script termini. È qui che entra in gioco il concetto di Hardware as Code. Nella programmazione tradizionale, il tuo codice manipola i dati in memoria. Nella programmazione embedded, il tuo codice manipola i segnali elettrici fisici. CircuitPython astrae questa complessità utilizzando tre moduli built-in: board, digitalio e time. Non devi installarli. Sono integrati direttamente nel firmware. Il modulo board funge da mappa hardware per il tuo specifico microcontrollore. Sa quale routing interno corrisponde ai pin fisici. Quando fai riferimento a board punto LED, stai prendendo l'indirizzo hardware corretto per la luce integrata, indipendentemente da quale modello fisico di board hai effettivamente tra le mani. Il modulo digitalio fornisce le classi necessarie per controllare il flusso di corrente elettrica. Traduce gli oggetti Python in segnali digitali. Infine, il modulo time gestisce le tempistiche. I microcontrollori eseguono milioni di istruzioni al secondo. Senza il modulo time per mettere in pausa l'esecuzione, una luce lampeggiante si accenderebbe e spegnerebbe così velocemente da apparire all'occhio umano come un'unica luce fioca e continua. Ecco come questi tre moduli lavorano insieme per far lampeggiare un LED integrato. Per prima cosa, importi board, digitalio e time. Poi, configuri l'hardware. Crei un nuovo oggetto usando la classe DigitalInOut dal modulo digitalio, e gli passi il pin board punto LED. Ora hai un oggetto Python che rappresenta quella specifica connessione fisica. I pin possono ricevere corrente in ingresso o emettere corrente in uscita. Devi dire esplicitamente a CircuitPython cosa deve fare questo pin. Imposti la proprietà direction del tuo nuovo oggetto pin su output. Questo dice al microcontrollore di spingere la tensione verso il LED. Ecco il punto chiave. Una volta configurato il pin come output, controllare il segnale elettrico fisico è esattamente come assegnare una variabile. Per accendere il LED, imposti la proprietà value del tuo oggetto pin su True. Dietro le quinte, CircuitPython traduce questa semplice assegnazione booleana in un segnale ad alta tensione, inviando corrente elettrica attraverso il circuito e illuminando il LED. Per spegnerlo, imposti la proprietà value su False, il che porta la tensione a zero. Ora, torniamo al problema iniziale. Se imposti semplicemente il valore su True e poi su False, lo script termina. CircuitPython fa cleanup resettando tutti i pin, e la tua board si spegne. Per far lampeggiare il LED in modo continuo, devi intrappolare la sequenza di esecuzione. Racchiudi i tuoi comandi in un ciclo while True infinito. All'interno di quel ciclo, imposti il valore del pin su True. Poi, usi time punto sleep per mettere in pausa lo script per mezzo secondo. Imposti il valore del pin su False. Metti in pausa per un altro mezzo secondo. Trattandosi di un ciclo infinito, lo script non arriva mai alla fine, l'hardware non si resetta mai e il LED continua a lampeggiare finché la board è alimentata. Quando scrivi hardware as code, non ti limiti a spostare byte. Stai fisicamente aprendo e chiudendo gate elettrici assegnando True e False a oggetti Python. Grazie per averci seguito. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. CircuitPython, episodio 3 di 7. La maggior parte del debug nei sistemi embedded prevede di modificare una riga di codice, aspettare la ricompilazione, fare il flashing della scheda e sperare che il tuo output log catturi il bug. Ma cosa succederebbe se potessi mettere in pausa l'esecuzione e comandare l'hardware in tempo reale? Questo è esattamente ciò che la serial console e la REPL ti permettono di fare. Quando colleghi una scheda CircuitPython al tuo computer, stabilisce una connessione seriale bidirezionale tramite USB. Puoi accedervi usando un programma terminale come PuTTY su Windows, o il comando screen su macOS e Linux. Molte connessioni seriali ti richiedono di impostare un baud rate specifico, in genere 115200. CircuitPython in realtà ignora questa impostazione via USB, ma è comunque prassi comune configurare il tuo terminale a quella velocità. La serial console è la tua finestra principale basata su testo verso la scheda. Ogni volta che il tuo script esegue un'istruzione print, l'output appare qui. Cosa ancora più importante, se il tuo codice incontra un errore fatale e va in crash, il traceback di Python viene stampato su questa console. Senza una connessione seriale aperta, una scheda in crash non ti dà alcuna informazione diagnostica. Semplicemente smette di funzionare. La serial console è anche il tuo punto di accesso alla REPL. REPL sta per Read, Evaluate, Print, Loop. È un prompt Python interattivo in esecuzione direttamente sul chip del microcontrollore stesso. Lo sviluppo firmware tradizionale richiede di scrivere il codice su una macchina host, compilarlo e trasferire il binary. La REPL cambia completamente questa dinamica. Tu digiti un comando, la scheda lo legge, valuta la logica, stampa il risultato e fa un loop tornando in attesa del tuo prossimo comando. Considera uno scenario pratico. Hai uno script in esecuzione sulla tua scheda, ma devi capire quale pin hardware controlla il LED built-in. Apri il tuo terminale seriale e premi Control C. Questo interrompe all'istante lo script in esecuzione. Ti viene richiesto di premere un tasto qualsiasi, il che ti fa entrare nella REPL. Sai di essere nel posto giusto quando vedi il prompt Python standard, che è formato da tre parentesi angolari. Ora, digiti import board. Per scoprire quale hardware è disponibile, passi il modulo board alla funzione built-in dir. La REPL stampa un elenco di tutti i nomi dei pin attivi per il tuo hardware specifico. Vedi il pin del LED nell'elenco. Proprio lì al prompt, importi il modulo digital IO. Crei un oggetto pin per il LED, imposti la sua direction su output, e imposti il suo value su true. Il LED fisico sulla tua scrivania si accende all'istante. Hai appena comandato l'hardware manualmente, una riga alla volta. Ecco il punto chiave. Il codice digitato nella REPL è effimero. Esiste solo nella memoria attiva di quella sessione corrente. Se scolleghi la scheda o la riavvii, tutto ciò che hai digitato scompare. La REPL è un tool esplorativo. È una sandbox dove puoi testare i limiti dell'hardware, verificare i nomi dei pin, o controllare la syntax al volo. Una volta trovata la sequenza esatta di comandi che raggiunge il tuo obiettivo, devi ricreare manualmente quella logica all'interno del tuo file code dot py sul drive USB per renderla permanente. Quando hai finito di testare, esci dalla REPL e riavvii il tuo codice salvato premendo Control D. Questo innesca un soft reboot, ricaricando il tuo file code dot py da zero. La REPL sposta lo sviluppo hardware da un lento ciclo di tentativi a un'esplorazione istantanea e interattiva. Grazie per l'ascolto, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. CircuitPython, episodio 4 di 7. I microcontrollori hanno una RAM incredibilmente limitata, il che significa che uno script relativamente breve può improvvisamente mandare in crash la tua board esaurendo completamente la memoria prima ancora di eseguire un singolo comando. Il colpevole è spesso il modo in cui la board elabora il codice esterno che importi, e risolvere questo bottleneck di memoria è esattamente lo scopo del Library Ecosystem. CircuitPython include moduli core integrati nel firmware, ma per hardware specifici come sensori di temperatura o display a LED, hai bisogno di librerie esterne. A differenza di un normale ambiente Python desktop, non c'è un package manager. Non lanci un comando per scaricare automaticamente un driver. Qui il dependency management è manuale by design. Quando colleghi il tuo microcontrollore via USB, appare come un flash drive. Nella root di questo drive c'è una directory chiamata semplicemente lib. Questa cartella è la casa dedicata a tutte le tue dipendenze esterne. Per popolarla, scarichi l'Adafruit Library Bundle, un enorme archivio ZIP che contiene centinaia di driver ufficiali e moduli helper. Ecco il punto fondamentale. Quando vai a scaricare questo bundle, vedrai diverse versioni disponibili. Un errore frequente è semplicemente scaricare il bundle più recente sulla pagina. Se la tua board fa girare CircuitPython versione otto, ma tu scarichi il bundle della versione nove, il tuo codice fallirà. La major version del bundle deve corrispondere esattamente alla major version del firmware CircuitPython installato sulla tua board. Se non corrispondono, il sistema lancia errori di bytecode incompatibile e si rifiuta di eseguirlo. All'interno di quel bundle corrispondente, troverai le librerie offerte in due formati di file distinti: file punto py standard e file punto mpy. I file punto py sono testo sorgente Python raw, human-readable. Anche se la tua board può farli girare, il microcontrollore deve caricare tutto quel testo raw nel suo minuscolo spazio RAM e compilarlo in bytecode al volo. Questo overhead di compilazione si mangia la memoria incredibilmente in fretta. I file punto mpy risolvono questo problema. Sono bytecode precompilato. Il pesante step di traduzione è già stato fatto su un computer prima ancora che tu scaricassi il file zip. Quando il microcontrollore carica un file punto mpy, esegue direttamente le istruzioni, bypassando completamente la fase di text parsing. Mettiamo che tu stia collegando una striscia LED NeoPixel alla tua board. Scrivi il tuo script di controllo, ma il sistema ha bisogno del driver hardware per sapere come comunicare con quegli specifici LED. Apri il tuo bundle di librerie con la versione corretta, individui il file chiamato neopixel punto mpy e lo trascini direttamente nella directory lib sulla board. Se invece avessi trascinato il file raw neopixel punto py, il tuo microcontrollore avrebbe potuto facilmente esaurire la memoria solo cercando di interpretare il codice del driver. Usando il file punto mpy precompilato, la board risparmia RAM critica per la tua vera application logic e accende immediatamente i pixel. Gestire le dipendenze manualmente ti obbliga a essere molto intenzionale su quale codice vive sul tuo device. Affidarsi al bytecode precompilato è l'unico modo per astrarre operazioni hardware complesse senza esaurire all'istante il minuscolo memory footprint di un microcontrollore. Questo è tutto per questo episodio. Grazie per l'ascolto, e keep building!

Ciao, sono Alex di DEV STORIES DOT EU. CircuitPython, episodio 5 di 7. A volte, eliminare una libreria dal tuo microcontrollore fa effettivamente girare meglio il tuo progetto. Rimuovi una grossa dependency dal tuo drive, riavvii la board, e il tuo codice magicamente continua a funzionare. Questo succede grazie a una feature chiamata Frozen Libraries. I microcontrollori, specialmente quelli più piccoli come la Circuit Playground Express, operano con limitazioni hardware estreme. Ogni file di libreria standard nella tua cartella lib occupa spazio di archiviazione fisico sul piccolo flash drive. Cosa ancora più importante, quando il tuo codice gira, il device deve caricare l'intero file nella sua random access memory. Se carichi troppi file, o file troppo grandi, finisci la memoria e il programma va in crash. Gli sviluppatori firmware risolvono questo problema facendo il freeze delle core library direttamente nella build di CircuitPython. Invece di esistere come file indipendente sul tuo drive USB visibile, il codice della libreria viene precompilato e pacchettizzato direttamente nel file firmware di base che carichi inizialmente sulla board. Questo offre un enorme vantaggio. Le Frozen Libraries occupano zero spazio sul tuo filesystem visibile. Dato che fanno parte dell'immagine di sistema core, il microcontrollore esegue il codice direttamente dalla memoria flash. Salta completamente il processo di copia della libreria nella random access memory. Questo porta a una trappola comune. Molti developer scaricano un enorme bundle di librerie, copiano tutto quello che pensano gli serva nella loro cartella lib, e accidentalmente duplicano librerie che sono già frozen nel loro firmware. Questo spreca spazio prezioso sul filesystem. Se elimini una libreria dalla tua cartella lib e il tuo progetto continua a girare senza problemi, quella libreria era frozen. Ecco il punto chiave. Per capire come evitare questa sovrapposizione, devi comprendere l'ordine di priorità di import controllato dal system path. Quando il tuo codice importa un modulo, CircuitPython non prende semplicemente la prima corrispondenza che vede. Cerca nelle varie posizioni seguendo una sequenza rigorosa. Primo, controlla la root directory del tuo drive. Secondo, controlla la cartella lib. Terzo, e solo se non riesce a trovare la libreria nelle prime due posizioni, controlla le Frozen Libraries nascoste all'interno del firmware. Questo ordine di priorità significa che qualsiasi file metti sul tuo drive fa l'override della versione frozen. Se metti una versione obsoleta o custom di una libreria nella tua cartella lib, CircuitPython esegue quel file. Ignora completamente la versione frozen, ottimizzata ed efficiente a livello di memoria, all'interno del firmware. Stai pagando il costo in memoria per un file che non avevi bisogno di fornire. All'interno di quelle directory, anche le estensioni dei file seguono una rigida regola di priorità. Un source file in plain text vince sempre su un file compilato. Se hai sia un file di testo standard che una versione compilata della stessa libreria esattamente nella stessa directory, CircuitPython carica il file di testo non compilato. Se vuoi sapere esattamente cosa è integrato nella tua specifica board, puoi aprire il prompt interattivo e digitare la parola help, passando la parola modules all'interno delle parentesi. Questo stampa una lista completa di ogni Frozen Library a tua disposizione out of the box. Il modo più intelligente per gestire la memoria su un device limitato è lasciare che il firmware faccia il lavoro pesante. Sapere esattamente cosa è già frozen previene i file duplicati, ferma gli override accidentali, e mantiene la tua memoria disponibile libera per la vera logica della tua applicazione. Grazie per l'ascolto. Statemi bene, ciao a tutti.

Ciao, sono Alex di DEV STORIES DOT EU. CircuitPython, episodio 6 di 7. Guardi un progetto hardware e noti che gli sviluppatori hanno deliberatamente rimosso feature avanzate come gli interrupt hardware dal core del linguaggio. Potresti pensare che questo abbia compromesso la piattaforma, ma in realtà l'ha resa un successo incredibile. Questa è la divergenza architetturale tra CircuitPython e MicroPython. Spesso gli sviluppatori danno per scontato che queste due piattaforme siano identiche. Entrambe fanno girare Python sui microcontrollori, e CircuitPython originariamente è nato come fork di MicroPython. Tuttavia, seguono filosofie completamente diverse. MicroPython è progettato per esporre la potenza bruta e le feature specifiche del microcontrollore sottostante. CircuitPython è progettato per imporre uno standard rigoroso e unificato su tutto l'hardware. La prima differenza che noterai è la standard library. MicroPython usa una naming convention che aggiunge il prefisso u ai moduli standard per indicare una versione micro. Importi uos o utime. CircuitPython lo abbandona completamente. Impone il naming standard del CPython per desktop. Importi semplicemente os o time. Se sei uno sviluppatore che sta facendo il porting di uno script MicroPython su CircuitPython, dovrai rinominare quegli import. In cambio di questo piccolo aggiustamento, il tuo codice diventa altamente portabile. Questa portabilità è la core feature di CircuitPython. MicroPython espone registri hardware specifici e numeri di pin specifici del chip. CircuitPython astrae completamente l'hardware usando un'API unificata incentrata su un modulo chiamato board. Invece di scrivere codice che fa il toggle del pin GPIO 15 su un ESP32, dici a CircuitPython di fare il toggle di board punto D4. Se sposti quello stesso script su un'architettura di microcontrollore completamente diversa, come un chip ARM Cortex standard, il codice hardware gira senza alcuna modifica. Per mantenere questa coerenza, CircuitPython impone alcune scelte architetturali che MicroPython lascia opzionali. Ad esempio, MicroPython ti permette di compilare il firmware senza supporto per i numeri floating-point per risparmiare memoria. CircuitPython impone il supporto floating-point in ogni singola build. Le operazioni matematiche si comportano esattamente allo stesso modo, indipendentemente da quanto sia limitato l'hardware. CircuitPython standardizza anche i messaggi di errore, fornendo un testo verboso e localizzato anziché dei concisi memory fault bare-metal. Ecco il punto chiave. La differenza più polarizzante è come i due gestiscono la concurrency. MicroPython supporta completamente gli interrupt hardware. Un interrupt permette a un cambio di stato di un pin fisico di mettere immediatamente in pausa il programma principale, eseguire una funzione specifica e poi riprendere. Questo fornisce un timing ad alte prestazioni, ma introduce anche complesse race condition e stati di memoria imprevedibili che sono incredibilmente difficili da debuggare. CircuitPython rimuove deliberatamente il supporto per gli interrupt hardware. Non puoi triggerare codice Python direttamente da un pin di interrupt hardware. Invece, impone il cooperative multitasking. Gestisci la concurrency usando le feature standard di asyncio o controllando gli stati in sequenza nel tuo main loop. Abbandonando gli interrupt, CircuitPython garantisce che il flusso di esecuzione rimanga completamente prevedibile ed elimina un'enorme categoria di silent crash. MicroPython ti dà le chiavi del bare metal, dando priorità alle raw performance e al controllo hardware. CircuitPython scambia questo controllo per un ambiente in cui il tuo codice è completamente portabile, prevedibile e si comporta esattamente come il Python standard che fai girare su un desktop. Grazie per l'ascolto, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. CircuitPython, episodio 7 di 7. Passi giorni a scrivere e testare il codice di interazione hardware per un sensore su un minuscolo microcontrollore da cinque dollari. Poi i requisiti del progetto cambiano, e all'improvviso hai bisogno della potenza di calcolo di un computer Linux completo per salvare quei dati su un database cloud remoto. Normalmente, passare da un microcontrollore bare-metal a un sistema operativo completo significa dover riscrivere completamente il tuo codice hardware. La tua piattaforma target ora ha un kernel dell'OS che gestisce l'accesso all'hardware, richiedendo driver e librerie completamente diversi. Ma cosa succederebbe se lo stesso identico script Python potesse girare senza modifiche su entrambe le piattaforme? Questo è esattamente ciò che Adafruit Blinka ti permette di fare. Prima di spiegare come funziona, chiariamo un malinteso comune. Blinka non sostituisce il sistema operativo Linux sul tuo Raspberry Pi, BeagleBone o su altri single-board computer. Non devi flashare un file firmware di CircuitPython su una scheda SD come fai con un microcontrollore. Invece, Blinka è semplicemente un pacchetto Python. Lo installi usando lo standard pip. Agisce come un compatibility layer che gira all'interno del CPython standard per desktop. Il suo unico compito è tradurre le chiamate API di CircuitPython nelle system call standard di Linux necessarie per controllare l'hardware. Quando scrivi codice hardware su un microcontrollore, CircuitPython gestisce l'accesso diretto all'hardware. Su un sistema Linux, il kernel del sistema operativo controlla l'hardware, e i programmi utente devono richiederne l'accesso. Blinka colma questo divario. Quando il tuo codice importa il modulo board o usa il modulo digitalio per fare il toggle di un pin, Blinka intercetta quei comandi. Mappa i nomi dei pin di CircuitPython allo specifico layout hardware del tuo single-board computer, instradando la richiesta attraverso i sottosistemi Linux necessari. Pensa a come questo si traduce in pratica con il nostro sensore di temperatura. Sul piccolo microcontrollore, il tuo codice importa board, configura un bus I2C e legge continuamente i valori di temperatura. Per scalare questa operazione su un Raspberry Pi 5, colleghi fisicamente il sensore agli header pin del Pi. Poi, all'interno del tuo terminale Linux, usi pip per installare Adafruit Blinka e il driver Python specifico per il tuo sensore di temperatura. Copi il tuo script Python originale, senza modificarne una sola riga. Quando esegui lo script usando Python 3 standard, il modulo board rileva dinamicamente che sta girando su un Raspberry Pi 5. Fornisce automaticamente le definizioni corrette dei pin per quella specifica board. Il modulo busio traduce in modo trasparente le tue richieste di lettura I2C in chiamate standard ai device I2C di Linux. Il tuo script legge i dati del sensore esattamente come faceva prima. Ed è qui che la cosa si fa interessante. Dato che ora stai facendo girare CPython standard su una macchina Linux completa, non sei più vincolato dai limiti di memoria di un microcontrollore. Il tuo script può leggere il sensore hardware usando il translation layer di Blinka, e poi passare immediatamente quei dati a librerie desktop più pesanti. Puoi usare richieste di rete standard per inviare le metriche a un database cloud, elaborare la telemetria con tool di data science, o persino servirla tramite un framework web locale. Ecco il punto chiave. Il codice di interazione hardware rimane identico su architetture di calcolo completamente diverse. Disaccoppiando la logica del sensore dal sistema operativo sottostante, Blinka ti permette di prototipare a basso costo su bare-metal e di scalare verso ambienti Linux completi con zero riscritture del codice hardware. Questo conclude la nostra serie su CircuitPython. Ti incoraggio a leggere la documentazione ufficiale, a provare a configurare un sensore con Blinka hands-on, o a visitare devstories dot eu per suggerire argomenti per le prossime serie. Per questo episodio è tutto. Grazie per l'ascolto, e continua a sviluppare!