INT_EXT Interrupts On Both Edges

[Bill_Smith]

After reading through most of the messages posted on Debouncing and Interrupt handling, especially those from PCM Programmer and Neutone, I attempted to create a simple INT_EXT driven State Machine.

I have a Normally Open pushbutton connected to B0, processor is an 18F452, and I'm using CCS PCWH 3.202. For lack of a better way to view state transitions, I incorporated a 16 x 2 LCD panel. The State Machine starts in MODE 0 and increments up to MODE 5, then it goes back to MODE 0. While in each MODE (state), mode specific data are calculated and displayed.

After several presses of the pushbutton I can see the MODE incrementing and interrupt_count increasing. The value of interrupt_count clearly shows that multiple interrupts are occuring. Even though I have ext_int_edge(INT_EXT,H_TO_L) selected, I am getting interrupts when I release the pushbutton as well.

Since I based my interrupt handler on PCM Programmer's posting, I'll direct my questions to him.

1. The variable interrupt_count is incremented each time an edge event occurs on EXT. How can I use this value to know when transitions have stopped?

2. The counter's value once initialized is never reset to zero. Is this correct?

3. How can I prevent the pushbutton's release from generating interrupts?

Thank you for your advice.

The following code is provided to illustrate my problem:

[SherpaDoug]

It sounds like a case of switch bounce. If you have a mechanical switch working against a pull up (or pull down) resistor then you will get a series of transitions every time the switch is opened or closed. This is because the metal of the switch contacts actually bounces a bit as contact is made or broken. To confirm this look carefully at the switch signal with a scope.
To solve the problem search for "switch bounce" or "contact bounce" on this BBS or the web. A good solution is not easy. Usually it requires some analog circuitry or a software timer that confirms the switch is actually opening or closing.

Good Luck
_________________
The search for better is endless. Instead simply find very good and get the job done.

[PCM programmer]

First I just want to say that my code was not intended as
a demo of how to make an interrupt-driven push button switch.

At the time I wrote it, I just wanted to show various aspects
of how to use the INT_EXT interrupt.

Now I guess I'm going to have to sit down and write some
push button code. I'll try to do that today, or at least by
tomorrow. And of course, anyone else can respond to this
thread as well.

[rnielsen]

Here's an interrupt routine that tries to debounce three buttons. I'm not sure if it's the cleanest or best but it seems to work quite nicely for me. I used a 18F452, running at 20MHZ, and used all three external interrupt pins.

[Bill_Smith]

SherpaDoug and PCM Programmer, thank you for your replies.

SherpaDoug: I confirmed your suspicions with a storage scope. I'm getting multiple edges on both press and release of the pushbutton. I suppose I could kludge in a couple of NAND gates to clean up the edges, but then I would probably [spam] off the 10,000 other folks out there who would like to see PCM's software solution, me included.

I found a couple of interesting indications while investigating my code a little more:

If I reduce the delay in the main routine to 10ms, I get fewer jumps in transitioning from one MODE to the next. Somewhere after 50 or 60 presses of the pushbutton, the processor goes whacky and locks up. Probably a stack overflow but that's only a guess.

Cheers

[Neutone]

For what it's worth I have never posted any debouncing routines that would would work well with an interupt. They were all based on the inputs being scaned on a periodic time base. What might work for you is to disable the edge interupt as soon as it occurs and set a timer to zero. Then when the timer interupts enable the edge interupt. This would be easy to operate and prevent excessive interupts. If your running a periodic loop you might find the examples I posted work better than what you can get working in an interupt. On the other hand I am wondering what PCM hand in mind.

[Jerry I]

I agree with Neutone; I don't think interupts are need to read a switch inputs.

What I have always done is to use the internal timer free running. Timer interupts every 10ms, this is the delay I use to debounce the switches.


When I detect a change in state of the switches I clear debounce_count=0;

At this point every time the timer interupts debounce_count++ increments
when it reaches say a count of 6 which is approx. 60ms I service the switch routine.

I do not wait in a loop for a delay for debouncing the switch.

I do use states, and as I poll the switches I check for the state and continue processing other code.

Sample Code

[Bill_Smith]

Thank you rnielsen and Jerry I for your responses, I am always amazed by the creativity of the human mind in solving a problem. I took a closer look at both of your methods, and I think that I will try to implement Jerry's. I discovered that the 18F452 has some really cool timers, and since I have 3 timers that are doing nothing in my current 18F452 design, I think I will take this opportunity to get to know them a little better.

Jerry I: Could you please check my declarations below? What are their start up values? The rtctic variable increments continually, do you ever reset it? What is the variable sec_ctr for?

#define DEBOUNCE_CNT 5 // 5x10ms
#define SW1 input(PIN_B0) // Pushbutton

short TEST_BIT;
int debounce_time;
int high_count;
int rtctic;
int event_ctr;
int sec_ctr;
int EVENT_TMR;
int sw1_changed;
int sw1_old_state;
int sw1_cur_state;
int bstate;

Cheers

[PCM programmer]

I am glad everyone else is posting code. Then I don't have
to write a specialized routine which wouldn't be the best way
to solve your problem anyway.

The way I was going to do it, was to disable external interrupts
after getting the first keypress. Then set a (hardware) timer for
the debounce delay. That uses a lot of resources and it's not
necessary. Normally, I use a system "tick" at 10 ms, and just
check the keypad every tick. The tick period provides the
debounce time.

There was one recent project where we did use interrupts.
Four push-buttons were connected to pins RB4-RB7.
The customer had a requirement wherein the time at which
a button was pushed had to be recorded at a resolution of
a few micro-seconds. This is because there were many
different keypads, and the outcome was decided based
on which user was the first one to press a button.

So we couldn't use the 10 ms tick method. Instead, we
used the interrupt-on-change feature. In the INT_RB
isr, we read and saved the value of Timer1, and the
state of the keys, and set a flag. Debouncing was
done outside the isr, by keeping a count of calls to
the check_keypad routine (similar to the CCS kbd.c
method).

[Jerry I]

Updated variables I used

int sw1_changed; SHOULD BE short or int1
int sw1_old_state; SHOULD BE short or int1
int sw1_cur_state; SHOULD BE short or int1
int bstate;

Old Code below really not required
int sec_ctr; I used var to count seconds not req.
int event_ctr; not req
short TEST_BIT; not req. used for testing pin toggles after int
int rtctic; not req



#define EVENT_TMR 38 // Event Timer every approx 1/2 sec
assuming 10MHz Clock

setup_timer_0(RTCC_INTERNAL|RTCC_DIV_128|RTCC_8_BIT);


Goot Luck

[SteveS]

While we are on the subject - Maxim makes a nice I2C debounce series MAX6816-8. They are hard to get sometimes and not real cheap, but real handy. They have an interrupt output when any input changes (after debounce). It takes away the debounce processing and lets you interface a bunch of discrete push buttons without taking up a bunch of pins. I put them on my front panel/user interface board and then I have a nice small cable to the processor board. Note that the debounce period (fixed) may be too slow for some encoders - good for buttons and switches though.

- SteveS

[mnv]

i created my own solution for debouncing.
i've got 5 buttons which are each connected to its port pins and rb0-interrupt is used for recognizing, when a button is pressed. this is done with a diode connected on each button to the interrupt line. this interrupt line is connected to a 680 resistor and the resisitor is connected to a 100n-capacitor against ground and to the rb0-pin. this is for a smooth sink and rise of the interrupt signal so it needs a few milliseconds. and this is longer than an eventually debounce could last.
sorry for my terrible english ;)

[Guest]

The simplest way to you (for the current state of your software) is to disable any further interrupts one the EXT_IT is fired. So:

#int_ext
.........
disable_interrupts(INT_EXT); // disable furthers
................

In main():

delay_ms(...);
enable_interrupts(INT_EXT); // re-enable after the delay

[Guest]

Maybe a bad question for a programming forum, but has anyone tried using one of these "Schmitt trigger" devices to avoid debounce? Do they work?

[Will Reeve]

I thought I would post how I allways handle push buttons (I allways place them on RB4-7 and use internal pull-up's and RB4-7 interrupt on change):

example button defines:

#define FIREPIN PIN_B4
#define MODEPIN PIN_B5
#define VOLPIN PIN_B6
#define FREQPIN PIN_B7
#define FIRE 0x01
#define MODE 0x02
#define VOL 0x04
#define FREQ 0x08

#int_RB
RB_isr(void) {
disable_interrupts(INT_RB); // prevent bounce
if (!input(FIREPIN)) iButton |= FIRE; else iButton &= ~FIRE;
if (!input(MODEPIN)) iButton |= MODE;
if (!input(VOLPIN)) iButton |= VOL;
if (!input(FREQPIN)) iButton |= FREQ;
set_timer1(1);
enable_interrupts(INT_TIMER1);
} // RB_isr(void)

The FIRE button in this case if a button which you hold down and the rest of the code can also tell when you release it, which is kind of neat! The other puttons set iButton and the code clears it when that action has been completed.

The INT_TIMER1 interrupt just does this:

#int_TIMER1
TIMER1_isr(void){
disable_interrupts(INT_TIMER1);
enable_interrupts(INT_RB);
} // TIMER1_isr(void)

This arrangment works well you just mask iButton with the button you want to check, like:


if (iButton&MODE)

for instance.

Keep well all,


Will