SPDT debounce doesn't
in [Basics]
|
From: John Larkin on 3 Dec 2009 18:21 On Thu, 03 Dec 2009 13:13:36 -0800, Jon Kirwan <jonk(a)infinitefactors.org> wrote: >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 So what did you do to flummox it? John
From: Jon Kirwan on 3 Dec 2009 18:59 On Thu, 03 Dec 2009 15:21:33 -0800, John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >On Thu, 03 Dec 2009 13:13:36 -0800, Jon Kirwan ><jonk(a)infinitefactors.org> wrote: > >>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 > >So what did you do to flummox it? There's no magic involved. Touch and bump and drop (like a user might, placing the equipment quickly onto a table or brushing by someone and the equipment or....) Observation does depend on what action software takes, obviously. If it takes no action, there's no problem to observe. ;) Bear in mind that your sample event might be ..1 or 1 or 10 or 100 or almost any number of microseconds after a bump event... the sampling is entirely asynchronous to the real world and the switch contact physics, as you know. And you are saying the software should take action, regardless. As I understand you. Jon
From: John Larkin on 3 Dec 2009 20:01 On Thu, 03 Dec 2009 15:59:29 -0800, Jon Kirwan <jonk(a)infinitefactors.org> wrote: >On Thu, 03 Dec 2009 15:21:33 -0800, John Larkin ><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: > >>On Thu, 03 Dec 2009 13:13:36 -0800, Jon Kirwan >><jonk(a)infinitefactors.org> wrote: >> >>>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 >> >>So what did you do to flummox it? > >There's no magic involved. Touch and bump and drop (like a user >might, placing the equipment quickly onto a table or brushing by >someone and the equipment or....) Observation does depend on what >action software takes, obviously. If it takes no action, there's no >problem to observe. ;) Bear in mind that your sample event might be >.1 or 1 or 10 or 100 or almost any number of microseconds after a bump >event... the sampling is entirely asynchronous to the real world and >the switch contact physics, as you know. And you are saying the >software should take action, regardless. As I understand you. > >Jon Sounds like a combination of bad switches, bad electronics (esd sensitivity) and bad code. So don't do that. A reasonable physical shock shouldn't cause a switch closure on a human interface panel. If you sample every 20 milliseconds, and the switch bounce is less than, say, 10 milliseconds, it just works. If you catch it in the middle of a bounce, the state is exactly as ambiguous as if you did all the debouncing in the world. I've done this on all sorts of hard and membrane switches and it works as it should. John
From: Jon Kirwan on 3 Dec 2009 20:55 On Thu, 03 Dec 2009 17:01:24 -0800, John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >On Thu, 03 Dec 2009 15:59:29 -0800, Jon Kirwan ><jonk(a)infinitefactors.org> wrote: > >>On Thu, 03 Dec 2009 15:21:33 -0800, John Larkin >><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >> >>>On Thu, 03 Dec 2009 13:13:36 -0800, Jon Kirwan >>><jonk(a)infinitefactors.org> wrote: >>> >>>>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 >>> >>>So what did you do to flummox it? >> >>There's no magic involved. Touch and bump and drop (like a user >>might, placing the equipment quickly onto a table or brushing by >>someone and the equipment or....) Observation does depend on what >>action software takes, obviously. If it takes no action, there's no >>problem to observe. ;) Bear in mind that your sample event might be >>.1 or 1 or 10 or 100 or almost any number of microseconds after a bump >>event... the sampling is entirely asynchronous to the real world and >>the switch contact physics, as you know. And you are saying the >>software should take action, regardless. As I understand you. >> >>Jon > >Sounds like a combination of bad switches, bad electronics (esd >sensitivity) and bad code. So don't do that. A reasonable physical >shock shouldn't cause a switch closure on a human interface panel. > >If you sample every 20 milliseconds, and the switch bounce is less >than, say, 10 milliseconds, it just works. If you catch it in the >middle of a bounce, the state is exactly as ambiguous as if you did >all the debouncing in the world. I've done this on all sorts of hard >and membrane switches and it works as it should. That looks like changing goal posts, to me. As I said, this comes from real experience with real equipment. I didn't design it. Switches vary a lot. And no, your argument that everything is exactly the same (ambiguous wise) no matter what you do in software doesn't make sense on its face. Software matters. And experience confirms. Jon
From: Michael A. Terrell on 3 Dec 2009 21:28
Jon Kirwan wrote: > > 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. You didn't look very hard: <http://www.cherrycorp.com/english/keyboards/Industrial/index.htm> -- The movie 'Deliverance' isn't a documentary! |