Author Topic: a hardware-independent software debouncer  (Read 12032 times)

0 Members and 2 Guests are viewing this topic.

Online nctnico

  • Super Contributor
  • ***
  • Posts: 28735
  • Country: nl
    • NCT Developments
Re: a hardware-independent software debouncer
« Reply #25 on: June 06, 2016, 08:36:52 pm »
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).
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online jpanhalt

  • Super Contributor
  • ***
  • Posts: 4252
  • Country: us
Re: a hardware-independent software debouncer
« Reply #26 on: June 07, 2016, 12:06:31 am »
@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.
« Last Edit: June 07, 2016, 01:47:29 pm by jpanhalt »
 

Offline dannyfTopic starter

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: a hardware-independent software debouncer
« Reply #27 on: June 07, 2016, 12:30:12 am »
jpanhalt: i'm happy that it is of use to you.
================================
https://dannyelectronics.wordpress.com/
 

Offline Alex Eisenhut

  • Super Contributor
  • ***
  • Posts: 3570
  • Country: ca
  • Place text here.
Re: a hardware-independent software debouncer
« Reply #28 on: June 08, 2016, 12:22:14 am »
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.
Quote
Just set the counter to zero when not pressed
:palm: 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....
Hoarder of 8-bit Commodore relics and 1960s Tektronix 500-series stuff. Unconventional interior decorator.
 

Offline obiwanjacobi

  • Super Contributor
  • ***
  • Posts: 1013
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
    • Marctronix Blog
Re: a hardware-independent software debouncer
« Reply #29 on: June 08, 2016, 07:45:57 am »
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?
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 28735
  • Country: nl
    • NCT Developments
Re: a hardware-independent software debouncer
« Reply #30 on: June 08, 2016, 07:59:49 am »
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.
Quote
Just set the counter to zero when not pressed
:palm: 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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline KL27x

  • Super Contributor
  • ***
  • Posts: 4108
  • Country: us
Re: a hardware-independent software debouncer
« Reply #31 on: June 09, 2016, 07:38:08 pm »
+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.  :-// 
« Last Edit: June 09, 2016, 07:41:44 pm by KL27x »
 

Offline wraper

  • Supporter
  • ****
  • Posts: 18227
  • Country: lv
Re: a hardware-independent software debouncer
« Reply #32 on: June 09, 2016, 07:43:11 pm »
+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?
 

Offline dannyfTopic starter

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: a hardware-independent software debouncer
« Reply #33 on: June 09, 2016, 11:58:27 pm »
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.
================================
https://dannyelectronics.wordpress.com/
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6618
  • Country: nl
Re: a hardware-independent software debouncer
« Reply #34 on: June 10, 2016, 05:34:59 am »
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.
 

Online jpanhalt

  • Super Contributor
  • ***
  • Posts: 4252
  • Country: us
Re: a hardware-independent software debouncer
« Reply #35 on: June 10, 2016, 08:06:45 am »
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 
 

Online AndyC_772

  • Super Contributor
  • ***
  • Posts: 4350
  • Country: gb
  • Professional design engineer
    • Cawte Engineering | Reliable Electronics
Re: a hardware-independent software debouncer
« Reply #36 on: June 10, 2016, 08:14:40 am »
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.

Online jpanhalt

  • Super Contributor
  • ***
  • Posts: 4252
  • Country: us
Re: a hardware-independent software debouncer
« Reply #37 on: June 10, 2016, 08:25:20 am »
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
 

Online AndyC_772

  • Super Contributor
  • ***
  • Posts: 4350
  • Country: gb
  • Professional design engineer
    • Cawte Engineering | Reliable Electronics
Re: a hardware-independent software debouncer
« Reply #38 on: June 10, 2016, 08:36:15 am »
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.

Online jpanhalt

  • Super Contributor
  • ***
  • Posts: 4252
  • Country: us
Re: a hardware-independent software debouncer
« Reply #39 on: June 10, 2016, 09:35:53 am »
@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
 

Online AndyC_772

  • Super Contributor
  • ***
  • Posts: 4350
  • Country: gb
  • Professional design engineer
    • Cawte Engineering | Reliable Electronics
Re: a hardware-independent software debouncer
« Reply #40 on: June 10, 2016, 10:08:37 am »
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.

Offline dannyfTopic starter

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: a hardware-independent software debouncer
« Reply #41 on: June 10, 2016, 10:33:11 am »
Quote
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.

Quote
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.
================================
https://dannyelectronics.wordpress.com/
 

Online jpanhalt

  • Super Contributor
  • ***
  • Posts: 4252
  • Country: us
Re: a hardware-independent software debouncer
« Reply #42 on: June 10, 2016, 11:08:09 am »
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
   
« Last Edit: June 10, 2016, 11:50:42 am by jpanhalt »
 

Offline dannyfTopic starter

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: a hardware-independent software debouncer
« Reply #43 on: June 10, 2016, 11:23:17 am »
Quote
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.
================================
https://dannyelectronics.wordpress.com/
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 28735
  • Country: nl
    • NCT Developments
Re: a hardware-independent software debouncer
« Reply #44 on: June 10, 2016, 01:51:38 pm »
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.  :palm: -out of hands and faces error-
« Last Edit: June 10, 2016, 01:55:42 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online jpanhalt

  • Super Contributor
  • ***
  • Posts: 4252
  • Country: us
Re: a hardware-independent software debouncer
« Reply #45 on: June 10, 2016, 02:16:33 pm »
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




 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 28735
  • Country: nl
    • NCT Developments
Re: a hardware-independent software debouncer
« Reply #46 on: June 10, 2016, 03:01:30 pm »
Pretty useless since 99.999% of the pushbuttons is single pole.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline bingo600

  • Super Contributor
  • ***
  • Posts: 2084
  • Country: dk
Re: a hardware-independent software debouncer
« Reply #47 on: June 10, 2016, 03:04:44 pm »
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

 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 28735
  • Country: nl
    • NCT Developments
Re: a hardware-independent software debouncer
« Reply #48 on: June 10, 2016, 03:10:09 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline dannyfTopic starter

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: a hardware-independent software debouncer
« Reply #49 on: June 10, 2016, 03:35:07 pm »
Quote
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.
================================
https://dannyelectronics.wordpress.com/
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf