4 ms·

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.