Specifications

Functionality
Main Loop
After power-up housekeeping is performed, the main loop of the PS/2 firmware is entered. This loop invokes the keyboard
scanning task at periodic (4msec) intervals and sends to the host any key presses that were detected, and also checks for
the presence of a host command request. Command requests are honored immediately: the firmware receives and parses
the command and invokes the proper subroutine to perform the command and return any required data to the host. See
Figures 22 and 23.
Scan Task
The reference firmware scans the key matrix approximately once every 4mS. This timing is generated from the 1mS interrupt
service routine, which increments a 1-msec count variable upon each invocation. On each pass through the Main Loop, the
1 msec count variable is checked and, if 4 ms has passed, a call to ps2_scan_keys is made and the 1-msec count variable
is reinitialized to 0. Key presses and releases identifed by the key-scan code are reported back to the PS/2 interface
processing code by a call to the currently active scan-code conversion routine. The PS/2 scan conversion routine converts
the key information into the current scan (1, 2, or 3) code, and places the resultant key codes into a 16-element circular
buffer. Some key changes generate key codes up to 8 bytes in length. If there is not enough room in the buffer for the entire
code, the code for that key is discarded and a 1-byte overflow code is placed in the buffer instead. One element of the buffer
is always reserved for this potential error code. After the matrix scanning routine completes, ps2_scan_keys will insert an
overflow code in the key buffer if global key errors such as phantom keys (discussed below) are detected.
PS/2 Command Processing
On each pass through the main loop, the firmware calls function ps2_get_byte to check for the initiation of a transaction
from the host. This is identified by a start condition, with the PS2 clock line high and the PS2 data line low. Upon recognition
of the host transmit request, ps2_get_byte proceeds to complete the byte transaction with the host, receiving the new data
byte, before returning to the main loop. The new byte is then passed off to the command processor, ps2_do_command. Any
additional parameter bytes associated with the command are then handled directly from the command processor by calls to
ps2_get_byte.
Keyboard Scanning Details
Debounce
The mechanical switch properties of the key switches cause them to bounce after a key press. These bounces may be
mistaken for actual key events. See Figure 18.
Figure 2. Key Switch Bounce
To solve this problem, all keys that are pressed or released have their code stored in a Debounce FIFO (the reference
firmware uses a 6-element FIFO). This FIFO is transparently maintained within the generic key matrix scanning routine.
As the routine executes, keys whose state has changed are searched for in the FIFO. If the key’s code is not already in the
FIFO, it is placed there, indicating that this is the initial state change, either as the key was pressed or released. At the time
the key is entered in the FIFO, a counter is initialized which is counted down on subsequent calls to the key matrix scanning
routine and thus keeps track of how long the key has been in the FIFO. When the count is exhausted, the key is removed
from the FIFO. Thus, a key ‘s code is present in the FIFO from the time it is initially pressed, to some predetermined count
(the debounce interval) afterwards. During this interval, key state changes for keys in the FIFO are considered to be caused
by switch debounces, and are ignored.
The reference firmware uses a value of 3 for the debounce count when a key is initially depressed, and 1 when the key is
released. Since the key matrix scanning interval is called every 4 msec, the debounce interval for key press is thus 12 msec,
and for releases is 4 msec. In other words, any status change for 12 msec after a key is pressed, or 4msec after a key is