stan-dard
Gli obiettivi del progetto, dello standard appena definito, erano quelli di definire un sistema di interconnessione di dispositivi su distanze limitate, al fine di poter integrare strumenti di diverso tipo, di diversa provenienza, in un unico sistema (come per esempio un oscilloscopio digitale); tutto ci`o deve essere fatto in maniera ottimale, e dunque devono essere minimizzate le re-strizioni che il sistema, ossia l’insieme dei blocchi, dei dispositivi, impone
sulle prestazioni dei singoli strumenti: all’interno del sistema, ogni strumen-to deve poter lavorare al massimo, e non essere limitastrumen-to da problemi per esempio dovuti all’interfaccia. La velocit`a dell’interfaccia deve dunque es-sere piuttosto elevata, in modo da non fornire un collo di bottiglia ai singoli dispositivi, permettendo una certa coralit`a, nel funzionamento globale del sistema.
Un sistema di interfacciamento `e caratterizzato da alcuni aspetti, di diverso tipo, che lo riguardano, ed influenzano le sue prestazioni:
• Specifiche funzionali: riguardano la descrizione logica delle funzioni che
comandano le attivit`a dell’interfaccia, ossia il modo in cui sono logica-mente definite le istruzioni che permettono di utilizzare l’interfaccia.
• Specifiche elettriche: stabiliscono la temporizzazione, le soglie elettriche
di tensione o corrente, il tipo di logica che si utilizza per le specifiche funzionali, ecc.
• Specifiche meccaniche: riguardano la forma, le dimensioni, il tipo di
connettore utilizzato, la sua posizione, la struttura fisica del cavo, ecc.
• Specifiche operative: l’insieme delle funzioni intrinseche di un
disposi-tivo: il sistema di interfaccia serve a mettere assieme e far comunicare un certo numero di dispositivi, ma le specifiche operative riguardano ci`o che ciascun dispositivo sia in grado di fare, slegato dall’interfaccia. I sistemi basati sullo standard IEEE-488 sono a BUS, ossia utilizzano un insieme di fili paralleli per poter comunicare; ciascun filo rappresenta una linea, ognuna con un determinato scopo. Ci sono in totale 24 fili di BUS, ossia 24 linee, con i seguenti scopi:
• 8 linee dato, ossia 8 linee che servono esclusivamente per la trasmissione
di dati;
• 8 schermi di massa, ciascuno per una linea dato;
• 3 linee di handshake (il cui scopo verr`a meglio definito in seguito); • 5 linee di gestione dell’interfaccia (idem, anche l’utilit`a di queste sar`a
meglio definita in seguito).
La logica utilizzata `e TTL Schottky compatibile (VLOW ≤ 0.8V , VHIGH >
2V ), open collector o tri-state: in questa maniera, alcune linee sono gestite con una connessione wired-or, e cos`ı si riesce a ottenere un minor consumo
di corrente nello stato logico FALSO. I messaggi di vario genere vengono trasferite sul BUS parallelo a 8 bit, in modo byte seriale, asincrono, e control-lato dalla linea handshake a tre linee prima descritta (le modalit`a verranno meglio affrontate parlando di handshake nel dettaglio); il codice utilizzato per le trasmissioni, `e l’ASCII standard versione 7 bit: anzich`e l’ASCII ex-tended a 8 bit; un bit viene utilizzato come bit di parit`a (come vedremo tra breve). L’architettura della rete, realizzata con questo tipo di interfacce, pu`o essere a stella (tutti i dispositivi collegati allo stesso dispositivo, che nella fatispecie potrebbe essere un controllore), o a festone (il primo dispositivo `e il controllore, e poi gli altri sono tutti collegati in serie). La lunghezza dei cavi `e limitata, poich`e si ha uno sviluppo totale massimo di lunghezza pari a 2N, dove N `e il numero di dispositivi collegati al BUS. A causa del fan-out delle porte logiche, il numero massimo di dispositivi collegabili `e pari a 15; la velocit`a di trasmissione `e dell’ordine di 1 MB/s come limite fisico, ma in realt`a `e difficile superare i 500 kB/s, a causa dell’handshake e dei dispositivi pi`u lenti che partecipano ad esso.
Sulle 8 linee dati, vengono scambiati messaggi tra i vari dispositivi; es-sendo un sistema parallelo, tutti i dispositivi possono leggere tutti i dati, tutti i messaggi; i messaggi potrebbero essere:
• Device dependent: legati al tipo di apparecchiatura posta sul bus; a
seconda dell’apparecchiatura, collegata al bus, vi saranno diverse codi-fiche dei dati: si potrebbe usare una codifica binaria, piuttosto che una codifica ASCII, piuttosto che altre codifiche;
• Device independent: si tratta di codici di sistema, standardizzati, che
ogni dispositivo collegato deve essere in grado di interpretare. Questi sono i codici come gi`a detto prima codificati mediante USA-ASCII a 7 bit (+ 1 bit di parit`a). Per ciascuna combinazione dei 7 bit corrisponde una certa casella, un certo numero, che permette di identificare un certo simbolo o una certa funzione dell’interfaccia.
I messaggi device independent sono molto importanti, proprio per questo motivo: essi costituiscono un insieme di comandi di sistema, ossia di comandi in grado di far lavorare il sistema, l’insieme dei vari blocchi, in una qualche maniera.
12.1.1 Ruoli dei dispositivi
Ciascun dispositivo all’interno del sistema pu`o assumere un determinato ruo-lo, a scelta tra 4 particolari, determinati dallo standard di interfacciamento
tra i dispositivi. Lo standard IEEE-488 prevede nella fatispecie i seguenti ruoli:
• Ascoltatore: il ruolo di ascoltatore `e assegnato a ciascun dispositivo
che deve ascoltare, ricevere i dati (device dependent) trasmessi sul bus. Semplicemente si tratta dunque di un ruolo intestante i ricevitori delle informazioni. Poich`e vi deve essere almeno un parlatore (come vedremo tra breve), e poich`e come gi`a detto per limiti del fan-out delle porte logiche si possono avere al pi`u 15 dispositivi collegati, al pi`u potremo avere 14 ascoltatori in contemporanea.
• Parlatore: il ruolo di parlatore `e il duale di quello di ascoltatore: si
tratta del dispositivo incaricato alla trasmissione di dati (device de-pendent) in un certo istante di funzionamento del sistema. Questo ruolo pu`o essere assunto da un solo dispositivo per volta (altrimenti si creerebbe confusione tra i vari dati trasmessi), di conseguenza `e pos-sibile che pi`u dispositivi ascoltino lo stesso parlatore, ma non possono esserci in contemporanea pi`u parlatori.
• Controllore: `e un ruolo molto delicato, all’interno dell’interfaccia: si
tratta di quel particolare dispositivo in grado di assegnare, mediante procedure di indirizzamento, a s`e stesso o ad altri dispositivi i ruoli di parlatore o ascoltatore. A seconda delle richieste di servizio che gli vengono inviate, il controllore stabilisce i ruoli, e gestisce il funzion-amento della rete. Si noti che in realt`a, in sistemi molto complessi, vi possono essere pi`u parlatori, anche se solo uno pu`o essere attivo in un certo istante; viene definito system controller il particolare control-lore in grado di controllare tutti gli eventuali controllori di un sistema: se il sistema come gi`a detto `e complesso, potrebbe presentare diversi controllori, nella fatispecie ciascuno per ogni sottosistema. Il system controller gestisce nel complesso il compito di gestione della rete, i con-trollori normali gestiscono solo alcune parti di rete, e possono essere fermati o accesi dal system controller.
• Ozioso: si tratta di un ruolo nullo, ossia di un tipo di dispositivo cui
non `e assegnato n`e il ruolo di ascoltatore n`e il ruolo di parlatore. In questo modo, si risparmia energia, e si evita di rallentare le operazioni di trasferimento dei dati. L’ozioso `e comunque in grado di ascoltare dati a partire dal controllore, in modo da attivarsi ed assumere uno dei ruoli dettati dal controllore.
Si noti che in un sistem IEEE-488 potrebbe anche non esserci un con-trollore: se l’assegnazione dei ruoli `e sempre statica, ossia non si ha mai un
cambio di ruoli, allora non sar`a necessario un dispositivo in grado di asseg-nare ruoli, poich`e essi saranno sempre definiti dalla nascita dei vari dispositivi (che potranno dunque essere talker-only o listener-only).
Un dispositivo pu`o avere pi`u funzioni, distinguibili all’interno del dis-positivo mediante alcuni comandi. Ogni disdis-positivo dispone di un indirizzo primario, in grado di identificarlo all’interno della rete, e permettere l’inter-faccia col bus e quindi con gli altri dispositivi; `e possibile che un dispositivo in grado di effettuare pi`u funzioni abbia anche una funzione di indirizzamento secondaria o estesa: inviando oltre alla richiesta al primario un comando al sistema di indirizzamento secondario, sar`a possibile selezionare la funzione che il dispositivo dovr`a avere in un certo istante, e cos`ı il controllore potr`a stabilire anche la funzione del dispositivo, oltre alla sua attivazione.
12.1.2 Handshake
L’handshake `e una tecnica, una procedura, necessaria al fine di avere la garanzia che un segnale, un dato, sia inviato quando tutti i destinatari sono pronti a riceverlo, e per avere la garanzia che il dato venga effettivamente ricevuto dagli ascoltatori.
A questo fine, si utilizzano 3 linee di handshake, DAV (Data Valid), NRFD (Not Ready For Data), NDAC (Not Data Accepted). Cerchiamo di capire come funzionano queste tre linee, e quale sia il loro scopo (aldil`a dei nomi, piuttosto esplicativi).
I dispositivi hanno bisogno di un certo tempo per ricevere il messaggio, devono essere tutti pronti: fino a quando ci`o non `e verificato, la linea NRFD `e allo stato logico VERO, e dunque non si pu`o avere trasmissione di dati. Dal momento che siamo in condizione wired-or, basta che uno solo dei dispositivi non sia pronto per ricevere, al fine di attivare la linea NRFD. Una volta che tutti i destinatari sono pronti, la linea NRFD viene posta su FALSO; a questo punto, il parlatore invia il primo data byte sul bus, e viene attivata la linea DAV. Ciascun destinatario a questo punto deve ricevere il primo data byte inviato dal parlatore, e disattivare la linea NDAC, indicante il fatto che non sono ancora arrivati dati a partire dalla trasmissione. Quando anche l’ultimo dispositivo avr`a negato NDAC, si potr`a riattivare NRFD, e cos`ı si riattiver`a il ciclo: appena tutti saranno pronti, si disattiver`a NRFD, si aspetter`a un certo tempo, si attiver`a DAV, poi si disattiveranno le NDAC, e cos`ı via.
Si noti che queste procedure di handshake si applicano sia per segnali device dependent che per segnali device independent: per i casi device de-pendent, l’handshake avverr`a solo tra parlatore e dispositivi interessati a ricevere dati (mentre gli altri saranno sostanzialmente oziosi, mantenendo a
OFF i driver open collector); nel caso di comandi di sistemi, tutti i device dovranno invece partecipare all’handshake.
12.1.3 Messaggi multilinea
Come si sar`a finora capito, sulle 8 linee dato possono transitare comandi (ossia segnali device independent), oppure dati (segnali device dependent): i primi devono essere codificati in maniera standard, ed essere comprensibili per qualsiasi dispositivo interno al sistema; per quanto riguarda i secondi, la cosa importante `e che parlatore e ascoltatori siano in grado di comprendersi, e quindi i segnali devono essere codificati in modo da essere comprensibili.
Perch`e si possano distinguere questi due tipi di messaggi, ossia il fatto che sulle linee di dato scorrano dati o comandi, si utilizza una delle cinque linee di gestione dell’interfaccia, ATN (Attention): se ATN `e negata, allora i messaggi sul bus sono dati; se ATN `e asserita, invece, i messaggi sui bus sono comandi. Dal momento che i comandi devono essere inviati dal controllore del sistema, allora ATN sar`a gestita direttamente dal controllore attivo: quando ATN `e attiva, tutti i dispositivi della rete, anche quelli idle, dovranno partecipare all’handshake; se ATN `e disattivata, sar`a necessaria la presenza all’handshake esclusivamente dei listener.