Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #13853
| From | Don Y <this@isnotme.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Counting 2ms long pulses on several input pins |
| Date | 2013-09-24 09:55 -0700 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <l1sg5m$6it$1@speranza.aioe.org> (permalink) |
| References | <l1qck1$9dd$4@dont-email.me> <7x61trxaam.fsf@ruckus.brouhaha.com> <52412bde$0$15931$e4fe514c@news2.news.xs4all.nl> <l1rffo$37b$2@speranza.aioe.org> <52414c4e$0$15979$e4fe514c@news2.news.xs4all.nl> |
Hi Arlet,
On 9/24/2013 1:24 AM, Arlet Ottens wrote:
> On 09/24/2013 09:37 AM, 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)
Scanning contact closures is NOT where you are going to come up
with those HUGE SAVINGS that are going to make/brake your product
or implementation. Invest the little extra code and state to
do the job reliably and you can reuse the algorithm far more
often and reliably than if you try to be "too clever".
WRT "buttons":
Most "people" tend to think "a switch is a switch". E.g., the
marketing guy figures you can sell a waterproof version of the
EXISTING product just by substituting a few components. So, he
comes along and replaces an Hg-wetted, magnetically actuated reed
switch with a membrane switch and wonders why things don't work
anymore.
Things like button bounce are *very* prominent in the user experience.
If the user has to deliberately focus on HOW he presses a button, your
product draws unnecessary attention to itself.
We have a clothes dryer (or, maybe its the washer, I can't recall which)
that requires you to *hold* the power button engaged. It is noticeable
(because the mating appliance doesn't exhibit this behavior). So,
instead of just pushing the button and moving on to the next step
in configuring the product for use, I have to deliberately pause and
*focus* on "turning the power on".
I have a (cheap) flashlight that has a single button that controls
multiple functions (press once for X, twice for Y, three times for Z,
etc.). Over time, it has developed significant bounce. So, I
have to be very careful and deliberate each time I turn it on/off, etc.
Similarly, I have a "ball cap" with LEDs in the bill (*almost* a
toy -- though it does have use in some hands-free uses). It is
the penultimate example of a multifunction button (each button
press cycles the LED controller through different patterns, etc.)!
But, the manufacturer encased the button in a rubber boot (presumably
to make it water-resistant? wear the hat in the rain??). So, it is
much harder to press than you would expect. Couple this with the
fact that the various light patterns include complex blinking patterns
(which are not obvious without *watching* the lights for a second or
two to identify which sequence is in play), and the choice of a
single button control ("UI") makes the experience (UX) tedious
[E.g., you're never completely sure you have returned the
controller to the "full off" condition -- or, if you have just
selected a slow blink pattern!]
> Of course, the OP has to determine whether there is a suitable polling
> frequency that satisfies all the requirements.
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