I recently read an article about button debouncing and was wondering if I should keep this in mind when working with, for example, an Arduino (ATMega mC)? I assume it is an issue, especially when working with interrupts.
So is it better to detect bounce in code, or should this be taken care of with hardware? Please elaborate.
I would highly recommend hooking a scope (hopefully you have one or can get your hands on one to use) up to your switch. I have seen a student's project that had a bounce on their switch that went from 5v down to -5v up to 4v down to -3v then up to 2v then back down to 0v. When we looked at the current draw on a scope there were some a very very large spike.
In his particular case it was very very much needed for him to debounce his switch in hardware.
However, on the other hand, I have seen switches that have a much smaller effect that could easily just be removed in software.
You do need to weigh your options though. If you have a very complex amount of firmware, adding the overhead on both you as a programmer and the cpu usage may not be worth it and you would be better off to just add a little bit of hardware. Now on the other hand, if you are trying to get costs and size down, you will want to remove as much hardware as possible and do it all in firmware if you can.
If you're a professional electronics designer chances are that your boss won't even let you do it in hardware. The reason is simple: if your production batch is large enough software is virtually free, while hardware has to be paid for for each unit you produce. And while resistors and capacitors are dirt cheap, mounting them on a PCB may cost up to 20 times their purchase price.
Whether you debounce in software or in hardware, you still have to select quality pushbuttons. The infamous 157ms button from the article is simply not fit for any application.
I usually sample the button at 32ms intervals, which is enough to bridge the debounce time of any good button. I'm quite a fan of the Alps SKQG TACT Switches.
On the few devices I tested it had an initial bounce time of less than 10ns. While it has an operating life of 100 000 cycles we tested it for 200 000 cycles and even then the 32ms debounce was sufficient. (I guess I should have measured the actual level of debounce, but our main interest at the time was the final product's behavior. Anyhow, we were using it out-of-spec.)
If you really want a hardware solution I second the SR flip-flop solution mentioned in the article as the technically best solution:
The flip-flop can be constructed with a dual NAND gate, which is available in a small VSSOP8 package, for instance. The major drawback of this solution is that you need a SPDT pushbutton, where SPST is much more commonly available.
There are lots (and lots) of different ways to debounce buttons. Whether you do it in software or hardware is going to depend on your project requirements and switch type.
Here are some links to different methods:
http://www.ganssle.com/debouncing.htm
http://hackaday.com/2010/11/09/debounce-code-one-post-to-rule-them-all/
That article is the "bible" on debouncing. Contact bounce can be a problem with any application.
It's generally best to debounce switches in software as it's easier to adjust for the delays for particular switches, as they differ in their amount of contact bounce. Debouncing the key release is often necessary, as well. Switch manufacturers often specify the amount of bounce for their products, it's typically around 10ms - 20ms.
Switch bounce can go on for tens of milliseconds. If you're polling a switch from an interrupt routine that runs on a timer, bounce won't be an issue, because even if you happen to poll the switch in the middle of a bounce storm, you either get the new state right away, or at worst get the old state, and don't see the new state until the next timer based poll. Polling from a timed ISR like this constitutes a form of software debounce.
However, if you are using that switch to cause the interrupt, and you expect that interrupt service routine to run quickly, in less than say 10 milliseconds, you'll need hardware debouncing, otherwise one switch event could result in a somewhat random number of interrupts, and certainly often more than just the one expected. On the other hand, if the interrupt routine runs long enough, the switch bounce will have settled before the ISR finishes, and you'd be fine, but most well constructed ISRs don't take all that long.
The best way to do anyhting is the way that suits you best. But when you already have a microcontroller you can debounce in software at only the cost of a some code effort.
The essiest way to debounce in software is to check the buttons at moments in time that are further apart than the longest bounce time. 50 ms seems to be an upper bound on the bounce time of 'normal' switches, so when you can arrange your software like this you are in the clear:
forever loop
wait (at least) 50 ms
check buttons
do procesing
end loop
One approach to debouncing which hasn't yet been mentioned is to use a double-throw switch with one throw tied to VDD and the other to ground. Feed that into a pin which (either via software or hardware) will be weakly pulled to its present state. Such an approach will provide the advantages of a double-throw switch, but will only require one I/O pin rather than two.
