AT Keyboard Interface V1.04

for Microchip PIC16F84  (without LCD)
 

Table of Contents [Toc]

Introduction
   Possible Applications
Concept
   How it works
   Specifications
   Features
   Limitations
AT Keyboard Theory
   Keyboard Scan Codes
   Keyboard to Host Protocol
   Keyboard Commands
   Host to Keyboard Protocol
   Host Commands
Project Resources
   Available PIC Assembler Code
   Schematic, Data Sheets, Pinout
User-specific Customization / FAQ
   How do I use the AT Keyboard Input?
   How does the Scan Pattern Decoding work exactly?
   My own Key Customization
   My own Key Sequence
Confusion about Sweden and Switzerland...?
 

Introduction   [Toc] [Top]

Sometimes you only need a simple and cheap RS232 terminal to get sufficient control over a PC or a RS232 device. There is no need, no space or even no power to place a monitor, a computer case and a keyboard. Maybe there exists also the problem, that the PC or the device is located somewhere else and you want to interact with it over a short distance.

The cheapest way to obtain a complete user interface is the use of standard components, such as LCD modules and PC keyboards. A standard PC keyboard (PS/2 type) costs about US-$ 12, a 2 lines by 40 characters dot matrix LCD module around US-$ 20.
To connect these items to the serial port by cable, a microcontroller and a RS232 level shifter are necessary. For longer distance control, there exists also the possibility to interconnect the terminal with the other device by a wireless physical transmission layer.
 

 

Possible Applications   [Toc] [Top]

The RS232 terminal for instance is very convenient in conjunction with a PC based Juke-Box playing MP3 files. You only need a command line programmable MP3 player (or a player with a supplied Active-X interface) and a software-based connection between player and RS232 port. This software 'connection' could be realized using Visual Basic and the often supplied Active-X interfaces of the various Windows based MP3 players.

Another possible area for applications is PC observed access control. Therefore, the RS232 terminal is placed at the entrance to the supervised area.

A further enhancement to be able to satisfy todays needs for network-based communication would be a complete TCP/IP based communication layer together with an Ethernet front-end. Then it would be possible to control simple Ethernet appliances, e.g. your coffee maker, electrical rolling shutters, autonomous net-based lawn mower,... ;-) by this remote terminal. Brave new world ...
 

 

Concept   [Toc] [Top]

The routine below contains no support for an LCD display. It only shows the complete fetch and decoding of AT keyboard scan patterns and RS232 transmission of ASCII characters to the RS232 client. If you want a PIC 16F84 based solution with additional LCD, have a look at the keyboard v2xx project.

The problem with the PIC 16F84 is the lack of RS232 hardware. The whole keyboard scan pattern fetch, decode and RS232 data transmission is done by software. Additional RS232 data reception has also to be carried out by software - based on interrupts - but is not implemented within this project. The current implementation features a preemptive interrupt-based keyboard scan pattern acquisition.

A recent picture of my workplace connecting a Microsoft PS/2 AT keyboard to the PIC16F84.

An elderly picture of my workplace, at which the initial development took place.

How it works   [Toc] [Top]

Any key stroke on the local keyboard will send the corresponding scan patterns from the keyboard to the PIC microcontroller. Afterwards, the microcontroller converts the keyboard scan patterns to ASCII characters and transmits them to the RS232 target device.
The keyboard scan code capture is done by an interrupt service routine (ISR). The event, which triggers the interrupt is a falling edge on the keyboard clock line (PORTB,0). Keyboard scan pattern acquisition takes place at the keyboard data line (PORTA,4). After 11 clocks (i.e. 11 external interrupts on RB0/INT), the interrupt service routine has completely captured an 8 bit element of the entire scan pattern and sets a ready flag. The decoding of this 8 bit element is then carried out during normal operation mode, activated by a valid ready flag whilst keeping the keyboard stalled (keyboard clock line low).

The fact, that the scan pattern acquisition is carried out using an interrupt service routine and the decoding thereof is done during normal operation mode allows for performing other tasks concurrently: That's why I call the acquisition methodology preemptive, it does not block the processor in the main loop while acquiring keyboard data - therefore passing processing resources to other services. Explicitely, it works as follows:
After proper acquisition, the corresponding flag KBDflag is set (at the end of the ISR) and the decoded keyboard character resides in the register KBD. The KBDflag is cleared at the end of the service routine KBDdecode.

        ;******************************
_MLOOP  btfsc   KBDflag      ; check scan pattern reception flag
        call    KBDdecode    ; if set, call decoding routine
        ;btfsc   your_other_flag
        ;call    your_other_service
        goto    _MLOOP
        ;******************************

Only RS232 transmission is supported by this program, since PORTB,0 interrupt is already used by the keyboard clock line. There exists no possibility to implement also RS232 reception using my modules m_rsxxx.asm, because they require PORTB,0 as well and are laid out as non-preemptive data acquisition routines (see also 'Limitations').

For dedicated code adaptations, please refer to the section 'User-specific Customization' below.
 

Specifications   [Toc] [Top]

Features   [Toc] [Top]

• Uni-directional communication between microcontroller application and remote RS232 client.
• Uni-directional communication between microcontroller and keyboard.
• Support for all keyboard characters typed with shift button active and inactive.
• English and modified Swiss-German 'codepages' available (QWERTY and QWERTZ)
• Caps Lock implemented
• Num Lock always active
• Possibility to implement short-cuts or user defined characters for 'Esc', 'Num Lock', 'Scroll Lock' and 'F1' - 'F12' keys.
• Further enhancement, not implemented: Support of ASCII conversion from direct ALT-DEC and CTRL-HEX entries, e.g. ALT + 6 + 4 = @ or CTRL + 3 + F = ?

To visualize the ASCII data sent by this microcontroller application, use a terminal program like the Windows Hyperterminal. Below an example session, which proves the correct functionality of the keyboard interface. This terminal program and the Excel 97 RS232 Debug Interface have been used to debug the interface during implementation time.

Example of a session using the Windows HyperTerminal. The entire contents was sent by the PIC controller.
 

Limitations   [Toc] [Top]

In case you want RS232 reception and keyboard decoding simultaneously on a single PIC 16X84, you'll have to configure either the keyboard clock line or the RS232 reception data line (both targeting PORTB,0 interrupt) to another separate interrupt source (e.g. PORTB,4 - PORTB,7 change interrupt) and to alter the RS232 data fetch routine to a preemptive one. But then you'll also run into troubles by using the LCD modules, because they are written to work on entire 8 bit ports (such as PORTB on 16X84, and PORTC & PORTD on 16X74).
So if you really appreciate to run the RS232 terminal entirely on a PIC 16X84 - from a technical perspective it is possible - you'll have to rewrite the LCD modules and the software RS232 reception routine. Be aware that there won't be a lot of code space remaining for other enhancements after putting all terminal related stuff onto the 16X84.

A workaround to get RS232 reception on the PIC 16X84 using this software could be a solution based on polling. But make sure you are polling fast enough, also in worst case.

Note from the author:

The comment above refers to bi-directional communication between PIC microcontroller and AT keyboard, i.e. to the source code of the AT Keyboard Interface V2.xx and higher versions. The bi-directional communication between host and keyboard is designed to support both Ack bits and Ack bytes.

• Every command sent from the host to the keyboard needs to have an Odd Parity bit and an Ack bit at the end.
• Every command received by the keyboard from the host needs to be acknowledged by the keyboard by sending an Ack byte (0xFA) to the host. See also section 'Host to Keyboard Protocol'.

A corresponding PIC assembler code example is shown below:

   ;*** switch keyboard LEDs on (default status) ***
    KBDcmd 0xED       ; keyboard LEDs' control command
    KBDexp 0xFA       ; expect keyboard acknowledge (FA)
    movfw  KBDleds    ; load keyboard LEDs' status
    KBDcmdw           ; send keyboard LEDs' control data
    KBDexp 0xFA       ; expect keyboard acknowledge (FA)

However, some AT keyboards may behave different and may need code adaptations to get bi-directional communication working properly.

AT Keyboard Theory   [Toc] [Top]

A complete functional description and timing diagram of the AT keyboard is available at Craig Peacock's website. Please refer to his website Interfacing the PC's Keyboard for an excellent and comprehensive description of all features and commands of the AT keyboard. At this place, I want to thank Craig Peacock for his outstanding work with his website.
Below I only want to sketch the most important technical aspects to be known when interfacing a PC's keyboard. Small parts of the introduction below are more or less copied from Craig Peacock's tutorial.
 

Keyboard Scan Codes   [Toc] [Top]

The diagram below shows the scan codes assigned to the individual keys for the english keyboard layout. The keys' corresponding scan codes are the numbers on the keys, for example the scan code of the ESC key is 0x76. All scan codes are shown in hexadecimal representation.
 

 
The scan code assignments are quite random (thanks to IBM and other early computer manufacturers) and appear to be really weird sometimes, for instance the break key. In many cases the easiest way to convert the scan code to ASCII characters would be to use a lookup table. Below are the scan codes shown for the extended part of the keyboard and the numeric keypad.

Cite of Craig Peacock: "How about E1,14,77,E1,F0,14,F0,77! Now that can't be a valid scan code? Wrong again. It 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?"

By the way, AT stands for Advanced Technology...
 

The AT keyboard sends different scan codes on pressing, holding and releasing of each button. An example is given at the table below:

 
All scan patterns can easily be visualized and verified with the AT Scan Code Debug Routine and the RS232 Debug Interface.
 

