Why would you want to interface the Keyboard? The IBM keyboard can be a cheap alternative to a keyboard on a Microprocessor development system. Or maybe you want a remote terminal, just couple it with a LCD Module.
Maybe you have a RS-232 Barcode Scanner or other input devices, which you want to use with existing software which only allows you to key in numbers or letters. You could design yourself a little box to convert RS-232 into a Keyboard Transmission, making it transparent to the software.
An interfacing example is given showing the keyboard’s protocols in action. This interfacing example uses a 89s51 MCU to decode an IBM AT keyboard and output the ASCII equivalent of the key pressed at 9600 BPS.
Note that this page only deals with AT Keyboards. If you have any XT keyboards, you wish to interface, consider placing them in a museum. We will not deal with this type of keyboard in this document. XT Keyboards use a different protocol compared to the AT, thus code contained on this page will be incompatible.
PC Keyboard Theory
The IBM keyboard you most probably have sitting in front of you, sends scan codes to your computer. The scan codes tell your Keyboard Bios, what keys you have pressed or released. Take for example the ‘A’ Key. The ‘A’ key has a scan code of 1C (hex). When you press the ‘A’ key, your keyboard will send 1C down it’s serial line. If you are still holding it down, for longer than it’s typematic delay, another 1C will be sent. This keeps occurring until another key has been pressed, or if the ‘A’ key has been released.
However your keyboard will also send another code when the key has been released. Take the example of the ‘A’ key again, when released, the keyboard will send F0 (hex) to tell you that the key with the proceeding scan code has been released. It will then send 1C, so you know which key has been released.
Your keyboard only has one code for each key. It doesn’t care it the shift key has been pressed. It will still send you the same code. It’s up to your keyboard BIOS to determine this and take the appropriate action. Your keyboard doesn’t even process the Num Lock, Caps Lock and Scroll Lock. When you press the Caps Lock for example, the keyboard will send the scan code for the cap locks. It is then up to your keyboard BIOS to send a code to the keyboard to turn on the Caps lock LED.
Now there’s 101 keys and 8 bits make 256 different combinations, thus you only need to send one byte per key, right?
Scan Codes
The diagram below shows the Scan Code assigned to the individual keys. The Scan code is shown on the bottom of the key. E.g. The Scan Code for ESC is 76. All the scan codes are shown in Hex.
A fifth wire can sometimes be found. This was once upon a time implemented as a Keyboard Reset, but today is left disconnected on AT Keyboards. Both the KBD Clock and KBD Data are Open Collector bi-directional I/O Lines. If desired, the Host can talk to the keyboard using these lines.
The Keyboard’s Protocol
As mentioned before, the PC’s keyboard implements a bi-directional protocol. The keyboard can send data to the Host and the Host can send data to the Keyboard. The Host has the ultimate priority over direction. It can at anytime (although the not recommended) send a command to the keyboard.
The keyboard is free to send data to the host when both the KBD Data and KBD Clock lines are high (Idle). The KBD Clock line can be used as a Clear to Send line. If the host takes the KBD Clock line low, the keyboard will buffer any data until the KBD Clock is released, ie goes high. Should the Host take the KBD Data line low, then the keyboard will prepare to accept a command from the host.
The transmission of data in the forward direction, ie Keyboard to Host is done with a frame of 11 bits. The first bit is a Start Bit (Logic 0) followed by 8 data bits (LSB First), one Parity Bit (Odd Parity) and a Stop Bit (Logic 1). Each bit should be read on the falling edge of the clock.
http://www.mytutorialcafe.com/Microcontroller%20Project%20Thesis%20PC%20Keyboard.htm
JEFRI DS SIANTURI 