Utilizzare le BOB Arduino per valutare rapidamente sensori e periferiche

La nascita di Internet delle cose (IoT) ha ispirato molte startup innovative alla ricerca del prossimo prodotto connesso rivoluzionario. Molte di queste startup hanno team di progettazione piccoli e snelli, ma si trovano comunque a dover far fronte a un time-to-market sempre più ristretto. Di conseguenza, i singoli progettisti sono chiamati a occuparsi di più settori e compiti di ingegneria, tra cui la rete analogica, digitale, a radiofrequenza (RF) e wireless/cablata. E, ovviamente, sono sempre alla ricerca di modi per accelerare la valutazione di circuiti integrati, sensori e periferiche e ridurne i costi.

Un'opzione è utilizzare i kit di valutazione e sviluppo offerti dai fornitori di circuiti integrati a supporto delle loro soluzioni. Se si parte dall'ipotesi che il livello di supporto sia buono, questo approccio va benissimo. Vi è però un'altra opzione: prendere in considerazione l'ecosistema Arduino. Quello che all'inizio era solo un parco giochi per hobbisti, è diventato un vero e proprio ecosistema di progettazione e supporto.

Questo articolo mostrerà come i progettisti possono utilizzare Arduino per iniziare a valutare circuiti integrati, periferiche e sensori nelle prime fasi del ciclo di progettazione, servendosi di hardware open-source sotto forma di schede di breakout (BOB) di sensori e periferiche, assieme a software open-source sotto forma di librerie e programmi di esempio. A scopo di esempio, utilizzeremo i clock in tempo reale (RTC) di Maxim Integrated e le BOB di Adafruit Industries

La nascita di IoT

Uno dei primi esempi reali di IoT risale agli inizi degli anni '80, quando alla Carnegie Mellon University un distributore di Coca-Cola venne collegato per permettere ai programmatori di usare Internet per controllare se le bevande erano disponibili e se erano fredde, prima di recarvisi di persona. Internet delle cose, come concetto, è stato ufficialmente battezzato solo nel 1999.

Il momento esatto della sua nascita non vede tutti d'accordo. Forse la migliore definizione della nascita di IoT, così come lo conosciamo noi, è "il momento in cui a Internet risultarono collegate più "cose" o "oggetti" che non persone". Partendo da questo assunto, si stima che IoT sia nato tra il 2008 e il 2009, con un rapporto cose/persone che è passato da 0,08 nel 2003 a 1,84 nel 2010.

La nascita di Arduino

La gestazione di IoT ha coinciso con la nascita del movimento dei maker nei primi anni 2000. La prima implementazione mondiale di Arduino è avvenuta nel 2005, lo stesso anno in cui fu lanciata la rivista Make e solo un anno prima della prima edizione di Maker Faire.

Fin dalla sua nascita, Arduino ha sviluppato sofisticati ecosistemi hardware e software open-source. Ciò che veniva chiesto era un modo per portare gli ecosistemi ben supportati di Arduino nel regno dei progettisti professionisti per semplificare il loro lavoro e accelerare il time-to-market.

La soluzione è nata di fatto in modo organico. L'enorme ecosistema che si è sviluppato intorno ad Arduino ha prodotto un effetto collaterale imprevisto: gli ingegneri professionisti utilizzano Arduino per valutare sensori e periferiche prima di implementarli nei loro progetti. Di esempi se ne contano ormai tanti, e l'RTC è uno di quelli.

Esempio di valutazione delle periferiche utilizzando un RTC

Quasi tutti i moderni microcontroller a 32 bit sono dotati di un RTC integrato, così come molti microcontroller a 16 e persino a 8 bit. Sebbene questo limiti lo spazio sulla scheda, riduca la distinta base e il costo del prodotto finale, l'uso di un RTC interno ha degli svantaggi.

Il microcontroller deve abilitare e disabilitare il suo RTC interno sotto il controllo software, quindi se si verifica ad esempio un glitch di alimentazione e il microcontroller si blocca o il suo codice viene danneggiato, l'RTC potrebbe venire inavvertitamente disabilitato. Un RTC esterno è considerato invece più robusto in quanto ha un rail di alimentazione e un cristallo separati, ed è meno probabile che venga spento accidentalmente dal codice in esecuzione sul microcontroller. Inoltre, in genere l'RTC esterno viene implementato utilizzando un nodo di processo di fabbricazione di chip più grandi del microcontroller, e il suo maggiore ingombro lo rende meno suscettibile ai bit-flip, cioè ai disturbi da evento singolo (SEU) causati dalle radiazioni, come i raggi cosmici.

Esempio di CI di RTC: DS1307 e DS3231 di Maxim Integrated

Due CI di RTC molto diffusi sono DS1307 e DS3231 di Maxim Integrated. Entrambi questi dispositivi tengono traccia di secondi, minuti, ore, giorno, data, mese e anno; si regolano automaticamente per mesi con meno di 31 giorni, tengono conto degli anni bisestili e supportano le modalità 24 o 12 ore. Inoltre, comunicano entrambi con il microcontroller host per mezzo di un bus I²C seriale e includono un circuito di rilevamento che rileva le interruzioni di corrente e passa automaticamente all'alimentazione ausiliaria (di solito una batteria), garantendo il mantenimento delle operazioni di temporizzazione (Figura 1).

Figura 1: DS1307 è un buon esempio di RTC esterno. Hanno il vantaggio di un proprio rail di alimentazione e di un cristallo locale e non sono soggetti a errori del codice. Comunica con il microcontroller host su un'interfaccia I²C. (Immagine per gentile concessione di Maxim Integrated)

Per scoprire le differenze tra questi dispositivi è ovviamente importante controllare le schede tecniche. Ad esempio, DS1307 richiede un'alimentazione di 5 V e un cristallo esterno. Il più preciso DS3231, invece, può funzionare con un'alimentazione tra 2,3 e 5,5 V ed è dotato di un oscillatore a cristallo termostabilizzato (TCXO) integrato e di un cristallo.

A volte, le differenze tra questi componenti non risultano subito evidenti. Ad esempio, entrambi i dispositivi forniscono un'uscita SQW (onda quadra) che, se attivata sotto controllo software, richiede un resistore pull-up esterno. Nel caso però di DS1307, l'uscita SQW può essere programmata per generare un segnale a 1 Hz, 4,096 kHz, 8,192 kHz o 32,768 kHz. Nel caso di DS3231, invece, questa uscita può essere programmata per generare un segnale a 1 Hz, 1,024 kHz, 4,096 kHz o 8,192 kHz.

Nel caso di DS1307, la precisione del clock dipende dalla precisione del cristallo e da quella della corrispondenza tra il carico capacitivo del circuito dell'oscillatore e quello capacitivo per il quale il cristallo è stato regolato. Facendo un confronto, DS3231 termostabilizzato ha una precisione più specifica di ±2 minuti all'anno tra -40 °C e +85 °C (Figura 2).

Figura 2: DS3231 è un oscillatore a cristallo termostabilizzato con una precisione di ±2 minuti l'anno su un intervallo di temperatura tra -40 °C e +85 °C. (Immagine per gentile concessione di Maxim Integrated)

Presumendo quindi che non ci siano degli "elementi fortemente contrari" nelle schede tecniche di questi due dispositivi, come farebbero i progettisti a valutarli nel mondo reale? Una soluzione potrebbe essere quella di progettare e costruire schede di breakout (BOB) personalizzate, sviluppando da zero anche il codice per pilotarle. Ma sarebbe più veloce ed economico utilizzare BOB di serie e codice sviluppato come parte degli ecosistemi hardware e software di Arduino.

Esempio di BOB RTC: DS1307 e ChronoDot di Adafruit

Due BOB diffuse per i CI DS1307 e DS3231 sono la BOB RTC DS1307 3296 (Figura 3) e la BOB RTC V2.1 ultraprecisa ChronoDot 255 (Figura 4) di Adafruit.

Figura 3: BOB RTC DS1307 di Adafruit. (Immagine per gentile concessione di Adafruit Industries)

Figura 4: BOB RTC v2.1 ultraprecisa ChronoDot. (Immagine per gentile concessione di Adafruit Industries)

Quando abbinata a una scheda di sviluppo di microcontroller appropriata, come ad esempio una Arduino Uno R3, in combinazione con librerie open-source e codici di esempio scaricabili tramite Internet, i progettisti professionisti di sistemi embedded e dispositivi IoT sono pronti a mettersi subito al lavoro.

Terminate le valutazioni, i progettisti possono prendere le parti appropriate dei progetti hardware open-source per le BOB e incorporarle direttamente nei loro progetti. Allo stesso modo, possono prendere le librerie open-source e il codice che hanno sviluppato sulla base degli esempi open-source e utilizzarli come parte dei loro prodotti.

Suggerimenti e consigli sull'hardware per gli sviluppatori di software

Come ricordato in precedenza, gli RTC sia DS1307 che DS3231 comunicano con il microcontroller host tramite un bus I²C seriale. Uno dei "gotcha" che spesso assilla gli sviluppatori di software è che entrambi i segnali che formano questo bus (chiamati SCL e SDA) richiedono resistori pull-up.

