Authors: F. Iacopetti, C. Oroni You are the visitor n.
Best view with 1024x768 |
Authors: F. Iacopetti, C. Oroni You are the visitor n.
Best view with 1024x768 |
At the moment, sorry, the complete document is available in Italian version only. I am going to translate it as soon as possible. For your convenience, I have reported here the part still in Italian (the most part at the moment!); if you think you can find here something interesting, please bookmark this link and visit this page again. There is, of course, another possibility: "Learning Italian in thirty hours". It's not so difficult, why not trying? F. Iacopetti Introduction The material here published it's part of the work made for the Digital Systems Electronics II exam at the University of Pisa, Electronic Engineering. As a material created and developed by mean of software regularly licensed to University, we believe opportune not to report in these pages the lists and the graphical description of primitives we have developed, as well as the name of the supplier of devices and of the Hardware Description Language. When possible, we are going to ask to the supplier itself to publish this work on its official site. If we'll be allowed, we'll report here the link. The material contained in these pages is the result of preliminary tests, development and verification of the project carried on in first person by the authors of this report. We list here the main sources for the project's approach and the basic description of PS/2 protocol. The PS/2 Mouse/Keyboard Protocol, by Adam. C. HT 6523 PS/2 Mouse Controller, 2nd June '96, HOLTEK The authors grant the originality of the material, though of course not excluding that on the net something similar could be found. As a material at free disposal of whoever wish it, every form of commercial use is severely prohibited. We of course don't assume any responsibility for direct or indirect damages to people or things deriving from the informations contained in this article. The aim of this work is to realize, by mean of a programmable device (EPLD), an interface able to communicate with a PS/2 mouse in order to carry out a test on it, allowing one to know if the mouse itself is working. In details, our mouse-tester uses data sent by the mouse and according to them displays and moves to a new position a cursor on a VGA display (640x480). According to the buttons' state, the cursor is displayed in a colour different for each of the following situations: left button pressed, right button pressed, both buttons pressed. A reset switch has been provided, in order to allow the mouse tester to start from its initial state in case of problems or for whichever reason. To realize the project we have used an EPLD, fed by regulated +5V and driven with a 25.175 MHz clock, the same frequency used to drive a VGA monitor. The pins used by our machine are the following: Input pins: output pins: bidirectional pins: 2.1 Introduction In the following lines the protocol of the communication between a host and a PS/2 mouse is described; such a protocol is appliable, with a few differences, also to PS/2 keyboards. In our tests we have used two mice from different companies, a two-switch standard mouse from Qtronix and a three-switch mouse from Logiech; in this last one, the middle button is inactive. The third switch is in fact not mentioned/used in the basic PS/2 mouse protocol. PS/2 devices are different from serial mice, concerning both the communication protocol and electrical levels. Supply in PS/2 mice is +5V, and levels used for data exchange are near 0V and +5V, while in serial mice RS-232 levels are used, around +12V e -12V. It is not therefore possible to think and build a universal adapter; existing ones are supplied with mice designed to work connected with both ports, and each company has his own standard. The communication between a host and a PS/2 mouse uses just two signals, clock and data. Beside those lines we can find the +5V supply, Vcc, and the ground, GND. On PCs, the most frequently used connector for PS/2 mice is the 6-pin mini Mini-Din; the female connector is on the host (mainboard). In our work the Mini-Din only has been used. The simplicity of the communication channel requires of course a protocol not just elementary. It is an asynchronous protocol, based on the use of a bidirectiona data line, whose levels are validated by proper transitions on clock lines. The fundamentals of the communication, at the electrical and protocol level, are the following ones:
2.2 Communication modes 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.
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).
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. Host - Mouse PS/2
communication - Part II |
| Last update: 30 March 2002, 23.34 | |
