Hola

05/11/2010

Interfacing the PC's Keyboard.
Membranes Keypads Custom Keypad and Switch. Unique ClickTouch Technology! www.clicktouchamerica.com Seal Shield Washable Keyboards Mice TV Remotes 100% Waterproof! Dishwasher Safe! www.SealShield.com
Friday, 5th, 2010 November Keypad by ACT Components Custom and Standard Rubber Keypads, Membrane Switches and Assemblies www.actcomponents.comUniversal Serial Bus Embedded Internet Legacy Ports Device Drivers Miscellaneous

Interfacing the AT keyboard.
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 youwant 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 68HC705J1A MCU to decode an IBM AT keyboard and output the ASCII equivalent of thekey 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 probablyhave 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 keepsoccurring 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 keyboardonly 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 yourkeyboard 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? Nop. Unfortunately a handful of the keys found on your keyboard are extended keys, and thus require two scan code. These keys are preceded by a E0 (hex). But it doesn't stop at two scan codes either. How aboutE1,14,77,E1,F0,14,F0,77! Now that can't be a valid scan code? Wrong again. It's happens to be sent when you press the Pause/break key. Don't ask me why they have to make it so long! Maybe they were having a bad day or something? When an extended key has been released, it would be expect that F0 would be sent to tell you that a key has been released. Then you would expect E0, telling you it was anextended key followed by the scan code for the key pressed. However this is not the case. E0 is sent first, followed by F0, when an extended key has been released.

Keyboard Commands
Besides Scan codes, commands can also be sent to and from the keyboard. The following section details the function of these commands. By no means is this a complete list. These are only some of the more common...