📄 the ps-2 mouse-keyboard protocol.htm
字号:
<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>8 data bits, least significant bit first.
<LI>1 parity bit (odd parity).
<LI>1 stop bit. This is always 1.
<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>8 data bits, least significant bit first.
<LI>1 parity bit (odd parity).
<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 height=139
src="The PS-2 Mouse-Keyboard Protocol_files/waveform1.jpg" width=432>
</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 height=255
src="The PS-2 Mouse-Keyboard Protocol_files/qscope.jpg" width=386>
<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></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>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 height=131
src="The PS-2 Mouse-Keyboard Protocol_files/waveform2.jpg" width=504> </P>
<P><FONT color=#ff0000>Figure 4: Detailed host-to-device
communication.</FONT> <BR><IMG height=247
src="The PS-2 Mouse-Keyboard Protocol_files/waveform3.jpg" width=552>
<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. </P>
<P></P>
<UL>
<UL></UL></UL>
<P></P>
<BLOCKQUOTE></BLOCKQUOTE><B>Other Sources / References:</B>
<UL>
<LI><A
href="http://govschl.ndsu.nodak.edu/~achapwes/PICmicro/index.html">Adam's
micro-Resources Home</A> </LI></UL><BR></TD></TR></TBODY></TABLE>
<CENTER></CENTER>
<CENTER></CENTER>
<P><BR></P>
<P><B></B></P><BR></BODY></HTML>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -