A matrix keypad instance is defined by:

1. Actual GPIO pins used forming the row and column of the m x n matrix
2. Individual character in-use as symbol for each button

Hence, I instantiate and call method like

...
QPad  = matrixQPi(keyPad=keyPad,row=row,col=col)
print QPad.scanQ()

to print the character being pressed. Some examples pushed to my github explains how the above keyPad, row, and col are defined to scan-read pressed button of 2×2, 2×3, and 4×3 matrix keypads (or have it 3×4 matrix keypads in other words).

Illustration of any m-by-n matrix: 4x3, 2x2, and 2x3 keypad with different button symbols & GPIO combinations

I used deprecated Wiring-Pi Python (they already moved to 2.x version) without problem. However, you’ll fail building from latest commit and must use combination of older commits as described by my updated part of an old-post. By the way, there’s I/O expander support for WiringPi2-Python which is good, considering:

GPIO is expensive and for the sake of a keypad, you should not spend all.

(A friend told me that once)

Updated: for those who fail to build using deprecated WiringPi-Python, check this updated post to know which commit that build without error. There is now also a Python class for matrix keypad.

My idea of having the keypad is to make alternative input available under no keyboard presence nor shell access. List of things I can think of for instances, pressed key “0″ will make the Raspberry Pi (RPi) dial GPRS to a specific ISP and act as router to the USB WiFi stick, pressed key “7″ will convert it to a router that will bridge the ethernet to WiFi, etc. In short, those key readings will invoke subsequent scripts to run inside RPi.

The physical connection schematic drawings and code are gitified (visit v1.2 of the project on gitHub). A nice animated image on how the buttons connect pins forming a matrix can be found in hackyourmind.org.

Matrix keypad: alternative quick input for Raspberry Pi to start certain command

Some remarks over what the code does:

• It only read one pressed key at a time.
• It uses no interrupt. To read input it must wait and scan (this waiting experience is by far negligible to human sense).
• Debouncing doesn’t seem necessary as WiringPi already provided this by software (I suppose this timing method on their gitHub deals with debounce).

How it works? RPi forum thread gives a general idea that applies in my case:

1. Divide the 3×4 matrix as columns and rows. 4 GPIO pins as rows are pulled-up with 10k resistors and initialized as input.
2. Other 3 GPIO pins as columns are initialized as output low.
3. First loop will scan for one pressed key being read as one of the rows pulled-low
4. After the loop breaks, all columns are set as input, then the row pin found in the loop is set as output-high
5. Second loop will scan for column being pulled-high by that row pin. Between both loops, it is assumed that the key press is still in effect. In reality, normal human act of pressing this key elapses long enough for the software to run the scans in two loops.
6. Bingo! The code reads row-column combination of the pressed key.

Example of the code’s output by calling from shell:

$ while true; do /usr/local/bin/matrixQPi.py -i; done
3
6
9
8
#
*

(In the above example ^C will throw Python KeyboardInterrupt messages before breaking the bash loop)

GPIO pin logic state (meaning voltage) are both programmable and driven by physical-connection. I choose wiringPi for practical reasons: availability of its Python wrapper and its simple syntax (glancing it at first sight). WiringPi has an option of using its own pin numbering to address it in the code instead of the original GPIO numbering (there are board revisions to watch for in some cases of usage, not mine). Every pin can be initialized as input or output.

Updated: Wiring-Pi Python is deprecated and moving to 2.x version that supports I/O expander. However, you can still find this combination of commits that will work and build without error message:

- main module: WiringPi-Python@9c77bde
- submodule: WiringPi@89bbe97

(Check how to build on my README)

Using an analog multitester, here are behavioral findings:

• GPIO pin voltage swings to high logic after reboot (the meter’s needle is rocking for a second or so). It is in low voltage afterward until being programmed or physically pulled-up.
• Two pins, wiringPi pin 8 and 9, remain in high logic voltage after reboot. They are SDA0 and SCL0 to be used as an I²C, however they can be used to read button as well. (eLinux Wiki: “there are 1.8 k pulls up resistors on the board for these pins”)
• I did short the high logic to ground accidentally, it invoked reboot. (I don’t know how many times or how long of this will brick the Raspberry Pi)

Prior to trying the push-button switch, I didn’t have proper circuitry and working with wires as probes, prone to accident that was. I found an advice to insulate the +5V pin voltage so I could worry less.

Insulate the +5V pin of Raspberry Pi

A 10k pull-up resistor and a button are enough to test the following. Go to interactive Python shell and run line by line until the button push is read as low logic (GPIO7 in this example):

# python
Python 2.7.3rc2 (default, May  6 2012, 20:02:25) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import wiringpi
>>> import time
>>> INPUT=0
>>> OUTPUT=1
>>> HIGH=1
>>> LOW=0
>>> SETUP=wiringpi.wiringPiSetup()
>>> print SETUP
0
>>> wiringpi.pinMode(7,INPUT)
>>> RESULT=wiringpi.digitalRead(7)
>>> print RESULT
1
>>> RESULT=wiringpi.digitalRead(7)
>>> print RESULT
1
>>> RESULT=wiringpi.digitalRead(7)
>>> print RESULT
0
>>>

These basics convince me to go ahead with my goal of having a membrane (matrix) keypad as input for Raspberry Pi to run some script (see next post).

(Check also RPi common USB problems post)