SPDT debounce doesn't
in [Basics]
|
From: John Larkin on 3 Dec 2009 14:26 On Thu, 03 Dec 2009 10:51:02 -0800, Jon Kirwan <jonk(a)infinitefactors.org> wrote: >On Thu, 03 Dec 2009 08:51:55 -0800, John Larkin ><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: > >>On Wed, 02 Dec 2009 19:36:56 -0800, Jon Kirwan >><jonk(a)infinitefactors.org> wrote: >> >>>On Wed, 02 Dec 2009 17:04:40 -0800, John Larkin >>><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >>> >>>>On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan >>>><jonk(a)infinitefactors.org> wrote: >>>> >>>>>On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin >>>>><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >>>>> >>>>>><snip> >>>>>>If you sample the switch state every, say, 20 milliseconds, and act on >>>>>>what you see, there's no need to debounce at all. >>>>> >>>>>I am generally able to tell when, and usually am annoyed by, equipment >>>>>sampling that way. >>>>> >>>>>Jon >>>> >>>>Can you push a button for less than 20 milliseconds? >>> >>>That's not exactly how I tell. And I can tell. >>> >>>Jon >> >>How can you tell that the software is sampling every 20 milliseconds >>if you can't push the button for less than that? Can you visually pick >>out the 50 Hz quantization of switch service, even assuming the >>associated display has instantaneous update? >> >>And how can you tell a simple 20 ms sample loop from your 3-sample 8 >>ms debounce algorithm? >> >>Maybe you could tell at 100 ms. Not at 20. >> >>Debouncing is like bypassing. All sorts of weird religions exist. > >Don't accuse me of being religious about this. It's experience with >real products, doing beta testing in a lab. The programmer who'd used >your technique told me how he'd written the code and I then knew what >to do to show him. It was kind of funny to see his face, then. I don't know that his code "used my technique." Maybe he wrote a messy switch service routine. Lots of people do. > >Keep in mind you are talking about a single sample and acting upon it. >That's the key. Not the 20ms period, which I consider fine. So stop >focusing on that aspect and you might begin to see. > >Jon So what do you do to a pushbutton that can differentiate between a 20 ms single sample loop and a 3x8 ms debounce loop? The only advantage of the multi-sample thing is some added EMI/ESD rejection. But ESD is a physical hazard to the uP, so if there's an ESD path it should be taken care of electrically. John
From: IanM on 3 Dec 2009 15:46 Jon Kirwan wrote: > On Thu, 03 Dec 2009 08:51:55 -0800, John Larkin > <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: > >> On Wed, 02 Dec 2009 19:36:56 -0800, Jon Kirwan >> <jonk(a)infinitefactors.org> wrote: >> >>> On Wed, 02 Dec 2009 17:04:40 -0800, John Larkin >>> <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >>> >>>> On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan >>>> <jonk(a)infinitefactors.org> wrote: >>>> >>>>> On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin >>>>> <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >>>>> >>>>>> <snip> >>>>>> If you sample the switch state every, say, 20 milliseconds, and act on >>>>>> what you see, there's no need to debounce at all. >>>>> I am generally able to tell when, and usually am annoyed by, equipment >>>>> sampling that way. >>>>> >>>>> Jon >>>> Can you push a button for less than 20 milliseconds? >>> That's not exactly how I tell. And I can tell. >>> >>> Jon >> How can you tell that the software is sampling every 20 milliseconds >> if you can't push the button for less than that? Can you visually pick >> out the 50 Hz quantization of switch service, even assuming the >> associated display has instantaneous update? >> >> And how can you tell a simple 20 ms sample loop from your 3-sample 8 >> ms debounce algorithm? >> >> Maybe you could tell at 100 ms. Not at 20. >> >> Debouncing is like bypassing. All sorts of weird religions exist. > > Don't accuse me of being religious about this. It's experience with > real products, doing beta testing in a lab. The programmer who'd used > your technique told me how he'd written the code and I then knew what > to do to show him. It was kind of funny to see his face, then. > > Keep in mind you are talking about a single sample and acting upon it. > That's the key. Not the 20ms period, which I consider fine. So stop > focusing on that aspect and you might begin to see. > > Jon Its fairly easy to hit a key fast enough so the uP doesn't respond if the debouncing is too 'clever' Even on this Cherry MX11900 keyboard, I can hit a key too fast for it to register. Not consistently, and it does require an aggressive wrist flick with a carefully aimed relaxed but extended finger so scarcely normal operation but it can be done about 20% of the time. The key is bottoming out fully so I'm not failing to make contact. -- Ian Malcolm. London, ENGLAND. (NEWSGROUP REPLY PREFERRED) ianm[at]the[dash]malcolms[dot]freeserve[dot]co[dot]uk [at]=@, [dash]=- & [dot]=. *Warning* HTML & >32K emails --> NUL:
From: Jon Kirwan on 3 Dec 2009 16:13 On Thu, 03 Dec 2009 11:26:42 -0800, John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >On Thu, 03 Dec 2009 10:51:02 -0800, Jon Kirwan ><jonk(a)infinitefactors.org> wrote: > >>On Thu, 03 Dec 2009 08:51:55 -0800, John Larkin >><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >> >>>On Wed, 02 Dec 2009 19:36:56 -0800, Jon Kirwan >>><jonk(a)infinitefactors.org> wrote: >>> >>>>On Wed, 02 Dec 2009 17:04:40 -0800, John Larkin >>>><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >>>> >>>>>On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan >>>>><jonk(a)infinitefactors.org> wrote: >>>>> >>>>>>On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin >>>>>><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >>>>>> >>>>>>><snip> >>>>>>>If you sample the switch state every, say, 20 milliseconds, and act on >>>>>>>what you see, there's no need to debounce at all. >>>>>> >>>>>>I am generally able to tell when, and usually am annoyed by, equipment >>>>>>sampling that way. >>>>>> >>>>>>Jon >>>>> >>>>>Can you push a button for less than 20 milliseconds? >>>> >>>>That's not exactly how I tell. And I can tell. >>>> >>>>Jon >>> >>>How can you tell that the software is sampling every 20 milliseconds >>>if you can't push the button for less than that? Can you visually pick >>>out the 50 Hz quantization of switch service, even assuming the >>>associated display has instantaneous update? >>> >>>And how can you tell a simple 20 ms sample loop from your 3-sample 8 >>>ms debounce algorithm? >>> >>>Maybe you could tell at 100 ms. Not at 20. >>> >>>Debouncing is like bypassing. All sorts of weird religions exist. >> >>Don't accuse me of being religious about this. It's experience with >>real products, doing beta testing in a lab. The programmer who'd used >>your technique told me how he'd written the code and I then knew what >>to do to show him. It was kind of funny to see his face, then. > >I don't know that his code "used my technique." Maybe he wrote a messy >switch service routine. Lots of people do. Actually, you bring up a good point. Not exactly the "messy" one, but another. I really don't have a full view of your method (you wrote simply, not fully) nor do I know the application space, switches used, etc. So I'm going on fumes, to be honest. The main thing, though, is the focus on using a single sample and acting on it. Not for every situation, but quite frequently in my experience this is a problem waiting to happen. >>Keep in mind you are talking about a single sample and acting upon it. >>That's the key. Not the 20ms period, which I consider fine. So stop >>focusing on that aspect and you might begin to see. > >So what do you do to a pushbutton that can differentiate between a 20 >ms single sample loop and a 3x8 ms debounce loop? > >The only advantage of the multi-sample thing is some added EMI/ESD >rejection. But ESD is a physical hazard to the uP, so if there's an >ESD path it should be taken care of electrically. In the case I was referring to, the programmer used a timer to set the sampling event and I didn't even need to look at the code. I assumed he was right about what he told me and didn't assume he wrote crappy code (he was experienced with both c and assembly and had been working in instrumentation for years.) The hardware was designed by a very thorough-going guy (who is now working in the medical products field) who I would watch use a 20kV zap-gun and would run around the aluminum casing zapping everywhere to make sure it was pretty solid. It was. So I'm probably not confusing ESD sensitivity here. I had instantly imagined how to flummox the software and it took only a minute or two to get him to see problems happen. His situation was a simple, scanned 4x4 matrix using the method you talked about. By the way, he'd tested his system and had encountered no problems in his own testing. He felt it was really pretty good. Until.... I don't consider acting on every 20ms observation 'solid.' And often, instrumentation developers "assume" a lot about how others might use their equipment and come away from their own testing feeling they have tested it well and the result is 'bullet proof.' In this guy's case, he felt really good about it. And when he saw me flummox it, he didn't argue with me about "well, no customer would do that!" He recognized immediately that some might do exactly "that." It had simply slipped by him to imagine the kinds of accidental things that actually happen in real situations. Long, long ago I learned that the very small effort involved (and almost zero overhead in execution time) goes a long way mitigating such things. All from real experience and actual practice. Most of the time, no one notices the difference. But when it matters, it matters. Best to go the extra mile. It's really not hard and does mitigate a few after-sale calls that can cost some money to handle. Not telling you what to do, though. Have at it. YMMV applies. Jon
From: Jon Kirwan on 3 Dec 2009 16:15 On Thu, 03 Dec 2009 20:46:16 +0000, IanM <look.in.my.sig(a)totally.invalid> wrote: >Jon Kirwan wrote: >> On Thu, 03 Dec 2009 08:51:55 -0800, John Larkin >> <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >> >>> On Wed, 02 Dec 2009 19:36:56 -0800, Jon Kirwan >>> <jonk(a)infinitefactors.org> wrote: >>> >>>> On Wed, 02 Dec 2009 17:04:40 -0800, John Larkin >>>> <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >>>> >>>>> On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan >>>>> <jonk(a)infinitefactors.org> wrote: >>>>> >>>>>> On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin >>>>>> <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >>>>>> >>>>>>> <snip> >>>>>>> If you sample the switch state every, say, 20 milliseconds, and act on >>>>>>> what you see, there's no need to debounce at all. >>>>>> I am generally able to tell when, and usually am annoyed by, equipment >>>>>> sampling that way. >>>>>> >>>>>> Jon >>>>> Can you push a button for less than 20 milliseconds? >>>> That's not exactly how I tell. And I can tell. >>>> >>>> Jon >>> How can you tell that the software is sampling every 20 milliseconds >>> if you can't push the button for less than that? Can you visually pick >>> out the 50 Hz quantization of switch service, even assuming the >>> associated display has instantaneous update? >>> >>> And how can you tell a simple 20 ms sample loop from your 3-sample 8 >>> ms debounce algorithm? >>> >>> Maybe you could tell at 100 ms. Not at 20. >>> >>> Debouncing is like bypassing. All sorts of weird religions exist. >> >> Don't accuse me of being religious about this. It's experience with >> real products, doing beta testing in a lab. The programmer who'd used >> your technique told me how he'd written the code and I then knew what >> to do to show him. It was kind of funny to see his face, then. >> >> Keep in mind you are talking about a single sample and acting upon it. >> That's the key. Not the 20ms period, which I consider fine. So stop >> focusing on that aspect and you might begin to see. >> >> Jon >Its fairly easy to hit a key fast enough so the uP doesn't respond if >the debouncing is too 'clever' Even on this Cherry MX11900 keyboard, I >can hit a key too fast for it to register. Not consistently, and it >does require an aggressive wrist flick with a carefully aimed relaxed >but extended finger so scarcely normal operation but it can be done >about 20% of the time. The key is bottoming out fully so I'm not >failing to make contact. Interesting points. Speaking of Cherry, I still have one of their really nice keyboards that uses reed relays under each and every switch and donut magnets in the key plungers. Absolutely rock solid. Damned if I can find anything like that being build, today. Jon
From: Rich Grise on 3 Dec 2009 18:20
On Thu, 03 Dec 2009 20:46:16 +0000, IanM wrote: > Jon Kirwan wrote: >> On Thu, 03 Dec 2009 08:51:55 -0800, John Larkin >>> On Wed, 02 Dec 2009 19:36:56 -0800, Jon Kirwan >>>> On Wed, 02 Dec 2009 17:04:40 -0800, John Larkin >>>>> On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan >>>>>> On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin >>>>>> >>>>>>> <snip> >>>>>>> If you sample the switch state every, say, 20 milliseconds, and act >>>>>>> on what you see, there's no need to debounce at all. >>>>>> I am generally able to tell when, and usually am annoyed by, >>>>>> equipment sampling that way. >>>>>> >>>>> Can you push a button for less than 20 milliseconds? >>>> That's not exactly how I tell. And I can tell. >>>> >>> How can you tell that the software is sampling every 20 milliseconds if >>> you can't push the button for less than that? Can you visually pick out >>> the 50 Hz quantization of switch service, even assuming the associated >>> display has instantaneous update? >>> >>> And how can you tell a simple 20 ms sample loop from your 3-sample 8 ms >>> debounce algorithm? >>> >>> Maybe you could tell at 100 ms. Not at 20. >>> >>> Debouncing is like bypassing. All sorts of weird religions exist. >> >> Don't accuse me of being religious about this. It's experience with >> real products, doing beta testing in a lab. The programmer who'd used >> your technique told me how he'd written the code and I then knew what to >> do to show him. It was kind of funny to see his face, then. >> >> Keep in mind you are talking about a single sample and acting upon it. >> That's the key. Not the 20ms period, which I consider fine. So stop >> focusing on that aspect and you might begin to see. >> > Its fairly easy to hit a key fast enough so the uP doesn't respond if the > debouncing is too 'clever' Even on this Cherry MX11900 keyboard, I can > hit a key too fast for it to register. Not consistently, and it does > require an aggressive wrist flick with a carefully aimed relaxed but > extended finger so scarcely normal operation but it can be done about 20% > of the time. The key is bottoming out fully so I'm not failing to make > contact. Or you could hack into a $5.00 or surplus (free) PC keyboard: http://mysite.verizon.net/richgrise/KeyZilla/ Cheers! Rich |