take a look at this conversation about PUCK Ble HID keyboard... your challenges ring for me the same bell. Timeouts and Intervals - all time driven things - are not that satisfactorily / predictable. If event drivenness can be achieved, conversation loop is much tighter/shorter/expedient.
Debouncing is a real world issue... that's why most time I do not go for the press of a button, but for a release of the button... and to be really sure, I make it a simple, force-driven flip-flop: a single shot watch for the press, then a check in a bit and when still pressed, I setup a single shot for the release, and there release runs the chore and then starts over with the cycle with setting up the single shot watch for the press...
Another practical approach is to get and keep the time of the event of the press - you get it with the event object - and keep it in a (global) variable, for example, xyzPressLastTime, which I initialize with 0. When I get a press and before venturing in honoring it, I compare the time if the current press with the one of the last press and decide: that's too quick, it cannot be real, and then just ignore the press - the 'too quick' I keep in a configurable variable. With that mechanism you can go for the press event to do something and at the same time prevent that it is not done multiple times in a non reasonable / impossible short time, as cause,. for example, by bouncing.
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.
@ayoganandan1984,
take a look at this conversation about PUCK Ble HID keyboard... your challenges ring for me the same bell. Timeouts and Intervals - all time driven things - are not that satisfactorily / predictable. If event drivenness can be achieved, conversation loop is much tighter/shorter/expedient.
Debouncing is a real world issue... that's why most time I do not go for the press of a button, but for a release of the button... and to be really sure, I make it a simple, force-driven flip-flop: a single shot watch for the press, then a check in a bit and when still pressed, I setup a single shot for the release, and there release runs the chore and then starts over with the cycle with setting up the single shot watch for the press...
Another practical approach is to get and keep the time of the event of the press - you get it with the event object - and keep it in a (global) variable, for example,
xyzPressLastTime
, which I initialize with 0. When I get a press and before venturing in honoring it, I compare the time if the current press with the one of the last press and decide: that's too quick, it cannot be real, and then just ignore the press - the 'too quick' I keep in a configurable variable. With that mechanism you can go for the press event to do something and at the same time prevent that it is not done multiple times in a non reasonable / impossible short time, as cause,. for example, by bouncing.