What device are you running it on? Up to date firmware?
It can be an issue when you have an input that bounces extremely quickly though. Basically on most systems the hardware doesn't record the status of the input pin, so it has to be explicitly read.
So you can get into a state where the IRQ fires, the state is read, then the state changes and the IRQ flag is cleared, but we're left logging only the previous state.
Having looked at the code on STM32 based devices again just now I realised I can actually do a bit better though (resetting the interrupt flags immediately rather than after the event is logged) - so if you install a cutting edge build now you may find that the problem has gone away. I just did some tests on the WiFi and it seems an awful lot better.
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.
What device are you running it on? Up to date firmware?
It can be an issue when you have an input that bounces extremely quickly though. Basically on most systems the hardware doesn't record the status of the input pin, so it has to be explicitly read.
So you can get into a state where the IRQ fires, the state is read, then the state changes and the IRQ flag is cleared, but we're left logging only the previous state.
Having looked at the code on STM32 based devices again just now I realised I can actually do a bit better though (resetting the interrupt flags immediately rather than after the event is logged) - so if you install a cutting edge build now you may find that the problem has gone away. I just did some tests on the WiFi and it seems an awful lot better.