Scanning of Keypad (4x4) using timer

Thread Starter

ecaits

Joined Jan 6, 2014
56
Hello Friends,

I have interface keypad (4x4) with PIC16F877 using Hi-tech C compiler.
Now I want to scan the keypad to know that is any key pressed or not???

How can I use timer to scan the keypad so that I did not need to scan the keypad every time in program code???

I think I can use timer to scan the keypad but I dont know how to use it..

Please suggest me.... Thank you in advance...

Nirav
 

ericgibbs

Joined Jan 29, 2010
18,734
hi,
If you use PORTB as the Keypad connection, say D4,5,6,7 as read Rows and D0,1,2,3 as Column drivers, you could use Interrupt on PORTB change D4,5,6,7 [ no polling]

E
 
Last edited:

ErnieM

Joined Apr 24, 2011
8,377
I use a timer to check for button presses by setting an interrupt at regular intervals, usually 1 mS. Inside the ISR I check the buttons every 25 mS (just count 1 to 25) and require the button state be the same for 2 readings before declaring a button pressed or unpressed.

The button state is kept in a global variable so the ISR can set it and the main code can read it..

Aside: generally it is more trouble then it is worth to scan keys with interrupts, especially keys in a matrix. You want to read keys quickly relative to a human's senses, and 1-- mS is fine for that. Connect directly to an ISR and you will have many many button bounces to deal with.
 

ericgibbs

Joined Jan 29, 2010
18,734
hi Ernie,
I would disagree over the problems you state using ISR for keypads, I have a 20mS delay at the start of the ISR after its confirmed that its a PORTB interrupt.
I dont have any key bounce misreads.

Eric
 

ErnieM

Joined Apr 24, 2011
8,377
I would disagree over the problems you state using ISR for keypads, I have a 20mS delay at the start of the ISR after its confirmed that its a PORTB interrupt.
I dont have any key bounce misreads.
I did not say you would get misreads. But by putting a delay inside the ISR you've wasted 20mS waiting to see if anything relevant happened.

Pole the inputs based on a timer and you'll earn back at least 19.5 of those 20 mS.
 

MrChips

Joined Oct 2, 2009
30,618
You don't need to scan a 4x4 keypad in the conventional scan technique.

1) Use interrupt on PORTB change as Eric has already suggested.

2) Disable further PORTB interrupts.

3) Wait 25ms then interchange the input/output functions of the row vs column ports.
Read back the data and you have your row-column key pressed.

4) Wait for all keys released (with debounce code) before resuming normal PORTB interrupts.
 

ericgibbs

Joined Jan 29, 2010
18,734
Pole the inputs based on a timer and you'll earn back at least 19.5 of those 20 mS.
Hi Ernie,
Yes but I only 'waste' 20mS when a key is pressed, I would say that using a continuous 1mS rate ISR will 'waste' a lot more time over a given period, when you consider the time saving and restoring important registers
every time you call the interrupt.

The point is if it works for you, thats fine, I am not critical of the way you do it, I am just defending my method, it works for me.

Eric
 

ericgibbs

Joined Jan 29, 2010
18,734
What else is there to do while waiting for the user to take his/her finger off the button?
hi,
I agree, normally when a user presses a key, its to interrupt the current program process and start a new process, so effectively no time is lost or wasted.

Eric
 

ErnieM

Joined Apr 24, 2011
8,377
What else is there to do while waiting for the user to take his/her finger off the button?
I agree, normally when a user presses a key, its to interrupt the current program process and start a new process, so effectively no time is lost or wasted.
That is true as long as your program has no need to walk and chew gum at the same time(share) as determined by interrupts.

As long as you're not reading or writing any asynchronous data over the USART or updating a multiplexed display or trying the keep the USB active or any number of other things you can stick dead or dumb delays anywhere you wish inside your code without any performance penality.

Sticking delays inside the ISR is among the list of things generally to be avoided.
 

ericgibbs

Joined Jan 29, 2010
18,734
I have often used the keypad interrupt method when using UART and USB comms' in commercial applications, if the program is written correctly a keypad ISR causes no problems at all.

If you wish to use a timer a timer interrupt for a pad, I dont have a problem with that.

E
 

THE_RB

Joined Feb 11, 2008
5,438
What else is there to do while waiting for the user to take his/her finger off the button?
I like it to be drawing to the screen and starting the new function.

Theres nothing worse than a function that does not start until after you press AND release.

Re the original question I scan keyboards in a timer interrupt as general practice;
1. Every timer int, it activates a new column and reads the 4 row inputs.
2. If a button is pressed, it puts button value into a variable.
3. If that variable is the same as the variable from last test, a debounce counter is incremented.
4. If the debounce counter >X the pressed key is loaded into an output variable to be detected in main().

It works quickly and easily and is fine in a 1mS timer interrupt. All main() ever has to do is check for the "key" variable to be set.
 

joeyd999

Joined Jun 6, 2011
5,220
Theres nothing worse than a function that does not start until after you press AND release.
Not always.

Judicious use of press, press & release, press & hold, or "double/triple-click" can enable a single push button to support more than one function. I do this often.

I also allow for multiple keys actuated simultaneously to activate other functions.
 

ericgibbs

Joined Jan 29, 2010
18,734
Time scanning a keypad is analogies to you opening your house door a 1000 times a second to see if anyone is there , rather than waiting for the door bell to ring.

Calling the keypad ISR can easily be controlled by using the ISR bit if its necessary for time critical processes in a program.

Its also possible to use a pad ISR without added wait delays by repeat scans after an interrupt is initiated.

I am not criticising which methods others may find ' the best' for them, its challenging claims by others in 'rubbishing' alternatives.

E
 

THE_RB

Joined Feb 11, 2008
5,438
Time scanning a keypad is analogies to you opening your house door a 1000 times a second to see if anyone is there , rather than waiting for the door bell to ring.
...
Actually it's more like getting your unpaid servant who moves at 10 million feet per second (and has nothing much else to do) to keep checking the door for you. ;)

I do get your point that there are lots of ways to do it which can all be good ways.

I was not rubbishing people's chosen methods so much as rubbishing the idea that a button should be pressed and released before performing its task. In my experience that leaves the user mashing buttons and swearing.
 

ericgibbs

Joined Jan 29, 2010
18,734
I was not rubbishing people's chosen methods so much as rubbishing the idea that a button should be pressed and released before performing its task. In my experience that leaves the user mashing buttons and swearing.
Morning Roman,
My post was directed at Ernie's comments regarding bouncing miss-reads, I should have made clear.:rolleyes:

Ref the On Button release action event, I have had some clients who have insisted on that method.

Also Joey999's note about multifunction keypad operation is a valid point.

Its horses for courses, whatever gets the job done in meeting the clients specification.

Eric
 

ErnieM

Joined Apr 24, 2011
8,377
My post was directed at Ernie's comments regarding bouncing miss-reads, I should have made clear.
What you should make clear is your own eyeballs.

I never made that statement. This is the second time you have made such a claim, and the second time I have to correct you.

Are straw man arguments actually necessary to make your point?
 

ErnieM

Joined Apr 24, 2011
8,377
Connect directly to an ISR and you will have many many button bounces to deal with.
You did post this comment, which I am disputing, its incorrect.
That is quite different from what you've been stating. So, is your point now that connecting a button to an interrupt pin is some magical means of eliminating the bounce problem?

I did not say "many many button bounces to deal with" is an insurmountable problem to deal with, I said it must be dealt with. Your choice was to deal with them by use of a delay inside that ISR.

My points are though that may work for you it is not without it's own problems and cautions. Additionally it is in opposition to the generally desirable method of keeping the ISR routine tight and tiny and fast, especially in baseline devices with but a single unprioritized interrupt vector.

Look, you have done this before, I've done it before, but poor ecaits (he's the OP here) is doing it for the first time, and I don't want to be teaching him poor coding practices.
 
Top