Numerous interrelated questions here.
I am trying to get a deep understanding regarding the keyboard scan functionality actually operates on this accessory.
I found the SX1509 I/O expander ESP32 question from Oct 2020 but the PDF link posted there does not work. Furthermore, it seems to me that my board does hold the interrupt signal low until readKeypad() is called, unlike what that user experienced.
I have tried a number of things trying to figure out how information is latched/buffered for readKeypad() to access.
It looks like: if I attempt to hold down multiple keys in the same row, only one appears in the data. Same goes for multiple rows.
So, am I correct that when a row is scanned, and column detected, that row/column is latched and interrupt stays low until it is read; other key-downs get ignored?
I suspect that the “scan” is also on hold until readKeypad(), correct?
Then the scan continues with the next row and that interrupt occurs?
I was able to get multiple columns in the same read, but I suspect that was when holding keys during readKeypad() causing another interrupt to be generated containing both. It also looks like multiple rows can never exist in the same ReadKeypad() result, correct?
I am trying to implement an interface that is not for human use so understanding how to detect multiple keys being held is important.
It would be useful to have a valid reference regarding how this functions.
That could do it but I will need to dig deeper into the SX1509 class to see why my tests do not exactly match what the data-sheet says.
Would I post questions about that code here or elsewhere?
According to the SEMTECH SX1509B datasheet regarding keypad operation:
When a key is pressed, NINT goes low, key scan is halted and the key coordinates are stored in RegKeyData.
When RegKeyData is read, this data along with the interrupt is automatically cleared and the key scan continues to the next row.
That would indicate that I was correct with all four of my questions.
Experiments show that the INT signal does stay low until the data is read. It also happens that multiple columns can be reported active in the same row, but not more than one row at the same time.
However, when multiple keys in the same row are simultaneously pressed, it often happens that only one is reported. Then the INT signal goes low again and the next read then contains all columns found down.
Also note that cheaper keypads do not have a diode installed between each switch and the row. These cause the following to occur when holding the following three keys down (r1,c1), (r1,c2), (r2,c2):
First read likely returns (r1,c1) and (r1,c2)
Next read returns (r2,c1) and (r2,c2)
The above is caused by the row-2 scan driving its signal through the (r2,c2) key to the (r1,c2) then the (r1,c1) key. So you will get a false (r2,c1) key-down event.