Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #13858
| From | Don Y <this@isnotme.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Counting 2ms long pulses on several input pins |
| Date | 2013-09-24 11:13 -0700 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <l1sko8$k38$1@speranza.aioe.org> (permalink) |
| References | (2 earlier) <52412bde$0$15931$e4fe514c@news2.news.xs4all.nl> <l1rffo$37b$2@speranza.aioe.org> <52414c4e$0$15979$e4fe514c@news2.news.xs4all.nl> <l1sg5m$6it$1@speranza.aioe.org> <5241ce05$0$15873$e4fe514c@news2.news.xs4all.nl> |
Hi Arlet, [Grrrr.... I always want to type "Arlett"! No doubt a consequence of your surname] On 9/24/2013 10:38 AM, Arlet Ottens wrote: > On 09/24/2013 06:55 PM, Don Y wrote: > >>>>> Polling at ~1kHz frequency may not be so bad, and gives you automatic >>>>> debouncing. >>>>> >>>>> Simple method: read all switches (possibly in single read from IO >>>>> port), >>>>> and put the state in a bitmap. Compare with bitmap from last time, and >>>>> every switch that went from 0->1 is considered pushed at that time. >>>> >>>> Only if there is no bounce! Consider seeing a switch go from 0 to 1 >>>> to 0 to 1 to 0 to 1 (thereafter). Is this *one* or *three* switch >>>> closures? >>> >>> The idea is that the polling routine is slow enough that the bouncing >>> has stopped before the next poll, and that every 0->1 transition should >>> count as a real closure. >> >> This seems like a bug waiting to manifest. A "contact's" dynamic >> characteristics can vary a lot over the life of a product (esp >> with very low voltage switching). Or, over operating conditions >> (do the dynamics of the mechanism change as the cams actuate >> more often or with shorter dwell times) > > How would this bug occur ? If the switch stays in 0 for at least one > polling period, bounces for less than a period, and stays in 1 for at > least one period, my simple algorithm will capture this reliably. It happens when the switches characteristics -- or conditions under which it operates -- change over time. E.g., "bounces for MORE than a period". Alternatively, "stays in 0 for LESS than one polling period". Or, the switch is replaced by a mechanism with different characteristics entirely (my "a switch is a switch" comment). Or, the code is lifted and reused in some other (inappropriate) project. > Of course if the switch bounce time exceeds the period of interest you > want to capture (say you want to capture 1000 useful events per second, > and the switch bounces for 5 ms), no algorithm is going to save you. > You'll need a better switch. Chances are, the limitations of your debounce algorithm (along with most other algorithms in your design) aren't spelled out in simple terms in a place where someone wanting to modify the hardware/software/specification can quickly review them for the downside consequences of any proposed changes. This leads to those annoying pointy-head conversations where you have to tell your boss/client that this "simple" change is going to take a week to implement/test: "Huh? Why can't we just use this different switch?? Why can't we just change the cam dwell to 7 degrees from 10?? etc." Then, as their frustration mounts, trying to reassure them that there was a *reason* you "crippled" (in their eyes) the algorithm in this way. So, they should, in a perverse sense, be HAPPY that it will take a week! (otherwise, it would imply you were using an inappropriate algorithm). [I'm sure we've *all* been through those sorts of "discussions"]
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Counting 2ms long pulses on several input pins pozz <pozzugno@gmail.com> - 2013-09-23 23:42 +0200
Re: Counting 2ms long pulses on several input pins mike <ham789@netzero.net> - 2013-09-23 15:00 -0700
Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-23 16:12 -0700
Re: Counting 2ms long pulses on several input pins Paul Rubin <no.email@nospam.invalid> - 2013-09-23 18:45 -0700
Re: Counting 2ms long pulses on several input pins Arlet Ottens <usenet+5@c-scape.nl> - 2013-09-24 08:06 +0200
Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 00:37 -0700
Re: Counting 2ms long pulses on several input pins Arlet Ottens <usenet+5@c-scape.nl> - 2013-09-24 10:24 +0200
Re: Counting 2ms long pulses on several input pins Paul Rubin <no.email@nospam.invalid> - 2013-09-24 02:05 -0700
Re: Counting 2ms long pulses on several input pins Arlet Ottens <usenet+5@c-scape.nl> - 2013-09-24 11:01 +0200
Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 09:55 -0700
Re: Counting 2ms long pulses on several input pins Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-24 18:13 +0100
Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 11:03 -0700
Re: Counting 2ms long pulses on several input pins Arlet Ottens <usenet+5@c-scape.nl> - 2013-09-24 19:38 +0200
Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 11:13 -0700
Re: Counting 2ms long pulses on several input pins Arlet Ottens <usenet+5@c-scape.nl> - 2013-09-24 20:30 +0200
Re: Counting 2ms long pulses on several input pins Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-09-24 21:20 +0100
Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 16:08 -0700
Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 00:34 -0700
Re: Counting 2ms long pulses on several input pins Andrew Smallshaw <andrews@sdf.lonestar.org> - 2013-09-24 04:31 +0000
Re: Counting 2ms long pulses on several input pins Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-09-24 11:15 +0100
Re: Counting 2ms long pulses on several input pins Paul <paul@pcserviceselectronics.co.uk> - 2013-09-24 15:51 +0100
Re: Counting 2ms long pulses on several input pins pozz <pozzugno@gmail.com> - 2013-09-25 00:33 +0200
Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 16:36 -0700
Re: Counting 2ms long pulses on several input pins pozz <pozzugno@gmail.com> - 2013-09-25 07:39 +0200
Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-24 23:37 -0700
Re: Counting 2ms long pulses on several input pins pozz <pozzugno@gmail.com> - 2013-09-27 15:54 +0200
Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-27 12:35 -0700
Re: Counting 2ms long pulses on several input pins mike <ham789@netzero.net> - 2013-09-24 16:43 -0700
Re: Counting 2ms long pulses on several input pins j.m.granville@gmail.com - 2013-09-24 17:32 -0700
Re: Counting 2ms long pulses on several input pins Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2013-09-25 09:52 +0300
Re: Counting 2ms long pulses on several input pins Don Y <this@isnotme.com> - 2013-09-25 00:09 -0700
Re: Counting 2ms long pulses on several input pins j.m.granville@gmail.com - 2013-09-25 16:53 -0700
csiph-web