Debouncing

[birefringence]

The switches in the Byteboi are rather bouncy and unreliable. First, I tried to improve the debounce code. There was some effect, but I was not completely satisfied. Then, I replaced the switches (now: Omron B3F-4050), which had a much better effect. With this improvement, the old code works fine as well.

Still, I would like to offer the debounce code, which may have some benefit for someone not wanting to solder. It also has less delay, because it reacts immediately if the button was in a stable position before.

I do understand if you reject this if you find it unnecessary!

[ducalex]

I'm not convinced that your code truly improves the situation, but I will try it this weekend and see how it feels!

One problem with our current debouncing is that the scheduler works at 100hz so we only get values every 10ms.

10ms is bad because it doesn't detect minor bounce and it forces a 20ms lag before the input is registered or released.

Perhaps we should try to set freertos' tick rate to 250hz or 500hz (and change the input task' rg_task_delay) and see if it's feels more responsive/accurate.

[ducalex]

I do agree that debounce should be configurable by the target (maybe even per button, but that's too much for now).

So I stole the idea and added it to config.h :). Your #ifdef in rg_input.h is no longer necessary.

[birefringence]

Well, having a reduced sample rate already is a debouncing strategy, so I'm not sure if it makes sense to increase it ;-)

My code already reduces the lag to 10ms. It limits the "repeat rate" of the keys to 10ms * debounce_level.

In any case, I'm happy with my new switches, which reduce the bounce time from sometimes of the order of 100ms to <5ms. This is has an enormous impact on the feeling of the game play.

[ducalex]

I've tested the changes but they produce bad results on devices with resistor dividers. For example on the ODROID-GO pressing UP often results in a phantom DOWN.

I don't know if the ADC is just very slow to react to voltage changes or if it's the resistors value causing a slow ramp up, but evidently sometimes we sample before it has reached its full potential so the wrong button ends up being registered.

It might be possible to have a different debounce mechanism for analog vs digital, so that digital buttons still benefit from the proposed change. But as is this patch is a no-go...

---

As a side note, wouldn't this simpler change effectively achieve the same thing as your patch?:

  debounce[i] = ((debounce[i] << 1) | ((state >> i) & 1));
  debounce[i] &= debounce_level;

+ // Button becomes pressed as soon as state goes from low to high and it gets released once
+ // state is low for two consecutive cycles.
+ if (debounce[i] == 0x01) // Pressed
- if (debounce[i] == debounce_level) // Pressed
  {
      local_gamepad_state |= (1 << i);
  }
  else if (debounce[i] == 0x00) // Released
  {
      local_gamepad_state &= ~(1 << i);
  }

[birefringence]

This code has a delay on the release event, even if the button was stable before. However, since the release is less timing sensitive for most types of game play, I guess the effect is about the same and I agree that it is much simpler.

Anyway, I'm not mad if you just leave it as is ;-)

Thanks for explaining how the ODROID-GO works. I wasn't aware of of this kind of implementation.

[ducalex]

I've done some measurements, when I press UP the voltage takes ~4ms to meet the UP threshold and almost 10ms to reach max voltage. Releasing it takes about 1-4ms to get back to 0. Both values vary a bit depending on how abruptly I press/release, so contact resistance is apparently part of it.

This is a lot slower than I would have expected but would definitely explain why we often end up measuring in the middle of the curve and why we can't trust single readings like we can for digital. I'm attaching an example log, reading the ADC every 100us whilst I press UP. adc.txt

I think narrowing valid ranges might help a little, but won't fix the issue entirely. So the only way to improve the ADC without breaking any device out there would be to read much more frequently and only accept a value once it's been stable for 2-3ms. Problem is we can't do that without blocking the core, unless we increase the tick rate.

In summary:
I think the main goal would be to make debounce configurable per button, so that special buttons (analog) can have special debouncing. A secondary goal is to improve ADC and that might be via increasing the sampling rate through tick rate increase if performance allows.