4 ms·

Debounce is an interesting topic[0], I tend to use hardware debounce whenever possible on my own projects. [0]: https://hackaday.com/2010/11/09/debounce-code-o

• CamperBob2 5y ago
  Don't accept a keypress if the same key was previously pressed less than x milliseconds ago. What else is there to know about debouncing?
  • talideon 5y ago
    The problem is that you're dealing with an analogue signal. The gold standard for debouncing because of that is a low-pass filter, which is implementable by a resistor and capacitor, and way more reliable (and responsive) than any software solution.
    • CamperBob2 5y ago
      Can you describe a case in which rejecting a duplicate keypress that arrives within a specified number of milliseconds is ineffective, unreliable, or even suboptimal? A lowpass filter is an empirical hack, not a gold standard. It has multiple disadvantages; rather than being "responsive," it adds latency to the initial input for no good reason, and it affects both rising and falling edges equally, again for no good reason. It also requires the addition of unnecessary physical components.
  • sydthrowaway 5y ago
    What is x? Is it related to human capability?
    • CamperBob2 5y ago
      Key bounce takes place at timescales far shorter than human reaction times. Typically you'd base the interval on the mechanical characteristics of the keypad. For instance, taking a look with a scope, if you observe that the signal stops bouncing after 3 milliseconds, it would be pretty safe to accept duplicate keypresses with a 10-ms guard interval.
      • alar44 5y ago
        You'd have to have two intervals though, one for on, one for off. It bounces both ways. Hardware is more elegant but obviously the tradeoffs depend on what you're implementing.
        • CamperBob2 5y ago
          It bounces both ways but as long as you don't accept another keypress action (up or down) immediately after the first, you're fine.
          • alar44 5y ago
            You're fine either way. You either have to poll, or use interrupts. If you are polling, you don't need to debounce the circuit. If you use interrupts, you're going to have a very bad time if you don't. Interrupts are much more efficient. Polling is wasteful.
            • brokenmachine 5y ago
              I don't see why interrupts wouldn't work without hardware debouncing. $2 micros are many MHz. All it has to do is save/compare one timestamp per interrupt. So lets do some back-of-the-napkin calculations and say it takes 1us to store/compare the timestamp, a switch transitions 50 times per press on each change of state, and a person is typing at 100wpm (lets say 600cpm = 10cps). I think these are pretty conservative numbers, 50 bounces sounds like a pretty crappy switch to me. So 1000 transitions per second which would take 1ms, which means 1/1000th of the time is spent servicing the interrupts. It's not going to cause a problem unless the coding is very inefficient.
            • CamperBob2 5y ago
              Since your ISR does nothing but record a timestamp (right...?) you are not going to have a "very bad time." Although in many cases polling is fine as well.
• auxym 5y ago
  There's some good info here if anyone is interested: http://www.ganssle.com/debouncing.htm http://www.ganssle.com/debouncing.htm