Keyboard to Host Protocol   [Toc] [Top]

The data transfer is implemented as bi-directional protocol: The keyboard can send data to the host (microcontroller) and the host can send commands and data to the keyboard. The host has the ultimate priority over the direction. It can at anytime (although not recommended) send a command to the keyboard.

The keyboard is free to send data to the host when both KBD data and KBD clock lines are high (idle). The serial clock is generated by the keyboard, but the host can also use it 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, i.e. goes high. Should the host take also 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, i.e. 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 has to be read on the falling edge of the clock.
 

AT keyboard to host protocol, with odd parity bit
 

Keyboard Commands   [Toc] [Top]

Once the host commands are sent from the host to the keyboard, the keyboard commands must be
sent from the keyboard to the host. If you think this way, you must be correct. Below details of some of
the commands which the keyboard is able to send.

Host to Keyboard Protocol   [Toc] [Top]

The host to keyboard protocol is initiated by taking the KBD data line low. However to prevent the keyboard from sending data at the same time that you attempt to send the keyboard data, it is common to take the KBD clock line low for more than 60 us. This is more than one bit length. Then the KBD data line is taken low, while the KBD clock line is released. The keyboard will start generating a clock signal on its KBD clock line. This process can take up to 10 ms. After the first falling edge has been detected, you can load the first data bit on the KBD data line. This bit will be read into the keyboard on the next falling edge, after which you can place the next bit of data. This process is repeated for all 8 data bits. After the data bits comes an odd parity bit.
 

Host to AT keyboard protocol, with odd parity bit and acknowledge
 

Odd parity = NOT(XOR(bits[0..7]))

Once the parity bit has been sent and the KBD data line is in a idle state (high) for the next clock cycle, the keyboard will acknowledge the reception of the new data. The keyboard does this by taking the KBD data line low for the next clock transition. If the KBD data line is not idle after the 10th bit (start, 8 data bits, and parity bit), the keyboard will continue to send a KBD clock signal until the KBD data line becomes idle (Note: see also Limitations).
 

Host Commands   [Toc] [Top]

These commands are sent by the host to the keyboard. The most common command would be the setting/resetting of the status indicators (i.e. the Num lock, Caps Lock & Scroll Lock LEDs). The more common and useful commands are shown below.

Please refer to Craig Peacock's website for more information: Interfacing the PC's Keyboard
 

Project Resources   [Toc] [Top]

Available Microchip PIC Assembler Code   [Toc] [Top]

Schematic, Data Sheets and Pinout   [Toc] [Top]

AT Keyboard Specification (PDF, 189 kB)

The schematic of the AT keyboard interface using the PIC 16F84:   Keyboard_V1xx.pdf.

You don't know how a dot matrix LCD is working? Have a look at my data sheets page.

Download ASCII Character Map: ASCII-Map.pdf

You can get the pinout and a description of the various keyboard connectors <here>.
 

User-specific Customization / FAQ   [Toc] [Top]

This section covers important details of the code structure. For a high level view, please refer to the section 'How it works' above. Basically, I have written this keyboard project in such a way that it is completely customizable depending on your programming/PIC assembler skills.
 

How do I use the AT Keyboard Input?   [Toc] [Top]

Question: I'm running your AT Keyboard code. But how do I use the decoded input of the AT keyboard...?

Answer: The decoded content resides usually in the register KBD. You can use the content of this register in the main routine in the infinitive loop. Please see the section 'How it works' above.
 

How does the Scan Pattern Decoding work exactly?   [Toc] [Top]

Question: How does your AT scan pattern decoding work exactly? You are using two strange look-up tables...

Answer: Have a look at some parts of the 'AT Keyboard Lookup Table', e.g. the eng_main.asm (QWERTY):

The simple lookup table decoding is done with retlw x and DT x. These directives just return the corresponding ASCII character. The more sophisticated decoding is done with subroutines, i.e. goto _XYZ. This means for instance that for a ENTER/RETURN key hit on the keyboard, the subroutine _CRLF is executed (carriage return, line feed) and for ALT, CTRL, SHIFT and CAPS_LOCK, the corresponding flags are set in their corresponding subroutines.

Because the keyboard sends slightly different scan patterns for both, key hit and key release, there is need for a key release handling. This is done with the so-called release flag. So for every single character typed, the interrupt service routine is called twice (due to two different scan codes for hit and release) and the scan pattern decoding routine is executed twice.

There are these four main code blocks in the keyboard assembler source:

1. Interrupt based keyboard scan pattern acquisition
2. Keyboard scan code pre-decoding, set / clear flags
3. Scan code range checking (consistency checks)
4. Scan code decoding (look-up tables) & ASCII character conversion and output (LCD, RS232)

To save code space, I've implemented the two look-up tables (main and shift) as follows:

• Small letters (a-z) are translated directly with the main look-up table, capital letters (A-Z) are obtained by simply adding d'224' (8 bit unsigned wrap-around) to the main look-up table results of small letters. Active shift button of the keyboard is only tracked by the shift flag.
• Shift table is only used for special character conversion, e.g. +, %, &, (, ), ?
• Compression is also applied to lookup sections, where scan patterns are quite distant, e.g. for the entire keyboard num-block (keypad).

If you apply changes to the existing code, you may need to change the ORG directives in order to realign the assembler code properly, due to the different lookup tables and the PIC page boundaries.
 

My own Key Customization   [Toc] [Top]

Question: I have built successfully your AT keyboard project and it is running very well.
Now I want to customize my code such as to print out a predefined phrase e.g. 'Hello World' whenever I hit a specific key...?

Answer: This is not a difficult task, if you just use one specific key, for instance F9.
(For sequences like 'asdf', you must write your own detection routine for the main loop by checking the values in register KBD.) First look at the look-up tables (LUT), for instance the eng_main.asm (QWERTY):

It is essentially a LUT which performs the decoding of the acquired keyboard scan codes into characters. At the top, the entries for the F1-F12 function keys are located.
If you want a specific text to be displayed by pressing F9, change the line
  retlw A'9' ; F9 -> 9 0x01

KBDtable ; (not used for characters typed with shift button active)
        addwf   PCL,F
        retlw   0       ; invalid entry
        retlw   A'9'    ; F9 -> 9       0x01
        retlw   0       ; 
        retlw   A'5'    ; F5 -> 5

to
  goto _MyRoutine

KBDtable ; (not used for characters typed with shift button active)
        addwf   PCL,F
        retlw   0       ; invalid entry
        goto    _MyRoutine ; NEW: user-specific decoding for F9
        retlw   0       ; 
        retlw   A'5'    ; F5 -> 5

Then you implement your own key-specific handler/subroutine _MyRoutine in the main file (section sub-routines), which displays your string, e.g. something like:

_MyRoutine
        SENDw    'H'    ; send to RS232
        SENDw    'e'
        SENDw    'l'
        SENDw    'l'
        SENDw    'o'
        SENDw    ' '
        SENDw    'W'
        SENDw    'o'
        SENDw    'r'
        SENDw    'l'
        RETLW    'd'    ; return with last character in w
; alternative termination:
;       SENDw    'd'
;       RETLW    0      ; clear w to obtain invalid entry

You can do anything in this routine, just terminate with a RETLW 0 and ensure not to change any reserved registers...
If you want to alter the output for the keyboard characters in general, look at the the '_OUTP' section in the assembler source file kbd_1xx.asm:

_OUTP  ;*** RS232 ***
       movfw    KBD
       SENDw            ; send actual pressed keyboard character
       goto _ClrStall

There, the acquired keyboard character (in KBD) is sent to the RS232 interface.
If having a LCD display, the value of KBD might also be displayed using:

_OUTP  ;*** LCD & RS232 ***
       movfw    KBD
       LCDw             ; display keyboard character on LCD
       movfw    KBD
       SENDw            ; send actual pressed keyboard character
       goto _ClrStall

This is roughly what is done in the '_OUTP' section in the assembler source file kbd_2xx.asm.
 

My own Key Sequence   [Toc] [Top]

Question: I have built successfully your AT keyboard project and it is running very well.
Now I want to customize my code such as to detect a specific key sequence, e.g. 'asdf'. Is this feasible...?

Answer: This is a more challenging task. (Alternatively, consider to just use one specific key e.g. F9 as described above.)
You need to write your own subroutine in the main loop in order to detect the desired character sequence. The keyboard character is usually passed within the register KBD.

        ;******************************
_MLOOP  btfsc   KBDflag      ; check scan pattern reception flag
        call    KBDdecode    ; if set, call decoding routine
        ;btfsc   your_other_flag
        ;call    your_other_service
        goto    _MLOOP
        ;******************************

Confusion about Sweden and Switzerland...?   [Toc] [Top]

Do you know Microsoft? Are you a global player, too? Or do you travel sometimes to Europe?
Did it happen to you, that you ended up in Stockholm instead of Zurich?

Don't worry, even Microsoft is confused by the two european countries, Sweden and Switzerland.
You are excused as well if you mix this up...

Microsoft Wired Keyboard 500 I recently bought two cheap, but nice Microsoft PS/2 keyboards - before PS/2 products are fading out. Microsoft obviously does not know the difference between Sweden and Switzerland: They supplied a skandinavian manual (swedish, norwegian, danish, finnish) instead of a central europe one (german, french, italian, english). Ok, it could have been worse: they could have shipped a japanese keyboard layout...

Last updated: 2006/04/23