SPDT debounce doesn't
in [Basics]
|
From: Jamie on 7 Dec 2009 20:13 Dan Coby wrote: > Edmond H. Wollmann wrote: > >> "John Larkin" <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in >> message news:2k3eh5lsso6nmcoejtpdq8aea5atv6thc2(a)4ax.com... >> >>> 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? >>> >>> John >> >> >> >> Hey John lackin, listen up, you are going to miss seeing the impulse >> if your software is dragged down by heavy task, especially in embedded >> system, equipped with slow CPU, don't say it won't happen, it happens >> all the time. Debouncing through hardware is the best solution, so >> your software can see wider impulse Stupid! You and John Fools are too >> goofy in your shitty brains. > > > I have built systems for over 30 years. We have never bothered doing > hardware > debouncing. Switches are sampled in a regular timer interrupt service > routine. > With this scheme, you can do whatever debouncing scheme that you want. > You can > also latch contact closures so that they can be processed whenever > desired. We > built systems using 8080s with a few Mhz clock rates with no problems. > > Only an extremely poorly designed piece of equipment would miss contact > closures > if you are sampling them with a timer interrupt. (You would have to be > missing > entire interrupt service requests and this would mean that you have > major problems.) All I ever did was disable the INT after each trigger for a short period via a timer.. On each INT trigger, I just disabled it, and then at the end of the ISR, initiate a timer for that ISR, I simply tested to see how it was configed each time it entered the ISR handler and alternated its state. This all was done in a single ISR handler instead of making two different ISRs. The uC wouldn't get flooded this way with deboucing issues.
From: John Larkin on 8 Dec 2009 22:55 On Sun, 6 Dec 2009 22:25:05 -0800, "Edmond H. Wollmann" <EHWollmann(a)aol.com> wrote: > >"John Larkin" <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in message >news:2k3eh5lsso6nmcoejtpdq8aea5atv6thc2(a)4ax.com... >> 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? >> >> John > > >Hey John lackin, listen up, you are going to miss seeing the impulse if your >software is dragged down by heavy task, especially in embedded system, equipped >with slow CPU, don't say it won't happen, it happens all the time. Debouncing >through hardware is the best solution, so your software can see wider impulse >Stupid! You and John Fools are too goofy in your shitty brains. > > > Why would a periodic IRQ fail to run because the operate side was doing stuff? You have heard of interrupts? Show us something you've designed. John
From: Rich Grise on 9 Dec 2009 15:23 On Mon, 07 Dec 2009 20:13:53 -0500, Jamie wrote: > Dan Coby wrote: >> Edmond H. Wollmann wrote: >>> "John Larkin" <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in >>>> 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? >>> >>> Hey John lackin, listen up, you are going to miss seeing the impulse if >>> your software is dragged down by heavy task, especially in embedded >>> system, equipped with slow CPU, don't say it won't happen, it happens >>> all the time. Debouncing through hardware is the best solution, so >>> your software can see wider impulse Stupid! You and John Fools are too >>> goofy in your shitty brains. >> >> I have built systems for over 30 years. We have never bothered doing >> hardware >> debouncing. Switches are sampled in a regular timer interrupt service >> routine. >> With this scheme, you can do whatever debouncing scheme that you want. >> You can >> also latch contact closures so that they can be processed whenever >> desired. We >> built systems using 8080s with a few Mhz clock rates with no problems. >> >> Only an extremely poorly designed piece of equipment would miss contact >> closures >> if you are sampling them with a timer interrupt. (You would have to be >> missing >> entire interrupt service requests and this would mean that you have >> major problems.) > All I ever did was disable the INT after each trigger for a short period > via a timer.. This happens automatically on any good processor; returning from the interupt service routine reenables automagically. > On each INT trigger, I just disabled it, and then at the end of the > ISR, initiate a timer for that ISR, I simply tested to see how it was > configed each time it entered the ISR handler and alternated its state. > > This all was done in a single ISR handler instead of making two > different ISRs. > The uC wouldn't get flooded this way with deboucing > issues. Do you have one ISR to do two different things, or are there two interrupts to initiate the same task? Thanks, Rich
From: Jamie on 9 Dec 2009 19:29 Rich Grise wrote: > On Mon, 07 Dec 2009 20:13:53 -0500, Jamie wrote: > >>Dan Coby wrote: >> >>>Edmond H. Wollmann wrote: >>> >>>>"John Larkin" <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in >>>> >>>>>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? >>>> >>>>Hey John lackin, listen up, you are going to miss seeing the impulse if >>>>your software is dragged down by heavy task, especially in embedded >>>>system, equipped with slow CPU, don't say it won't happen, it happens >>>>all the time. Debouncing through hardware is the best solution, so >>>>your software can see wider impulse Stupid! You and John Fools are too >>>>goofy in your shitty brains. >>> >>>I have built systems for over 30 years. We have never bothered doing >>>hardware >>>debouncing. Switches are sampled in a regular timer interrupt service >>>routine. >>>With this scheme, you can do whatever debouncing scheme that you want. >>>You can >>>also latch contact closures so that they can be processed whenever >>>desired. We >>>built systems using 8080s with a few Mhz clock rates with no problems. >>> >>>Only an extremely poorly designed piece of equipment would miss contact >>>closures >>>if you are sampling them with a timer interrupt. (You would have to be >>>missing >>>entire interrupt service requests and this would mean that you have >>>major problems.) > > >>All I ever did was disable the INT after each trigger for a short period >> via a timer.. > > > This happens automatically on any good processor; returning from the > interupt service routine reenables automagically. > > >> On each INT trigger, I just disabled it, and then at the end of the >>ISR, initiate a timer for that ISR, I simply tested to see how it was >>configed each time it entered the ISR handler and alternated its state. >> >> This all was done in a single ISR handler instead of making two >>different ISRs. >>The uC wouldn't get flooded this way with deboucing >>issues. > > > Do you have one ISR to do two different things, or are there two > interrupts to initiate the same task? > > Thanks, > Rich > > One ISR function block, just test a global flag to see how the event was programmed and alter the state of the flag and registers required. If a timer call this block, I disabled the timer and enabled the external event triggers and visa versa. The idea is to disable the external trigger events via config registers, so that the CPU does not get into a flooded state. When you receive an external event, process it, disable it and then enable the timer to avoid debouncing. The timer is only used to restore the external trigger events after a few ms (msec) Doing this way, you don't have a flooded condition. For me, it's simpler to do this all in one code block how ever, some uC's are a little harder to do this with and there for, 2 ISR's may make it easier to handle. But, You still need to disable the external events in both cases each time an input is active, then, re-enable it via the timer ISR. The timer ISR must be asynchronous with the external event ISR. I think you get the picture.
From: Edmond H. Wollmann on 16 Dec 2009 23:24 "John Lackin" <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in message news:cl7uh5t38ods0e154okm7764immj851iqo(a)4ax.com... > On Sun, 6 Dec 2009 22:25:05 -0800, "Edmond H. Wollmann" > <EHWollmann(a)aol.com> wrote: > >> >>"John Larkin" <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in message >>news:2k3eh5lsso6nmcoejtpdq8aea5atv6thc2(a)4ax.com... >>> 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? >>> >>> John >> >> >>Hey John lackin, listen up, you are going to miss seeing the impulse if your >>software is dragged down by heavy task, especially in embedded system, >>equipped >>with slow CPU, don't say it won't happen, it happens all the time. >>Debouncing >>through hardware is the best solution, so your software can see wider impulse >>Stupid! You and John Fools are too goofy in your shitty brains. >> >> >> > > Why would a periodic IRQ fail to run because the operate side was > doing stuff? > > You have heard of interrupts? > Show us something you've designed. > John > Yeah before you were born dumbass, if you have 40 key to debounce, I bet you won't have time for your little 3rd leg at all...heehee...... and I can debounce all 40 key with a single RC. Why should I give away my precious brain to a dumbass like you Punk?
First
|
Prev
|
Pages: 1 2 3 4 5 6 7 Prev: Absolutly Free Lectures on C++ by MIT Studied Professor Next: Cyborg Beetles |