# Keyboard and display multiplexing - the traditional approach

Aubrey Kagan

Embedded

Webster’s Dictionary defines “multiplex” as “many” or “multiple”. Coincidentally, in an electronics context the word can have several meanings. Whilst they all share the intention to economize on the number of connections used, there are subtle differences. It can mean combining messages on to a single communications channel for transmission and reception. In a similar vein, it can also mean configuring several continuous inputs (either digital or analog) so that only one is accessed at a time. It can also mean the technique of configuring displays and keyboards/switches in a matrix in order to reduce the number of I/O lines used in hardware. This article is about the last option.

If you had 12 switches and you wanted to monitor each one individually, you would need 12 I/O (only input). Multiplexing will allow you to reduce that. If you configure it as a 6 × 2 matrix, this would require only eight (6+2) I/O pins, or if you altered the approach to a 3 × 4 (as shown in Figure 1) you would be down to seven I/O pins.

 Figure 1. A 4 × 3 matrix for 12 switches.

Signals Out0 to Out3 are normally at logic high. A logic low signal is moved sequentially through these outputs and at each stage the inputs In0 to In2 are inspected. If any of switches in a particular column are closed, the corresponding input reads zero and so you know which switch is pressed. It is possible to reduce the number of I/O line from the controller by using decoders. You could get the four driver lines by using a 2-to-4 line decoder to drive the switch matrix. This works very well up to the point that you have two keys in the same row closed, and then the low signal is fed back possible creating a false closed signal and more importantly loading the outputs that are at a logic one. The way around this is to insert a diode in series with the switch. This technique can be used on any kind of switch including ones that are not momentary by nature. You can see an example of using the diodes together with some thumbwheel switches in Figure 2.

 Figure 2. The micro enables each BCD switch in turn by activating each transistor. Where a switch is closed the associated micro input is pulled low and the micro can read the setting on each BCD (or hexadecimal) switch in turn.

There are specialized controllers like the ancient 74C922, as well as sophisticated keyboard controllers like the TCA8418 or the ADP5585, but since IBM started doing this with a dedicated microcontroller way back when, it seems to me that most people do this with their own micro/FPGA, especially since the I/O pin counts have increased significantly with package density.

Driving displays works in a very similar fashion. You could be driving individual LEDs or an LED 7-segment display, but you are not limited to that. There are “starburst” (14 segment) displays (that allow for alphanumeric output), and they don’t even have to be implemented in LED technology: Vacuum Fluorescent Displays are one such alternative. Often characters are grouped into a single module taking advantage of the multiplexing technique. Let me discuss a four digit 7-segment approach which can be extrapolated in any direction. See Figure 3.

 Figure 3. Two two-digit common cathode 7-segment modules connected for a four digit multiplexed display. Note that you may need drivers on both the “DIGITx” outputs and “SEG_X” inputs and depending on the drivers you may not need resistors. You can achieve a similar arrangement using common anode displays.

The principle of operation here is that the desired segments of each digit are illuminated in turn. Because of the persistence of vision in the human eye, the image appears to be there for some time after it has gone. If the image is refreshed at a frequency that is fast enough it appears to be permanently on. A minimum refresh cycle of 50 Hz is considered sufficient, but at the lower end you may still detect a flicker out of the corner of your eye, so I normally aim for at least 60 Hz. The intensity of the LED to the eye is proportional to the time that it is on. So if the digit is on for a quarter of the time, the current must be four times the value needed for a static display so that the average current is the same. There is a potential problem here. If you look at the display data sheet (MAN6400, in our example), there is a peak current for a particular on time that you cannot exceed without damaging the LEDs (Figure 3). With four digits this may not be a problem, but as you increase the number of digits, the current you must supply must increase, and this could limit the number of digits. There is yet another consideration to evaluate: The maximum continuous current is significantly less than this peak current (30 mA from the data sheet) and if you are implementing the scan within you micro and during development the execution halts with one of the digits on, a current above 30 mA will fry the display. You have been warned! All of this presumes that the micro can supply and sink sufficient current.

To both reduce I/O lines and to reduce computing time there are decoders that will convert a particular BCD code to 7-segment (see the prehistoric 7447) or even 14-segment outputs (like the Maxim 6995). There are still plenty of display drivers like the MAX7219 and some like the aforementioned MAX6995 integrate a keyboard controller as well. But many of us economize on the hardware and create the whole interface on a micro. There are app notes aplenty on the topic from Microchip and Atmel, for example. Cypress even has a User Module (IP) for 7-segment drivers for all the PSoC families. The method for driving dot-matrix displays is no different, although the character lookup is a little more complicated, and normally there are a lot more columns so the duty cycle goes down.

This was the state of play up until the mid-90s (that is the 1990s for you cheeky young whippersnappers). Join me in Part 2 when we turn to Charlieplexing to reduce the number of I/O pins needed. Isn’t it ironic that just when the number of I/O pins start going up because of package sizing, a technique appears to reduce the number of pins required.

embedded.com