Implementazione hardware della comunicazione

fra host e mouse PS/2

Autori: F. Iacopetti, C. Oroni

Siete il visitatore n.

Click here for English version

Pagina ottimizzata per risoluzione 1024x768

 

Introduzione
Riconoscimenti
1. Specifiche
2. Descrizione del protocollo di comunicazione
2.1 Introduzione
2.2 Modalità di comunicazione
2.3.1 Comunicazione Host - to - Device
2.3.2 Comunicazione Device - to - Host
2.4 Struttura delle trame relative a stato dei pulsanti e spostamento
2.5 Rilievo sperimentale del protocollo
2.5.1 Significato dei comandi Host - to - Device utilizzati
2.5.2 Messaggi Device - to - Host rilevati
2.6 Differenze e novità rispetto al protocollo descritto nel materiale a nostra disposizione
3. Descrizione del mouse tester
3.1 Mouse tester
3.2 Resetmouse
3.3 Mousecom
3.4 Vga
3.5 Sender
3.6 Receiver
3.7 Registri RBR e TBR
3.8 Contatori
3.9 Bus di I/O
3.10 Multiplexer
4. Simulazioni

Torna alla Home Page

Recapiti

Introduzione

Il materiale qui pubblicato costituisce una sintesi dell'elaborato presentato ad un esame di Elettronica dei Sistemi Digitali II.

Trattandosi di materiale creato ed elaborato per mezzo di strumenti software proprietari, regolarmente concessi in licenza all'Università, riteniamo opportuno non riportare in queste pagine i listati e le descrizioni grafiche delle primitive implementate, nonché il nome della casa produttrice dei dispositivi utilizzati e del linguaggio di descrizione dell'hardware.

Invieremo prossimamente alla casa produttrice stessa una richiesta di pubblicazione di questo lavoro sulle pagine del sito ufficiale. In caso di accoglimento della domanda, indicheremo qui immediatamente il relativo collegamento.

Riconoscimenti

Il materiale contenuto in queste pagine costituisce il frutto di prove preliminari, sviluppo e verifica del progetto eseguiti in prima persona dagli autori di questa relazione.

Elenchiamo di seguito le principali fonti utilizzate per lo studio dell'approccio al progetto e la descrizione fondamentale del protocollo PS/2.

The PS/2 Mouse/Keyboard Protocol, by Adam. C.

HT 6523 PS/2 Mouse Controller, 2nd June '96, HOLTEK

Gli autori garantiscono l'originalità del materiale, pur ovviamente non escludendo che in rete sia possibile incontrarne di analogo.

Trattandosi di materiale messo gratuitamente a disposizione di chiunque lo desideri, ne è assolutamente vietata ogni forma di utilizzazione a fini commerciali. Non ci assumiamo naturalmente alcuna responsabilità per danni diretti o indiretti a cose o persone derivanti dalle informazioni attinte da questo articolo.

1. Specifiche

Lo scopo del lavoro è stato quello di implementare mediante un dispositivo programmabile (EPLD) una interfaccia in grado di sostenere un colloquio con un mouse PS/2 al fine di eseguire un test di funzionalità del mouse stesso. In particolare, il nostro mouse-tester raccoglie i dati sullo spostamento inviati dal dispositivo e in base ad essi aggiorna la posizione di un cursore su un monitor VGA (640x480). Per visualizzare lo stato dei pulsanti, il cursore si colora differentemente se viene premuto il pulsante destro, il pulsante sinistro, o entrambi i pulsanti contemporaneamente. E' stato poi previsto un pulsante di reset che, in caso di malfunzionamenti o per qualsiasi altro motivo, permette al mouse tester di ripartire dallo stato iniziale.

Per implementare il progetto abbiamo utilizzato un EPLD, alimentato a +5V regolati e pilotato con un clock a 25.175 MHz, la stessa frequenza prevista dallo standard per il pilotaggio di un monitor VGA.

I terminali del dispositivo utilizzati dalla nostra macchina sono i seguenti:

piedini di input:
ereset - reset esterno mediante pulsante normalmente aperto, con pull-up a +5V;
clock di sistema;

piedini di output:
r,g,b,h_sync,v_sync;

piedini bidirezionali:
mouseclock, mousedata.

2. Descrizione del protocollo di comunicazione

2.1 Introduzione

Di seguito viene descritto il protocollo di comunicazione fra un host e un mouse PS/2; tale protocollo è applicabile con qualche variante anche alle tastiere PS/2.

Nella nostra indagine sperimentale abbiamo utilizzato due mouse di marca diversa, un mouse standard a due tasti della Qtronix e uno a tre tasti della Logitech; in quest'ultimo, il tasto centrale risulta inattivo. La gestione del terzo tasto non è infatti prevista dal protocollo PS/2 di base.

I dispositivi PS/2 sono diversi dai mouse seriali sia per quanto riguarda il protocollo di comunicazione che per quanto riguarda i livelli elettrici. Nei mouse PS/2 l'alimentazione è di +5V, e i livelli utilizzati per lo scambio dati sono 0V e +5V, in quelli seriali troviamo invece i livelli della RS-232, attorno a +12V e -12V. Non è allora pensabile costruire un adattatore seriale-PS/2 che sia universale; quelli esistenti sono forniti con mouse costruiti per funzionare sulle due porte, ed ogni costruttore adotta un proprio standard.

La comunicazione fra un host e un mouse PS/2 prevede l'impiego di due sole linee di segnale, clock e data. A tali linee si aggiungono quelle di alimentazione, ovvero il positivo a +5V, Vcc, e la massa, GND.

Il connettore mouse più comunemente utilizzato nei PC è il Mini-Din a 6 poli; il connettore femmina si trova sull'host. Nel nostro caso è stato utilizzato solo il Mini-Din.

Alla relativa semplicità del canale di comunicazione corrisponde naturalmente la necessità di stabilire un protocollo non proprio elementare. Si tratta di un protocollo asincrono che prevede l'impiego di una linea dati bidirezionale, il cui livello sia validato da opportune transizioni sulla linea di clock.

I punti fondamentali della comunicazione, a livello elettrico e di protocollo, sono i seguenti:

  • entrambe le linee data e clock sono pilotabili sia dall'host che dal device; per evitare conflitti elettrici tali linee sono di tipo open collector, il cui livello inattivo è proprio Vcc;
  • l'host invia al device comandi di configurazione e di richiesta; in alcuni casi il device deve rispondere ai comandi, in altri è esso stesso ad iniziare una trasmissione verso l'host;
  • l'host può interrompere la trasmissione del mouse e riguadagnare in tal modo il controllo delle linee; al mouse naturalmente questo non è consentito;
  • la linea di clock è pilotata da entrambi i dispositivi, ma l'host pone la linea di clock a zero solamente per interrompere o inibire la comunicazione o per segnalare al mouse di tenersi pronto a ricevere un comando, mentre è sempre il mouse a generare il clock vero e proprio le cui transizioni validano i dati, sia quando trasmessi dall'host che quando trasmessi dal mouse;
  • quando è l'host a trasmettere, i dati vengono campionati dal device dopo un tempo massimo di 25 microsecondi da ciascun fronte in salita del clock; quando è invece il mouse a pilotare la linea dati, l'host campiona a seguito del fronte in discesa del clock;
  • la validità dei dati trasmessi, in entrambe le direzioni, è subordinata alla consistenza di alcuni bit di controllo e al rispetto di determinati tempi massimi.

2.2 Modalità di comunicazione

Tipicamente il mouse comunica all'host i dati sullo stato corrente dei pulsanti e sullo spostamento nelle direzioni x e y rispetto all'inizio della comunicazione precedente, ma può anche dover rispondere ad un comando dell'host o richiederne la ritrasmissione.

Esistono sostanzialmente due modalità di funzionamento: la prima è detta stream mode, e, se configurato ad operare in tale modalità, il mouse trasmette all'host ogni volta che viene mosso o che viene premuto o rilasciato un pulsante; la seconda è detta invece remote mode, e prevede che il mouse trasmetta informazioni su pulsanti e spostamento solo quando interrogato dall'host.

Come verrà precisato nella sezione relativa al rilievo sperimentale del protocollo, per la nostra macchina abbiamo utilizzato la modalità remote.

Per ogni byte da trasmettere, in entrambi i sensi, il protocollo prevede l'invio di un bit di start, otto bit di dati, un bit di parità, un bit di stop, e, nella sola comunicazione Host-to Device, anche di un bit di acknowledge.

Ogni trama si compone dunque di un totale di undici bit (più uno eventuale di acknowledge). I bit di dato, quindi dal secondo al nono, sono trasmessi a partire dal meno significativo.

2.3.1 Comunicazione Host-to-Device

Il significato dei bit delle trame è il seguente:

bit 0: bit di start, sempre uguale a zero;

bit 1: bit meno significativo del comando inviato al device;

...

bit 8: bit più significativo del comando inviato al device;

bit 9: bit di parità pari della stringa di otto bit costituente il comando;

bit 10: bit di stop, sempre uguale a uno;

bit 11: bit di acknowledge

Quando l'host vuole inviare una stringa al mouse, in generale attende che il mouse abbia terminato la trasmissione, ma, in ogni caso, può guadagnare il diritto al controllo della comunicazione; in entrambi i casi, per segnalare al mouse di tenersi pronto a ricevere una stringa, abbassa il clock per un tempo non inferiore a 60-100 microsecondi; prima di lasciare libero il clock l’host abbassa la linea data, cosicché, alla salita del clock, il mouse campionerà un bit a zero, ovvero il bit di start della trama. A questo punto il mouse, dopo un certo tempo, che deve essere comunque inferiore a 15 millisecondi dall'istante in cui l'host ha abbassato il clock, deve cominciare a generare il segnale di clock. Come visto, l'host pilota la linea di clock solo una volta per ogni trama trasmessa, ed è sempre il mouse a generare il clock, sia quando riceve che quando trasmette verso l'host. Il mouse campiona il bit di start, e tutti i bit successivi, entro un tempo di 5-25 microsecondi dal fronte in salita del clock; prima che il clock sia riportato a zero dal mouse, l'host deve aggiornare lo stato della linea dati. La durata del periodo in cui il clock è alto o basso varia da 30 a 50 microsecondi; i tempi di commutazione della linea di clock arrivano ad un massimo di 25 microsecondi; il periodo del clock risulta compreso fra 70 e 150 microsecondi.

Dopo il bit di start, il mouse campiona la linea dati per altre 10 volte in seguito alla transizione low-high del clock. A questo punto il clock è alto, e sulla linea dati è ancora presente l'uno logico del bit di stop; il mouse allora esegue in sequenza le seguenti operazioni: abbassa la linea dati, abbassa il clock, rialza il clock e rialza la linea dati. Quest'ultima procedura assume il significato di bit di acknowledge. Il protocollo di trasmissione host-to-device si conclude dunque con entrambe le linee a livello alto; se la linea dati è mantenuta a zero dall'host, il mouse continua a generare il clock finché essa non torna a uno, e quando ciò avviene genera una stringa di errore.

2.3.2 Comunicazione Device-to-Host

Il significato dei bit delle trame è il seguente:

bit 0: bit di start, sempre uguale a zero;

bit 1: bit meno significativo della trama inviata all'host;

...

bit 8: bit più significativo della trama inviata all'host;

bit 9: bit di parità pari della stringa di otto bit costituente la trama inviata;

bit 10: bit di stop, sempre uguale a uno;

Quando il device vuole inviare una trama all'host, su richiesta o meno di quest'ultimo, il protocollo può iniziare se le linee clock e data sono libere. In tal caso il mouse porta a zero la linea dati (bit di start), e, dopo un tempo compreso fra 5 e 25 microsecondi, porta a zero la linea di clock. L'host campiona a seguito del fronte in discesa del clock. Il mouse rilascia il clock, e dopo un tempo compreso fra un massimo di 25 e un minimo di 5 microsecondi prima di abbassare nuovamente il clock, pone sulla linea dati il primo bit della trama. Abbassa e rialza il clock per nove volte (8 bit di dati e un bit di parità), pone poi sulla linea dati il bit di stop (uno) e genera un ulteriore ciclo di clock. Anche in questo caso la comunicazione si conclude con entrambe le linee a uno.

2.4 Struttura delle trame relative a stato dei pulsanti e spostamento

Indipendentemente dalla modalità di funzionamento, stream o remote, le trame contenenti le informazioni sullo stato dei pulsanti e sullo spostamento rispetto all'ultima lettura sono tre e hanno la struttura riportata di seguito.

