Is there any other method of taking input from a keypad except polling/scanning?

[zia.newversion]

Hi there.

I always wondered how the keyboards/keypads worked. I found out a while ago that it is nothing but a simple matrix of push switches such that each switch has one end connected to a common column line and the other connected to a common row line... What you can do is, poll either columns and scan for a signal on rows or poll rows and scan for a signal on columns. The problem with this approach is, I don't know why, but it looks too shabby to me. I improvised and though instead of continuously polling/scanning the lines, why not provide constant power at either of rows/columns and wait for an interrupt on the other side (through an OR gate, perhaps). But once the ISR is executed, the program will again have to poll/scan the lines to check which one was pressed... And if the button is pressed for so short an interval that as the controller enters ISR, the signal on the scanning end has gone off, the input will go waste. The controller knows a button was pressed, but doesn't know which one.!

What I meant to ask was, is there any other, more advanced method of implementing a keypad/keyboard?
If you haven't seen it work yet, but have a novel idea, it is more than welcome.

Waiting for your input.
- Zia

 

[Hewitson]

I'd go with the interrupt method, the MCU will easily be fast enough to enter the ISR and recognise which key has been pressed before the user has stopped pressing it.

 

[sajeev]

Just go for interrupt method in PortB pins in case of PIC micro. Y you want to always power the rows and columns?

 

[alexan_e]

I prefer the polling method, use a timer to check a few times per second if anything has been pressed, as a bonus there is no need to debounce the keys.

Alex

 

[zia.newversion]

Y you want to always power the rows and columns?

Because otherwise there is not use of using the interrupt method. I am using the interrupt method so that the controller can do something useful when it's not polling. If I don't always power the rows OR columns, there will be no interrupt unless I am running a poll. And in that case, the MCU is still busy polling outside the ISR...
I think the side which I would otherwise be polling should be given a constant power. The controller can do something else in the main loop. When a button is pressed, an interrupt will be generated. So the controller will know some button has been pressed. To check which one, the controller will have to immediately (in the ISR) poll the keypad only once. Once it knows which key has been pressed, it can save the key in some GPR and the stored value can be used by main routine when it comes out of the ISR. The controller can go back to doing whatever else it was doing. This is not possible without giving constant power to the poll side. [Or is it?]

I prefer the polling method, use a timer to check a few times per second if anything has been pressed, as a bonus there is no need to debounce the keys.

Alex

Well the ONLY bonus is, there is no need to debounce the keys. BUT, this is a bit inefficient, don't you think? A controller interfaced with a keypad cannot do another job without rendering the keypad disabled. The keypad cannot be used during the time controller is doing something else... I guess that is the kind of problem which must have been the reason for existence of interrupts.

I'd go with the interrupt method, the MCU will easily be fast enough to enter the ISR and recognise which key has been pressed before the user has stopped pressing it.

That's a chance. Controllers can be slower and human can be faster (while pressing keys, I mean).

Guys, these are the procedures that I already mentioned in the original post! Sure, your opinions on them are welcome, too... But I meant to ask if there is any OTHER method there.
By the way, I did find one in Microchip's Tips 'N Tricks Compiled Notes... It was something about using resisters along the matrix and then using the ADC to find out which key was pressed depending on the incoming voltage.
That's a good idea too. But difficult to implement, error prone if not implemented right and certainly not NOVEL.

 

[alexan_e]

I prefer the polling method, use a timer to check a few times per second if anything has been pressed, as a bonus there is no need to debounce the keys.

Note what I said, all you need is to check 5-10 times per second, you have an mcu that can execute millions of instructions so having it spend a hundred to check the keyboard is almost nothing.
Your description would be true if you were using an endless loop in the main code to check the keyboard every few micro seconds or if you were using a delay function (that actually freezes execution) between checks.

Alex

 

[zia.newversion]

Note what I said, all you need is to check 5-10 times per second, you have an mcu that can execute millions of instructions so having it spend a hundred to check the keyboard is almost nothing.
Your description would be true if you were using an endless loop in the main code to check the keyboard every few micro seconds or if you were using a delay function (that actually freezes execution) between checks.

Alex

Yes! There's an idea. Timer interrupts (with high prescalar) can be used... And the controller can do something in the background.
But don't you think a key-press could be quicker than 10 times per second? I mean have you seen the younger generation text on their phones?

I would like to out forward a new question in parallel.
How do industry standard applications of keypads work? I mean how does the computer keyboard work? Does the inside controller use the same polling/scanning method? And the keypads in cellphones these days (they are mostly touchscreen, but otherwise), how do they work? It's be silly if they used polling too...

 

[alexan_e]

About the polling method you can easily change the rate to suite your need , you can use 20 or 50 times per second , it will still be a minimum effort for the mcu.
There is always the possibility to use external interrupt, you can choose either way, it is a matter of preference and available resources, maybe your timers are already used for something else or on the other hand maybe you don't have any available external interrupt free.

About the industry standard for keypads I'm afraid I have no idea.

Alex

 

[KerimF]

Hi,

I usually work with 50Hz mains. So I distribute all the necessary subroutines in the two half cycles (10ms + 10ms). One of these subroutines could be to read the keyboard which is likely the shortest subroutines. Also I won't accept a valid press till it is repeated a number of time (N) so the press time should be at least N*20ms (N could be 2 to 5 for example which depends on the application) then it should be followed by a no key reading to accept later another one. Also I reject any multi press (more than one key pressed simultaneously).

Kerim

 

[Hewitson]

That's a chance. Controllers can be slower and human can be faster (while pressing keys, I mean).

Absolutely not. What we are talking about could easily be achieved with a 1970's MCU, let alone a modern one.