Arduino è un nome molto conosciuto: ne esistono cloni, versioni derivate e soprattutto progetti ad esso ispirati. Non molto tempo fa, infatti, vi abbiamo parlato di Archiduino, una soluzione Open Source non solo compatibile con Arduino Leonardo ma pensata per riconsiderare il progetto Archimede ed adattarlo a nuove esigenze (anche grazie all'impiego dell'ATMega32). Oggi, dopo avervelo presentato, lo vediamo al lavoro ed in particolare valuteremo un caso applicativo che prevede l'utilizzo di un canale di comunicazione su bus SPI. Siete pronti?

Quando abbiamo presentato la piattaforma che oggi torna ad essere protagonista ne abbiamo lodato soprattutto la natura Open Source perché, sebbene si tratti di un prodotto finito, con applicazioni di riferimento e disponibile per l'acquisto, mantiene il perfetto spirito da cui è stato ispirato, lasciando liberi tutti coloro che avranno a che fare con la scheda di riprodurla e modificarla.
È importante sottolineare che la natura Open non è stata alterata per cui questa è la dimostrazione che si può fare “impresa” mantenendo un profondo rispetto nei confronti del lavoro degli altri.

Lo scopo primario di questa scheda è quello di sfruttare al massimo due caratteristiche dell'hardware, ovvero flessibilità e modularità. Tutto questo, come abbiamo visto, grazie all'utilizzo di un ambiente di sviluppo molto ben conosciuto dalla comunità Arduino, ovvero il suo IDE.

Nella seguente immagine è possibile capire come è strutturato il sistema:

Archiduino stupisce per la sua completezza di dotazione: dall'orologio alla micro SD card, dalla EEPROM al display LCD. Tutte queste caratteristiche rendono la scheda particolarmente utile in qualunque tipo di applicazione domotica in cui ci sia la necessità di fare azionamenti, record di informazioni, gestione di allarmi o segnalazioni basate sull'orario. E, naturalmente, qualunque combinazione tra queste.

Senza contare quanto detto riguardo alla possibilità di inserire il sistema in un contenitore modulare da barra DIN, il che rende più facile il montaggio e più protetta la scheda da qualunque eventuale contatto accidentale.

Un piccolo esempio di rete realizzata con moduli Archiduino e la libreria Xtendino per la comunicazione su bus SPI è il seguente:

Approfondiamo

Molti di noi sanno che il bus SPI è prevalentemente utilizzato da dispositivi che si interfacciano con un microcontrollore, per avervi accesso nel modo più veloce possibile. Ma naturalmente, vista l'esigenza della comunicazione, viene anche la voglia di sperimentare: il collegamento alle periferiche può essere fatto con quest'interfaccia?

Archiduino, quindi, viene oggi testato come una libreria che prende il nome di Xtendino la quale è stata progettata specificatamente per aggiungere risorse ad un sistema.

Per comprendere al meglio le necessità, i risultati attesi e soprattutto le possibilità che l'SPI offre, bisogna segnalare che il bus non è affatto il più indicato quando si vogliono percorrere lunghe distanze; è per questo motivo che si consiglia caldamente di mantenersi entro la decina di centimetri di distanza.

Non è un mistero che qualsiasi interfaccia di comunicazione abbia dei limiti, quantomeno fisici. Ecco allora che bisogna affrontare il discorso sulla velocità di comunicazione.

Utilizzando il bus alla massima velocità il tempo impiegato per la trasmissione di un carattere è inferiore ai 4 us, e questo lo vediamo nell'immagine che segue:

C'è da considerare che un canale seriale RS232 configurato a 9600 baud impiega circa 1 ms a carattere.

Questo vuol dire che siamo in grado di inviare un pacchetto dati, mediamente composto da una ventina di caratteri, in meno di 1 ms. Vediamolo:

Se, dunque, la velocità ci sembra un aspetto molto positivo, è necessario considerare che esistono complicazioni che si possono ricondurre a tre problemi principali:

• necessità di abilitazione (enable) per ogni slave;
• latenza (ritardo) sulla risposta;
• “desincronizzazione”.

L'enable

La libreria Xtendino è stata studiata in maniera tale da non utilizzare altro che i principali segnali associati al bus SPI, ovvero Clock, MOSI e MISO, in collegamento tra loro come segue:

Quello che faremo, in effetti, però, è leggermente diverso:

Qual è il vantaggio? Semplice: non vengono occupati segnali da utilizzare come “enable”. È tutto qui? Naturalmente no: c'è il beneficio che tutti gli slave sono sempre abilitati e, di conseguenza, ricevono e trasmettono ogni volta che il master trasmette dati sul bus.
Succede anche che, quando il microcontrollore utilizza un altro dispositivo (ad esempio la memoria SD), anche gli slave vengono coinvolti. Questo perchè  su un bus SPI solo un dispositivo per volta può comandare il bit MISO, mentre le periferiche non abilitate devono mantenere questo pin in alta impedenza.

Come risolviamo questo problema? Inviando nel pacchetto dati un segnale convenzionale, che funziona come una chiave di abilitazione software: soltanto quando la sequenza di caratteri viene riconosciuta lo slave abiliterà l'uscita MISO.

Sebbene attualmente la chiave sia limitata a cinque caratteri, è necessario tenere presente che l'utilizzo del bus SPI allo scopo di effettuare comunicazioni è tutto da testare e verificare ed un primo controllo può essere fatto aumentando il numero di caratteri che compongono la chiave (che naturalmente ridurrà la probabilità che lo slave risponda):

La latenza

Il bus SPI è, ovviamente, un bus sincrono e la cadenza con cui vengono trasmessi i caratteri è stabilita dal master. Ma all'interno della libreria Xtendino è stata fatta una scelta precisa, ovvero l'inserimento di una funzionalità per la quale lo slave non aspetta di ricevere tutto il comando per inviare la risposta al master ma, mentre riceve i caratteri, elabora già la risposta.
Questo, però, comporta una complicazione, ovvero che lo slave, tra un carattere e l'altro, deve elaborare i dati da inviare.

Come si risolve? Il bit MISO viene controllato dallo slave per generare un segnale di occupato (busy) che il master acquisirà leggendone lo stato; solo quando il segnale sarà basso verrà inviato il carattere successivo. Lo vediamo nel dettaglio con la figura che segue:

Desincronizzazione

Come dicevamo, il terzo ed ultimo problema è quello della desincronizzazione. Di che si tratta? Per capirlo meglio è indispensabile ricordare il principio di funzionamento del bus SPI:

Per ciascun impulso di clock (generato dal master) avviene una rotazione dei bit presenti nei due shift register. Il bit MSB del master finisce sull'LSB dello slave, l'MSB dello slave finisce sul bit LSB del master e così via fino alla completa trasmissione del byte. Descriverlo è sicuramente più complicato che vederlo applicato per cui, nell'immagine successiva, potete vedere il ciclo completo della trasmissione:

Fin qui tutto bene. La domanda diventa: quand'è che si verifica il problema della “desincronizzazione”?

Accade nel momento in cui uno dei due shift register riceve degli impulsi “spuri” che fanno avanzare un registro in maniera non sincrona rispetto all'altro. Ed è proprio il collegamento tra master e slave il punto debole del sistema:

Avete visto? Qui il dispositivo più esposto a ricevere degli impulsi spuri è lo slave, ma questo non vuol dire che il master non possa risentirne.

Quando il microcontrollore comanda un dispositivo è difficile che si verifichi il problema perché i collegamenti sono molto ridotti.

L'uso del bit di enable, inoltre, riallinea i due shift register. Purtroppo, nel sistema Xtendino, nel quale l'enable dello slave risulta sempre abilitato, la desincronizzazione interviene direttamente sugli shift register per tutta la durata della trasmissione del pacchetto dati. Ma non solo, perché si rischia di bloccare completamente la comunicazione per via degli effetti sulle trasmissioni successive.

Per porre un rimedio è stato necessario fare alcune prove sul sistema e verificare che, disabilitando e riabilitando il bus, tramite operazioni sui bit che controllano il registro del microcontrollore, lo shift register viene reinizializzato. L'operazione in questione viene effettuata soltanto dagli slave.

Per ottenere l'allineamento dei due shift register, all'inizio di una nuova comunicazione, il master invia un carattere non significativo, che prende il nome di dummy byte: alla ricezione del primo carattere, lo slave effettua il riallineamento.

Conclusioni

L'abbiamo lodata come iniziativa ed apprezzata come dotazione hardware ma vederla al lavoro ci consente di guardare ad Archiduino in un'ottica diversa, ovvero quella di un progetto funzionale e completo, studiato per rispondere ad esigenze precise e nel più minimo dettaglio.

I test e l'analisi del sistema di comunicazione basato sulla libreria Xtendino hanno dato ottimi risultati. C'è sicuramente del lavoro da fare per poter rendere questa soluzione utile e spendibile in ambito professionale ma le premesse sono tra le migliori.

Vi lasciamo con due contributi video che saranno sicuramente interessanti per voi:

Se volete ulteriori dettagli su quanto vi abbiamo raccontato potete trovarli sul sito di SELETRONICA.

Ti potrebbe interessare anche:

Il sistema di comunicazione wireless Li-Fi indoor

I connettori lineari a basso profilo risolvono la gestione dei dati Multi-Signal

Progettazione di un sensore di velocità acustico passivo