Sorry for bad English.
How fast people can press a tact button? I.e. what is minimal time of holding a button pressed people can get?
What is typical bouncing time when people press tact button?
I have no oscilloscope to check it, but maybe anyone already did it and public in the Internet?
I am not sure how fast. It's likely few hundered miliseconds.
2) Here are some nice resources about the topic. It highly depends on the type of switch and how it's built, but 10's of miliseconds is the norm.
If you really try, you can press a button for only a few 10s of milliseconds. However, that is quite extreme and requires a deliberate attempt.
In my experience, 50 ms is a good debounce time. That is about the limit where humans start to notice the delay if they aren't specifically looking for it. Most switches stop bouncing in 10-20 ms, but I have run into a few that bounced longer than that. Since humans don't notice a 50 ms delay, it's pretty much a no-brainer to debounce for at least that long, assuming the switch is being operated by a human.
If the switch is a mechanical sensor, then a faster response may be needed depending on its exact purpose. In that case a different debouncing algorithm may be appropriate, like react to the first state change immediately, but then block out new state changes for some interval.
I have used basic 50 ms debounce logic in many products, and not once has anyone complained or even mentioned they noticed the delay. To me the response feels instantaneous, although I know it's not. The processor usually has a 1 ms periodic interrupt for various other timing purposes anyway. To be clear, the debounce algorithm is that the new state of the switch is only made official if it has been seen that way for 50 consecutive 1 ms samples. This is easy to do and quite robust in my experience.
(1) If you have a microcontroller, you don't need an oscilloscope to measure the bounce times. Just poll the data from the tact switch and record it to memory along with millisecond-resolution times, and then after a few seconds of data (depending on memory availability) dump it to serial. In fact, you'll get more useful data from using your project's microcontroller than using an oscilloscope, since the data will match the detection thresholds of the specific microcontroller.
(2) Last night I was working on the software side of a project using cheap Aliexpress tact switches in a scaled-down 3D printed arcade-style button enclosure. Here is what I found. I had no detected bouncing on button depression, but I had quite a bit of bouncing on button release. Debouncing for 20ms was insufficient to remove the release-bounce. Debouncing for 30ms was sufficient. Edit: Interestingly, this morning I retested with the same hardware, and now 30ms was insufficient and I had to increase the debounce time to 50ms.
(3) Speaking for myself, I am annoyed by latency on button depression, but if you debounce correctly in software, on initial button depression there should be no latency introduced. The algorithm I use in my debounce code is basically this. Keep track of the settled state of the button in a variable S. Start with S=0. Poll hardware button. If the hardware button state doesn't match the S variable, immediately update S to match the hardware state and pass this on to the rest of the software as a press or release, but after that ignore all changes in the hardware button state for the delay time. Repeat.
The result is that in ordinary operation, there is no delay when the button is first pressed. (Delay when a button is first pressed always feels bad to me.) The debouncing algorithm introduces the following two artifacts. First, if the button is depressed for less than the debounce time, the software handles it as if it was pressed for all of the debounce time. E.g., with 30ms debounce time, you lose the distinction between a 25ms press and a 30ms press. This is unlikely to matter for most applications except maybe piano. Second, after the button is released, no new button press can be detected for the delay time. So in button-mashing scenarios, you get a bit of latency on subsequent button pressing, and the maximum detectable button mashing frequency is one per two delay cycles.
Looking around the Internet, I see that sometimes people may debounce differently in a way that delays the detection of the initial depression. Don't do that. As soon as the contact is closed, the button has been pressed, even if it bounces up immediately. (This is assuming you don't have noise in your lines. If you do, that's a different issue from bouncing.)
(4) As of 2020, the world button mashing record was apparently 16 in a second, or 62.5ms. If this button mashing was perfectly timed with 31.25ms down and 31.25ms up time, a 30ms debounce time wouldn't affect it at all. However, presumably sometimes the button presses were faster than 62.5ms and sometimes they were slower, so the debounce time would likely affect the world record.
(5) If I was designing hardware for the more extreme scenarios, like piano or Tetris, I would try to get better hardware, and I would also adjust the algorithm to have a different debounce delay on depression and release to match what the hardware was actually doing. (See point 1.)
