You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@allObjects
Before implementing the keypad un-biased myself, I felt understanding how Espruino's event queue and setWatch()'s debouncing works... after all I implemented Resistive Touchscreen directly (no touch controller) and used it successfully in multiple applications, such as UI Module w/ Buttons, Checkboxes,... for Display w/ Touchscreen and Puzzle16+ Game on ILI9341 2.8" 262K Color TFT LCD w/ Resistive Touch Screen, and also the press-time detection in Software Buttons - Many buttons from just one hardware button.
After implementing the keypad, I'm not so sure anymore about how they work - more precisely: how my code should interact with them properly - especially the way how I tested it: I just used a wire connected (firmly) to the driver side - output - (high/low - 3.3V/GND) and touching the - input - GPIO 'pin' (castellation / board pad, header pin). The moving wire may have just overstepped the working boundaries of the debounce, because I got a flurry of events (callback calls), no matter how I did set the debouncing.
Therefore, I switched to the setup as outlined:
If I do not see any 'on' in step 2 - check/scan state - I consider the trigger as an errant (button not pressed long enough), and return right away to step 1.
Even though this setup made it work for me, there is still the possibility that step 3 - watchng the switch turning 'off' - will not trigger, because it's setup was too late and the switch had already returned to initial - 'off' - state. To make it more predictable, a timeout - 'safety net timer' - has to be setup at the same time as the setWatch is set to check the state... just in case... ;-). If the state shows (still) 'on', the setWatch will eventually fire. If the state is 'off', the watch has to be called off (clearWatch), and process has to return to step 1. If the watch fires before the 'safety net timer' expires, the timer has to be cleared when returning to step 1.