Button debouncing

[GoogleCodeExporter]

Would it be possible to implement a new 'getButton' like method that has 
debouncing?

It would save a step in basically every program that needs a reliable reading 
of button input.

You could leave the existing getButton method for those who want to implement 
their own debouncing.

Original issue reported on code.google.com by dacomput...@gmail.com on 6 Jan 2012 at 5:19

[GoogleCodeExporter]

I'll look into this

Original comment by rjbati...@gmail.com on 6 Jan 2012 at 5:29

• Changed state: Accepted
• Added labels: OpSys-All, Priority-Medium, Type-Enhancement

[GoogleCodeExporter]

Thanks!

If you haven't seen them already, here's a few links.

http://www.arduino.cc/en/Tutorial/Debounce

http://www.arduino.cc/playground/Code/Bounce

Original comment by dacomput...@gmail.com on 7 Jan 2012 at 6:23

[GoogleCodeExporter]

I've tried on my units and found no bouncing on the buttons. Works perfectly 
for me.

Are you sure your unit bounces ?

#include <TM1638.h>

// define a module on data pin 8, clock pin 9 and strobe pin 7
TM1638 module(3, 2, 4);

byte currentKeys;
byte currentLEDs;

void setup() {
  currentKeys = 0;
  currentLEDs = 0;
}

void loop() {
  byte keys = module.getButtons();

  if (keys != currentKeys) {
    currentKeys = keys;

    currentLEDs ^= currentKeys;

    module.setLEDs(currentLEDs);
  }
}

Original comment by rjbati...@gmail.com on 8 Jan 2012 at 11:06

• Changed state: WontFix

[GoogleCodeExporter]

Check out my video here. You can see the buttons bouncing at 0:41 when I try to 
display "PANICI"

http://www.youtube.com/watch?v=F4DPi-5Swxo

Original comment by dacomput...@gmail.com on 8 Jan 2012 at 11:26

[GoogleCodeExporter]

I really can't see bouncing on my modules - I really think that is looks more 
like reading the state of the button too quickly without consideration for the 
button release than bouncing, in which clicking a button sends a random number 
of on-off before the actual press. I've dumped the buttons to serial and never 
saw any bouncing on the signal in any button on my modules.

I didn't see your code, but your video looks more like you're reading the 
button and toggling the state without considering for the button release - the 
button debouncing method would NOT help if this is the case.

Sucessive readings of a single button state with bouncing would present itself 
as:
000000101110010011111111111111111 (would look like multiple presses)
instead of:
000000000000000111111111111111111 (would look like one press)
The last seems to be the case with my tm1638 modules - they are not bouncing at 
all.

The debouncing on the examples you gave basically provide a time delay in 
successive readings: reading the button several times in a small interval 
always return the first saved value. I can add that to the library, but I'll 
make me save the last 8 press times and a state for the buttons, making the 
library footprint bigger by, at least, 33 bytes for each module instance.

As the memory "allocation" in arduino is not as in a regular c, I cannot 
provide an option with and without debouncing without always spending the extra 
memory. Another other option would be to provide a library extension with 
deboucing, but doesn't really look nice. The most realistically cleaner 
approach would be conditional defines, which will probably be the solution if 
you're really sure your unit bounces.

Is your sketch checking for the button press and release ? Because it will 
solve your problem in the video if you're reading the buttons and changing the 
state - the debouncing method on arduino.cc would STILL return a button press 
on the multiple readings.

Original comment by rjbati...@gmail.com on 10 Jan 2012 at 3:08

[GoogleCodeExporter]

Here's my button code for that video.

  button1State = (display1.getButtons() == 0b00000001);

  if ((button1State != lastButton1State)&&(button1State == HIGH)) {
    if (button1Toggle == 0)
      button1Toggle = 1;
    else
      button1Toggle = 0;
  }

I've got 4 TM1638 modules, i'll check them for bouncing over serial as you 
have, and get back to you.

Original comment by dacomput...@gmail.com on 10 Jan 2012 at 5:44