They didn't say how often the reads are - 50 reads could be only 5ms.

In practice switch bounce often lasts tens or even hundreds of milliseconds, and you need to space out the read process to cover the entire bouncing process if you want to avoid registering fake presses. Using basic averaging means your minimum input latency is going to be ~half your bounce time - which is often way too high for it to feel like real-time input.

If you want to achieve low-latency input, "act on first edge, then ignore for the switch bounce period" is a far better approach. It also conveniently solves the "press, then release within bounce period" problem where an averaging algorithm would completely ignore the button press.

▲

mrob an hour ago | parent | prev | next [-]

Latency is cumulative, so avoidable latency is never acceptable. Maybe the hardware will change. Maybe somebody will run your software in an emulator. That 5ms could be enough to push the total latency into the "annoying" level.

And even with no additional latency, 5ms is perceptible in some cases anyway. Microsoft Research has a video demonstration:

https://www.youtube.com/watch?v=vOvQCPLkPt4

▲

inigyou an hour ago | parent [-]

Do you really think the people who programmed your microwave should have taken into consideration that someone might write a microwave emulator in the future? Dealing with that is not their job, it is the job of the emulator creators.

	▲	crote an hour ago \| parent [-]
		Who says the emulator is "unauthorized"? For example, smartphone app developers routinely run their apps in emulators first to make the development process more convenient, only running it on a physical device for confirmation when the work is basically done. Many embedded developers would kill for something similar, and we're already seeing the start of it with platforms like Wokwi. Being able to do integration tests without the physical device itself is an absolute game changer.

▲

PunchyHamster 14 minutes ago | parent | prev [-]

Doesn't matter, their way is terrible one that adds latency for no reason.

There are 2 things here worth paying attention

* first "bounce" is user action * last "bounce" is stop of user action.

You can run action on first bounce then just ignore the button for whatver debounce period you deem satisfactory. But adding delay to start action is always wrong answer for debouncing.

Now the harder problem is the off of the button, especially if hold is also an action but "be off for at least few ms" usually handles it well and off time is not lag user feels