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.
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 …
How it works
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.
Infinitive main loop to acquire keyboard input (keyboard_v1xx.asm), keyboard data is in 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 ;******************************
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.
|Processor:||Microchip PIC 16F84|
|Clock Frequency:||4 MHz crystal|
|RS232 Baud Rate:||9600 baud, 8 bit, no parity, 1 stopbit|
|Code Size of entire Program:||523 instruction words|
|Keyboard Routine Features:||Capability of uni-directional communication between microcontroller and keyboard|
|Acquisition Methodology:||Preemptive, interrupt-based keyboard scan pattern acquisition, decoding to ASCII characters during normal operation mode activated by ready flag|
|Required Hardware:||AT keyboard, PS/2 connector, MAX232|
|Required Software:||RS232 terminal software (or Excel 97 RS232 Debug Interface)|
- 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.
For more detail: AT Keyboard Interface V1.04 using PIC16F84