Gli spostamenti delta_x e delta_y si riferiscono ad un piano cartesiano ove sono considerati positivi per x gli spostamenti verso destra e per y in avanti (o in alto). Si ricorda che il primo bit di dato dopo il bit di start è quello meno significativo del byte che viene trasmesso.

    D0 D1 D2 D3 D4 D5 D6 D7    
Trama 1 Start L R 0 1 XS YS XV YV Parity Stop
Trama 2 Start X0 X1 X2 X3 X4 X5 X6 X7 Parity Stop
Trama 3 Start Y0 Y1 Y2 Y3 Y4 Y5 Y6 Y7 Parity Stop

Tabella 1: Struttura delle trame

Trama 1 : stato dei pulsanti

L : Left Button (1 = premuto)

R : Right Button (1 = premuto)

Il terzo bit è utilizzato in alcuni protocolli per codificare lo stato del pulsante centrale.

Il quarto bit è sempre 1.

XS : segno dello spostamento orizzontale (0 = positivo, 1 = negativo)

YS : segno dello spostamento verticale (0 = positivo, 1 = negativo)

XV : overflow nello spostamento orizzontale.

YV : overflow nello spostamento verticale.

X0-X7 esprimono lo spostamento orizzontale avvenuto dall'ultima lettura.

Y0-Y7 esprimono lo spostamento verticale avvenuto dall'ultima lettura.

La rappresentazione dello spostamento x e y avviene in complemento a due.

2.5 Rilievo sperimentale del protocollo

Il materiale che abbiamo attinto dalla rete, pur essendo nel complesso sufficiente per quanto riguarda la descrizione di base del protocollo, si è rivelato però assolutamente incompleto per stabilire esattamente le modalità con le quali pilotare il mouse e da esso ricevere i dati.

