Debouncing of an Interrupting Device to prevent Multiple Triggering - how?

Community General Discussion
1

In the following INT0 interrupt process (Fig-1), I press and release K1 (the interrupting device) just for once; as a result, the MCU goes to ISR and sets a flag which is tested in loop() function to blink L for three times. The precess should be ending here; instead, the L blinks again for three times (sometimes it is repeated) though I have not activated K1.

My conclusion is that the MCU is being interrupted agian and again due to bouncing of K1. My question is - how can I implement debouncing here for K1? Will software debouncing strategy be working under Debounce.h Library? If not, should I implement hardware debouncer?

Would appreciate to hear from the readers.

int125
Figure-1:

The Test Sketch:

#define L 13
#define LED1 4
volatile bool flag = false;

void setup()
{
  Serial.begin(9600);
  pinMode(L, OUTPUT);
  pinMode(LED1, OUTPUT);
  pinMode(2, INPUT_PULLUP);
  attachInterrupt(digitalPinToInterrupt(2), ISRINT0, LOW); 
  sei();  //global interrupt switch is eanbled though init() did it
}

void loop()
{
  if (flag == false)
  {
    //--execute Mainline program; keep blinking LED1 at DPin-4
    digitalWrite(LED1, HIGH);
    delay(1000);
    digitalWrite(LED1, LOW);
    delay(1000);
  }
  else  //perform ISR's job here as L can't be blinked in ISR due to disabled interrupt logic
  {
    for (int i = 0; i < 3; i++)
    {
      digitalWrite(L, HIGH);
      delay(500);
      digitalWrite(L, LOW);
      delay(500);
    }
    flag = false;
  }
}

void ISRINT0()
{
  flag = true;
}
2

"Programming questions" is the section heading.

What is missing?

3

New Arduino Forum whose features are yet to be known and learnt.

4

"Understanding the language, error messages, etc."

6

Section or sub-section, does it really matter?
There's NO CODE.

7

Do you want to see the codes that I have tried?

8

Personally, no, but others who could be bothered to be interested may.

9

Should I post the codes in a new post or in Post-1?

10

Sadly, I think you've been here long enough to know the answer to that.

I see you've changed the original post. {Sigh}

11

I have thought that you have expected re-formatting of Post-1 and that's why I have put all the texts together and the diagram at the bottom plus a correction in the mistake of the diagram (active LOW triggering and not FALLING edge triggering).

12

This sounds like you are using interrupts to handle a pushbutton.

Generally this is not necessarily.

Please elaborate upon your use case.

If it isn’t human slow, how fast are the valid interrupts expected to arrive? What is the nature of the spurious triggers of the interruot?

You can have the interrupt set the flag, but use software at a higher level to “debounce” the flag, as in ignore flag settings for some period of time after acting on one that was the first to come in awhile.

Or all this clever rhetorical questions? Seems like this is old hat for you!

a7

13

Not really! I am using a switch to inject LOW level interrupting signal.

It might appear to you as a "statement" instead of a task (for me and my pupils) which sould be solved.

Do you have any idea how can I use Debounce.h Library? Probably, the library will not help me as it returns the settled state (open or close) of a debounced switch.

14

Without any code, we'll just have to take your word for that, but LOW or HIGH are pretty unusual interrupt conditions.

15

With big salute and smile, the codes are given in Post-1.:slight_smile:

16

AFAIK, HIGH triggering level is not supported by ATmega328P.

17

@GolamMostafa Buttons are still not a viable application of a low level interrupt,
unless you have installed the electrocute button extension.

18

In practice, LOW level triggering signal will be a very narrow pulse and to be provided by a hardware (the interrupting device). However, in the Lab as a part of practice, we have placed a switch to injcet LOW level triggering signal and then we have fallen into trouble of multiple interrupts due to bouncing of the switch. Can the bouncing of the switch be ignored by software or hardware debouncer?

19

Yes, of course it can. The ISR can store the value of any timer like micros() or millis(), thus it can decide, each time it is activated, whether the debounce interval has expired, by examining that stored time stamp.

But preventing the ISR from running at all during the debounce interval, is a different matter. There was a long difficult thread about that here, years ago I think. The idea was to disable interrupts for that interval. Perhaps you can imagine the pitfalls in that scheme.

20

Curiously, yes.

Every denounce library I have examined, and many and various debounce methods tossed off in some larger context make what is IMO a huge mistake.

Since pushbutton do not normally close capriciously, that is to say we only observe a switch closure when someone or something is actually pressing the button, it would make sense to immediately act upon seeing such a closure.

Yet the codes always wait for the button to settle… this just delays needlessly the reaction of the code to the switch input.

The same could be argued for switch openings. Good pushbuttons do not open until a finger is lifted from them, yet the libraries and adhoc denounce methods again wait for stability.

To be sure, there are noisy signals where waiting for a period of stability is necessary. Pushbuttons do not generate such signals, and should be debounce differently to how it is customarily expressed.

It may be argued that we are only talking about 10 or 20 milliseconds, so who cares?

I just find it odd and mildly offensive to see action delayed without good reason.

So @GolamMostafa roll your own immediate reaction to the first interrupt and code a period of ignoring subsequent triggers until a debounce period has passed.

Also don’t. Don’t use interrupts for pushbuttons, it won’t be any faster than polling, for after all, must you not essentially be polling the flag the ISR sets?

a7

21

I despair.