Group Actions
Engagement
  • Author Author: balearicdynamics
  • Date Created: Date Created
  • Views 13954 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

image

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

image

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

image

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.

imageimage

imageimage

imageimage

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.

imageimage

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

 

 

 

imageimage

 

Parents

  • Nice post image

     

    I have seen the RC variant on STM32 Nucleo boards and I guess it is the cheapest if we consider the total bill of material.

     

    By the way, PSoCs have a component just for this purpose: a Debouncer. Works like a charm.

  • in reply to koudelad

    PSoCS are absolutely innovative ! I love these ICs but I think that the Arduino generation needs to be more involved in real programming to manage them. This is the advantage and disadvantage of the Arduino-like platforms: keep makers far away from the depth of electronics.

     

    Enrico

  • in reply to michaelkellett

    Michael Kellett wrote:

     

    ... and the 16 (or thereabouts) in the divider.

    I'm not that happy about only using one flip flop to clean up an asynchronous input to an FPGA - I always use 2.

    Xilinx are a bit inconsistent on this and some of the latest IP uses three flip flops for synching up an input along with clever stuff to force them into the right physical locations in hardware.

     

     

    MK

     

    I turns out I settled with 20 image

     

    signal clk_debounce : unsigned(19 downto 0);

     

    I've not intentionally used IPs in the example. I think (not skilled enough to know what happens at synthesis time) that it's plain VHDL.

    I'm interested to see the 3 FF solution though ...

     

    In my own designs, certainly when working with rotary encoders or with GPIO interrupts on microcontrollers, I prefer hardware debouncing.

  • in reply to Jan Cumps

    Hello Jan,

     

    I looked up the Xilinx IP to see how they do it and in fact they use 4 flip flops.

     

    The code is weird and has a copyright notice (and came with paid for IP) so I can't post the whole thing - I think it's fair to post the following extract to give an idea of the hoops they go through:

     

    entity tri_mode_ethernet_mac_0_reset_sync is

     

    ............ stuff deleted by MK to respec X's copyright

     

    attribute dont_touch : string;

      attribute dont_touch    of  tri_mode_ethernet_mac_0_reset_sync : entity is "yes";

     

    end tri_mode_ethernet_mac_0_reset_sync;

     

    --------------------------------------------------------------------------------

     

    architecture rtl of tri_mode_ethernet_mac_0_reset_sync is

      signal reset_sync_reg0 : std_logic;

      signal reset_sync_reg1 : std_logic;

      signal reset_sync_reg2 : std_logic;

      signal reset_sync_reg3 : std_logic;

      signal reset_sync_reg4 : std_logic;

     

      attribute async_reg                 : string;

      attribute async_reg of reset_sync0  : label is "true";

      attribute async_reg of reset_sync1  : label is "true";

      attribute async_reg of reset_sync2  : label is "true";

      attribute async_reg of reset_sync3  : label is "true";

      attribute async_reg of reset_sync4  : label is "true";

      attribute shreg_extract                 : string;

      attribute shreg_extract of reset_sync0  : label is "no";

      attribute shreg_extract of reset_sync1  : label is "no";

      attribute shreg_extract of reset_sync2  : label is "no";

      attribute shreg_extract of reset_sync3  : label is "no";

      attribute shreg_extract of reset_sync4  : label is "no";

     

    begin

     

    After this there are 4 flip flops connected nose to tail.

     

    It's way more complicated than I normally use - typically:

     

    d1 <= input

    d2 <= d1

    d3 <= d2

     

    and then work with d2

     

    MK

  • in reply to balearicdynamics

    Enrico Miglino wrote:

     

    ....

    The second (most important) is that you cant drive the button by interrupt that reveals essential in some cases.

     

    Enrico

     

     

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

    I'm an interrupt fan - use it with serial communication (uart, spi, i2c) and other machine generated events. For human interface it tends to make things complex.

    There's a good place for them in a user interface though. It's not black/white. Very useful in wake up from low power mode scenarios.

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

  • in reply to Jan Cumps

    Jan, maybe I have not understood image

     

    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)

     

     

    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.

     

     

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

     

    Is not exactly the opposite of what your told before ?

     

    image Enrico

     

  • 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.

Comment Children
No Data