Did I mention my YouTube video #13 all about keypads (a key matrix) like yours (but not exactly). At least it might give you an idea of what is going on behind the scenes. The example keypad I use is most definitely not I2C either!
You can get the keypad I use in the video also in a 12-key arrangement with buttons A, B, C, D as extra - requires another pin though (as there's another column of buttons).
URL to my YouTube channel in the signature of this post, take a look it might help. If it does, consider subscribing.
/*
Reading a TTP229 based capacitive touch Keyboard
to enable 16-Key Mode short TP2 with a 820kOhms (up to 1MOhms)
Resistor to GROUND or close Jumper 3 on TP229 Module
hardware required TTP229 Module with
* SCL connected to PIN8
* SDD connected to PIN9
created 1 Mar 2015
by Thomas Schmitz (thomas.schmitz@tschmitz.com)
This example code is part of the public domain
*/
#define CLOCK_PIN 8
#define DATA_PIN 9
void setup()
{
Serial.begin(9600);
pinMode(CLOCK_PIN, OUTPUT);
pinMode(DATA_PIN, INPUT);
digitalWrite(CLOCK_PIN, HIGH);
}
void loop() {
for (int button = 1; button < 17; button++)
{
//set clock
digitalWrite(CLOCK_PIN, LOW);
//read bit
int databit = digitalRead(DATA_PIN);
Serial.print(databit);
//reset clock
digitalWrite(CLOCK_PIN, HIGH);
};
Serial.println();
}
I know this is an old topic but I never was able to find a solution. There are probably lots out there but I never found any.
It turns out it is relative easy to use. First and foremost it is not I2C or SPI, it is simply a 16 bit shift register that you need to clock the data out. I used Thomas Schmitz's code and made a few modifications. Thomas's code located at:
It is important to realize this encoder with the one jumper (from Thomas Schmitz) does not give any indication that a key has been pressed. I found many variations of this code, they simply read back the output shift register in the keyboard decoder chip. It always shows the bit pattern of the key that is currently depressed or zero if none are decoded. It shows what is at the output pins, the data is the same. It does a nice job of debouncing the keys. It is up to the user to determine a key change etc.
Thomas used a simple counter to shift in the bits and display them. By using his counter (button) it gave me the HEX value of the key pressed (0x01 - 0x10H). Using this information I was able to detect when we had a key press and what key it is. The code is written so it requires a keypress for each key returned, there is no repeat.
Please realize this code was modified for my use and structured and commented for me. It was written for a different application but I stripped this part out to explain what I did. I have programmed in assembler for over 40 years, this C++ I have been playing with for just a few years.
I do several things in my code that is probably odd to most. First I insert a Flood Trap, this simply is a delay in the setup section that will allow the arduino IDE to take control of the board if the serial port gets flooded with user data being sent. This saved many boards of mine from locking up. The 5 seconds is enough for me to compile and upload the code. I use Linux and it works great.
I have a variety of the arduino boards so when I grab one I just launch the IDE, connect with the serial and read out what the code is programmed into that particular board. I normally also show the compile date, file path etc in the message, that makes it easy to find things months later.
