Page 1 of 1

GPIO matrix keyboard driver

Posted: Tue Jan 07, 2014 11:10 pm
by dan3008
Hi guys

I'm looking at making a matrix keyboard driver, that uses pins 2,3,4,17,27,22,10,9,11 as the rows (the left side of the GPIO header on a rev 2 board), and pins 18,23,24,25,8,7 as the columns, and translates the input into keypresses (like pythons uinput does)

However, for speed, I'd like to do this in c++ (i dont like C, dont ask why, just never got on with it)

any pointers would be greatly appreciated.

Thanks

Dan

Re: GPIO matrix keyboard driver

Posted: Thu Jan 09, 2014 6:02 pm
by Redrobes
Sounds like you might use the internal pull up resistors or add some high value ones of your own to one half of the IO bank and then set them to inputs. On the other half you set them as outputs and set them all high and put in some lower value resistors (say 1/10th value). Then sequentially lower one pin at a time and read all the inputs and if any are low then that gives you the keys down. If you press two keys then it would not know exactly which ones were pressed. By selecting suitable resistors you should prevent the system from shorting out two output pins of different logic levels. Something like 100K to 1M on the inputs and 1K to 4K7 on the outputs sounds about ball park to me.

Re: GPIO matrix keyboard driver

Posted: Thu Jan 09, 2014 10:35 pm
by dan3008
Thanks Redrobes. I think i've got my head arround the matrix logic now. (I would upload the diagram i made, but that would just confuse things lol)
The bit I'm really stuck with is emulating a key press :/ Any idea?

Re: GPIO matrix keyboard driver

Posted: Fri Jan 10, 2014 10:01 pm
by Paul Moir
You can use blocking diodes to discriminate during multiple keypresses:
http://www.headfuzz.co.uk/midihack2
This also solves the output short problem, so you just use weak pull-downs on the input GPIOs as long as you only turn on one output GPIO at a time. The cost is more parts (diodes) on larger matrices so if you don't care about multiple keypresses, Redrobe's solution can be better.

For the input you probably want to be looking at /dev/uinput. But I've never done that so that's only a lead...