Abbiamo allora deciso di rilevare sperimentalmente i segnali di clock e data generati dal mouse quando connesso alla sola alimentazione (e a due resistenze di pull-up). Le prove eseguite con l'oscilloscopio non hanno portato a rilevare alcun tipo di attività. Abbiamo allora deciso di osservare i medesimi segnali durante il normale funzionamento del mouse connesso ad un PC, ma, dato l'elevato numero di comandi che l'host invia al mouse durante la fase di avvio del sistema operativo, l'osservazione con l'oscilloscopio non si è rivelata praticabile per l'impossibilità di registrare la sequenza delle varie trame scambiate. La strada che abbiamo deciso di seguire è stata quella di registrare i segnali clock e data attraverso i due ingressi della scheda audio di un PC (con opportuna attenuazione e protezione: ignoriamo quale sia l'effetto di inviare +5V su un canale di ingresso della scheda audio). Abbiamo deciso allora di registrare tutta la sequenza di comunicazione mouse-PC dal momento dell'accensione fino al funzionamento a regime (circa due minuti), ma il numero di trame osservate è stato superiore al centinaio, il che ha reso naturalmente impossibile identificare le trame significative per i numerosi problemi nell'analisi dei file .wav ottenuti. La difficoltà dell'interpretazione dei risultati è infatti legata a vari fattori: la frequenza di commutazione del clock del mouse, di circa 14 kHz (il periodo misurato è di 70 microsecondi), seppur con un campionamento a 48 kHz permette di ottenere solamente pochi punti per periodo, rendendo difficile l'identificazione delle transizioni; la banda della scheda audio, essendo limitata verso l'alto a circa 20 kHz, lascia passare solo la prima armonica del clock, il quale risulta tutt'altro che un'onda quadra, mentre la limitazione verso il basso a circa 20 Hz non permette un agevole riconoscimento dei livelli di continua nel caso di commutazioni ravvicinate (ad esempio, è difficile distinguere i singoli bit nella stringa sullo stato dei pulsanti).

Per risolvere il problema della selezione delle trame di configurazione fra tutte quelle presenti, e per sperimentare diverse configurazioni del mouse, abbiamo ritenuto inevitabile provare a pilotare il mouse con un microcontrollore, che presenta il grande vantaggio di essere messo a punto più facilmente rispetto alla macchina a stati scopo del nostro progetto. E' stato utilizzato un PIC 16F84, programmato in modo da inviare trame diverse, e in diversa sequenza, al mouse; lo stato delle linee di comunicazione è stato inviato in ingresso alla scheda audio di un PC e in seguito analizzato.

In appendice è riportato il programma utilizzato sul PIC, l'elenco dei possibili comandi inviati dall'host al device e dei possibili messaggi inviati dal device all'host; abbiamo provato ad utilizzare i principali, in diverse sequenze, e abbiamo ottenuto i risultati riportati in tabella 2. Il mouse utilizzato è stato quello della Qtronix.

2.5.1 Significato dei comandi Host-to-Device utilizzati

FFH - Reset

Il mouse entra in uno stato di reset, e dopo un tempo di alcune centinaia di millisecondi risponde con AAH seguito da 00H; la configurazione del mouse è ora quella di default, stream mode con parametri predefiniti di scaling e di massimo report rate (numero di trasmissioni al secondo verso l'host). Il mouse si disabilita.

F6H - Set to default

Il mouse entra in stream mode, con parametri predefiniti di scaling e di report rate.

F4H - Enable

Se in stream mode, il mouse è abilitato a trasmettere.

EBH - Read Data

Il mouse risponde con tre stringhe riportanti lo stato dei pulsanti e le informazioni sullo spostamento, qualunque sia la modalitá di funzionamento.

E9H - Read Status

Il mouse risponde con tre stringhe che riportano il sampling rate, la risoluzione e alcune informazioni sulla modalità di comunicazione e sullo stato dei pulsanti.

EAH - Set stream mode

Il mouse entra in stream mode.

2.5.2 Messaggi Device-to-Host rilevati

AAH - Tale byte viene inviato all'host dopo alcune centinaia di millisecondi dal reset, sia esso indotto dal comando FFH, sia esso dovuto al collegamento del mouse all’alimentazione.

00H - ID device : segue la stringa contente il byte AAH.

FAH - Acknowlegde

Il device risponde con questo byte ad ogni comando inviato dall'host, e precede sempre eventuali altre trame di risposta.

Elenchiamo di seguito la sequenza di comandi inviati dal nostro microcontrollore e la risposta del mouse (quando interpretabile).

Comando inviato Risposta del mouse
Collegamento all'alimentazione (Power-on reset) Dopo un tempo di 330 ms, il mouse genera i due byte AAH e 00H, e poi rimane inattivo.
FFH (Reset) Il mouse risponde immediatamente con FAH (Acknowledge), e dopo un tempo di 330 ms (stesso tempo del power-on reset) trasmette AAH e 00H; rimane poi inattivo.
EBH (Read Data) Il mouse trasmette quattro trame consecutive: FAH (Acknowledge) seguito da tre trame sullo stato dei pulsanti e sullo spostamento.
F6H (Set Default) Il mouse risponde con FAH (Acknowledge) e rimane inattivo.
F4H (Enable) Contrariamente a quanto affermato nel materiale annesso in appendice, il mouse non entra affatto in stream mode, ovvero non trasmette anche se mosso.
EBH (Read Data) Il mouse trasmette quattro trame consecutive: FAH (Acknowledge) seguito da tre trame sullo stato dei pulsanti e sullo spostamento.
E9H (Richiesta Status) Il mouse trasmette una trama (non interpretabile).
EAH (Set stream mode) Il mouse trasmette una trama (non interpretabile).
EBH (Read Data) Il mouse trasmette quattro trame consecutive: FAH (Acknowledge) seguito da tre trame sullo stato dei pulsanti e sullo spostamento.

Tabella 2: Comandi del mouse

Per brevità si ritiene opportuno non elencare altre sequenze di comandi; è però significativo che non sia stato possibile, neppure con altre combinazioni dei comandi Reset, Enable, Set Stream Mode, Set Default, ottenere l'ingresso del mouse in stream mode. Avendo osservato invece che il mouse risponde sempre al comando Read Data, abbiamo deciso di utilizzare tale modalità di funzionamento, che corrisponde alla definizione di remote mode, per l'implementazione della nostra macchina a stati.

Comunicazione Host - Mouse PS/2 - Parte II


Se volete contattarmi per chiarimenti o suggerimenti potete farlo al seguente indirizzo:

f_iacopetti@libero.it

 
Ultimo aggiornamento: 30 Marzo 2002, 22.37 HyperCounter