防弹跳按钮
Answers:
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.
在他的特殊情况下，他非常需要消除硬件开关的抖动。
但是，另一方面，我看到的开关效果要小得多，可以很容易地在软件中将其删除。
您确实需要权衡您的选择。如果您的固件数量非常复杂，那么增加程序员和cpu使用量的开销可能不值得，那么最好增加一点硬件。现在，另一方面，如果您想降低成本和减小尺寸，则将希望尽可能多地删除硬件，并在固件中全部完成。
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.