I'm new to this forum.  Will add one implementation on keypad/switch
debouncing.  It probably is disconcerting for a newbie to realize switches
require debouncing.  Life's tough!

The customer's design consisted of all TTL parts for an emulator he wanted
for his own use.  My take on it was to use a PIC on the Display/Keypad (D/K)
board to handle the LED multiplexing and keypad 'scanning'.  Another board
was used for a 'Control section'; some 50 ICs which got pared down to
another PIC, a CPLD and about 19 TTL (to i/f with the TTL and other parts on
the Pod board).  The communications between the D/K and Control was the
USART.

The LED segments were driven by RD0 - RD7 (including the decimal points)
through 100 ohm resistors and each LED from RA0 - RA5 via a FET.  Each LED
was on for 2 ms; for the 6 LEDs this provided a 83 Hz refresh rate.  Fast
enough to appear 'solidly on' and no glitching.

Just before turning on a next LED, the RD and RA lines were put LOW (turning
the LEDs off), and the RB lines were checked for any line low (a key down
state).

The keypad array consisted of 28 keys in 7 rows x 4 columns.  PIC lines RD0
- RD6 drove the rows.  When a key was sensed down, a counter was decremented
for 10 LED scan intervals.  If the keydown state remained without changing
for the 10 counts (20 ms), it was considered valid.

A valid keydown 'scan' then took place to determine which of the 28 keys was
pressed.  The unary of row and column was converted to a binary value; 00h -
0Fh for the hex keys, 10h - 1Bh for the 'command' keys.  The keydown value
was then output via the USART.  The LEDs then were continued to be refreshed
from where it left off prior to scanning for keydown.

Harley Shanko 
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist