debounce with an interrupt

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guys

I am working on a project, it's a battery power device. So the device needs to sleep as much as possible. And I don't want to use delay within interrupt to debounce.

The interrupt is triggered by a push button. Thanks guys!

 

uint8_t global_var_state_1;
uint8_t global_var_state_2;
uint8_t global_var_state_3;

while(1)
{
    //state machine bases on
    //input from global variables
    sleep();
}

ISR(PIN_CHANGE_vect)
{
    //debounce (how?, don't want to use delay here)
   if (button_press_is_valid)
    {
        //change values of global_var
        //for state machine.
    }
}

 

Zhuhua Wu - Electronic Engineering Student

Last Edited: Wed. Mar 11, 2015 - 08:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you don't have noise, then the key are pressed ! 

The debounce is just to ignore new keypress'es within next xx ms, and that you could do many different ways, and not here.

Last Edited: Wed. Mar 11, 2015 - 08:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Exactly.  If the button is pushed then it doesn't matter if it bounces because it is likely that by the time you have woken up the processor and done what you need to do you will have effectively debounced.  Also for the switch to close and bounce it must have been pressed anyway.

 

However, if you suspect that you may see erroneous button presses causing false waking of the Microcontroller then you need to handle that in hardware.

 

David 

Last Edited: Wed. Mar 11, 2015 - 09:01 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have to add:

Make sure that you disable the ISR , and hanging ISR's from that source, to avoid a "bouncing" ISR to happen.

When you are done with your keypress then reenable the ISR!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

However, if you suspect that you may see erroneous button presses causing false waking of the Microcontroller then you need to handle that in hardware.

I disagree. [That stated, all apps are different...]

 

In general terms, I use the wakeup sources just to awaken.  Then I go through the normal debounce of a few passes a few milliseconds apart to confirm the event.  If no event confirmed, then go back to sleep.

 

I have a couple wireless apps with previous generation "radios" that take some tens of milliseconds to warm up.  In those apps, I indeed "peek" at the input states after awakening and if there might be action to be taken, start warming up the radio.  As it takes some microseconds to awaken and get to the "peek", a true noise spike may well have gone away.

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely it is better to only awake when needed so removing spurious transients externally must be more efficient than starting up a processor.  After all it could be as simple as a capacitor.

 

David

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely it is better to only awake when needed ...

Shirley doesn't blow her power budget with a few spurious awakenings each year from e.g. static zaps.  Again, not all apps are created equal.  The approach I described works well in my apps.  An awakening signals a possible event.  The possible events are examined and confirmed and acted upon if confirmed.  Nothing happening for a while?  Prepare for bed and go back to sleep.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Understood and I agree as long as the number of spurious awakenings is low.

 

David

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks guys, I will try out all suggestion. :)

Zhuhua Wu - Electronic Engineering Student

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bug13avr wrote:

 

I am working on a project, it's a battery power device. So the device needs to sleep as much as possible. And I don't want to use delay within interrupt to debounce.

The interrupt is triggered by a push button. Thanks guys!

 

What is the consequence of multiple button presses ?

Some designs may not care (simply duplicating the same activity), others may have state-changes.

If you design is simple, you can just follow any bounce.

If you do need once only, you can use trailing-edge-bounce, where you action the first edge, then go into a low-power-timer mode, and wait a short time, before re-enable of the interrupt & deeper sleep.

That needs less energy than a leading edge delay()