Né la BOB DS1307 né quella DS3231 (ChronoDot) di Adafruit includono questi resistori, anche se ChronoDot ha delle piazzole con contrassegni R1 e R2 in cui possono essere aggiunti.

La ragione per non includere resistori pull-up è che a un bus I²C possono essere attaccati più dispositivi (CI o BOB). Il bus I²C usa un indirizzo a 7 bit, dove 2⁷ = 128. Tuttavia, l'indirizzo 0000000 è un indirizzo di chiamata generale che viene utilizzato per tutti i dispositivi sul bus, permettendo al bus, in teoria, di supportare 127 dispositivi discreti. In pratica, il numero effettivo di dispositivi che possono essere supportati dipende dalla capacità del bus, compresa la capacità delle tracce e dei carichi, che è limitata a un totale di 400 pF.

Esiste una formula che i progettisti hardware utilizzano per calcolare il valore equivalente di resistori multipli collegati in parallelo. Ai fini di queste discussioni, possiamo prendere in esame un semplice esempio come quello che segue. Se due dispositivi hanno resistori pull-up dello stesso valore, la resistenza risultante è la metà del valore; se quattro dispositivi hanno resistori pull-up dello stesso valore, la resistenza risultante è un quarto del valore.

Se sul bus è già presente un dispositivo I²C con resistori pull-up, non occorre fare nient'altro. Se non ci sono resistori pull-up e il progettista ha l'assoluta certezza che in futuro non aggiungerà una BOB con resistori pull-up, è preferibile usare una coppia di resistori da 4,7 kΩ per i pull-up. Tuttavia, se questa possibilità esiste, a questo punto si dovrebbe aggiungere una coppia di resistori da 10 kΩ perché lavoreranno prima e dopo l'aggiunta dell'altra BOB al bus.

Suggerimenti e consigli sul software per i progettisti hardware

La "libreria wire" è una libreria di comunicazione che facilita le comunicazioni a due fili con dispositivi I²C. Nel caso di Arduino, viene fornita come parte dell'ambiente di sviluppo integrato (IDE), quindi un progettista deve solo aggiungere l'istruzione #include <Wire.h> all'inizio del programma.

Il vero trucco è trovare una libreria RTC idonea. RTClib di Adafruit è una di queste e può essere scaricata da Github. Aggiungere poi l'istruzione #include "RTClib.h" all'inizio del programma.

In seguito, di solito dopo aver definito tutti i valori costanti, occorre creare un'istanza di RTC tramite l'istruzione RTC_ DS1307 RTC; o RTC_DS3231 RTC; a seconda della BOB utilizzata.

Quindi, al momento di impostare tutto nel loro programma (come parte della funzione setup() nel caso di uno sketch Arduino), i progettisti devono aggiungere le istruzioni Wire.begin(); e RTC.begin(); per inizializzare le comunicazioni I²C e il sottosistema RTC.

Gli esempi forniti nella pagina Github ricordata sopra permetteranno al progettista di accedere e modificare rapidamente la data e l'ora correnti. Meno ovvio è come accedere all'uscita SQW (onda quadra). Per impostazione predefinita, questa uscita è inattiva per risparmiare energia. Si potrebbe rendere attivo questo pin e impostarlo a 1 Hz, ad esempio, quindi utilizzare questo segnale per far scattare un interrupt sul microcontroller host.

Uno sviluppatore di software non avrà difficoltà a trovare tutto ciò che gli serve nel codice della libreria; ma per un progettista di hardware la cosa sarà più problematica, quindi ecco un breve riassunto:

Nel caso di DS1307, è sufficiente aggiungere una o più istruzioni del tipo RTC.Ds1307SqwPinMode(<option>); dove i valori delle opzioni supportate sono ON, OFF, SquareWave1HZ, SquareWave4kHz, SquareWave8kHz e SquareWave32kHz.

Analogamente, nel caso di DS3231, aggiungere una o più istruzioni del tipo RTC.Ds3231SqwPinMode(<option>); dove i valori delle opzioni supportate sono ON, OFF, DS3231_SquareWave1Hz, DS3231_SquareWave1kHz, DS3231_SquareWave4kHz e DS3231_SquareWave8kHz.

Conclusione

Con team più piccoli e un time-to-market sempre più ristretto, i progettisti devono svolgere più attività e occuparsi di più campi di ingegneria, cercando sempre nuovi modi di accelerare la valutazione di circuiti integrati, sensori e periferiche e ridurne i costi. Come è stato dimostrato, un modo è quello di utilizzare Arduino con hardware open-source sotto forma di sensori e schede di breakout (BOB) periferiche, in combinazione con software open-source sotto forma di librerie e programmi di esempio.