Il BUS GPIB IEEE-488

Lo standard che ha raggiunto una discreta diffusione per collegamenti, con canale parallelo, di sistemi programmabili autonomi è il IEEE-488 conosciuto anche come GPIB (General Purpose Interface Bus) o HP-IB (dal nome della ditta, l’Hewlett Packard, che lo ha brevettato). Lo standard IEEE-488 ha posto le basi necessarie per superare lo scoglio dell’incompatibilità tra prodotti di case diverse. Inoltre esso ha rivelato doti di versatilità e completezza che ne hanno suggerito l’uso come generico bus di collegamento tra computer e periferiche, o anche per trasferimento di segnali tra personal computer.

La molla che già nella seconda metà degli anni ‘70 ha portato lo IEEE (Institute of Electrical and Electronic Engineers) ad elaborare e proporre questa particolare struttura d’interfaccia è stata la constatazione di come la diffusione di mini e microcomputer stesse cambiando radicalmente la struttura degli strumenti elettronici e il modo di organizzare il lavoro nei laboratori di misura e collaudo. Tra la fine degli anni ’60 e l’inizio degli anni ’70, la Hewlett Packard ha sviluppato il General Purpose Interface Bus (GPIB). La IEEE ha trasformato il bus GPIB in uno standard nel 1975, e da allora il bus GPIB è noto come IEEE 488; i termini GPIB, HP-IB e IEEE 488 sono quindi sinonimi. Lo scopo originario del bus GPIB era quello di fornire un metodo basato sull’utilizzo di un computer per la gestione simultanea di più strumenti per test e misure; tuttavia, il bus GPIB è piuttosto versatile ed ora è ampiamente utilizzato per comunicazione tra computer e per il controllo di scanner e film recorder. Il GPIB è un bus parallelo digitale, a 24 conduttori. Consiste in otto linee per i dati, cinque linee per la gestione del bus (ATN, EOI, IFC, REN e SQR), tre linee di handshake e otto linee di massa. Il bus GPIB utilizza uno schema di trasferimento dei dati parallelo a otto bit, seriale sul byte e asincrono. Ciò significa che sul bus vengono trasmessi in modo sequenziale interi byte, con il relativo handshake, ad una velocità che è determinata dal più lento dei partecipanti al trasferimento. Poiché l’unità dei dati nel GPIB è il byte, i messaggi trasmessi sono frequentemente codificati come stringhe di caratteri ASCII. Ci sono tre modi per segnalare la fine di un trasferimento di dati. Il metodo migliore consiste nell’utilizzo di un segnale hardware (EOI) di cui si cambia il livello logico quando è trasmesso l’ultimo byte di dati. In alternativa, è possibile collocare uno specifico carattere di fine-stringa (EOS, per “End-Of-String”) al termine della stringa di dati stessa. Alcuni strumenti utilizzano questo metodo al posto, o in aggiunta, all’impiego del segnale EOI. Infine, lo strumento ricevente può contare i byte dopo l’handshake e interrompere la lettura quando è stato raggiunto un valore prefissato per il conteggio dei byte. Il metodo del conteggio dei byte è usato molto spesso come default perché il trasferimento dei dati viene interrotto facendo un OR logico tra il segnale EOI, il segnale EOS (se utilizzato), e con il conteggio dei byte. Generalmente il conteggio dei byte viene fissato quindi a un valore uguale o superiore al numero di byte che si prevede di leggere. Ogni dispositivo, inclusa la scheda di interfaccia, deve possedere un unico indirizzo GPIB che può essere un numero tra 0 e 30. L’indirizzo 0 è normalmente assegnato alla scheda di interfaccia GPIB, mentre agli strumenti sono assegnati come indirizzo i numeri da 1 a 30. Il GPIB ha un Controller (il computer dell’utente) che controlla il bus. Per trasferire sul bus i comandi e i dati dello strumento il Controller identifica un Talker e uno o più Listener. Il Talker e gli uno o più Listener si scambiano le stringhe di dati attraverso il bus. Il ruolo di controller è di regola associato ad un elaboratore e la sua interfaccia dovrà essere in grado di svolgere anche le funzioni di talker, per inviare messaggi di controllo, e di listener, per acquisire lo stato degli altri dispositivi collegati. Per l’interesse crescente che suscita l’elaborazione distribuita, è prevista anche la possibilità che al bus siano connessi più controller (cioè, in pratica, più calcolatori). La possibilità di conflitti è superata prevedendo che si stabilisca al momento dell’impianto, settando un opportuno switch sulle interfacce, quale controllore debba assumere il governo del bus all’avviamento (power on). Successivamente i controller potranno richiedersi e cedersi vicendevolmente il governo del bus, le cui linee di gestione verso la periferia restano pilotate solo dal controller in carica.

Le specifiche funzionali del controller possono essere riassunte nel seguente modo:

Gestisce l’uso del bus da parte di altri dispositivi mediante gli interfaces messages;
Un solo controller alla volta può essere attivo sul bus, il controller in charge;
Ogni controller in charge può cedere le proprie prerogative ad un altro;
Uno solo dei controllers collegati al bus può assumere autonomamente il controllo, il system controller.

Le specifiche funzionali del Talker sono, invece:

Invia device message agli altri dispositivi connessi al bus;
Inizia a trasmettere se il controller in charge lo indirizza come talker;
Interrompe la trasmissione se: il controller glielo ordina, il controller designa un altro talker.

Le specifiche funzionali del Listener, infine sono:

Riceve device message da un dispositivo connesso la bus;
Inizia ad ascoltare se il controller in charge lo indirizza come listener;
Interrompe l’ascolto se il controller glielo ordina, o se è indirizzato come talker.

Figura 1. Architettura di u sistema basato su Bus GPIB

STRUTTURA DEL BUS

Il sistema di interfaccia GPIB (figura 2 e 3) si compone di:

16 linee di segnali
8 linee di ritorno a massa

Figura 2. BUS GPIB, linee e segnali

Figura 3. BUS GPIB, linee e segnali

Per le linee di segnali abbiamo: le linee dati (DI01– DI08), utilizzate per il trasferimento di dati e messaggi di comando. Tutti i messaggi utilizzando la codifica ASCII a 7 bit. Poi ci sono le linee Handshake ovvero 3 linee asincrone per il controllo del trasferimento di messaggi:

NRFD (Not Ready For Data): indica quando un dispositivo è pronto a ricevere messaggi;
NDAC (Not Data Accepted): indica quando un dispositivo ha o non ha ricevuto i messaggi;
DAV (Data Valid): indica la validità dei dati sulle corrispondenti linee.

Infine abbiamo le linee di gestione dell'interfaccia che sono:

ATN (Attention): determina il tipo di informazione che il bus sta analizzando;
IFC (Interface Clear): inizializza il bus;
REN (Remote Enable): mette il dispositivo in modalità remota o locale;
SRQ (Service Request): richiesta di servizio;
EOI (End or Identify): Il talker utilizza questa linea per segnare la fine dei messaggi.

Lo standard IEEE-488 comprende le normative per tre aspetti fondamentali:

caratteristiche meccaniche (per la compatibilità dei connettori);
caratteristiche elettriche (per la compatibilità dell’I/O sul bus, dei livelli logici, delle correnti assorbite);
caratteristiche funzionali (significato delle linee e protocolli di comunicazione).

