Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #13858

Re: Counting 2ms long pulses on several input pins

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>

Show all headers | View raw


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


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