a hardware-independent software debouncer

[nctnico]

The schmitt trigger is what makes things hairy. Many microcontrollers don't have schmitt trigger inputs and some even have truly awfull logic level thresholds (like Atmel's Attiny).

[jpanhalt]

@dannyf
Thank you for the links to your blog and Kuhn's description.  I have been unhappy with my software debouncer and wrote a small program for that approach (simulates, but not thoroughly tested).   I only use Assembly, and the code requires one register and a couple of rotates. This is for a switch (PORTC,0) that is low when open and waits for a low before returning from the ISR.

EDIT: Couldn't get the code to format, so added as image attachment.
 
EDIT2:  Was worried about a step and in fact, it is a bug with a more complex simulation.  Disregard code, it doesn't work.  If fixed, I will repost.
EDIT3:  Fixed that bug. There may be others.  Updated image attachment. Changed rlf debounce,w to rlf debounce,f and added step.

I realize this may be of interest to only 13 people in the world.  But when you are retired, that doesn't matter.

John

Edit:  That code looks horrible, but looked fine in the "preview."   What is the preview for if it doesn't work? Tried pasting from MPLAB, as I usually do and skipped preview.  That wasn't much better.  Attached image.  Sorry for inconvenience.

[dannyf]

jpanhalt: i'm happy that it is of use to you.

[Alex Eisenhut]

Why decrement when released? Just set the counter to zero when not pressed and when pressed count up to a maximum value and trigger at a certain value.

Why??? Because it gives robust result when signal is not clean. Both presses and releases. The less clean signal is, the more time it take takes to trigger value. And signal don't need to completely settle for triggering the value. Allows very fast and reliable debounce even with very crappy switches.

Just set the counter to zero when not pressed

and that's the reason why many devices start to experience double/triple presses after the switches receive some wear when actually there was only one press.

Like my Breville toaster oven... grrrrr....

[obiwanjacobi]

I like the adaptive nature of an integrator, provided it is called frequently enough - you don't want to starve it - which in some apps may require some thought... If the switch gets old and bounces more, it'll just take longer to make out a steady state. Sounds fine.

I like the argument that Andy brought forth about reacting on first sign of change and doing the debouncing afterwards...

I also like the argument that you could really solve this easily in hardware too (do you really need a schmitt-trigger input?) which saves you some software complexity. This however, is not adaptive with the switch's wear....


I have written an implementation that uses approximate time to debounce (and detect hold). I would not mind making a 'better' or alternative implementations...

So how would you consolidate these aspects into a solid implementation?

[nctnico]

Why decrement when released? Just set the counter to zero when not pressed and when pressed count up to a maximum value and trigger at a certain value.

Why??? Because it gives robust result when signal is not clean. Both presses and releases. The less clean signal is, the more time it take takes to trigger value. And signal don't need to completely settle for triggering the value. Allows very fast and reliable debounce even with very crappy switches.

Just set the counter to zero when not pressed

and that's the reason why many devices start to experience double/triple presses after the switches receive some wear when actually there was only one press.

Like my Breville toaster oven... grrrrr....

Still you have to consider what can happen if a switch starts to make contact by itself due to moisture or dirt. Do you want your toaster to start toasting by itself with the chance of setting the bread crumbs inside on fire and burning down your house? One of the systems I worked on was for dispensing drinks in bars and restaurants. Replacing a flaky switch is much cheaper than cleaning up a 2000 liter beer spill.

[KL27x]

+1 to Andy C. For human input switches, I prefer the action to occur immediately, then time out long enough for the switch bounces to end. This is where the noise from the switch, itself, and not other devices on the power rail, are the only concern, of course. If the circuit is getting false signals outside of switch transition that are big enough to register state change, I would probably try to fix the hardware. Many of the micros I use have Schmitt trigger inputs available. I don't often have such problems.   

[wraper]

+1 to Andy C. For human input switches, I prefer the action to occur immediately, then time out long enough for the switch bounces to end. This is where the noise from the switch, itself, and not other devices on the power rail, are the only concern, of course. If the circuit is getting false signals outside of the switch that are big enough to register state change, I would probably try to fix the hardware. Many of the micros I use have Schmitt trigger inputs available. I don't often have such problems. 

<20-30 milliseconds delay is not fast enough for you?

[dannyf]

There is some merit in responding to the leading edge of key bounces, if you assume that a key wouldn't bounce unless it is pressed. To me, however, that is not a robust enough of an assumption, as there could be line noise, or accidental but short key presses (from mechanical shock for example). But I certainly understand how others may choose that approach.

If so, the Kuhn debouncer can be easily adapted to capture most (but not all) such cases, by changing the key_get() routine to this:

Code: [Select]

//return key state
KEY_STATE key_get(KEY_TypeDef *key) {
return (key->cnt_key != 0)?KEY_PRESSED:KEY_NOTPRESSED; //could be made to return KEY_BOUNCE
}

Essentially it is saying that as long as the debouncer is working (key->cnt_key !=0), the key must have been pressed.

That logic fails if the duration of signal KEY_NOTPRESSED is longer than the duration of signal KEY_PRESSED, which statistically speaking is not as likely as the other way around conditional on the key having been pressed.

[Kjelt]

What i have seen done multiple times on adc inputs and could also work for switches is using an moving average algorithm, the size of the buffer, sampling frequency and threshold will determine the debounce and response time. However these cost ram which usually is a scarce resource in embedded projects.

[jpanhalt]

Let's say you have a press and release, like most button switches.   Of course, you can respond to the first change, but if you are going into an interrupt, don't you still have to wait for the release bounce to end before exiting? (Or use some other mechanism to delay enabling that interrupt.)

The SR method with cross-connected NAND's actually removes bounce rather than waits for it to be over.  Unfortunately, that method requires a double-throw switch, which are hard to find.

After a bit more reading, I have decided to try using the "release" edge of a button switch to initiate an interrupt, rather than the first change, and to go with hardware debounce.  Hardware plus interrupt on release avoids having to poll the switches and/or to wait in the interrupt.

John 

[AndyC_772]

In the ISR, you set a flag which indicates that a button has been pressed, do whatever you want to do with timers and counters to de-bounce the switch, then exit. It should be a very quick process.

In some foreground task, you poll the flag at a convenient time to see if it's been set since last time you checked. If it has, then you clear the flag, and do whatever the button is meant to do. This could take quite a long time, so it's not something you want to be doing in an ISR anyway.

[jpanhalt]

In the ISR, you set a flag which indicates that a button has been pressed, do whatever you want to do with timers and counters to de-bounce the switch, then exit. It should be a very quick process.

That (underlined) is what I want to avoid.   Debounce usually has a wait of 10ms to 40ms.  At 16 MHz with a PIC, even 10 ms is equal to a lot of instructions.   That seems to be contrary to the advice to keep interrupts short.

On the other hand, if you don't even enter the ISR until all bouncing is over, then time there can be short.  As for the flags being set and so forth, that is what I do.

John

[AndyC_772]

I think you misunderstand how debouncing is done.

The ISR is entered each time the switch input changes state. This is exactly once per press and once per release for a 'perfect' switch, and maybe 2 or 3 times per change for a bouncy one.

The purpose of the de-bouncing code is to make a decision as to whether each state change is due to an actual press or release, or whether it's just contact bounce. Once that decision has been made, the ISR exits. Since the code to make that decision is simple, the actual time spent in the ISR is minimal.

There's clearly some differences of opinion on what the criteria should be, but I think we're all in agreement that you don't just sit in the ISR doing nothing until the debounce period has elapsed.

[jpanhalt]

@AndyC_772
Assume you enter the ISR on the first rising edge as has been suggesed and the switch bounces for 10 ms.   A short ISR will exit and re-enable the interrupt well before that bouncing ends.    So, you have the potential to get multiple interrupts.

Now, if you wait until the bouncing is over, then you are stuck in the routine for a long time.  Hardware debounce will delay entering the routine, but it doesn't carry a risk of exiting while the switch is still bouncing.

John

[AndyC_772]

So, you have the potential to get multiple interrupts

Yes, you do, absolutely. Intentionally so, by design. Each individual change in state of the button input causes a jump to the ISR.

Your ISR in turn makes a decision about whether the state change was 'real' or not.

If it's 'real', then the ISR signals to some other process that the button state has really changed, and requires action. That other process updates the UI, changes a setting, or whatever else the button was meant to do.

If not, and the switch is deemed to simply be bouncing, the ISR exits with no further action taken.

[dannyf]

using an moving average algorithm, the size of the buffer, sampling frequency and threshold will determine the debounce and response time. However these cost ram which usually is a scarce resource in embedded projects.

The Kuhn debouncer is a moving average algorithm.

I have decided to try using the "release" edge of a button switch to initiate an interrupt, rather than the first change, and to go with hardware debounce.

Release-based actions are more reliable, obviously. But it is a little counter-intuitive for the user, and it also requires debouncing: the buttons bounces on both presses and releases.

If you are simply detecting on the first release, and ignoring the subsequent bounces, the Kuhn debouncer can be modified easily to detect that too.

[jpanhalt]

Right now, I have re-designed the circuit to use hardware debounce.

Even with testing only for first release, you are still talking about a of time in the ISR, unless you somehow delay re-enabling that interrupt.

BTW, the code I posted earlier is not really Kuhn's method.  It looks for consecutive ones or zeros, which is what the MAX681x and MC14490 also do.  I later wrote some code for averaging that actually uses Kuhn's method and works pretty well.  Each routine is 9 instructions, excluding the delay call or macro.

Will these debouncing delays actually affect what I am doing now?  Probably not.  The only time-critical interrupt in my code is caused by a TMR0 overflow.

Regards, John
   

[dannyf]

It looks for consecutive ones or zeros

The Kuhn debouncer can be made to do that too. For example, rather than decrementing the integrator on KEY_NOTPRESSED, you reset it. Under that scheme, KEY_PRESSED is returned by key_get() if and only if a consecutive number of KEY_PRESSED is detected.

The beauty of this particular implementation is the separation of the integration and the detection of the key's states.

[nctnico]

I think you misunderstand how debouncing is done.

The ISR is entered each time the switch input changes state. This is exactly once per press and once per release for a 'perfect' switch, and maybe 2 or 3 times per change for a bouncy one.

That is a very, really very bad idea! I've seen embedded applications come to a grinding halt (*) due to interference on a switch input. If you use an interrupt to flag a switch then you'll also need to disable the interrupt at that point and enable it from the main process. This also kinda negates the need for using interrupts because what is the difference between polling a flag and a GPIO? Interrupts are for stuff which needs a timely response which cannot be guaranteed by the main loop. A switch is unlikely to need an interrupt since a response time below 100ms to 200ms is perceived as immediately.

* Worst example I've seen is several meters of wire connected to a doorbell on an unprotected I/O pin. At some point the system started to become flaky but my co-workers tasked with that project could not figure out what was wrong. I just never realised they where so stupid to use an interrupt for detecting a key switch input.  -out of hands and faces error-

[jpanhalt]

Just and FYI to add.   I was browsing the new 3rd edition of Horowitz and Hill and came across this "debouncer" on page 730.  There is a brief discussion of why it works there.  So far as I can tell, it is not in the 2nd edition.

I had not seen such a simple version before.  Would be interested in testing it, but I can't find a bad switch to do it with.

John

[nctnico]

Pretty useless since 99.999% of the pushbuttons is single pole.

[bingo600]

I'm debouncing in a 10ms timer IRQ
Using Peter D's code , that implements (if  remember corect) a 4bit barrelshifter

Peter's code (attached)
http://community.atmel.com/projects/efficient-key-debounce


Threads (German)
https://www.mikrocontroller.net/topic/tasten-entprellen-bulletproof#new


I never had any problems , and even extended it to so a 4 x 3 keyboard wo. problems.

/Bingo

[nctnico]

The golden rule is: don't use lines from buttons or switches as interrupt sources! Ofcourse you can use a timer interrupt to poll keys. The only (extra) problem you'll have is parallel thread synchronisation to convey the switch value to the main process.

[dannyf]

Peter's code (attached)
http://community.atmel.com/projects/efficient-key-debounce

The following change in the Kuhn debouncer would do the same thing:

Code: [Select]

//update the integrator [0..CNT_MAX]
if ((*(key->keyread))()==KEY_NOTPRESSED) key->cnt_key = 0; //reset cnt_key if key is not pressed
else key->cnt_key += (key->cnt_key >= CNT_MAX)?0:1; //increment cnt_key otherwise

The rest remains unchanged.

Under XC8 Free, the Kuhn version compiles to 17 instructions and the Peter version compiles to 36 instructions. However, it does have the advantage of being able to read multiple buttons at once, assuming that they are on the same port.