Occorre solo aggiungere che le linee di gestione non pilotate dal controller (SRQ, EOI) e le linee di controllo flusso dati richiedono uscite open-collector, perché realizzano una funzione logica di OR cablato nel raccogliere le segnalazioni provenienti da diversi dispositivi connessi. Allora, grazie alla logica negativa, basta un solo dispositivo attivo, che tenga bassa la sua uscita sul bus per attivare una linea di controllo, mentre tutti i dispositivi devono essere disattivi perché essa torni disattiva. Per quanto riguarda gli aspetti funzionali, l’individuazione delle diverse interfacce connesse al bus avviene attraverso un indirizzo di cinque bit, presettabile dall’utente tramite opportuni switches. In questo modo il controller può rivolgersi individualmente ad ogni singola interfaccia inviando sul bus il relativo indirizzo, che essa sola è in grado di riconoscere. Inizialmente, all’accensione del sistema, il controller deve resettare tutte le interfacce, ponendole in stato di riposo tramite la linea IFC, per assumere il governo del sistema in uno stato noto. Poi, per configurare il sistema e per assegnare il ruolo di parlatore o di ascoltatore/i, in vista di un trasferimento di dati, attiva la linea ATN, che distingue le fasi in cui, sul bus, sono inviati indirizzi o comandi, invece dei dati, e indirizza l’interfaccia prestabilita. Insieme ai cinque bit di indirizzo (linee DIO1DIO7) la cui configurazione indica la selezione del modo parlatore o del modo ascoltatore. Quando si seleziona un nuovo parlatore, quello precedente si disattiva; comunque la nuova configurazione stabilita dal controller non diventa operativa finché il controller, disattivando ATN, non segnale di aver terminato e di essere tornato al suo stato di stand-by (attesa). Il controller può poi rilevare dallo stato della linea EOI quando è terminato il trasferimento dei dati in corso tra un talker e uno o più listener, in modo da poter proseguire con altre attività. La linea di ATN gli consente comunque di interrompere qualsiasi collegamento in atto, per inviare ulteriori comandi. Le interfacce possono invece richiedere l’attenzione del controller attraverso la linea SRQ (richiesta di servizio). La quinta di gestione (REN, cioè abilitazione al comando remoto) permette al controller di sottrarre gli strumenti programmabili all’azione locale esercitata tramite il pannello frontale per riprendere a comandarli da programma (lo stesso comando è generalmente presente come commutatore sul pannello frontale dello strumento). Il controllo del trasferimento dati avviene con la tecnica dell’handshake, che permette di risolvere completamente il problema dell’adattamento della velocità di trasmissione alle prestazioni del più lento tra i dispositivi abilitati come listener. Si comincia con il talker, che tiene la linea DAV disattiva e testa NRFD e NDAC; trovandoli attivi (listener non pronti) prepara il dato sul bus. Intanto il listener, sentendo DAV alto e trovandosi nello stato con NDAC attivo, disattivano NRFD. Solo quando tutti hanno portato alto NRFD il talker segnala la disponibilità del dato. Di risposta i listener riattivano NRFD, leggono il dato sul bus e ne segnalano la ricezione disattivando NDAC. Il talker, quando anche l’ultimo listener ha mandato alto NDAC, disattiva DAV e prepara un nuovo byte. Intanto i listener si predispongono a un nuovo ciclo di scrittura, riattivando NDAC e alzando NRFD. La gestione delle interfacce collegate al bus si realizza non solo attraverso i segnali di controllo, ma anche con dei messaggi convenzionali costituiti da singoli byte, trasmessi sul bus dati. Essi si distinguono in due gruppi:

quelli universali, che sono acquisiti comunque da tutte le periferiche ed eseguiti, anche se non sono state precedentemente indirizzate;
quelli indirizzati, che sono presi in considerazione solo dalle interfacce che sono state appositamente selezionate come ascoltatore.

Tra le procedure più interessanti che si possono avviare attraverso i comandi elencati in figura 4 ci sono quelle di sincronizzazione e di richiesta di servizio, con conseguente interrogazione da parte del controller.

Figura 4. Principali comandi GPIB

Nella realizzazione di misure complesse si può presentare la necessità di far partire insieme più strumenti, o di attivare una funzione in un istante preciso; ciò è possibile indirizzando tutti gli apparecchi interessati come ascoltatori e mettendo poi sul bus, al momento opportuno, il comando GET. Viceversa la richiesta di servizio è la possibilità offerta ad un’apparecchiatura per avere un interessamento più sollecito da parte del controller (situazione di allarme). La linea SRQ si comporta verso il controllore come una normale linea d’interrupt e, dato che è pilotata con degli open collector, si attiva quando almeno un’apparecchiatura lo richiede. Per individuare il dispositivo interrompente il controller ha disposizione due alternative: il polling seriale e quello parallelo. Nel primo caso deve sospendere le attività sul bus e avvisare le apparecchiature collegate che sta per iniziare un’interrogazione circolare di tutte, per individuare quella che necessita di un servizio (comando SPE). Dopo una simile riconfigurazione, infatti, se indirizzate come parlatore, le interfacce rispondono inviando sul bus un loro byte di stato, nel quale il bit sette segnala con uno logico la richiesta pendente di servizio. Terminata l’interrogazione, il controller può ripristinare l’attività interrotta inviando il comando SPD. La procedura dell’interrogazione sequenziale è piuttosto lenta, ma consente al controllore di aggiornarsi sullo stato delle periferiche. Per un massimo di otto apparecchiature che debbano usare SRQ è però possibile configurare un sistema di risposta in parallelo, assegnando (da programma o da switches sulla scheda stessa) a ciascuna periferica una linea del bus dati su cui rispondere convenzionalmente con uno o uno zero se c’è una richiesta pendente o meno. La predisposizione delle periferiche richiede l’invio del comando PPC (Parallel Poll Configure) e quindi del byte del comando PPE, al cui interno alcuni bit stabiliscono su quale linea e con quale logica (positiva o negativa) il dispositivo debba rispondere. All’arrivo di SRQ il controller sospende l’attività in corso abbassando ATN e contemporaneamente attiva EOI; la coincidenza dei due segnali funge da interrupt acknowledge, provocando la risposta di ciascuna periferica. Il controller può allora rivelare il byte sul bus e dal suo esame bit per bit risalire all’apparato che ha richiesto il servizio. Il prezzo che si paga per la maggiore velocità di intervento è l'impossibilità di conoscere lo stato completo della periferica e quindi il tipo di servizio richiesto nel caso possano essere diversi. Il comando PPC, seguito dal comando PPD, permette di annullare la predisposizione al polling parallelo. Un limite che pesa sempre più sullo standard GPIB, in un’epoca di crescente diffusione dei collegamenti a distanza, è quello della sua limitata estensione spaziale tanto che, per non vanificare i vantaggi di questo sistema di collegamento comunque molto versatile, si stanno studiando delle opportune interfacce per connettere tra loro due bus GPIB dislocati in posti diversi, o per collegarli a reti dati pubbliche, attraverso un canale seriale. L’interfaccia dovrà disporre di una memoria tampone, per non perdere dati nel passaggio tra due velocità di trasferimento, e una logica di codifica e decodifica delle linee di controllo, per permettere anche in questo caso la massima trasparenza del canale seriale rispetto alla comunicazione tra due dispositivi di due bus GPIB differenti. Ogni dispositivo è identificato univocamente da un indirizzo a 5 bit. Per l’indirizzamento si utilizzano le linee dati in command mode. Per identificare i dispositivi che prenderanno parte all’handshake il controller usa caratteri ASCII a 7 bit. I due bit in più vengono usati per specificare la funzione del dispositivo indirizzato. L’ultimo bit viene utilizzato come controllo di parità. Una volta che il controllore ha verificato la presenza di una richiesta di servizio (linea SRQ) deve identificare il dispositivo richiedente. Lo standard IEEE 488.1 prevede che il 7° bit dello status byte del richiedente (RQS) sia “vero”.