??? 03/23/10 16:53 Read: times |
#174436 - Short spikes Responding to: ???'s previous message |
As Erik notes, there are more than one way to skin a cat.
The interrupt method gets a quicker response time, while the timer loop version can handle a large set of buttons without need for individual interrupt lines or an external chip for summary interrupt. If the main loop has reasonably repeatable loop times, then you don't need to use a timer interrupt either. However, basing the debouncing on main loop iterations is likely to result in troubles if you switch to a higher clock frequency or decides to rewrite parts of the main loop code resulting in changes in the loop frequency. One thing to consider is how sensitive your input is from spurious noise. If using an interrupt, a very short pulse can trig. This can be improved by adding a couple of polls in the interrupt handler. If at least one of the polls shows the same state, then it wasn't a single spike. |
Topic | Author | Date |
switch input > interrupt (debouncing) | 01/01/70 00:00 | |
double post | 01/01/70 00:00 | |
Why the extra hardware? | 01/01/70 00:00 | |
wow | 01/01/70 00:00 | |
other ISR recommendation | 01/01/70 00:00 | |
or the other solution (my favorite) | 01/01/70 00:00 | |
using timer | 01/01/70 00:00 | |
Some switches have very long bounce time | 01/01/70 00:00 | |
a lot depends on the switches themselves | 01/01/70 00:00 | |
which is a $#@!! disaster | 01/01/70 00:00 | |
Remember that there is more than push buttons out there | 01/01/70 00:00 | |
What about the others? | 01/01/70 00:00 | |
Majority of implementations synchronizes with key down | 01/01/70 00:00 | |
Now I'm confused ... | 01/01/70 00:00 | |
Not Sure About The Code | 01/01/70 00:00 | |
More info on PC keyboard![]() | 01/01/70 00:00 | |
Short spikes | 01/01/70 00:00 | |
The real problem with debouncing | 01/01/70 00:00 |