My apologies if this is posted in the wrong spot or is totally off-topic, but I’m sure it’ll all work out.
I have a dilemma. In my possession is the discontinued KP16 keypad, which is normally used by being plugged into a main (GHI) board. Then, code is written to poll these keys through some implementation provided by Gadgeteer.
What I’m trying to do is take input from the keypad through GPIO on a non-GHI controller by polling the GPIO for highs and lows.
This means that when I press a key, I need to know exactly what pins on the KP16 board go high and which pins go low so that I can write my own driver for the controller that I am using.
I would really rather not shove wires into my cable coming off the KP16 and use a DMM to probe every single pin for every single key. If anyone already has this mapping, or if the current drivers are available to be viewed, it would save me a great deal of time.
@ andre.m - Thank you. This definitely feels like a step in the right direction. However, I can’t seem to find a code snippet for the retrieval of pin statuses. Unless they’re going some totally different route or I’m just glossing over it, I really don’t see anything that will help me here.
@ andre.m - No, IsKeyPressed is part of Gadgeteer’s implementations. Sorry if my question was unclear, I basically need to write my own IsKeyPressed. For this I need a list or similar of given voltages. For instance, something like:
“Key 1 pressed:
Or, even code that shows this happening would be fine too. I don’t mind doing a little… interpreting?
Seeing as the hardware is open source, I was hoping that this kind of information was available.
What do you think?
Wow. What an adventure I just had. Thanks for the direction Sprigo, I had just kind of glanced over that part of the files (it actually exists in a couple of files in that directory).
Turns out, A0 and A1 are inputs. They specify what keys could be pressed for a given 2 bit state (2 bits = 4 states -> four columns). So, polling row 3, for example, will give you a different readout depending on if the inputs are given a 00, 01, 10, or 11.
I just tested it by hooking it all up and probing it out.
How strange, though. Because the keypad isn’t debounced and must be polled, this means my resulting code will have to flick 2 GPIO pins HIGH and LOW at the rate of… what, 10-30 mS depending on existing state? Very interesting indeed. This must have been necessary to keep a common connector and to keep the keypad as intelligence-free as possible. Or maybe some other reasons.
Anyhow, thank you both, (Sprigo and andre.m). I learned something today Sorry for all the confusion.