Blog Post Actions
Group Actions
Engagement
  • Author Author: balearicdynamics
  • Date Created: Date Created
  • Views 1784 views
  • Likes 8 likes
  • Comments 26 comments
Related
Recommended

Vintage 555 - A general-purpose button debouncer

balearicdynamics

Too many button clicks

Buttons and tactile switches are frequently used in many projects involving micro controllers; one of the most frequent issue is related to unwanted multiple transitions when the button is pressed once.

Tactile switches as well as push buttons are mechanical components subject to the problem of bouncing. When a button is connected to a digital GPIO input pin (i.e. an Arduino pin configured as INPUT) we ideally expect that when the button is pressed we get only one high signal; unfortunately this rarely happens. During the mechanical movement the physical material vibrates affecting the voltage and the transitions between the On/Off status are not so clear as we usually need. Micro controllers and FPGA are fast enough reading the microseconds oscillations when the button is pressed, resulting multiple transitions while apparently we are pressing the button only once.

 

Button debouncing

To solve this problems we should apply a button debouncing to reach the goal: pressing a button only one signal should be detected by the micro controller digital input. We can identify two possible approaches: software and hardware.

There are plenty of source examples on how to debounce a button via software; the software approach seems the easiest way but in my opinion this is one of the cases where a hardware solution may be more efficient and resource saving. Micro controllers have memory and resource limits so adding a debouncing routine maybe critical in many cases.

 

The hardware choice

As I had to add a button debouncer to a test project based on Arduino 101 I decided to make something as much general as possible, easy to adapt to almost any micro controller and possibly platform independent. I figured two possible approaches: RC (resistor-capacitor) method and IC method. The RC option is easier to realise but I am not so confident it can be applied to very different operating conditions (e.g. very different micro controllers types and clock speed). It is not so difficult to calculate the values of resistor and capacitor for a RC debouncing circuit but I see a limitation restricting the application range. The calculation of the RC circuit is  dependent on the voltage of the board used; this means that for different voltage boards (1.8V, 3.3V, 5V etc.) we should provide a different RC calculation.

The RC simple circuit shown in the image below can be calculated with the nice RC Debounce online calculator

The parameters involved in the calculation are:

 

  • Voltage
  • High logic level
  • Bounce time (ms)
  • Capacitor value
  • Resistor value

 

The other hardware alternative is adopting a debouncing IC.

There are many specific IC for mechanical contacts debouncing, but they are almost expansive and oriented to manage power buttons while we generally use a push button is to generate a logic signal. The LTC2951CTS8 for example sounds good (not sure if the DIL version is available) with a base price of about 5$.

This is why I decided to move to a general-purpose debounce circuit based on the Vintage NE555. TI provides a wide range of 555 ICs including DIL packaging covering a range supply levels from 1.5V up to 16V; the most common is the DIL package NE555-P in the range between 4.5V and 16V. Just what I need, sold at 1/10 (one tenth) of the specialised debouncing ICs average price!

 

The NE555 circuit

I designed the circuit based on the popular NE555 monostable configuration shown above and detailed in the below schematics:

In this specific case using the two 10uF capacitors connected in parallel to the discharge pin and the 10K resistor for charging we get a timing of about 220 ms. It is a reasonable value to debounce a tactile switch connected to a digital input pin of an Arduino board; changing the values of the capacitors and the resistor we can increase or reduce the charge time resulting a different timing to the output pin (debounced signal.

 

Wiring the circuit

Using the NE555-P IC the circuit can be powered by the Arduino itself; the images below show the circuit placed as part of the Arduino 101 project where a push button is needed. The small board can also host the designated button making a compact object independent by the platform (an external power source can also be used) involving only the debounced signal connected to the desired GPIO micro controller pin.

The resulting PCB is about 30x35 mm; I have provided a tactile switch button surface mounted on the opposite side of the components to make easier assembling the module in any project.

The button in action

The video below shows the debouncer module at work powered by the Arduino 101 and a couple of screenshots showing the stability of the signal

 

 

 

 

Anonymous
  • in reply to Jan Cumps

    Maaaany thanks. Sometimes it's not easy for me to understand clearly the options of a concept. Very good.

     

    Enrico

  • in reply to balearicdynamics

    Enrico Miglino wrote:

     

    Jan, maybe I have not understood

     

    I try to avoid interrupts for user buttons. If I can get away with it, I poll.

    So you don't want manage buttons by interrupt, correct? (But what happens when buttons should immediately change what is happening? I find IRQ are one of the most useful way, but does not mind, it's a question of personal approaches)

    ....

     

     

    If the buttons aren't debounced in hardware: yes. I prefer not to use interrupts then.

    I'm not the only one with that opinion. On the other hand, there's also a lot of people with the exact opposite opinion ...

    Immediate is relative in the whole mechanics of reaching for a button and pushing it.

     

    Enrico Miglino wrote:

     

    ..

     

    For human interface it tends to make things complex.

     

    I agree but IMHO pushbuttons are not sufficient to be considered Human Interface. Maybe are just reset or need to stop an event that maybe risky or any other stuff without considering them a real user interface.

    ...

     

    see above

     

     

    ...

     

     

    And if the keys are hardware-debounced, interrupts are just fine.

     

    Is not exactly the opposite of what your told before ?

     

    Enrico

    That would not be the first time . I think no, because here I am talking about buttons that have been debounced in hardware.

  • Great post! Very cool thread to share various debouncing methods.

    I recently needed to implement single and double-press (and in the future perhaps triple-press) so it was fun creating the state machines for that while also debouncing. One project I semi-worked on used a button for multiple purposes, the user could swap it out for a control unit which would send something like 1-Wire signals. So then the system needed to understand button-presses (and debounce that) but also recognise when the button was swapped out and the human replaced with a higher-speed machine for different functionality (kind-of like a headset which might have a simple mute button, but the more advanced version will have a display and soft-buttons). I didn't do the hardware or software for that portion of the design.

     

    Another technique where the debounce is semi-hardware and semi-software, is to use a I2C expander and an interrupt. Then, whenever the interrupt signals a pin change, the signal levels are read using I2C. Since it takes some time to perform the I2C read action, the software performs a partial debounce by confirming the data has not changed (the data from the last I2C read is always retained to be compared) or by then waiting for the next interrupt (when the button is released) if an action on release is desired.  Some expanders have some deliberate built-in debounce capability too, I've not tried them.

  • in reply to Jan Cumps

    If you have your interupt service routine set a flag "button pressed" you can then poll for that instead.

    Should solve the debounce issue too, if you don't poll too fast and reset the flag once you've read the value.