diff options
| author | root <root@lamia.panaceas.james.local> | 2015-06-07 01:52:49 +0100 |
|---|---|---|
| committer | root <root@lamia.panaceas.james.local> | 2015-06-07 01:52:49 +0100 |
| commit | e47a3aa300eac638317013eb9426a579fbecc229 (patch) | |
| tree | 685071a9ffe8697790bc10fbe65636bc1e02629c /docs/www.computer-engineering.org/ps2protocol | |
| parent | 6bdae4e8e3e7d59cdea0e507c8d277f119ed8097 (diff) | |
| download | tims_keyboard-e47a3aa300eac638317013eb9426a579fbecc229.tar.gz tims_keyboard-e47a3aa300eac638317013eb9426a579fbecc229.tar.bz2 tims_keyboard-e47a3aa300eac638317013eb9426a579fbecc229.zip | |
more documentation
Diffstat (limited to 'docs/www.computer-engineering.org/ps2protocol')
12 files changed, 537 insertions, 0 deletions
diff --git a/docs/www.computer-engineering.org/ps2protocol/fpdin1.JPG b/docs/www.computer-engineering.org/ps2protocol/fpdin1.JPG Binary files differnew file mode 100644 index 0000000..378895b --- /dev/null +++ b/docs/www.computer-engineering.org/ps2protocol/fpdin1.JPG diff --git a/docs/www.computer-engineering.org/ps2protocol/fpindin.JPG b/docs/www.computer-engineering.org/ps2protocol/fpindin.JPG Binary files differnew file mode 100644 index 0000000..2ef568f --- /dev/null +++ b/docs/www.computer-engineering.org/ps2protocol/fpindin.JPG diff --git a/docs/www.computer-engineering.org/ps2protocol/index.html b/docs/www.computer-engineering.org/ps2protocol/index.html new file mode 100644 index 0000000..8adffd9 --- /dev/null +++ b/docs/www.computer-engineering.org/ps2protocol/index.html @@ -0,0 +1,537 @@ +<!DOCTYPE doctype PUBLIC "-//w3c//dtd html 4.0 transitional//en"> +<html> +<head> + + + <meta http-equiv="Content-Type" + content="text/html; charset=iso-8859-1"> + + <meta name="GENERATOR" + content="Mozilla/4.76 [en] (Win98; U) [Netscape]"> + + <meta name="Author" content="Adam C"> + + <meta name="Description" + content="This site contains info on the PS/2 protocol and interfacing keyboards and the PS/2 mouse."> + + <meta name="KeyWords" + content="PS/2, PS/2, PS/2, PS/2, PS/2, PS/2, PS/2, PS/2, PS/2, PS/2, PIC, microcontroller, interfacing, keyboard, mouse, mice, AT keyboard, PS/2 mouse, PC keyboard, interfacing, mouse, PS/2"> + <title>The PS/2 Mouse/Keyboard Protocol</title> + <!--This file created 3:58 PM 2/5/2000 by Claris Home Page version 3.0--> +</head> + <body bgcolor="#ffffff" link="#0000ee" vlink="#3333ff" alink="#3333ff"> + + <small><b><font face="Arial,Helvetica"><font size="+3"><small>The PS/2 +Mouse/Keyboard Protocol</small></font></font></b></small><br> + +<center></center> + +<center> +<hr width="400" size="1" align="left" noshade="noshade"></center> + <br> + <font face="Arial,Helvetica">Source: <a + href="http://www.Computer-Engineering.org">http://www.Computer-Engineering.org</a></font><br> + <font face="Arial,Helvetica">Author: Adam Chapweske<br> + + Last Updated: 05/09/03<br> + <br> + <br> + </font><b>Legal Information:</b><br> + <br> + All information within this article is provided "as is" and without +any express or implied warranties, including, without limitation, the implied + warranties of merchantibility and fitness for a particular purpose. <br> + <br> + + This article is protected under copyright law. This document may + be copied only if the source, author, date, and legal information is included.<br> + <br> + <b>Abstract:</b> +<p>This document descibes the interface used by the PS/2 mouse, PS/2 keyboard, + and AT keyboard. I'll cover the physical and electrical interface, + as well as the protocol. If you need higher-level information, such + as commands, data packet formats, or other information specific to the keyboard + or mouse, I have written separate documents for the two devices: + </p> + +<blockquote><a href="../ps2keyboard">The PS/2 (AT) Keyboard Interface</a> + + <br> + <a href="../ps2mouse">The PS/2 Mouse Interface</a></blockquote> + <b>The Physical Interface:</b><br> + +<p>The physical PS/2 port is one of two styles of connectors: The + 5-pin DIN or the 6-pin mini-DIN. Both connectors are completely +(electrically) similar; the only practical difference between the two is + the arrangement of pins. This means the two types of connectors can + easily be changed with simple hard-wired adaptors. These cost about + $6 each or you can make your own by matching the pins on any two connectors. + The DIN standard was created by the German Standardization Organization + (Deutsches Institut fuer Norm) . Their website is at <a + href="http://www.din.de" target="_top">http://www.din.de</a> (this site is +in German, but most of their pages are also available in English.) + +</p> + +<p>PC keyboards use either a 6-pin mini-DIN or a 5-pin DIN connector. + If your keyboard has a 6-pin mini-DIN and your computer has a 5-pin DIN + (or visa versa), the two can be made compatible with the adaptors described + above. Keyboards with the 6-pin mini-DIN are often referred to as + "PS/2" keyboards, while those with the 5-pin DIN are called "AT" devices + ("XT" keyboards also used the 5-pin DIN, but they are quite old and haven't + been made for many years.) All modern keyboards built for the PC +are either PS/2, AT, or USB. This document <i>does not</i> apply +to USB devices, which use a completely different interface. </p> + +<p>Mice come in a number of shapes and sizes (and interfaces.) The + most popular type is probably the PS/2 mouse, with USB mice gaining popularity. + Just a few years ago, serial mice were also quite popular, but the computer + industry is abandoning them in support of USB and PS/2 devices. This + document applies only to PS/2 mice. If you want to interface a serial + or USB mouse, there's plenty of information available elsewhere on + the web.<br> + + <br> + The cable connecting the keyboard/mouse to the computer is usually +about six feet long and consists of four to six 26 AWG wires surrounded +by a thin layer of mylar foil sheilding. If you need a longer cable, +you can buy PS/2 extenstion cables from most consumer electronics stores. + You should not connect multiple extension cables together. If +you need a 30-foot keyboard cable, buy a 30-foot keyboard cable. Do +not simply connect five 6-foot cables together. Doing so could result +in poor communication between the keyboard/mouse and the host.<br> + </p> + +<p>As a side note, there is one other type of connector you may run into + on keyboards. While most keyboard cables are hard-wired to the keyboard, + there are some whose cable is not permanently attached and come as a separate + component. These cables have a DIN connector on one end (the end + that connects to the computer) and a SDL (Sheilded Data Link) connector +on the keyboard end. SDL was created by a company called "AMP." + + This connector is somewhat similar to a telephone connector in that it +has wires and springs rather than pins, and a clip holds it in place. +If you need more information on this connector, you might be able to find +it on AMP's website at <a href="http://www.connect.amp.com" + target="_top">http://www.connect.amp.com</a>. Don't confuse the SDL +connector with the USB connector--they probably both look similar in my +diagram below, but they are actually very different. Keep in mind +that the SDL connector has springs and moving parts, while the USB connector +does not. </p> + +<p>The pinouts for each connector are shown below: <br> + +<table width="468"> + + <tbody> + <tr> + <td> + + <center>Male <br> + <img src="fpindin.JPG" height="68" width="80" + alt=""> + <br> + (Plug)</center> + </td> + + <td> + + <center>Female <br> + <img src="fpdin1.JPG" height="68" width="80" + alt=""> + <br> + (Socket)</center> + </td> + <td><b>5-pin DIN (AT/XT): </b> <br> + + 1 - Clock <br> + 2 - Data <br> + 3 - Not Implemented <br> + 4 - Ground <br> + 5 - Vcc (+5V)</td> + </tr> + + + + </tbody> +</table> + <br> + +<table width="469"> + <tbody> + <tr> + <td> + + <center>Male <br> + <img src="spindin.JPG" height="68" width="80" + alt=""> + + <br> + (Plug)</center> + </td> + <td> + + <center>Female <br> + <img src="spindin1.JPG" height="68" width="80" + alt=""> + <br> + (Socket)</center> + + </td> + <td><b>6-pin Mini-DIN (PS/2):</b> <br> + 1 - Data <br> + 2 - Not Implemented <br> + 3 - Ground <br> + 4 - Vcc (+5V) <br> + + 5 - Clock <br> + 6 - Not Implemented</td> + </tr> + + + </tbody> +</table> + <br> + +<table width="469"> + <tbody> + + <tr> + <td> + + <center><img src="sdl.jpg" height="49" width="114" alt=""> + </center> + </td> + <td> + + <center><img src="sdl1.jpg" height="49" width="114" alt=""> + </center> + </td> + <td><b>6-pin SDL:</b> <br> + + A - Not Implemented <br> + B - Data <br> + C - Ground <br> + D - Clock <br> + E - Vcc (+5V) <br> + F - Not Implemented</td> + + </tr> + + + </tbody> +</table> + </p> + +<p> </p> + +<p><br> + <b>The Electrical Interface:</b><br> + </p> + + +<p>Note: Throughout this document, I will use the more general term + "host" to refer to the computer--or whatever the keyboard/mouse is connected + to-- and the term "device" will refer to the keyboard/mouse. </p> + + +<p>Vcc/Ground provide power to the keyboard/mouse. The keyboard or + mouse should not draw more than 275 mA from the host and care must be taken + to avoid transient surges. Such surges can be caused by "hot-plugging" + a keyboard/mouse (ie, connect/disconnect the device while the computer's + power is on.) Older motherboards had a surface-mounted fuse protecting + the keyboard and mouse ports. When this fuse blew, the motherboard + was useless to the consumer, and non-fixable to the average technician. + Most newer motherboards use auto-reset "Poly" fuses that go a long +way to remedy this problem. However, this is not a standard and +there's still plenty of older motherboards in use. Therefore, I +recommend against hot-plugging a PS/2 mouse or keyboard.<br> + </p> + + +<blockquote> + <p><u>Summary: Power Specifications</u><br> + Vcc = +4.5V to +5.5V. <br> + Max Current = 275 mA.<br> + </p> + </blockquote> + +<p>The Data and Clock lines are both open-collector with pullup resistors + to Vcc. An "open-collector" interface has two possible state: low, + or high impedance. In the "low" state, a transistor pulls the line + to ground level. In the "high impedance" state, the interface acts + as an open circuit and doesn't drive the line low or high. Furthermore, +a "pullup" resistor is connected between the bus and Vcc so the bus is pulled + high if none of the devices on the bus are actively pulling it low. The + exact value of this resistor isn't too important (1~10 kOhms); larger resistances + result in less power consumption and smaller resistances result in a faster + rise time. A general open-collector interface is shown below:<br> + + </p> + +<blockquote> + <p><font color="#ff0000">Figure 1: General open-collector interface. Data + and Clock are read on the microcontroller's pins A and B, respectively. + Both lines are normally held at +5V, but can be pulled to ground by + asserting logic "1" on C and D. As a result, Data equals D, inverted, + and Clock equals C, inverted.</font><br> + </p> + </blockquote> + +<blockquote> + <p><img src="ps2.JPG" alt="" width="352" height="330"> + <br> + + </p> + </blockquote> + +<p><br> + Note: When looking through examples on this website, you'll notice +I use a few tricks when implementing an open-collector interface with +PIC microcontrollers. I use the same pin for both input and output, +and I enable the PIC's internal pullup resistors rather than using external + resistors. A line is pulled to ground by setting the corresponding + pin to output, and writing a "zero" to that port. The line is set +to the "high impedance" state by setting the pin to input. Taking +into account the PIC's built-in protection diodes and sufficient current +sinking, I think this is a valid configuration. Let me know if your +experiences have proved otherwise.<br> + <br> + <b>Communication: General Description</b><br> + + </p> + +<p>The PS/2 mouse and keyboard implement a bidirectional synchronous serial + protocol. The bus is "idle" when both lines are high (open-collector). + This is the only state where the keyboard/mouse is allowed begin + transmitting data. The host has ultimate control over the bus and + may inhibit communication at any time by pulling the Clock line low. <br> + </p> + +<p>The device always generates the clock signal. If the host wants +to send data, it must first inhibit communication from the device by pulling + Clock low. The host then pulls Data low and releases Clock. This + is the "Request-to-Send" state and signals the device to start generating + clock pulses.<br> + + </p> + +<blockquote> + <p><u>Summary: Bus States</u><br> + Data = high, Clock = high: <i>Idle state.</i><br> + Data = high, Clock = low: <i>Communication Inhibited.</i><br> + Data = low, Clock = high: <i>Host Request-to-Send</i></p> + + </blockquote> + All data is transmitted one byte at a time and each byte is +sent in a frame consisting of 11-12 bits. These bits are: + +<ul> + <li> 1 start bit. This is always 0.</li> + <li> 8 data bits, least significant bit first.</li> + + <li> 1 parity bit (odd parity).</li> + <li> 1 stop bit. This is always 1.</li> + <li> 1 acknowledge bit (host-to-device communication only)</li> + +</ul> + + +<p> The parity bit is set if there is an even number of 1's in the data bits + and reset (0) if there is an odd number of 1's in the data bits. + The number of 1's in the data bits plus the parity bit always add up to +an odd number (odd parity.) This is used for error detection. The + keyboard/mouse must check this bit and if incorrect it should respond + as if it had received an invalid command.<br> + </p> + +<p>Data sent from the device to the host is read on the <i>falling </i>edge +of the clock signal; data sent from the host to the device is read on the + <i>rising </i>edge<i>.</i> The clock frequency must be in the +range 10 - 16.7 kHz. This means clock must be high for 30 - 50 microseconds +and low for 30 - 50 microseconds.. If you're designing a keyboard, +mouse, or host emulator, you should modify/sample the Data line in the +middle of each cell. I.e. 15 - 25 microseconds after the appropriate +clock transition. Again, the keyboard/mouse always generates the clock +signal, but the host always has ultimate control over communication. + </p> + + +<p> </p> + Timing is absolutely crucial. Every time quantity I give +in this article must be followed exactly.<br> + <br> + <b>Communication: Device-to-Host</b><br> + +<p>The Data and Clock lines are both open collector. A resistor is +connected between each line and +5V, so the idle state of the bus is high. + When the keyboard or mouse wants to send information, it first checks +the Clock line to make sure it's at a high logic level. If it's not, + the host is inhibiting communication and the device must buffer any to-be-sent + data until the host releases Clock. The Clock line must be continuously + high for at least 50 microseconds before the device can begin to transmit + its data. </p> + + +<p>As I mentioned in the previous section, the keyboard and mouse use a +serial protocol with 11-bit frames. These bits are: </p> + +<ul> + <li> 1 start bit. This is always 0.</li> + <li> 8 data bits, least significant bit first.</li> + + <li> 1 parity bit (odd parity).</li> + <li> 1 stop bit. This is always 1.</li> + +</ul> + The keyboard/mouse writes a bit on the Data line when Clock + is high, and it is read by the host when Clock is low. Figures 2 +and 3 illustrate this.<br> + + +<p><font color="#ff0000">Figure 2: Device-to-host communication. + The Data line changes state when Clock is high and that data is valid + when Clock is low.</font> <br> + </p> + +<blockquote><img src="waveform1.jpg" height="139" width="432" alt=""> + </blockquote> + +<p> </p> + + +<p><font color="#ff0000">Figure 3: Scan code for the "Q" key (15h) being +sent from a keyboard to the computer. Channel A is the Clock signal; +channel B is the Data signal.</font> </p> + +<blockquote><font color="#ffffff">---</font><img src="qscope.JPG" + height="255" width="386" alt=""> + <br> + </blockquote> + +<p> The clock frequency is 10-16.7 kHz. The time from the rising + edge of a clock pulse to a Data transition must be at least 5 microseconds. + The time from a data transition to the falling edge of a clock pulse +must be at least 5 microseconds and no greater than 25 microseconds. + +<br> + </p> + +<p>The host may inhibit communication at any time by pulling the Clock + line low for at least 100 microseconds. If a transmission is inhibited + before the 11th clock pulse, the device must abort the current transmission + and prepare to retransmit the current "chunk" of data when host releases + Clock. A "chunk" of data could be a make code, break code, device + ID, mouse movement packet, etc. For example, if a keyboard is interrupted + while sending the second byte of a two-byte break code, it will need to + retransmit both bytes of that break code, not just the one that was interrupted.<br> + </p> + +<p>If the host pulls clock low before the first high-to-low clock transition, + or after the falling edge of the last clock pulse, the keyboard/mouse +does not need to retransmit any data. However, if new data is created +that needs to be transmitted, it will have to be buffered until the host +releases Clock. Keyboards have a 16-byte buffer for this purpose. + If more than 16 bytes worth of keystrokes occur, further keystrokes +will be ignored until there's room in the buffer. Mice only store +the most current movement packet for transmission. </p> + + + +<p><b>Host-to-Device Communication:</b><br> + </p> + +<p>The packet is sent a little differently in host-to-device communication... + </p> + +<p>First of all, the PS/2 device always generates the clock signal. + If the host wants to send data, it must first put the Clock and Data +lines in a "Request-to-send" state as follows: </p> + +<ul> + <li> Inhibit communication by pulling Clock low for at least 100 +microseconds.</li> + + <li> Apply "Request-to-send" by pulling Data low, then release Clock.</li> + +</ul> + The device should check for this state at intervals not to exceed + 10 milliseconds. When the device detects this state, it will begin + generating Clock signals and clock in eight data bits and one stop bit. + The host changes the Data line only when the Clock line is low, +and data is read by the device when Clock is high. This is opposite +of what occours in device-to-host communication. + +<p>After the stop bit is received, the device will acknowledge the received + byte by bringing the Data line low and generating one last clock pulse. + If the host does not release the Data line after the 11th clock pulse, the + device will continue to generate clock pulses until the the Data line is +released (the device will then generate an error.) </p> + + +<p>The host may abort transmission at time before the 11th clock pulse + (acknowledge bit) by holding Clock low for at least 100 microseconds. + </p> + +<p>To make this process a little easier to understand, here's the steps + the host must follow to send data to a PS/2 device: </p> + +<blockquote>1) Bring the Clock line low for at least 100 microseconds. + <br> + 2) Bring the Data line low. <br> + 3) Release the Clock line. <br> + + 4) Wait for the device to bring the Clock line low. + <br> + 5) Set/reset the Data line to send the first data bit + <br> + 6) Wait for the device to bring Clock high. <br> + 7) Wait for the device to bring Clock low. <br> + + 8) Repeat steps 5-7 for the other seven data bits and + the parity bit <br> + 9) Release the Data line. <br> + 10) Wait for the device to bring Data low. <br> + 11) Wait for the device to bring Clock low. <br> + + 12) Wait for the device to release Data and Clock</blockquote> + +<p><br> + <font color="#000000">Figure 3 shows this graphically and +Figure 4 separates the timing to show which signals are generated by the +host, and which are generated by the PS/2 device. Notice the change +in timing for the "ack" bit--the data transition occours when the Clock + line is high (rather than when it is low as is the case for the other +11 bits.)</font> </p> + +<p><font color="#ff0000">Figure 3: Host-to-Device Communication.</font> + <br> + + <img src="waveform2.jpg" height="131" width="504" alt=""> + </p> + +<p><font color="#ff0000">Figure 4: Detailed host-to-device communication.</font> + <br> + <img src="waveform3.jpg" height="247" width="552" alt=""> + <br> + </p> + + +<p>Referring to Figure 4, there's two time quantities the host looks for. + (a) is the time it takes the device to begin generating clock pulses + after the host initially takes the Clock line low, which must be no greater + than 15 ms. (b) is the time it takes for the packet to be sent, which + must be no greater than 2ms. If either of these time limits is not +met, the host should generate an error. Immediately after the "ack" +is received, the host may bring the Clock line low to inhibit communication + while it processes data. If the command sent by the host requires +a response, that response must be received no later than 20 ms after the +host releases the Clock line. If this does not happen, the host generates + an error.<x-claris-window top="0" bottom="607" left="0" right="1012"> <x-claris-tagview + mode="minimal"> </x-claris-tagview></x-claris-window> </p> + + <br> + <br> + <br> +</body> +</html> diff --git a/docs/www.computer-engineering.org/ps2protocol/ps2.JPG b/docs/www.computer-engineering.org/ps2protocol/ps2.JPG Binary files differnew file mode 100644 index 0000000..067edaf --- /dev/null +++ b/docs/www.computer-engineering.org/ps2protocol/ps2.JPG diff --git a/docs/www.computer-engineering.org/ps2protocol/qscope.JPG b/docs/www.computer-engineering.org/ps2protocol/qscope.JPG Binary files differnew file mode 100644 index 0000000..aa62a11 --- /dev/null +++ b/docs/www.computer-engineering.org/ps2protocol/qscope.JPG diff --git a/docs/www.computer-engineering.org/ps2protocol/sdl.jpg b/docs/www.computer-engineering.org/ps2protocol/sdl.jpg Binary files differnew file mode 100644 index 0000000..9e2f926 --- /dev/null +++ b/docs/www.computer-engineering.org/ps2protocol/sdl.jpg diff --git a/docs/www.computer-engineering.org/ps2protocol/sdl1.jpg b/docs/www.computer-engineering.org/ps2protocol/sdl1.jpg Binary files differnew file mode 100644 index 0000000..df7ceab --- /dev/null +++ b/docs/www.computer-engineering.org/ps2protocol/sdl1.jpg diff --git a/docs/www.computer-engineering.org/ps2protocol/spindin.JPG b/docs/www.computer-engineering.org/ps2protocol/spindin.JPG Binary files differnew file mode 100644 index 0000000..e60cb72 --- /dev/null +++ b/docs/www.computer-engineering.org/ps2protocol/spindin.JPG diff --git a/docs/www.computer-engineering.org/ps2protocol/spindin1.JPG b/docs/www.computer-engineering.org/ps2protocol/spindin1.JPG Binary files differnew file mode 100644 index 0000000..a0ec642 --- /dev/null +++ b/docs/www.computer-engineering.org/ps2protocol/spindin1.JPG diff --git a/docs/www.computer-engineering.org/ps2protocol/waveform1.jpg b/docs/www.computer-engineering.org/ps2protocol/waveform1.jpg Binary files differnew file mode 100644 index 0000000..cda9a5c --- /dev/null +++ b/docs/www.computer-engineering.org/ps2protocol/waveform1.jpg diff --git a/docs/www.computer-engineering.org/ps2protocol/waveform2.jpg b/docs/www.computer-engineering.org/ps2protocol/waveform2.jpg Binary files differnew file mode 100644 index 0000000..f234c1e --- /dev/null +++ b/docs/www.computer-engineering.org/ps2protocol/waveform2.jpg diff --git a/docs/www.computer-engineering.org/ps2protocol/waveform3.jpg b/docs/www.computer-engineering.org/ps2protocol/waveform3.jpg Binary files differnew file mode 100644 index 0000000..560ac50 --- /dev/null +++ b/docs/www.computer-engineering.org/ps2protocol/waveform3.jpg |
