Comunicazioni RS-485, il bus dei bus - aep-italia.it · bile 8250, una UART di Intel che ha fatto...

4
Apparati di bordo Comunicazioni MobilityLab 35 Perché la dorsale di comunicazione più usata tra apparati di bordo funziona sempre a meraviglia sui sistemi a microcontrollore e può non funzionare in altri casi. di Gianni Becattini > [email protected] RS-485 , il bus dei bus E rano almeno venti anni che dovevo scrivere questo articolo, ma non me ne ero reso conto fino a stamani, quando, angosciato dall’ennesimo caso di “non funziona nulla” ho deciso di prende- re carta e penna per buttare giù un po’ di note su questo argomento. Mi mangio però un pò le mani. Se lo avessi fatto prima, col tempo impiegato a convincere molti pro- gettisti, avrei potuto imparare il tedesco, cosa che mi sarebbe stata utilissima per apparire crucco e ricevere quindi un miglior trattamento negli hotel dell’Alto Adige... RS-85, cuslè? Non farò finta di saper enunciare al volo una sua esatta definizione e quindi prefe- risco confessare candidamente che quello che segue è bovinamente copiato da Wiki- pedia: EIA RS-485, equivalente allo standard Eu- ropeo CCITT V11, è una specifica Modello OSI a livello fisico di una connessione se- riale a due fili, half-duplex e multipoint. Lo standard specifica un sistema di gestione del segnale in forma differenziale: la diffe- renza tra la tensione presente sui due fili costituisce il dato in transito. Una polarità indica un livello logico 1, quella inversa in- dica il livello logico 0. La differenza di po- tenziale deve essere di almeno 0,2 V per un’operazione valida, ma qualsiasi tensio- ne compresa tra +12 V e −7 V permette il corretto funzionamento del ricevitore. La EIA RS-485 specifica soltanto le carat- teristiche elettriche del trasmettitore e del ricevitore. Non indica né raccomanda alcun protocollo per la trasmissione dei dati. EIA RS-485 permette la configurazione di reti locali a basso costo e comunicazioni mul- tipunto. Permette una velocità di trasmis- sione molto elevata (35 Mbit/s fino a 10 m e 100 kbit/s a 1.200 m). Dal momento che utilizza un sistema di segnalazione con una tensione non trascurabile, con una linea bilanciata tramite l’impiego di un doppino (come avviene nella EIA RS-422), si pos- sono raggiungere distanze relativamente notevoli (fino a poco più di 1.200 m).Accettabile da un punto di vista formale (forse è meglio il testo in inglese) ma poco chiaro per quelli che non sanno già cosa sia, quindi, bando alla pigrizia, cercherò di spiegarlo in modo un po’ più intuitivo. La comunicazione seriale asincrona Prima di parlare delle interfacce elettriche, come la RS-485, definiamo cosa sia una comunicazione seriale asincrona. Niente di più facile; essa è semplicemente l’evo- luzione del sistema inventato nel 1835 dal sig. Samuel Morse, con poche importanti variazioni: trasmettitore e ricevitore, invece che da un operatore umano, sono costituiti da un circuito integrato detto UART (Universal Asynchronous Receiver Transmitter); invece di punti e di linee si usano “0” e “1” (binary digit, alias “bit”); i caratteri sono codificati in un formato fis- so, perché i circuiti integrati sono meno fur- bi degli umani. Nel Codice Morse i caratteri hanno lunghezze diverse (es. la “E” è “pun- to” mentre la “Z” è “linea-linea-punto-pun- to”, nella comunicazione seriale asincrona tutti i caratteri sono composti dall’identico numero di bit, ovviamente in combinazioni di “0” e “1” differenti; in questa parte della galassia, si usa or- mai quasi esclusivamente il codice ASCII inserito in caratteri di 8 bit. La comunicazione seriale asincrona non è una novità: si usava già estensivamente in tempo di guerra (le famose telescriventi al- leate TG7, vedi figura, presenti in ogni film che si rispetti, che sono state uno dai miei grandi amori di gioventù, quando far stam- pare qualcosa a un circuito digitale non era facile come oggi) e ha costituito la base del sistema Telex ormai scomparso ma molto usato fino a un pò di anni fa.

Transcript of Comunicazioni RS-485, il bus dei bus - aep-italia.it · bile 8250, una UART di Intel che ha fatto...

Apparati di bordoComunicazioni

� MobilityLab 35

Perché la dorsale di comunicazione più usata tra apparati di bordo funziona sempre a meraviglia sui sistemi a microcontrollore e può non funzionare in altri casi.

di Gianni Becattini > [email protected]

RS-485, il bus dei bus

Erano almeno venti anni che dovevo scrivere questo articolo, ma non me ne ero reso conto fino a stamani,

quando, angosciato dall’ennesimo caso di “non funziona nulla” ho deciso di prende-re carta e penna per buttare giù un po’ di note su questo argomento. Mi mangio però un pò le mani. Se lo avessi fatto prima, col tempo impiegato a convincere molti pro-gettisti, avrei potuto imparare il tedesco, cosa che mi sarebbe stata utilissima per apparire crucco e ricevere quindi un miglior trattamento negli hotel dell’Alto Adige...

RS-�85, cuslè?

Non farò finta di saper enunciare al volo una sua esatta definizione e quindi prefe-risco confessare candidamente che quello che segue è bovinamente copiato da Wiki-pedia:“EIA RS-485, equivalente allo standard Eu-ropeo CCITT V11, è una specifica Modello OSI a livello fisico di una connessione se-riale a due fili, half-duplex e multipoint. Lo standard specifica un sistema di gestione del segnale in forma differenziale: la diffe-renza tra la tensione presente sui due fili costituisce il dato in transito. Una polarità indica un livello logico 1, quella inversa in-dica il livello logico 0. La differenza di po-tenziale deve essere di almeno 0,2 V per un’operazione valida, ma qualsiasi tensio-ne compresa tra +12 V e −7 V permette il corretto funzionamento del ricevitore.

La EIA RS-485 specifica soltanto le carat-teristiche elettriche del trasmettitore e del ricevitore. Non indica né raccomanda alcun protocollo per la trasmissione dei dati. EIA RS-485 permette la configurazione di reti locali a basso costo e comunicazioni mul-tipunto. Permette una velocità di trasmis-sione molto elevata (35 Mbit/s fino a 10 m e 100 kbit/s a 1.200 m). Dal momento che utilizza un sistema di segnalazione con una tensione non trascurabile, con una linea bilanciata tramite l’impiego di un doppino (come avviene nella EIA RS-422), si pos-sono raggiungere distanze relativamente notevoli (fino a poco più di 1.200 m).”Accettabile da un punto di vista formale (forse è meglio il testo in inglese) ma poco chiaro per quelli che non sanno già cosa sia, quindi, bando alla pigrizia, cercherò di spiegarlo in modo un po’ più intuitivo.

La comunicazione seriale asincrona

Prima di parlare delle interfacce elettriche, come la RS-485, definiamo cosa sia una comunicazione seriale asincrona. Niente di più facile; essa è semplicemente l’evo-luzione del sistema inventato nel 1835 dal sig. Samuel Morse, con poche importanti variazioni:•trasmettitore e ricevitore, invece che da un operatore umano, sono costituiti da un circuito integrato detto UART (Universal Asynchronous Receiver Transmitter);• invece di punti e di linee si usano “0” e “1” (binary digit, alias “bit”);• i caratteri sono codificati in un formato fis-so, perché i circuiti integrati sono meno fur-bi degli umani. Nel Codice Morse i caratteri hanno lunghezze diverse (es. la “E” è “pun-to” mentre la “Z” è “linea-linea-punto-pun-to”, nella comunicazione seriale asincrona tutti i caratteri sono composti dall’identico numero di bit, ovviamente in combinazioni di “0” e “1” differenti;• in questa parte della galassia, si usa or-mai quasi esclusivamente il codice ASCII inserito in caratteri di 8 bit.

La comunicazione seriale asincrona non è una novità: si usava già estensivamente in tempo di guerra (le famose telescriventi al-leate TG7, vedi figura, presenti in ogni film che si rispetti, che sono state uno dai miei grandi amori di gioventù, quando far stam-pare qualcosa a un circuito digitale non era facile come oggi) e ha costituito la base del sistema Telex ormai scomparso ma molto usato fino a un pò di anni fa.

Apparati di bordoComunicazioni

5MobilityLab 35

RS-485, il bus dei bus

L’interfaccia elettrica

È evidente che, defi nita la tecnica di scam-bio di informazioni, essa deve poi comple-tarsi con quella da usarsi per trasportare il segnale elettrico fi no alla destinazione. L’uscita dell’UART non può essere collega-ta direttamente al fi lo che attraversa l’auto-bus, per almeno due buoni motivi:• l’uscita dell’integrato non è adeguata-mente protetta; le interferenze elettroma-gnetiche captate dal lungo cavo, che opera come un antenna radio, distruggerebbero facilmente i delicati circuiti in esso racchiu-si;•l’uscita dell’integrato non ha una capacità di pilotaggio suffi ciente; la capacità elettri-ca del cavo e la sua induttanza dannegge-rebbero in misura signifi cativa l’integrità del segnale.

EIA RS-232

Il rimedio è semplice: si usano degli amplifi -catori, detti “line driver” e “line receiver”. I più comuni sono quelli con i quali la linea rispetta lo standard EIA RS-232. In pratica si usa una tensione positiva per un livello logico e negativa per l’altro.

La topologia più comune è quella “point-to-point” con una coppia driver/re-ceiver per ogni direzione, come mostrato in fi gura.

Con questa confi gurazione, detta “full du-plex”, entrambe le stazioni possono parlare simultaneamente.

Topologia multipoint

A bordo di un mezzo, più apparati devono comunicare tra loro. Ovviamente si potreb-bero unire tra loro con una ragnatela di fi li (da A a B, da A a C, da A a D, da B a C ecc.) ma è chiaro che questo non sarebbe pratico. Si preferisce invece utilizzare la topologia “multipoint” (fi gura) dove la linea è unica e unisce tutti gli apparati, che stanno tut-ti quanti normalmente in ricezione; solo quando hanno qualcosa da dire abilitano il proprio trasmettitore e parlano.

Questa confi gurazione implica ovviamen-te:• che ogni stazione abbia un identifi cativo univoco;• che esistano delle regole condivise per l’accesso al mezzo fi sico (“protocollo”). La più semplice è che un apparato funga da regolatore (“master”) e che interroghi le al-tre stazioni (“slave”) per sapere se hanno qualcosa da dire;• che due apparati non abilitino mai il loro trasmettitore allo stesso momento.

E’ chiaro che quello che si guadagna da una parte si perde dall’altro; a fronte di un cablaggio semplifi cato e di un hardware ri-dotto (ogni stazione ha richiede una sola UART), si perde la capacità di parlare e ricevere simultaneamente (“half-duplex”), ma questo non è ritenuto un limite troppo pesante nella maggior parte dei casi.

Linee differenziali

La linea RS-232, pur dotata di amplifi catori, presenta però dei limiti quando la distanza tra i due punti cresca o comunque quan-do la linea sia soggetta a disturbi di natu-ra elettromagnetica. Come dicevo prima, infatti, i cavi si comportano come antenne e all’ingresso del ricevitore sarà quindi pre-sente non solo il segnale che veicola l’in-formazione ma anche una quota di rumore che, se supera certi livelli, impedisce la co-municazione. La schermatura risolve solo in parte il problema e ne aggiunge un altro, causato dalla capacità elettrica eccessiva, che determina distorsioni nei fronti e limita la velocità raggiungibile.

Comunicazione full duplex

Topologia multipoint

Apparati di bordoComunicazioni

� MobilityLab 35

Per questo motivo sono state inventate le linee “differenziali bilanciate” che utilizzano due conduttori, invece di uno, per ciascun segnale.

Nella linea bilanciata il segnale da trasmet-tere è convertito in due segnali uguali e simmetrici (A e B) come mostrato nella fi-gura seguente:

I due stati di ciascuna linea sono definiti nel seguente modo: • quando il terminale A è negativo rispetto a B, la linea rappresenta un uno binario. Tale stato rappresenta anche l’assenza di segnale;• quando il terminale A è positivo rispetto a B, la linea rappresenta uno zero binario. Il circuito ricevitore, di tipo particolare, pre-senta alla propria uscita un segnale uguale alla differenza dei due segnali in ingresso.Questa caratteristica fa sì che, qualunque sia il livello di rumore raccolto dai cavi, esso si ritrovi in maniera pressoché uguale su ciascuno dei due conduttori. L’operazio-ne differenza, quindi, lo annulla del tutto, restituendo integro il segnale contenente l’informazione.Nella pratica, ovviamente, il livello massi-mo di rumore ammissibile è limitato dalle caratteristiche fisiche dei dispositivi.

Se un fulmine cade sulla linea, ad esempio, la differenza tra i due segnali è.... il fumo!

Il bus...dei busL’affermazione non del tipo “Il re dei re”, anche se suona in modo simile, ma sta in-vece per il bus (ossia la dorsale di comuni-cazione) degli ...autobus. Il bus dei bus per eccellenza è ancora oggi, almeno per gli apparati che ci interessano, lo RS-485 in modalità multipoint (vedi figura).

Il problema

Da un punto di vista logico, tutto appare semplice (e lo è). L’unità X, autorizzata a trasmettere, deve:•abilitare il trasmettitore;• inviare il messaggio;•disabilitare il trasmettitore;•aspettare indietro la risposta.

Vediamo adesso dove “inciampano” anche molti bravi progettisti.

Ricordatevi le condizioni che avevamo enunciato poc’anzi: “due apparati non de-vono abilitare mai il loro trasmettitore allo stesso momento”.

Un piccolo passo indietro: il PC attuale affonda le sue radici nel vecchio, antichis-simo PC IBM, capostipite nel bene e nel male, dell’interminabile genia arrivata fino ai nostri giorni.In esso, l’interfaccia seriale asincrona era implementata per mezzo dell’indimentica-bile 8250, una UART di Intel che ha fatto la storia dell’informatica. Come ogni UART che si rispetti, essa ha un “buffer” che con-sente al software di cacciare il carattere da trasmettere in un registro e passare poi a fare altre cose, mentre la UART, lemme lemme, si manda via i bit uno dopo l’altro.Risultato: ogni progettista, me compreso, ci è cascato. Si mette il byte nel trasmettitore e, dimenticando che i bit usciranno sul ca-nale seriale alla loro velocità, si disabilita subito il trasmettitore, bloccando quin-di l’effettiva trasmissione dei bit sulla linea! Per fortuna il progettista della 8250 aveva pensato a questo e aveva messo un bit, detto LBS, ossia “last bit sent” (ultimo bit trasmesso), in un apposito registro leg-gibile dal software.

Capito questo, la soluzione è facile. Non si disabilita il trasmettitore prima di avere ricevuto il “Last Bit Sent” e il problema è risolto.

“Deh, bimbo” – direbbe il mio amico livor-nese – “allora sei propio...che fai il saccen-te se anche te ti ci sei spiaccicato.... ma sei propio un tegame!” Alt! La storia non è finita e vedremo tra poco delle belle.

Linea differenziale bilanciata

Apparati di bordoComunicazioni

�MobilityLab 35

Il mondo cambia

Per il Gattopardo, tutto doveva cambiare se si voleva che nulla cambiasse. Nel mondo del PC, le cose stanno in ma-niera leggermente diversa: tutto può cam-biare... a patto che nulla cambi. Per essere più chiari, qualunque cambiamento deve garantire la compatibilità con il passato. Con la crescita dell’integrazione dei com-ponenti, ossia con la miniaturizzazione cre-scente dei circuiti, ci si rese conto ben pre-sto che la buona vecchia 8250 era troppo, troppo grossa... una molletta per il bucato era davvero troppo per le piastre sempre più dense di integrati, anche perché, per tradizione, il PC, di UART, ne ha sempre avute due (COM1 e COM2).

Il primo passo fu integrare le due UART e l’interfaccia stampante in un solo integra-to (16C452) ma anch’esso divenne presto troppo ingombrante. Fu così che la nostra UART finì per...sma-terializzarsi, diventando niente più che una “macro” nella definizione di circuiti logici custom o configurabili da software. E qui cadde l’asino....Accadde, infatti, che l’implementazione di questa funzione fosse eseguita in modo non sempre ortodosso (“tanto la seriale chi vuoi che la usi, ormai....”) e che quindi in al-cuni “chip set” la medesima non risultasse perfettamente funzionale o completamente a specifica, fino a perdere del tutti, nei casi estremi, il bit LBS. Come lo so? Semplice, anni addietro mi trovai nella necessità di modificare un Device Driver seriale.

Le disgrazie non giungono mai

da sole

In parallelo a questo avvenne un altro fe-nomeno, auspicabile per certi versi ma nefasto in questo: la virtualizzazione delle porte di I/O. In un buon sistema operativo di tipo “evoluto”, infatti, è tassativamente, e giustamente, vietato al software utente di accedere direttamente all’hardware.

Tutti gli accessi devono essere mediati dal sistema operativo. Quando voi credete di scrivere su una porta (es. leggere il registro contenente il bit LBS), in realtà viene gene-rata una eccezione che fa sì che il s.o. pro-

cessi la vs. richiesta, se non vi mette in pu-nizione per l’eccesso di ardire (per inciso, questo è uno dei motivi che rendono poco adatti i sistemi operativi evoluti agli appara-ti di tipo embedded, come ad esempio alle validatrici).

Risultato ultimo

Nella pratica questo vuol dire che:• il software vede solo una astrazione del bit LBS, costruita dal paradiso artificiale costituito dalla macro usata nel chipset e dal sistema operativo in complicità con il driver;•il software quindi va a disabilitare il driver non quando l’ultimo carattere è stato spe-dito ma quando è venuto il momento per farlo;• anche il segnale usato per comandare il driver (di solito lo RTS della porta seriale) subisce la stessa sorte ed esce quando il Sistema Operativo si degna di comandare ai suoi servi (driver) di farlo e quando i me-desimi sono in comodo.

Di conseguenza il trasmettitore sarà disabi-litato non quando è il momento buono ma molto dopo, ossia quando il corrisponden-te ha già iniziato a inviare la sua risposta. Due a trasmettere però, lo sappiamo, è una condizione vietata. Come in televisione, quando due o più persone si parlano sopra, nessuno capisce niente. La RS-485 non fa eccezione. La risposta viene perduta e niente funziona o funziona molto male.L’unica maniera per correggere questa si-tuazione è di non aspettare il bit LBS ma, piuttosto, inserire ritardi calibrati sia dal lato del trasmettitore che del ricevitore. Anche nella gestione di ritardi precisi le Loro Signorie, ossia i sistemi operativi bla-sonati, possono migliorare. Un antico Z80, antesignano dei moderni processori, è mil-le volte più bravo (in compenso, però, ab-biamo simpatici pupazzetti che ci strizzano l’occhio dal video e ci forniscono sugge-rimenti, mentre vorremmo avere una pisto-la per “terminarli” definitivamente).La soluzione sopra descritta funziona...e non funziona, vale a dire che questi ritar-

di devono essere aggiustati caso per caso perché non tutte le Loro Signorie si com-portano nello stesso modo quando viaggia-no su cocchi diversi (= diverse piattaforme hardware).

Trucchi segreti

Dimenticavo di rivelarvi alcuni dei miei truc-chi preferiti per garantire il sicuro non fun-zionamento della linea RS-485:

•se niente funziona, non fate assoluta-mente niente, potreste rovinare tutto!• al massimo potete mandare un po’ di mail, cosa che non fa mai male;•in particolare, non andate a investigare con un oscilloscopio; perdereste quel ma-gico senso di mistero e scoprireste subito tutti i problemi;• un’ottima tecnica è quella di collegate il filo “+” al “-” della linea differenziale e vice-versa;•molto buono anche configurare l’uso della porta COM1 ma collegare poi le validatrici alla COM2;•e, infine, mi raccomando: non provate niente in laboratorio; andate invece diretta-mente sul campo ed installate a tappeto!

Conclusione

Chiederò all’Editore di farmi mille copie di questo articolo in modo da essere pronto a sbatterlo lestamente sul grugno del prossi-mo che mi dice che il 485 non funziona.....Ogni riferimento a persone e accadimenti reali è del tutto quasi casuale.

Scherzi a parte, mi sono permesso di es-sere... un pochino sarcastico perché... nes-suno “nasce imparato”! Anche il sottoscritto ha commesso molti degli errori sopra indi-cati, più qualche altro migliaio in merito ai quali prima o poi scriverò un libro per conto di MobilityLab (“I miei primi mille errori nel-l’elettronica” vi sembrerebbe un bel titolo?). Resto come sempre disponibile per ogni chiarimento e/o disputa teologica.

Gianni BeccattiniÈ uno dei pionieri dell’informatica italiana. Nel 1975 progetta uno dei primi personal computer italiani e fonda la General Processor, i cui prodotti sono oggi esposti al Museo dell’Informatica di Pisa. Dal 1999 dirige AEP, di cui oggi è Amm. Delegato.