Cosa rende felice un ingegnere?

Ci sono tanti imprevisti quando si programma: una variabile riallocata per errore, una routine scritta male, un ciclo mal condizionato. Tra gli esempi più comuni ci sono le interfacce di comunicazione. Questa è una storia che parla di come gli ingegneri sorridano quando le interfacce funzionano e diventino, invece, funerei quando queste ultime si dimostrano fallaci.

Nella famiglia delle interfacce più comuni che permettono il collegamento tra microprocessori e circuiti integrati ci sono: Usart, SPI, I²C e GPIO. Bene, tra mito e legenda, tra serio e faceto, in questo articolo cercheremo di discutere alcuni degli errori più comuni che si verificano nelle comunicazioni seriali; molti di questi sono piuttosto difficili da identificare qualora si verifichino in sistemi molto “grandi” o comunque complessi.

E dal fatto che il sistema funzioni discende la felicità dell'ingegnere che ci sta lavorando.

Come può una semplice interfaccia far sorridere un programmatore?

Stabilire la modalità di comunicazione, e quindi di interfacciamento tra un circuito integrato ed un micro controllore, oppure una CPU, è piuttosto importante per rendere il progetto funzionante. Le interfacce, di solito, sono semplici da gestire ma molto spesso se ne sottovaluta l'importanza. Il tempo impiegato per gli sforzi ripagati sono gli elementi che possono regalare un sorriso al programmatore impegnato nella realizzazione del sistema.

Il programmatore triste è, tipicamente, quello sul quale si è abbattuta la legge di Murphy; è quasi proverbiale ma ormai è noto alla stragrande maggioranza di tutti noi che “se qualcosa può andare storto, lo farà!”

Murphy viene, talvolta, considerato un semplice iettatore ma in realtà la sua formulazione è di stimolo a tutti gli uomini di scienza, un monito saggio a considerare sul serio ogni possibile variabile, senza trascurare nulla. Perché qualunque dato si trascuri, si dimostrerà non trascurabile.

Ed ecco, sull'onda di questa riflessione, un articolo che parla di una storia di interfacciamento seriale come molte se ne sentono. La storia di come un'operazione di comunicazione e bitstream possa rattristare il volto di un programmatore.

“Vi prego, qualcuno dica al mio bus SPI di fermarsi!”

Un bus di interfaccia di comunicazione seriale (SPI) non è altro che un bus di dati sincroni seriali che operano una comunicazione di tipo full-duplex. I dispositivi comunicano in una modalità master/slave, ovvero esistono delle gerarchie, in cui i dispositivi master iniziano la trasmissione dei dati ed uno o più slave restano “in ascolto” su linee dedicate. A volte un'interfaccia seriale viene anche identificata con il nome di “three/four wires” per indicare i collegamenti che sono presenti all'interno del bus. Un'interfaccia seriale in cui la comunicazione avvenga in una sola direzione offre “facilmente” un isolamento galvanico per ridurre la possibilità di anelli di terra, ovvero collegamenti parassiti o scariche localizzate non desiderate. L'interfaccia di questo tipo risulta unidirezionale perché ciascuno dei quattro collegamenti viene “percorso” dall'informazione in un solo senso. L'isolamento galvanico può essere ottenuto grazie a diverse tecnologie: ottica, capacitiva oppure con accoppiamento a trasformatore.

Nella figura che segue analizziamo, schematicamente, il funzionamento di questo particolare bus.

 

non è certo corretto affermare che il bus di collegamento seriale sia semplice da gestire e che non vi si verifichino mai errori. Si tratta, tuttavia, di una stringa di registri che vengono scritti in maniera seriale per cui risulta, in ogni modo, semplice dal punto di vista concettuale: quando la linea denominata “chip select” risulta “alta” i registri risultano “caricati” del dato perché sono abilitati alla ricezione. Se per il registro corrente la linea di selezione resta bassa, allora nessun caricamento verrà effettuato su quel registro.

L'interfaccia risulta molto efficace perché permette la selezione degli elementi di memoria da utilizzare per ciascuna operazione.

