Skip to content

Buttons_Explanations

elral edited this page Mar 30, 2023 · 2 revisions

First some basics to buttons.

  1. A human pressed button is closed for a minimum time of ~100ms, one is not able to press and release much faster.
  2. A delay of ~100ms between pressing a button and processing it's state will not be recognized by the user.
  3. Buttons debounce, they will close and open within severall us, sometimes up to ms.
  4. Pressing a button is as important as release a button.

According 1) you have a lot of time to detect a status change of a button, and according 2) the user will not recognize this. After a signal change you have to be aware that multiple signal changes will occur, so debouncing is required. An "easy" solution is to check the buttons ~10ms for a signal change (there are also other methods also for heavy bouncing buttons or very old buttons), according 3) you will be for most buttons after there debouncing state and therefore you will get only one signal change. Doing it this way there is no difference between pressing or releasing, this fullfills 4). Using a pinchange interrupt will cause problems without additional measures. Every (or most) bouncing will lead to jump into the ISR (assuming the ISR is fast) and lead to detection of multiple key presses and time delays in the main loop (much more worse for reading encoders via pinchange interrupt). A time based interrupt every 10ms for reading the switches would be the preferred way (espacially when using long press or repeat detection), but with a lot of buttons it is also OK to set a flag (or use millis() like done in the firmware).

Transfering this to the keymatrix with MCP('s) it would be "enough" to check ~10ms if a button was pressed. This could be done by reading the interrupt register, processing which button is pressed and then clearing the interrupt. As preoccessing means multiple I2C accesses the required time will be in the digit ms range (I measured 6ms for my way), so buttons will not bouncing anymore. For the next coming relase of the button the some applies. If using the interrupt line and a pinchange interrupt nearly the same applies, it "just" has to be ensured that a release of the interrupt in the MCP has to be done after bouncing of the switch. As processing which button is pressed does not change (still multiple ms), clearing the interrupt afterwards should also enable a button release via an interrupt.

CMD-Messenger

Buttons

Memory Consumption

Clone this wiki locally