-
• #2
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.
-
• #3
You're the best!
So, then, if I read BTN instead of using a.state in the callback it should work always... right?
Thanks!
-
• #4
Yesss, this seems to work fine:
function onInit () { setDeepSleep(1); setBusyIndicator(LED1); setSleepIndicator(LED3); /* var t; setInterval(function () { t= E.getTemperature(); }, 3000); */ setWatch(function (a) { digitalWrite(LED2, digitalRead(BTN)); }, BTN, {repeat:true, debounce:0, edge:'both'}); }
I don't understand why does the red led stay on until the first BTN press?
-
• #5
What device are you running it on? Up to date firmware?
Original Espruino Rev 1.3b, firmware 1v99
-
• #6
So, then, if I read BTN instead of using a.state in the callback it should work always... right?
Yes, that's correct.
I'll answer the red LED thing in your other post on that topic: http://forum.espruino.com/conversations/326517/#comment14452282
-
• #7
I'll answer the red LED thing in your other post on that topic
Got it, thanks.
With this:
Press the BTN a few times and the green led remains on sometimes, so the last edge has been missed?