1 |
131 |
jt_eaton |
<!DOCTYPE doctype PUBLIC "-//w3c//dtd html 4.0 transitional//en">
|
2 |
|
|
<html><head>
|
3 |
|
|
|
4 |
|
|
|
5 |
|
|
|
6 |
|
|
|
7 |
|
|
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
8 |
|
|
|
9 |
|
|
<meta name="GENERATOR" content="Mozilla/4.76 [en] (Win98; U) [Netscape]">
|
10 |
|
|
|
11 |
|
|
<meta name="Author" content="Adam C">
|
12 |
|
|
|
13 |
|
|
<meta name="Description" content="This site contains info on the PS/2 protocol and interfacing keyboards and the PS/2 mouse.">
|
14 |
|
|
|
15 |
|
|
<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">
|
16 |
|
|
<title>The PS/2 Mouse/Keyboard Protocol</title>
|
17 |
|
|
<!--This file created 3:58 PM 2/5/2000 by Claris Home Page version 3.0-->
|
18 |
|
|
</head><body vlink="#3333ff" alink="#3333ff" bgcolor="#ffffff" link="#0000ee">
|
19 |
|
|
|
20 |
|
|
<small><b><font face="Arial,Helvetica"><font size="+3"><small>The PS/2
|
21 |
|
|
Mouse/Keyboard Protocol</small></font></font></b></small><br>
|
22 |
|
|
|
23 |
|
|
<center></center>
|
24 |
|
|
|
25 |
|
|
<center>
|
26 |
|
|
<hr size="1" width="400" align="left" noshade="noshade"></center>
|
27 |
|
|
<br>
|
28 |
|
|
<font face="Arial,Helvetica">Source: <a href="http://www.computer-engineering.org/">http://www.Computer-Engineering.org</a></font><br>
|
29 |
|
|
<font face="Arial,Helvetica">Author: Adam Chapweske<br>
|
30 |
|
|
|
31 |
|
|
Last Updated: 05/09/03<br>
|
32 |
|
|
<br>
|
33 |
|
|
<br>
|
34 |
|
|
</font><b>Legal Information:</b><br>
|
35 |
|
|
<br>
|
36 |
|
|
All information within this article is provided "as is" and without
|
37 |
|
|
any express or implied warranties, including, without limitation, the implied
|
38 |
|
|
warranties of merchantibility and fitness for a particular purpose. <br>
|
39 |
|
|
<br>
|
40 |
|
|
|
41 |
|
|
This article is protected under copyright law. This document may
|
42 |
|
|
be copied only if the source, author, date, and legal information is included.<br>
|
43 |
|
|
<br>
|
44 |
|
|
<b>Abstract:</b>
|
45 |
|
|
<p>This document descibes the interface used by the PS/2 mouse, PS/2 keyboard,
|
46 |
|
|
and AT keyboard. I'll cover the physical and electrical interface,
|
47 |
|
|
as well as the protocol. If you need higher-level information, such
|
48 |
|
|
as commands, data packet formats, or other information specific to the keyboard
|
49 |
|
|
or mouse, I have written separate documents for the two devices:
|
50 |
|
|
</p>
|
51 |
|
|
|
52 |
|
|
<blockquote><a href="http://www.computer-engineering.org/ps2keyboard">The PS/2 (AT) Keyboard Interface</a>
|
53 |
|
|
|
54 |
|
|
<br>
|
55 |
|
|
<a href="http://www.computer-engineering.org/ps2mouse">The PS/2 Mouse Interface</a></blockquote>
|
56 |
|
|
<b>The Physical Interface:</b><br>
|
57 |
|
|
|
58 |
|
|
<p>The physical PS/2 port is one of two styles of connectors: The
|
59 |
|
|
5-pin DIN or the 6-pin mini-DIN. Both connectors are completely
|
60 |
|
|
(electrically) similar; the only practical difference between the two is
|
61 |
|
|
the arrangement of pins. This means the two types of connectors can
|
62 |
|
|
easily be changed with simple hard-wired adaptors. These cost about
|
63 |
|
|
$6 each or you can make your own by matching the pins on any two connectors.
|
64 |
|
|
The DIN standard was created by the German Standardization Organization
|
65 |
|
|
(Deutsches Institut fuer Norm) . Their website is at <a href="http://www.din.de/" target="_top">http://www.din.de</a> (this site is
|
66 |
|
|
in German, but most of their pages are also available in English.)
|
67 |
|
|
|
68 |
|
|
</p>
|
69 |
|
|
|
70 |
|
|
<p>PC keyboards use either a 6-pin mini-DIN or a 5-pin DIN connector.
|
71 |
|
|
If your keyboard has a 6-pin mini-DIN and your computer has a 5-pin DIN
|
72 |
|
|
(or visa versa), the two can be made compatible with the adaptors described
|
73 |
|
|
above. Keyboards with the 6-pin mini-DIN are often referred to as
|
74 |
|
|
"PS/2" keyboards, while those with the 5-pin DIN are called "AT" devices
|
75 |
|
|
("XT" keyboards also used the 5-pin DIN, but they are quite old and haven't
|
76 |
|
|
been made for many years.) All modern keyboards built for the PC
|
77 |
|
|
are either PS/2, AT, or USB. This document <i>does not</i> apply
|
78 |
|
|
to USB devices, which use a completely different interface. </p>
|
79 |
|
|
|
80 |
|
|
<p>Mice come in a number of shapes and sizes (and interfaces.) The
|
81 |
|
|
most popular type is probably the PS/2 mouse, with USB mice gaining popularity.
|
82 |
|
|
Just a few years ago, serial mice were also quite popular, but the computer
|
83 |
|
|
industry is abandoning them in support of USB and PS/2 devices. This
|
84 |
|
|
document applies only to PS/2 mice. If you want to interface a serial
|
85 |
|
|
or USB mouse, there's plenty of information available elsewhere on
|
86 |
|
|
the web.<br>
|
87 |
|
|
|
88 |
|
|
<br>
|
89 |
|
|
The cable connecting the keyboard/mouse to the computer is usually
|
90 |
|
|
about six feet long and consists of four to six 26 AWG wires surrounded
|
91 |
|
|
by a thin layer of mylar foil sheilding. If you need a longer cable,
|
92 |
|
|
you can buy PS/2 extenstion cables from most consumer electronics stores.
|
93 |
|
|
You should not connect multiple extension cables together. If
|
94 |
|
|
you need a 30-foot keyboard cable, buy a 30-foot keyboard cable. Do
|
95 |
|
|
not simply connect five 6-foot cables together. Doing so could result
|
96 |
|
|
in poor communication between the keyboard/mouse and the host.<br>
|
97 |
|
|
</p>
|
98 |
|
|
|
99 |
|
|
<p>As a side note, there is one other type of connector you may run into
|
100 |
|
|
on keyboards. While most keyboard cables are hard-wired to the keyboard,
|
101 |
|
|
there are some whose cable is not permanently attached and come as a separate
|
102 |
|
|
component. These cables have a DIN connector on one end (the end
|
103 |
|
|
that connects to the computer) and a SDL (Sheilded Data Link) connector
|
104 |
|
|
on the keyboard end. SDL was created by a company called "AMP."
|
105 |
|
|
|
106 |
|
|
This connector is somewhat similar to a telephone connector in that it
|
107 |
|
|
has wires and springs rather than pins, and a clip holds it in place.
|
108 |
|
|
If you need more information on this connector, you might be able to find
|
109 |
|
|
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
|
110 |
|
|
connector with the USB connector--they probably both look similar in my
|
111 |
|
|
diagram below, but they are actually very different. Keep in mind
|
112 |
|
|
that the SDL connector has springs and moving parts, while the USB connector
|
113 |
|
|
does not. </p>
|
114 |
|
|
|
115 |
|
|
<p>The pinouts for each connector are shown below: <br>
|
116 |
|
|
|
117 |
|
|
<table width="468">
|
118 |
|
|
|
119 |
|
|
<tbody>
|
120 |
|
|
<tr>
|
121 |
|
|
<td>
|
122 |
|
|
|
123 |
|
|
<center>Male <br>
|
124 |
|
|
<img src="The_PS_2_Mouse_Keyboard_Protocol_files/fpindin.JPG" alt="" width="80" height="68">
|
125 |
|
|
<br>
|
126 |
|
|
(Plug)</center>
|
127 |
|
|
</td>
|
128 |
|
|
|
129 |
|
|
<td>
|
130 |
|
|
|
131 |
|
|
<center>Female <br>
|
132 |
|
|
<img src="The_PS_2_Mouse_Keyboard_Protocol_files/fpdin1.JPG" alt="" width="80" height="68">
|
133 |
|
|
<br>
|
134 |
|
|
(Socket)</center>
|
135 |
|
|
</td>
|
136 |
|
|
<td><b>5-pin DIN (AT/XT): </b> <br>
|
137 |
|
|
|
138 |
|
|
1 - Clock <br>
|
139 |
|
|
2 - Data <br>
|
140 |
|
|
3 - Not Implemented <br>
|
141 |
|
|
4 - Ground <br>
|
142 |
|
|
5 - Vcc (+5V)</td>
|
143 |
|
|
</tr>
|
144 |
|
|
|
145 |
|
|
|
146 |
|
|
|
147 |
|
|
</tbody>
|
148 |
|
|
</table>
|
149 |
|
|
<br>
|
150 |
|
|
|
151 |
|
|
<table width="469">
|
152 |
|
|
<tbody>
|
153 |
|
|
<tr>
|
154 |
|
|
<td>
|
155 |
|
|
|
156 |
|
|
<center>Male <br>
|
157 |
|
|
<img src="The_PS_2_Mouse_Keyboard_Protocol_files/spindin.JPG" alt="" width="80" height="68">
|
158 |
|
|
|
159 |
|
|
<br>
|
160 |
|
|
(Plug)</center>
|
161 |
|
|
</td>
|
162 |
|
|
<td>
|
163 |
|
|
|
164 |
|
|
<center>Female <br>
|
165 |
|
|
<img src="The_PS_2_Mouse_Keyboard_Protocol_files/spindin1.JPG" alt="" width="80" height="68">
|
166 |
|
|
<br>
|
167 |
|
|
(Socket)</center>
|
168 |
|
|
|
169 |
|
|
</td>
|
170 |
|
|
<td><b>6-pin Mini-DIN (PS/2):</b> <br>
|
171 |
|
|
1 - Data <br>
|
172 |
|
|
2 - Not Implemented <br>
|
173 |
|
|
3 - Ground <br>
|
174 |
|
|
4 - Vcc (+5V) <br>
|
175 |
|
|
|
176 |
|
|
5 - Clock <br>
|
177 |
|
|
6 - Not Implemented</td>
|
178 |
|
|
</tr>
|
179 |
|
|
|
180 |
|
|
|
181 |
|
|
</tbody>
|
182 |
|
|
</table>
|
183 |
|
|
<br>
|
184 |
|
|
|
185 |
|
|
<table width="469">
|
186 |
|
|
<tbody>
|
187 |
|
|
|
188 |
|
|
<tr>
|
189 |
|
|
<td>
|
190 |
|
|
|
191 |
|
|
<center><img src="The_PS_2_Mouse_Keyboard_Protocol_files/sdl.jpg" alt="" width="114" height="49">
|
192 |
|
|
</center>
|
193 |
|
|
</td>
|
194 |
|
|
<td>
|
195 |
|
|
|
196 |
|
|
<center><img src="The_PS_2_Mouse_Keyboard_Protocol_files/sdl1.jpg" alt="" width="114" height="49">
|
197 |
|
|
</center>
|
198 |
|
|
</td>
|
199 |
|
|
<td><b>6-pin SDL:</b> <br>
|
200 |
|
|
|
201 |
|
|
A - Not Implemented <br>
|
202 |
|
|
B - Data <br>
|
203 |
|
|
C - Ground <br>
|
204 |
|
|
D - Clock <br>
|
205 |
|
|
E - Vcc (+5V) <br>
|
206 |
|
|
F - Not Implemented</td>
|
207 |
|
|
|
208 |
|
|
</tr>
|
209 |
|
|
|
210 |
|
|
|
211 |
|
|
</tbody>
|
212 |
|
|
</table>
|
213 |
|
|
</p>
|
214 |
|
|
|
215 |
|
|
<p> </p>
|
216 |
|
|
|
217 |
|
|
<p><br>
|
218 |
|
|
<b>The Electrical Interface:</b><br>
|
219 |
|
|
</p>
|
220 |
|
|
|
221 |
|
|
|
222 |
|
|
<p>Note: Throughout this document, I will use the more general term
|
223 |
|
|
"host" to refer to the computer--or whatever the keyboard/mouse is connected
|
224 |
|
|
to-- and the term "device" will refer to the keyboard/mouse. </p>
|
225 |
|
|
|
226 |
|
|
|
227 |
|
|
<p>Vcc/Ground provide power to the keyboard/mouse. The keyboard or
|
228 |
|
|
mouse should not draw more than 275 mA from the host and care must be taken
|
229 |
|
|
to avoid transient surges. Such surges can be caused by "hot-plugging"
|
230 |
|
|
a keyboard/mouse (ie, connect/disconnect the device while the computer's
|
231 |
|
|
power is on.) Older motherboards had a surface-mounted fuse protecting
|
232 |
|
|
the keyboard and mouse ports. When this fuse blew, the motherboard
|
233 |
|
|
was useless to the consumer, and non-fixable to the average technician.
|
234 |
|
|
Most newer motherboards use auto-reset "Poly" fuses that go a long
|
235 |
|
|
way to remedy this problem. However, this is not a standard and
|
236 |
|
|
there's still plenty of older motherboards in use. Therefore, I
|
237 |
|
|
recommend against hot-plugging a PS/2 mouse or keyboard.<br>
|
238 |
|
|
</p>
|
239 |
|
|
|
240 |
|
|
|
241 |
|
|
<blockquote>
|
242 |
|
|
<p><u>Summary: Power Specifications</u><br>
|
243 |
|
|
Vcc = +4.5V to +5.5V. <br>
|
244 |
|
|
Max Current = 275 mA.<br>
|
245 |
|
|
</p>
|
246 |
|
|
</blockquote>
|
247 |
|
|
|
248 |
|
|
<p>The Data and Clock lines are both open-collector with pullup resistors
|
249 |
|
|
to Vcc. An "open-collector" interface has two possible state: low,
|
250 |
|
|
or high impedance. In the "low" state, a transistor pulls the line
|
251 |
|
|
to ground level. In the "high impedance" state, the interface acts
|
252 |
|
|
as an open circuit and doesn't drive the line low or high. Furthermore,
|
253 |
|
|
a "pullup" resistor is connected between the bus and Vcc so the bus is pulled
|
254 |
|
|
high if none of the devices on the bus are actively pulling it low. The
|
255 |
|
|
exact value of this resistor isn't too important (1~10 kOhms); larger resistances
|
256 |
|
|
result in less power consumption and smaller resistances result in a faster
|
257 |
|
|
rise time. A general open-collector interface is shown below:<br>
|
258 |
|
|
|
259 |
|
|
</p>
|
260 |
|
|
|
261 |
|
|
<blockquote>
|
262 |
|
|
<p><font color="#ff0000">Figure 1: General open-collector interface. Data
|
263 |
|
|
and Clock are read on the microcontroller's pins A and B, respectively.
|
264 |
|
|
Both lines are normally held at +5V, but can be pulled to ground by
|
265 |
|
|
asserting logic "1" on C and D. As a result, Data equals D, inverted,
|
266 |
|
|
and Clock equals C, inverted.</font><br>
|
267 |
|
|
</p>
|
268 |
|
|
</blockquote>
|
269 |
|
|
|
270 |
|
|
<blockquote>
|
271 |
|
|
<p><img src="The_PS_2_Mouse_Keyboard_Protocol_files/ps2.JPG" alt="" width="352" height="330">
|
272 |
|
|
<br>
|
273 |
|
|
|
274 |
|
|
</p>
|
275 |
|
|
</blockquote>
|
276 |
|
|
|
277 |
|
|
<p><br>
|
278 |
|
|
Note: When looking through examples on this website, you'll notice
|
279 |
|
|
I use a few tricks when implementing an open-collector interface with
|
280 |
|
|
PIC microcontrollers. I use the same pin for both input and output,
|
281 |
|
|
and I enable the PIC's internal pullup resistors rather than using external
|
282 |
|
|
resistors. A line is pulled to ground by setting the corresponding
|
283 |
|
|
pin to output, and writing a "zero" to that port. The line is set
|
284 |
|
|
to the "high impedance" state by setting the pin to input. Taking
|
285 |
|
|
into account the PIC's built-in protection diodes and sufficient current
|
286 |
|
|
sinking, I think this is a valid configuration. Let me know if your
|
287 |
|
|
experiences have proved otherwise.<br>
|
288 |
|
|
<br>
|
289 |
|
|
<b>Communication: General Description</b><br>
|
290 |
|
|
|
291 |
|
|
</p>
|
292 |
|
|
|
293 |
|
|
<p>The PS/2 mouse and keyboard implement a bidirectional synchronous serial
|
294 |
|
|
protocol. The bus is "idle" when both lines are high (open-collector).
|
295 |
|
|
This is the only state where the keyboard/mouse is allowed begin
|
296 |
|
|
transmitting data. The host has ultimate control over the bus and
|
297 |
|
|
may inhibit communication at any time by pulling the Clock line low. <br>
|
298 |
|
|
</p>
|
299 |
|
|
|
300 |
|
|
<p>The device always generates the clock signal. If the host wants
|
301 |
|
|
to send data, it must first inhibit communication from the device by pulling
|
302 |
|
|
Clock low. The host then pulls Data low and releases Clock. This
|
303 |
|
|
is the "Request-to-Send" state and signals the device to start generating
|
304 |
|
|
clock pulses.<br>
|
305 |
|
|
|
306 |
|
|
</p>
|
307 |
|
|
|
308 |
|
|
<blockquote>
|
309 |
|
|
<p><u>Summary: Bus States</u><br>
|
310 |
|
|
Data = high, Clock = high: <i>Idle state.</i><br>
|
311 |
|
|
Data = high, Clock = low: <i>Communication Inhibited.</i><br>
|
312 |
|
|
Data = low, Clock = high: <i>Host Request-to-Send</i></p>
|
313 |
|
|
|
314 |
|
|
</blockquote>
|
315 |
|
|
All data is transmitted one byte at a time and each byte is
|
316 |
|
|
sent in a frame consisting of 11-12 bits. These bits are:
|
317 |
|
|
|
318 |
|
|
<ul>
|
319 |
|
|
<li> 1 start bit. This is always 0.</li>
|
320 |
|
|
<li> 8 data bits, least significant bit first.</li>
|
321 |
|
|
|
322 |
|
|
<li> 1 parity bit (odd parity).</li>
|
323 |
|
|
<li> 1 stop bit. This is always 1.</li>
|
324 |
|
|
<li> 1 acknowledge bit (host-to-device communication only)</li>
|
325 |
|
|
|
326 |
|
|
</ul>
|
327 |
|
|
|
328 |
|
|
|
329 |
|
|
<p> The parity bit is set if there is an even number of 1's in the data bits
|
330 |
|
|
and reset (0) if there is an odd number of 1's in the data bits.
|
331 |
|
|
The number of 1's in the data bits plus the parity bit always add up to
|
332 |
|
|
an odd number (odd parity.) This is used for error detection. The
|
333 |
|
|
keyboard/mouse must check this bit and if incorrect it should respond
|
334 |
|
|
as if it had received an invalid command.<br>
|
335 |
|
|
</p>
|
336 |
|
|
|
337 |
|
|
<p>Data sent from the device to the host is read on the <i>falling </i>edge
|
338 |
|
|
of the clock signal; data sent from the host to the device is read on the
|
339 |
|
|
<i>rising </i>edge<i>.</i> The clock frequency must be in the
|
340 |
|
|
range 10 - 16.7 kHz. This means clock must be high for 30 - 50 microseconds
|
341 |
|
|
and low for 30 - 50 microseconds.. If you're designing a keyboard,
|
342 |
|
|
mouse, or host emulator, you should modify/sample the Data line in the
|
343 |
|
|
middle of each cell. I.e. 15 - 25 microseconds after the appropriate
|
344 |
|
|
clock transition. Again, the keyboard/mouse always generates the clock
|
345 |
|
|
signal, but the host always has ultimate control over communication.
|
346 |
|
|
</p>
|
347 |
|
|
|
348 |
|
|
|
349 |
|
|
<p> </p>
|
350 |
|
|
Timing is absolutely crucial. Every time quantity I give
|
351 |
|
|
in this article must be followed exactly.<br>
|
352 |
|
|
<br>
|
353 |
|
|
<b>Communication: Device-to-Host</b><br>
|
354 |
|
|
|
355 |
|
|
<p>The Data and Clock lines are both open collector. A resistor is
|
356 |
|
|
connected between each line and +5V, so the idle state of the bus is high.
|
357 |
|
|
When the keyboard or mouse wants to send information, it first checks
|
358 |
|
|
the Clock line to make sure it's at a high logic level. If it's not,
|
359 |
|
|
the host is inhibiting communication and the device must buffer any to-be-sent
|
360 |
|
|
data until the host releases Clock. The Clock line must be continuously
|
361 |
|
|
high for at least 50 microseconds before the device can begin to transmit
|
362 |
|
|
its data. </p>
|
363 |
|
|
|
364 |
|
|
|
365 |
|
|
<p>As I mentioned in the previous section, the keyboard and mouse use a
|
366 |
|
|
serial protocol with 11-bit frames. These bits are: </p>
|
367 |
|
|
|
368 |
|
|
<ul>
|
369 |
|
|
<li> 1 start bit. This is always 0.</li>
|
370 |
|
|
<li> 8 data bits, least significant bit first.</li>
|
371 |
|
|
|
372 |
|
|
<li> 1 parity bit (odd parity).</li>
|
373 |
|
|
<li> 1 stop bit. This is always 1.</li>
|
374 |
|
|
|
375 |
|
|
</ul>
|
376 |
|
|
The keyboard/mouse writes a bit on the Data line when Clock
|
377 |
|
|
is high, and it is read by the host when Clock is low. Figures 2
|
378 |
|
|
and 3 illustrate this.<br>
|
379 |
|
|
|
380 |
|
|
|
381 |
|
|
<p><font color="#ff0000">Figure 2: Device-to-host communication.
|
382 |
|
|
The Data line changes state when Clock is high and that data is valid
|
383 |
|
|
when Clock is low.</font> <br>
|
384 |
|
|
</p>
|
385 |
|
|
|
386 |
|
|
<blockquote><img src="./The_PS_2_Mouse_Keyboard_Protocol_files/waveform1.jpg" alt="" width="432" height="139">
|
387 |
|
|
</blockquote>
|
388 |
|
|
|
389 |
|
|
<p> </p>
|
390 |
|
|
|
391 |
|
|
|
392 |
|
|
<p><font color="#ff0000">Figure 3: Scan code for the "Q" key (15h) being
|
393 |
|
|
sent from a keyboard to the computer. Channel A is the Clock signal;
|
394 |
|
|
channel B is the Data signal.</font> </p>
|
395 |
|
|
|
396 |
|
|
<blockquote><font color="#ffffff">---</font><img src="./The_PS_2_Mouse_Keyboard_Protocol_files/qscope.JPG" alt="" width="386" height="255">
|
397 |
|
|
<br>
|
398 |
|
|
</blockquote>
|
399 |
|
|
|
400 |
|
|
<p> The clock frequency is 10-16.7 kHz. The time from the rising
|
401 |
|
|
edge of a clock pulse to a Data transition must be at least 5 microseconds.
|
402 |
|
|
The time from a data transition to the falling edge of a clock pulse
|
403 |
|
|
must be at least 5 microseconds and no greater than 25 microseconds.
|
404 |
|
|
|
405 |
|
|
<br>
|
406 |
|
|
</p>
|
407 |
|
|
|
408 |
|
|
<p>The host may inhibit communication at any time by pulling the Clock
|
409 |
|
|
line low for at least 100 microseconds. If a transmission is inhibited
|
410 |
|
|
before the 11th clock pulse, the device must abort the current transmission
|
411 |
|
|
and prepare to retransmit the current "chunk" of data when host releases
|
412 |
|
|
Clock. A "chunk" of data could be a make code, break code, device
|
413 |
|
|
ID, mouse movement packet, etc. For example, if a keyboard is interrupted
|
414 |
|
|
while sending the second byte of a two-byte break code, it will need to
|
415 |
|
|
retransmit both bytes of that break code, not just the one that was interrupted.<br>
|
416 |
|
|
</p>
|
417 |
|
|
|
418 |
|
|
<p>If the host pulls clock low before the first high-to-low clock transition,
|
419 |
|
|
or after the falling edge of the last clock pulse, the keyboard/mouse
|
420 |
|
|
does not need to retransmit any data. However, if new data is created
|
421 |
|
|
that needs to be transmitted, it will have to be buffered until the host
|
422 |
|
|
releases Clock. Keyboards have a 16-byte buffer for this purpose.
|
423 |
|
|
If more than 16 bytes worth of keystrokes occur, further keystrokes
|
424 |
|
|
will be ignored until there's room in the buffer. Mice only store
|
425 |
|
|
the most current movement packet for transmission. </p>
|
426 |
|
|
|
427 |
|
|
|
428 |
|
|
|
429 |
|
|
<p><b>Host-to-Device Communication:</b><br>
|
430 |
|
|
</p>
|
431 |
|
|
|
432 |
|
|
<p>The packet is sent a little differently in host-to-device communication...
|
433 |
|
|
</p>
|
434 |
|
|
|
435 |
|
|
<p>First of all, the PS/2 device always generates the clock signal.
|
436 |
|
|
If the host wants to send data, it must first put the Clock and Data
|
437 |
|
|
lines in a "Request-to-send" state as follows: </p>
|
438 |
|
|
|
439 |
|
|
<ul>
|
440 |
|
|
<li> Inhibit communication by pulling Clock low for at least 100
|
441 |
|
|
microseconds.</li>
|
442 |
|
|
|
443 |
|
|
<li> Apply "Request-to-send" by pulling Data low, then release Clock.</li>
|
444 |
|
|
|
445 |
|
|
</ul>
|
446 |
|
|
The device should check for this state at intervals not to exceed
|
447 |
|
|
10 milliseconds. When the device detects this state, it will begin
|
448 |
|
|
generating Clock signals and clock in eight data bits and one stop bit.
|
449 |
|
|
The host changes the Data line only when the Clock line is low,
|
450 |
|
|
and data is read by the device when Clock is high. This is opposite
|
451 |
|
|
of what occours in device-to-host communication.
|
452 |
|
|
|
453 |
|
|
<p>After the stop bit is received, the device will acknowledge the received
|
454 |
|
|
byte by bringing the Data line low and generating one last clock pulse.
|
455 |
|
|
If the host does not release the Data line after the 11th clock pulse, the
|
456 |
|
|
device will continue to generate clock pulses until the the Data line is
|
457 |
|
|
released (the device will then generate an error.) </p>
|
458 |
|
|
|
459 |
|
|
|
460 |
|
|
<p>The host may abort transmission at time before the 11th clock pulse
|
461 |
|
|
(acknowledge bit) by holding Clock low for at least 100 microseconds.
|
462 |
|
|
</p>
|
463 |
|
|
|
464 |
|
|
<p>To make this process a little easier to understand, here's the steps
|
465 |
|
|
the host must follow to send data to a PS/2 device: </p>
|
466 |
|
|
|
467 |
|
|
<blockquote>1) Bring the Clock line low for at least 100 microseconds.
|
468 |
|
|
<br>
|
469 |
|
|
2) Bring the Data line low. <br>
|
470 |
|
|
3) Release the Clock line. <br>
|
471 |
|
|
|
472 |
|
|
4) Wait for the device to bring the Clock line low.
|
473 |
|
|
<br>
|
474 |
|
|
5) Set/reset the Data line to send the first data bit
|
475 |
|
|
<br>
|
476 |
|
|
6) Wait for the device to bring Clock high. <br>
|
477 |
|
|
7) Wait for the device to bring Clock low. <br>
|
478 |
|
|
|
479 |
|
|
8) Repeat steps 5-7 for the other seven data bits and
|
480 |
|
|
the parity bit <br>
|
481 |
|
|
9) Release the Data line. <br>
|
482 |
|
|
10) Wait for the device to bring Data low. <br>
|
483 |
|
|
11) Wait for the device to bring Clock low. <br>
|
484 |
|
|
|
485 |
|
|
12) Wait for the device to release Data and Clock</blockquote>
|
486 |
|
|
|
487 |
|
|
<p><br>
|
488 |
|
|
<font color="#000000">Figure 3 shows this graphically and
|
489 |
|
|
Figure 4 separates the timing to show which signals are generated by the
|
490 |
|
|
host, and which are generated by the PS/2 device. Notice the change
|
491 |
|
|
in timing for the "ack" bit--the data transition occours when the Clock
|
492 |
|
|
line is high (rather than when it is low as is the case for the other
|
493 |
|
|
11 bits.)</font> </p>
|
494 |
|
|
|
495 |
|
|
<p><font color="#ff0000">Figure 3: Host-to-Device Communication.</font>
|
496 |
|
|
<br>
|
497 |
|
|
|
498 |
|
|
<img src="./The_PS_2_Mouse_Keyboard_Protocol_files/waveform2.jpg" alt="" width="504" height="131">
|
499 |
|
|
</p>
|
500 |
|
|
|
501 |
|
|
<p><font color="#ff0000">Figure 4: Detailed host-to-device communication.</font>
|
502 |
|
|
<br>
|
503 |
|
|
<img src="./The_PS_2_Mouse_Keyboard_Protocol_files/waveform3.jpg" alt="" width="552" height="247">
|
504 |
|
|
<br>
|
505 |
|
|
</p>
|
506 |
|
|
|
507 |
|
|
|
508 |
|
|
<p>Referring to Figure 4, there's two time quantities the host looks for.
|
509 |
|
|
(a) is the time it takes the device to begin generating clock pulses
|
510 |
|
|
after the host initially takes the Clock line low, which must be no greater
|
511 |
|
|
than 15 ms. (b) is the time it takes for the packet to be sent, which
|
512 |
|
|
must be no greater than 2ms. If either of these time limits is not
|
513 |
|
|
met, the host should generate an error. Immediately after the "ack"
|
514 |
|
|
is received, the host may bring the Clock line low to inhibit communication
|
515 |
|
|
while it processes data. If the command sent by the host requires
|
516 |
|
|
a response, that response must be received no later than 20 ms after the
|
517 |
|
|
host releases the Clock line. If this does not happen, the host generates
|
518 |
|
|
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>
|
519 |
|
|
|
520 |
|
|
<br>
|
521 |
|
|
<br>
|
522 |
|
|
<br>
|
523 |
|
|
</body></html>
|