[CCC DEV] More on debounce - probable bug

[Matt Jadud]

On Wed, Jan 26, 2011 at 18:11, Steve Pretty
<steve.g.pretty at btinternet.com> wrote:
> Well, the reason I was looking at it was because I have been getting some
> unexpected results when using it.  I created an "instrumented" version of

We do this, too.

> debounce.  A lot of the time it is 1 - which means no additional bounce
> interrupts occurred.  The line continues by saying what LEVEL was sent to

In part, this is because the runtime isn't terribly fast.

> I have experienced the problem with two different types of switch. Changing
> the length of the debounce timer has no effect.

Below a point it will make no difference. I forget what the shortest
delay is that we can actually wait for. ~10 ms, I think. (That is, the
scheduler takes a finite amount of time to run around. We should
quantify that.)

> the state change, when the signal will be most noisy - and we trust this
> reading and pass it on unchanged through debounce.  So basically, that means
> debounce does not work properly - all it is doing is ensuring there is a

Our code is, as you have learned by now Steve, perfect. I'm afraid
you're going to have to look for another possible source of error.

> Now, I suspect you have not experienced this problem, because as we have
> discussed, your current version of digital.input has a "feature" where it

Correct. Also, see previous comment.

> 1. Eliminate debounce at source - The input pins have schmitt trigger

Agreed - awful solution.

> 2. Add a 50 ms delay into digital.input before doing the digital.read  -
> effectively doing the debounce in there.  Dont like that one - it rather

Elch. Also ugly. Agreed.

> 3. Take another look at debounce - I believe if a bounce does occur, we can

Which we only gave it a first look, so yes.

> Tests on this approach look solid so far
>
> (It is a shame that I will have to press my button an infinite number of
> times to be sure this new version of debounce never emits the wrong value!)

When you finish testing, do submit a patch. ;)

Humor aside, if you have a second Arduino, you could test it by
driving a pin up-and-down at different rates, and see what the
occam-powered Arduino thinks of it. (I have enough Arduinos free to do
this.) That would give us a fairly reliable edge to work with, with
fairly precise timing, and we could find out where debounce breaks
down.

That would be one way to test this. (I think your code and reasoning
looks sound, but we could do a test like that to see how this fares.)

I think this looks reasonable. I have an
clock-and-PIR-interrupt-driven sensor that I've just worked on; I'll
substitute your debounce() in on my local machine, and see what
happens to my sensor. It should still "just work."

Many thanks, Steve. As a question to the list: does this kind of patch
extend the copyright on the source file? Or, do we develop an acks
file in the repos? What is the right way to ack these kinds of
patches/contributions?

Cheers,
Matt