What is the advantage to debouncing buttons in software, as opposed to hardware? Say I have a switch on a device, the following schematics ought to debounce, correct?



It seems that via this approach, not only do I eliminate the bounce, but I also save room in FLASH memory, and simplicity in the program, not to mention processor cycles, if we are in a time critical application.

Is there anything inheriantly wrong about this approach?

__________________
--------------------
-Gandledorf

Come visit http://groups.yahoo.com/group/laser_design a group dedicated to help designers build electronic games, and design optical combat systems.

 

less component count => less cost and less board space
from a manufacturing point of view

Also failure modes. If manufacturing makes a bad solder connection (ie a solder bridge or dry joint => short or open) then no input signal.

But personally you cannot beat a good RC network.

 

There's nothing wrong with a hardware approach, though your reasoning is flawed. The components may seem cheap, but memory and processor cycles are far less expensive. Debouncing a pushbutton switch is inherently not a time critical application, that's why a firmware solution works.

An interesting difference between the two debounce circuits you posted: A SPDT switch can be completely debounced with a RS flip-flop, while a SPST switch depends on a time delay for debouncing.

see http://www.e-insite.net/ednmag/conte...ges/196470.pdf for some more info on debouncing SPST switches using hardware.

 

You are misunderstanding what I said abt components being cheap

I am argueing FOR the software method. By doing it in software you do not have to put the analogue components down thus you are saving board space and also cost because you do not have to buy those components.

By doing the jitter filter in software you do not have to track for a resistor and a cap, thus your board is smaller thus the chost is lower and also you do not have to buy those components.

Also in doing it in software you are eliminating another point of hardware manufacturing errors.


However, I am an analogue persone and will personally go for the hardware method

 

styx, he was referencing "It seems that via this approach, not only do I eliminate the bounce, but I also save room in FLASH memory, and simplicity in the program, not to mention processor cycles, if we are in a time critical application. " not you

__________________
A rectangular bear is just a polar bear after a coordinate transform. -- I dunno who.
A recent study shows that research causes cancer in rats. -- I dunno who said that one either.

 

Styx, I was not responding to your post, my comments were directed at Gandledorf's original question. You made some good points, the higher the volume, the better it is to use a software solution. I'm an old school hardware designer, and I think hardware should be reserved for applications that software/firmware can't touch (yet).

 

C'mon, this was an interesting comment. Tell me why this is true. One of those things that seems simple but is not so simple until you think about it...

 

ops:

 

The reason I am looking for a hardware solution is because I am using a very low frequency processor, generating a complex signal on one of it's pins on a carrier wave. The uC is at a low frequency to conserve power, and I end up only having 20 cycles or so in between interrupts. In addition to that, 11 of those cycles are used to prepare for the next interrupt, book keeping, etc.

That leaves me 9 cycles to do everything else my uC must do. Debouncing becomes a bit more costly at this level, and I was looking for a decent hardware debouncing method, so I can respond to a key press faster.

__________________
--------------------
-Gandledorf

Come visit http://groups.yahoo.com/group/laser_design a group dedicated to help designers build electronic games, and design optical combat systems.

 

Many functions like this can be done either in hardware or software, and often it comes down whether your processor has the extra cycles to spare. Didn't realize you were on the edge. For hobbyist or low to moderate volume applications, the few extra pennies spent on hardware debouncing isn't significant.

The note I referenced above makes some good points about debouncing SPST switches. Another part I've used in the past is the MC14490, a hex contact debouncer. http://www.onsemi.com/pub/Collateral/MC14490-D.PDF

(the reason a SPDT switch can be fully debounced with an RS flip-flop while a SPST needs a time delay has to do with how far the switch arm travels between contacts vs. the much shorter distance it travels during bounce.)

 

both approaches are satisfactory, however, if there is no microprocessor or any such chip in the project, then there's no need to add one.. therefore, you can do it all with hardware. if there is a microprocessor or some such chip that the pushbutton is going directly into, then you can debounce it on the software side.

two different solutions that accomplish the same thing, for two different situations.