Let's Make Robots!

Button debouncing

Hi LMR...


       I think that you often run into the problem with MCU that when you press a button it read it not only one time but often even 50 times or more. You probably thought about how to do the so-called "debounce". Here how  I am making it, but let me explain why this is happening to you.


        First of all the button has two metalic plates which touch each other when the button is pressed. When these metalic plates get at a really close distance it elaborates pikes, so the result will be a lot of touch/untouched signals. Like pressing the button like an idiot a lot of times but this happens in a fraction of second, you know MCU's speed, right?


       So here is what you can do, there are several method but I will tell you just two of them.

  • first is the schmitt trigger.
  • second is using a simple cap.


Schmitt trigger method

    This is the best way to make the debouncing. The schmitt trigger calculates all the semnals and using a threshold it will give a simple 1 or 0 to the MCU. This is the best way to make the debounce because using my second method the signal will be even sometimes under 0V like -1V and MCU's doesn't really like it. I have never had problems with AtTiny2313 with the cap.


Cap method

   This is the cheapest method ever had and the seasiest one. All you have to do is attaching in parallel a 0.1uF capacitor. It must not be electrolytic. The debouncing is working perfetly with the cap as can be seen in the video.


        I have to say that these are the best methods and the cheapest one. You know hardware debouncing is the best and not the software debounce because it eats a little memory and in a big program it is really probable that you will bang your hand in the monitor because forgotting to re-enable an interrupt or something.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Just add a delay of about 50 to 100ms after the button is pushed and before the code is executed.

yes I know this is the simplest way, but when you work/worked a company which makes tickit printers and ticket validating tools you will know that 50ms delay over 24 hours means a lot delay and you will and up that your time on the ticket will be late... thats why isn't recomended using delay's in an interrupt... :| A master builder will learn that using an mcu isn't just a fun, its hard coding, debunging and avoiding delays...

      fo course, in a simple project, there no use of this, but if it is simpler... why not?

Actually, the Picaxe has a ready command for you to use, to overcome debouncing:


(Manual 2, page 39)

I was talking about the simple PIC and AVR models not the whole developing board Fritsl.... I know that there is much more simple but you know, I jumped over the arduino thing.... I get directly into deep water and ran off with atmega8-16PU.... with these chips the debounceing is a bit harder.... but I am sure the there will be peoples who will enjoy and will follow this tip...

Yes, It is a good tip, sorry if I made it sound the other way!

And I will use it one day, I am sure! Just wanted to point out for Picaxe users that there is this faster way :)

And thanks for the tip!!


sure... more comming soon.... btw I was used to be a master of avr's... but as I heard, they stopped production :| need to change to PICs...

I've used the cap with CMOS devices, works wonders, and without a cap it wasn't that bad, 3 "fake button presses" at most, but of course, that is too much.

yeah but as I said, cap isn't the best choice all the time. PU type of avrs are industrial and they support much more effort. :)

Here's some reading about debouncing: http://www.ganssle.com/debouncing.htm. I found it very enlightening. Also includes examples of HW and SW debouncers.