As cell phones and other portable handheld devices continue to add features, design trade-offs are constantly evolving. Popular features such as text messaging and web browsing demand more data entry, but that can be cumbersome with traditional dual tone multiple frequency (DTMF) (0-9, #, *) keypads. Using this type of keypad requires multi-tap data entry, which is inefficient and error-prone. One option to make text entry easier is to use a QWERTY keypad (Figure 1). This type of keypad employs 40 or more keys versus the normal 12 in a DTMF handset, although the additional keys make the handset larger and involve more electronic components.

Text message users may be willing to trade size for a QWERTY keypad; text entry is much easier and you can use two thumbs to enter text messages or data. Recently, some cell phone manufacturers have released handsets with QWERTY keypads that cater to text users.

There are many ways to design data entry keypads, but no standard exists. In this article, we’ll examine one possible solution to the design challenge of adding additional keys to a traditional DTMF-type keypad.

QWERTY Building Blocks
Our solution uses a Xilinx® CoolRunner™-II CPLD; its low power, small package options, and low cost make it an ideal candidate for this application.

Going from a DTMF to a QWERTY keypad requires more keys and thus more general-purpose I/O (GPIO). For instance, a DTMF keypad may have only four rows and three columns, whereas a QWERTY keypad may have as many as eight rows and eight columns. But keypad size can vary depending on the requirements of the end system.

Typically, a processor or DSP is used as an interface to the keypad’s rows and columns (see Figure 2). The processor scans the rows and monitors the columns for a logic change. When a change occurs, it indicates that the user pressed one of the buttons. By knowing which row was being scanned and which column changed state, the processor can deduce which specific button was pushed.

Expanding I/O
When designing keypads that require more I/O (as is the case with a QWERTY keypad), you may find that your existing processor does not have enough GPIO. A possible solution is to use a CPLD as an I/O expander to reduce the number of I/Os required from the processor.

Figure 3 introduces a CPLD in between the processor and keypad where one side of the CPLD interfaces to the keypad rows/columns and the other side interfaces to the processor’s available GPIO. In this example, an 8 x 8 keypad requires the same number of processor GPIO ports as the 4 x 4 keypad (actually one less) when using a CPLD. Without the CPLD, the processor would require 16 GPIO ports instead of 7.

Scanning and Encoding
In addition to reducing the processor’s GPIO requirements, the CPLD can offload some of the processor functions, such as scanning the rows and monitoring the columns for a change in state. When the user presses a key, the CPLD stops scanning and immediately produces an encoded word, which is sent to the processor. The encoded word lets the processor know which key was pressed. This will reduce processor I/O requirements because an encoded word is used to convey which button is pressed to the processor.

In the example shown in Figure 3, six bits are used to represent the encoded word. Six bits provide 26 or 64 different values, each representing a different key. However, one value must represent the state when no keys are pressed. So really, only 63 keys can be represented in this example (without adding an additional GPIO).

The processor does not need to scan the keypad because this is being performed by the CPLD; however the processor is still required to monitor for changes on its GPIO – only it would not need to deduce which key was pressed because the information is encoded in a 6-bit word.

Switch debounce is also needed. It can be designed in the CPLD or the processor, depending on which device has available resources. Performing this in the processor will keep the size and cost of the CPLD to a minimum.

Summarizing this design example, the CPLD scans the keypad for a pressed key and provides an encoded word to the processor to read and interpret. This function not only offloads the processor from scanning but expands the GPIO.

The design fits nicely (~75% utilization) in a CoolRunner-II 32-macrocell device, leaving ~25% headroom for other possible functions. Plus, there are additional design ideas that can reduce power and make use of CoolRunner-II powersaving features.

CPLD Design Details
To scan the keypad rows, a barrel shift register is initialized with all ones, except for a single bit preset to zero. Each bit of the shift register drives an output pin of the CPLD that is connected to a row of the keypad. As the shift register is clocked, the zero bit shifts through the barrel shifter and scans the rows by driving them low one at a time. The keypad columns are inputs to the CPLD and each input is pulled up through an internal pull-up resistor.

When no keys are being pushed, all column inputs to the CPLD are passively pulled up to logic high. All the column inputs are AND’d together and a logic one at the output indicates that no keys are being pressed.

The output of the AND is used as an enable to the shift register. When a key is pressed, the connection between the row and column is made and the column with the key being pressed is driven low by the row associated with that key. The output of the AND will go low and disable the shift register when the key is pressed.

At this point the shift register is driving the row of the key being pressed to a low, and the column of that key is also at a low. To correlate this information, two encoders are used: one for the row bits (outputs of the shift register) and another for the column inputs. The outputs of the two encoders are grouped together to form the encoded word that is sent to the processor. Figure 4 shows a block diagram of the operation.

Conclusion
By using Xilinx CoolRunner-II CPLDs, you get design flexibility and low power. Besides I/O expansion, other “glue” functions can be absorbed into the CPLD, such as voltage translation, I/O standards translation, and input hysteresis.

Because CPLDs are programmable, you can use the same device with different keypads and in different products, leading to higher volume quantities and lower cost. The ability to reprogram them (along with simple-to-use design tools) allows for late design changes and lower risk.

To learn more about this application, see the Xilinx application note, “Implementing Keypad Scanners with CoolRunner-II,” at www.xilinx.com/bvdocs/appnotes/xapp512.pdf. For more information about Xilinx CPLDs, visit www.xilinx.com/cpld/.

Printable PDF version of this article with graphics.  (7/11/05) 230 KB