Se proviamo ad immaginare, come rappresentato nella figura, che ci siano tre dispositivi collegati, avremo che il primo dei tre chip “ vedrà” il comando al terzo, seguito dai comandi al secondo. Solo dopo che sarà arrivato il suo comando, allora il “chip-select” diventerà alto per lui. Allora, e solo allora, i comandi avranno senso per ciascun chip. Perché saranno completi.

Quando il sistema diventa più grande, e quindi le istruzioni che deve seguire diventano maggiori, allora è possibile che i comandi vengano inviati in maniera parziale, con conseguenze catastrofiche sul funzionamento globale. Questo tipo di errori, che risultano fatali, accadono quando i bit vengono caricati all'inizio dello shift-register del bus. Così, prima che i bit si trovino nella posizione corretta all'interno dello shift-register, il chip select diventa alto e qualunque cosa che fosse presente all'interno del registro viene posta in shift parallelo all'interno del chip.

È possibile illustrare il funzionamento corretto dell'interfaccia dall'analisi del MAX5312; il DAC prevede l'ordinamento dei bit in ordine decrescente (dall'MSB all'LSB), e l'utilizzo di bit di controllo, C3, C2, C1 e C0, per effettuare le operazioni di caricamento dei registri.

Grazie alla figura che segue, viene illustrato quale dovrebbe essere il corretto “comportamento” dell'interfaccia.

Un rumore misterioso...

A volte un utente può risultare preoccupato dalle “strane cose” che accadono nel suo sistema. Molto spesso, di questi fenomeni che tendono al paranormale, si incolpa il rumore ma non è sempre così.

Talvolta il rumore semplicemente non si comporterebbe in quel modo e questo dipende dal fatto che se una trasmissione su interfaccia seriale non avviene, allora semplicemente è successo che il chip-select (da adesso abbreviato in CS, anche se la dicitura completa dovrebbe prevedere la negazione) è rimasto basso, ovvero zero. Questo significa che non c'è rumore coinvolto perché se così fosse si sarebbero fluttuazioni rapide ma non un valore fisso.

Nel frattempo clock e data continuano a fluttuare, questi sì, tra il 30% ed il 70% dei valori delle relative soglie. L'esperienza insegna che se ce n'è davvero del rumore, e tanto da creare problemi, spesso si propaga ed ha effetti anche sul dato desiderato che comincia a fluttuare come risultato di operazioni “strane” compiute dal DAC. Se noi abbiamo, invece, tre linee pulite, un grande rumore sulle linee di clock e data è improbabile.

Il rasoio di Occam insegna che la soluzione più semplice è di sicuro la migliore, nonché la più probabile. Quindi, nel nostro esempio, è molto più probabile rispetto ad una “strana attività” che ci siano semplicemente dati incompleti in transito sull'interfaccia. Da dove viene? Durante lo sviluppo del sistema di solito si lavora con “pezzi del sistema” piuttosto che con l'intera realizzazione completata ed è possibile che, con il processore non “completamente” al lavoro ci siano istruzioni di interrupt troncate, a livello di comandi su interfaccia. Man mano che il sistema diventa più complesso e si completa, questi fenomeni possono essere molto più frequenti è la probabilità che si manifestino come problematiche sul funzionamento diventa più alta.

Ecco per quale motivo è esplicitamente richiesto che ci sia la necessità di mascherare gli interrupt durante le trasmissioni.

E il rumore che fa sul circuito?

Grandi sorgenti di rumore possono creare grossi problemi sulle trasmissioni digitali, specie se molto veloci e con gran mole di dati. È indispensabile gestire gli errori indirizzandoli a livello di sistema piuttosto che di chip considerandoli dal più intenso almeno significativo.

Un esempio di errore dovuto a contributo “grande” che non può essere “risolto” da un normale circuito integrato è un'alimentazione instabile. Fluttuazioni su un'alimentazione di 3V che facciano passare il segnale da 1 a 5, di sicuro causeranno grossi danni alla circuiteria. È ovvio che si tratti di un esempio assolutamente estremo e che non si verificherà mai esattamente in questo modo, anche perché problematiche di questo tipo suggeriscono che il progetto sia da rivedere per intero; tuttavia rende l'idea di quale sia il problema. Questo è tanto più valido quanto ogni giorno sull'alimentazione di rete ci sono dei glitches, delle oscillazioni, e questo può causare delle fluttuazioni sul funzionamento o sull'assunzione di potenza da parte di motori, sorgenti di illuminazione o più in generale su qualunque carico connesso. Le griglie di alimentazione agiscono abilitando generatori di potenza durante il giorno per sopperire ad un calo di tensione oppure per stabilizzare il valore della tensione erogata e questo può cambiare il valore di tensione che effettivamente arriva ai circuiti integrati, introducendo dei ripple.

Non solo cause interne, dunque, per un esempio che introduce diversi concetti, come l'interferenza alle radiofrequenze (RFI), l'interferenza da onde elettromagnetiche (EMI) e le scariche elettrostatiche (ESD).

Errori più “piccoli”, invece, possono essere “gestiti” a livello di chip, utilizzando le connessioni a stella verso massa. Qui, inoltre, vengono realizzati opportuni piani isolati nell'ambito delle PCB, proprio per gestire questo tipo di inconvenienti. Talvolta esistono piani di massa analogica ed altri dedicati alle masse digitali perchè usarne di condivisi può causare la presenza di correnti parassite, per quanto di scarsa entità.

Questi rumori possono addirittura, talvolta, essere causa di rottura dei sistemi ed è per questo che, in particolare, Maxim utilizza opportuni sistemi come il watchdog timer. Il nome suggerisce che si tratti di una specie di “cane da guardia” che tiene traccia di tutti i cicli eseguiti dal microprocessore cercando quelli che “fanno perdere più tempo” perché si presuppone che siano quelli potenzialmente “incriminati” di eventuali malfunzionamenti.

Nel mare delle interfacce, l'I²C

Esiste un numero impressionante di interfacce diverse che possono essere utilizzate. Vale la pena di elencarne qualcuna: RS-232, RS-422/RS-485, USB, Ethernet IEEE® 802, IO-Link®, LIN bus, 1-Wire®, I²C, SMBus, SPI, MICROWIRE®/MICROWIRE PLUS™, M-Bus (EN1434), e CAN (ISO11898). Ci sono una serie di protocolli, standard, direttive, anche non convenzionali, in merito.

È chiaro che, per poter scegliere l'una all'altra o l'altra ancora, è necessario conoscerne i dettagli qualitativi e così come accade per tutte, anche I²C dimostra di avere pregi e difetti.

In generale, possiamo dire che si tratta di un'interfaccia seriale, multimaster, single-ended che viene utilizzata per mettere in comunicazione dispositivi non “eccessivamente” veloci, prevalentemente in ambito consumer, come telefoni cellulari, dispositivi elettronici oppure televisioni.

Dicevamo di pregi e difetti: la limitazione più grande dipende dal fatto che abbiamo una rete resistiva che effettua il pullup e che la massima capacità di carico può essere pari a 400 pF.

Idealmente, il bus dovrebbe anche avere un basso consumo di potenza ma alcune applicazioni richiedono comunicazioni molto veloci e specie quando i dispositivi sono lenti questo protocollo si dimostra inefficace.

Tuttavia, se si ha la necessità di segnali di sincronizzazione che si aggirino intorno alla decina di MegaHertz, è possibile utilizzare un protocollo I²C modificato, detto “a due fili”, che può garantire anche segnali bidirezionali.

Ingegnere, un sorriso prego.

Beh, ma se le cose funzionano perché uno non dovrebbe sorridere? Quando un'interfaccia funziona è sempre motivo di soddisfazione e capire perché qualcosa che si ha per le mani non sta funzionando come dovrebbe è certamente parte della soluzione al problema. Esistono limiti tecnologici contro i quali sarebbe stupido accanirsi ma c'è una lezione da imparare in tutto questo: l'attenzione al particolare, ai dettagli, specie se di solito si tende a trascurarli, è la chiave del successo!

Scarica subito una copia gratis
Tags:, ,

2 Commenti

  1. Avatar photo Piero Boccadoro 29 Agosto 2012
  2. Avatar photo Giovanni Giomini Figliozzi 28 Aprile 2013

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend