Post by thread:[PIC] Debounce Code Idea and a Question

Hi all. I'm got a project where I'm using 4 normally open, momentary switches. The port pins are normally held high via pullups, and the switch pulls the pin to ground. Thus the normal value for the pin is high. What I ultimately want is to detect a key down event and trigger an event in my code. I don't want the event to reoccur until the switch has been released and then pressed a second time. I'm using some excellent code to debounce the switches (found here: http://www.dattalo.com/technical/software/pic/debounce.html , thanks Scott!). It's called from a interrupt routine triggered by a timer rolling over. What's great about this code is that I end up with a register that holds the debounced state of my switches, and a register that shows which switches have changed state. Rather than do a bunch of bit testing to see which bit has changed, then which direction it's changed (ie key up or key down), I've come up with the following flow: We start with two registers, the debounced state and the changes register: 11111101 - debounced output - showing one switch pressed 00000010 - changes - showing the switch has just been pressed First we invert the debounced output: 00000010 - inverted debounced output 00000010 - changes - not touched Then we AND them together and we end up with: 00000010 - which should represent the debounced output filtered for a key down operation only. So...does this sound like it might work? I feel like I've run through the possibilities but few second opinions might not be a bad idea. Also it appears that in the process of writing this email I've thought of another potential difficulty. The way I understand things, every time the debounce routine runs, it updates the "changes" output. So, once a keypress makes it through the debounce the corresponding changes bit is only set until the next time through the routine. What if instead of overwriting the changes register each time I IOR it. If I'm right, I'll end up with a status register that I can then clear when I process the event. How's that sound? Ok, that's all I can think of for now, thanks for the help! Josh -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -Douglas Adams

Josh Koffman wrote: {Quote hidden}> Hi all. I'm got a project where I'm using 4 normally open, momentary > switches. The port pins are normally held high via pullups, and the > switch pulls the pin to ground. Thus the normal value for the pin is > high. > > What I ultimately want is to detect a key down event and trigger an > event in my code. I don't want the event to reoccur until the switch > has been released and then pressed a second time. > > I'm using some excellent code to debounce the switches (found here: > http://www.dattalo.com/technical/software/pic/debounce.html , thanks > Scott!). It's called from a interrupt routine triggered by a timer > rolling over. What's great about this code is that I end up with a > register that holds the debounced state of my switches, and a register > that shows which switches have changed state. > > Rather than do a bunch of bit testing to see which bit has changed, > then which direction it's changed (ie key up or key down), I've come > up with the following flow: > > We start with two registers, the debounced state and the changes register: > 11111101 - debounced output - showing one switch pressed > 00000010 - changes - showing the switch has just been pressed > First we invert the debounced output: > 00000010 - inverted debounced output > 00000010 - changes - not touched > Then we AND them together and we end up with: > 00000010 - which should represent the debounced output filtered for a > key down operation only. > > So...does this sound like it might work? I feel like I've run through > the possibilities but few second opinions might not be a bad idea. > > Also it appears that in the process of writing this email I've thought > of another potential difficulty. The way I understand things, every > time the debounce routine runs, it updates the "changes" output. So, > once a keypress makes it through the debounce the corresponding > changes bit is only set until the next time through the routine. What > if instead of overwriting the changes register each time I IOR it. If > I'm right, I'll end up with a status register that I can then clear > when I process the event. How's that sound? Sounds like it might work. :) For anyone interested in the theory of debouncing, I recommend Ganssle's "A Guide to Debouncing": http://www.ganssle.com/debouncing.pdf I used some of the ideas from the guide to create a generic module for the PIC24/33F which is configurable (you can specify press and release debounce times) and clock speed independent. Vitaliy

Hi, What happened with good old analog debouncer? (You just need a simple RC low-pass there for each switch) My idea comes from "lets save every possible bit of memory" kind of ... Meaning, why wasting memory on debouncer code if you can just debounce it with 2-3 extra components/switch? Sincerely, Alex. 2009/6/18 Vitaliy <spam_OUTspamTakeThisOuTmaksimov.org>: {Quote hidden}> Josh Koffman wrote: >> Hi all. I'm got a project where I'm using 4 normally open, momentary >> switches. The port pins are normally held high via pullups, and the >> switch pulls the pin to ground. Thus the normal value for the pin is >> high. >> >> What I ultimately want is to detect a key down event and trigger an >> event in my code. I don't want the event to reoccur until the switch >> has been released and then pressed a second time. >> >> I'm using some excellent code to debounce the switches (found here: >> http://www.dattalo.com/technical/software/pic/debounce.html , thanks >> Scott!). It's called from a interrupt routine triggered by a timer >> rolling over. What's great about this code is that I end up with a >> register that holds the debounced state of my switches, and a register >> that shows which switches have changed state. >> >> Rather than do a bunch of bit testing to see which bit has changed, >> then which direction it's changed (ie key up or key down), I've come >> up with the following flow: >> >> We start with two registers, the debounced state and the changes register: >> 11111101 - debounced output - showing one switch pressed >> 00000010 - changes - showing the switch has just been pressed >> First we invert the debounced output: >> 00000010 - inverted debounced output >> 00000010 - changes - not touched >> Then we AND them together and we end up with: >> 00000010 - which should represent the debounced output filtered for a >> key down operation only. >> >> So...does this sound like it might work? I feel like I've run through >> the possibilities but few second opinions might not be a bad idea. >> >> Also it appears that in the process of writing this email I've thought >> of another potential difficulty. The way I understand things, every >> time the debounce routine runs, it updates the "changes" output. So, >> once a keypress makes it through the debounce the corresponding >> changes bit is only set until the next time through the routine. What >> if instead of overwriting the changes register each time I IOR it. If >> I'm right, I'll end up with a status register that I can then clear >> when I process the event. How's that sound? > > Sounds like it might work. :) > > For anyone interested in the theory of debouncing, I recommend Ganssle's "A > Guide to Debouncing": > > http://www.ganssle.com/debouncing.pdf > > I used some of the ideas from the guide to create a generic module for the > PIC24/33F which is configurable (you can specify press and release debounce > times) and clock speed independent. > > Vitaliy > > -

You know this debounce topic comes up with regularity. Someone in the past commented that, **user input**, they were not convinced that you need to do debouncing per se. If you can arrange to periodically poll your inputs, less often than the debounce period, but often enough for a good user experience, tehn you can dispense with the classic debounce methods. According to http://www.ganssle.com/debouncing.pdf, most switches bounced <6.2ms (there was one worst case of bouncing for 157ms when opening!) So, a poll-period of >10ms should cover almost all switches, and give a response time of two times that. David Quoting Alex <aleksancKILLspamgmail.com>: {Quote hidden}> > Hi, > > What happened with good old analog debouncer? (You just need a simple > RC low-pass there for each switch) > > My idea comes from "lets save every possible bit of memory" kind of > ... Meaning, why wasting memory on debouncer code if you can just > debounce it with 2-3 extra components/switch? > > Sincerely, > Alex. > > 2009/6/18 Vitaliy <.....spamKILLspam.....maksimov.org>: > > Josh Koffman wrote: > >> Hi all. I'm got a project where I'm using 4 normally open, momentary > >> switches. The port pins are normally held high via pullups, and the > >> switch pulls the pin to ground. Thus the normal value for the pin is > >> high. > >> > >> What I ultimately want is to detect a key down event and trigger an > >> event in my code. I don't want the event to reoccur until the switch > >> has been released and then pressed a second time. > >> > >> I'm using some excellent code to debounce the switches (found here: > >> http://www.dattalo.com/technical/software/pic/debounce.html , thanks > >> Scott!). It's called from a interrupt routine triggered by a timer > >> rolling over. What's great about this code is that I end up with a > >> register that holds the debounced state of my switches, and a register > >> that shows which switches have changed state. > >> > >> Rather than do a bunch of bit testing to see which bit has changed, > >> then which direction it's changed (ie key up or key down), I've come > >> up with the following flow: > >> > >> We start with two registers, the debounced state and the changes > register: > >> 11111101 - debounced output - showing one switch pressed > >> 00000010 - changes - showing the switch has just been pressed > >> First we invert the debounced output: > >> 00000010 - inverted debounced output > >> 00000010 - changes - not touched > >> Then we AND them together and we end up with: > >> 00000010 - which should represent the debounced output filtered for a > >> key down operation only. > >> > >> So...does this sound like it might work? I feel like I've run through > >> the possibilities but few second opinions might not be a bad idea. > >> > >> Also it appears that in the process of writing this email I've thought > >> of another potential difficulty. The way I understand things, every > >> time the debounce routine runs, it updates the "changes" output. So, > >> once a keypress makes it through the debounce the corresponding > >> changes bit is only set until the next time through the routine. What > >> if instead of overwriting the changes register each time I IOR it. If > >> I'm right, I'll end up with a status register that I can then clear > >> when I process the event. How's that sound? > > > > Sounds like it might work. :) > > > > For anyone interested in the theory of debouncing, I recommend Ganssle's > "A > > Guide to Debouncing": > > > > http://www.ganssle.com/debouncing.pdf > > > > I used some of the ideas from the guide to create a generic module for the > > PIC24/33F which is configurable (you can specify press and release > debounce > > times) and clock speed independent. > > > > Vitaliy > > > > --

Alex wrote: > What happened with good old analog debouncer? (You just need a simple > RC low-pass there for each switch) > > My idea comes from "lets save every possible bit of memory" kind of > ... Meaning, why wasting memory on debouncer code if you can just > debounce it with 2-3 extra components/switch? Because memory is free and components cost real money and space, of course. For most applications, your strategy is backwards. As long as the little extra code space, RAM, and cycles required to do debouncing in firmware don't require the next size up processor, firmware debouncing is free. Since these requirements are minimial, this is usually the case. Then there is the separate issue that firmware debouncing is better. A low pass filter is *not* debouncing, although it can alleviate the issue to a reasonable extent in some cases, it is not a true fix. That would require additional hysteresis or explicit timing like a one-shot. In other words, true debouncing requires something non-linear, which is simple to do in firmware and less so in hardware. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

Actually, debouncing _IS_ a time - related matter. Only firmware means can reliably resolve debounce issues. Well-said, Olin. --Bob On 6/18/09, Olin Lathrop <EraseMEolin_piclistspam_OUTTakeThisOuTembedinc.com> wrote: {Quote hidden}> Alex wrote: >> What happened with good old analog debouncer? (You just need a simple >> RC low-pass there for each switch) >> >> My idea comes from "lets save every possible bit of memory" kind of >> ... Meaning, why wasting memory on debouncer code if you can just >> debounce it with 2-3 extra components/switch? > > Because memory is free and components cost real money and space, of course. > > For most applications, your strategy is backwards. As long as the little > extra code space, RAM, and cycles required to do debouncing in firmware > don't require the next size up processor, firmware debouncing is free. > Since these requirements are minimial, this is usually the case. > > Then there is the separate issue that firmware debouncing is better. A low > pass filter is *not* debouncing, although it can alleviate the issue to a > reasonable extent in some cases, it is not a true fix. That would require > additional hysteresis or explicit timing like a one-shot. In other words, > true debouncing requires something non-linear, which is simple to do in > firmware and less so in hardware. > > > ******************************************************************** > Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products > (978) 742-9014. Gold level PIC consultants since 2000. > -

On Thu, 18 Jun 2009 12:22:05 -0700, you wrote: >According to http://www.ganssle.com/debouncing.pdf, most switches bounced <6.2ms >(there was one worst case of bouncing for 157ms when opening!) >So, a poll-period of >10ms should cover almost all switches, and give a response >time of two times that. What is the 'bounce' time for contacts on a membrane keypad (without clicky discs) or the rubber keypads with carbon 'pills'. Very variable and user dependent I imagine. I used to have a Binatone DECT phone with the most annoying keypad I have ever used. They somehow managed to disconnect the debounce from the audible confirmation beeps. I would dial a number looking at the keypad and be absolutely certain I heard a beep for every digit I pressed, the call would fail then I look at the LCD to see a digit was missing. Unbelievable.

Quoting Terry Harris <terry.harrisspam_OUTiname.com>: > > On Thu, 18 Jun 2009 12:22:05 -0700, you wrote: > > >According to http://www.ganssle.com/debouncing.pdf, most switches bounced > <6.2ms > >(there was one worst case of bouncing for 157ms when opening!) > > >So, a poll-period of >10ms should cover almost all switches, and give a > response > >time of two times that. > > What is the 'bounce' time for contacts on a membrane keypad (without clicky > discs) or the rubber keypads with carbon 'pills'. Very variable and user > dependent I imagine. I don't know, and I suspect, as you do, they are very variable. However, one still needs to wait for whatever bouncing is occurring to end; whether the method used employs a busy-wait, a timed interrupt, or the method that I outlined. The first busy-wait wastes the cpu cycles during it, the interrupt method is uses up resources. The last would appear to be sufficient, and it is likely that it fits nicely into the (pre-existing) background loop found in many programs that implement a UI. > I used to have a Binatone DECT phone with the most annoying keypad I have > ever used. They somehow managed to disconnect the debounce from the audible > confirmation beeps. I would dial a number looking at the keypad and be > absolutely certain I heard a beep for every digit I pressed, the call would > fail then I look at the LCD to see a digit was missing. Unbelievable. I think I would find that distressing to the point of turning the phone into a short-lived projectile ;-) David

dpharris@telus.net wrote: >> What is the 'bounce' time for contacts on a membrane keypad (without >> clicky >> discs) or the rubber keypads with carbon 'pills'. Very variable and user >> dependent I imagine. > > I don't know, and I suspect, as you do, they are very variable. However, > one > still needs to wait for whatever bouncing is occurring to end; whether the > method used employs a busy-wait, a timed interrupt, or the method that I > outlined. The first busy-wait wastes the cpu cycles during it, the > interrupt > method is uses up resources. The last would appear to be sufficient, and > it is > likely that it fits nicely into the (pre-existing) background loop found > in many > programs that implement a UI. Ganssle describes a method where you shift in a '1' or a '0' into a byte (or an int16, etc) and then compare the result with 0x00 or 0xFF. You can enhance it further by checking the timer before shifting a bit in, to ensure you don't sample too fast. Vitaliy

On Thu, Jun 18, 2009 at 12:22 PM, <@spam@dpharrisKILLspamtelus.net> wrote: > > According to http://www.ganssle.com/debouncing.pdf, most switches bounced > <6.2ms > (there was one worst case of bouncing for 157ms when opening!) I took that one to be an "outlier" . I once had a switch that would "bounce" the entire time it was held. So that makes infinity the upper limit on bounce time. I agree that 10ms is the most practical sample time. I also agree with others' experience; having done this debouncing thing for years, when I get a consumer gadget were the keys are not "done right", I know it right away. Come to think of it, the so-called "power" switch on my aging 533 Pentium is such that if I use it to power-off while booting, the machine will turn back on when I release it! Barry