Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There's a ton of nuance to something as simple as debounce, and that's why the Ganssle article is so great; unlike the simple comments ("just add a 100ms sleep to your code!"), it explores the end to end experience with each given solution, both in hardware and in pseudo code.

Too many people find a solution that fits the bare minimum requirement and move on, leading to years of frustration from the end users. Spend a little more time using the thing like an end user would, and you can solve that issue much better, usually.



There is ton of nuance in the physics but "trigger on first and wait" is objectively fastest response way to do it.

Only reason to do it other way is if you have some limitations. Like timer being costly on resources (valid concern for microcontroller)

> Too many people find a solution that fits the bare minimum requirement and move on, leading to years of frustration from the end users. Spend a little more time using the thing like an end user would, and you can solve that issue much better, usually.

A little time won't give you much. Those are kind of problems where you need to be using it daily in anger to find the issues.

Like the buttons on elevator where I live. I press the button, it lights up, I do it few more times, debounce works fine!

Another day I'm in hurry, press it quickly, does not work. Turns out someone picked the worst way to debounce (wait till it is ON for that amount of ms), and on top of that tied LED to button itself so you see the light flash but button does not turn on). So you can't just tap it quickly, and you can't risk tapping it more than once because that would cancel the floor request


De bouncing is solved in hw with right-sized capacitor. That's it....


You need schmitt trigger input to do it properly and most microcontrollers don't have it.


I really, really hate HW solution for something so easily solved in Software.


In reality you implement both. Basic noise filtering in hardware, plus rate limiting or something in software.

onClick event handlers in most GUI triggers on mouse button releases, for example.


I have almost never seen hardware debouncing. It's just way better done in software. Unless you have extremely specialized switched which require HW debouncing(???), please just do it in software.


Really? A button just coming from GPIO into a 10k to ground? Is CPU not going to randomly lock up?


There is no reason the CPU is going to lock up. Bounce is not random spurious triggers.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: