[Pin2 Style Works 2000 Universal
Amancio Mccrae
I was inspired to create this debouncer after reading this great debouncing guide, especially referring to the last plot of the microswitch on page 8, where it says "I found it usually generated a pulse train guaranteed to play havoc with simple filter code. There's no high speed hash, just hard-to-eliminate solid ones and zeroes."
Hello Caltoa,
This is my attempt at writing a universal input de-bouncer/filter function that is hopefully easy to use. I'm still quite green at programming, however I've tested this with random patterns by simulating noise (signal generator) and touching bare wires. It seems to work as intended. I'm asking if anyone is interested in testing and finds any issues, to please comment.
Regards,
dlloyd
tgsuperspec, I like your generic read / debounce code because it looks for 2 equal reads before confirmation. So it would work both when the signal goes high or when it goes low. Also, you can change the number of equal reads in your define DebounceCount.
I see it mentions "one pin at a time every 5 mS" for reading our inputs. It looks like this time is set elsewhere to establish an interval between reads, so I guess the overall debounce time is 10 mS. So, for example, if there were 10 pins to debounce, would this increase the latency by 90 mS?
The code I posted works on an array of inputs (the example shows 10, but it can be anything from 1 input up to all available inputs). All inputs are read at once. I've set the interval between complete array reads to 2 mS.
Rather than each input requiring 1 byte for each reading, I use the byte as a shift register to store the history of the previous 8 readings. From this moving snapshot in time, the required pattern for rising and falling status are determined and used to change the output state.
An advantage is the rolling filter action where spurious noise is continuously rejected and never falsely triggers the debouncer. Using this method, it's possible (for example) to successfully debounce an input having 30 mS bounce time where the debounced signal is clean and responds in only 40 mS.
I was inspired to create this debouncer after reading this great article, especially referring to the last 2 plots of the microswitch where it says "I found it usually generated a pulse train guaranteed to play havoc with simple filter code. There's no high speed hash, just hard-to-eliminate solid ones and zeroes."
dlloyd:
The code I posted works on an array of inputs (the example shows 10, but it can be anything from 1 input up to all available inputs). All inputs are read at once. I've set the interval between complete array reads to 2 mS.
I thought your technique looked familiar. I had seen the same report as a pdf file that I referenced on another thread. I do have a couple notes/questions about your function that does the main work. Here it is again for reference (I slightly modified the bracing style to my preferred method to help keep track of brace pairs, otherwise this is the same as you posted at the head of this thread):
With further thought, I'm wondering if it wouldn't be better to fire the function regularly with a timer interrupt. My thought here is if the actual function of what a sketch is designed to do makes single or multiple iterations of loop() last longer than 2ms (lots or poorly managed I/O with Wire, SPI, and/ or Serial, a lot of floating point math, lots of analogRead()s, etc) then the input latency increases. Unfortunately, I don't have enough experience playing with timing interrupts (actually none...) to know without significant research how to implement one w/o breaking any of the core Arduino routines that also use interrupts behind the scenes.
Note that the 2 ms interval is the "period between reads". By using the shift register for pattern recognition (B01111 for rising edge and B10000 for falling edge) the over-all latency would be 8+ ms (in the example) but only if the input signal is clean. If the input signal is has considerable bounce, say 50 ms, then the rising edge would not be detected until B01111 occurs (58-60 ms). That way the function can safely reject noise while providing a responsive output.
Note that if the user's sketch takes longer than the 2 ms reading interval, this only adds to the latency which would not create a problem. If the user's sketch was so slow that it's iteration speed was only 10 Hz, then it would take about 1/2 second for the debouncer to recognize the correct pattern and change the output ... but it would still work.
This is because there is no time-out involved that tells the debouncer to start looking for another input event. It only looks at the 8-bit pattern. This pattern only shifts left after each read, which is determined by the main loop's execution speed.
I've timed the function on the Due. For 1,000 iterations of 10 inputs (10,000 reads) it took 790 us or 0.79 us per read. Outside of the function, I've timed just one digitalRead(pin) for 1,000 iterations and got 1170 uS or 1.17 us per read. For some reason the function is faster??
795a8134c1