I don't see how the time-of-last-state-change is useful to any client code.
It's actually hugely useful when measuring pulse widths. Often you'd only want your JavaScript code to be called on (for instance) the falling edge, but you want to measure the width of the pulse. In that case only calling your JS once means you can handle signals that are (almost) twice as fast as you'd be able to otherwise, while keeping your code really simple.
As you suggest it's kind of a side effect of the debounce - in most cases (edge:'both' or debounce!=0) you need both edges, so it's easier for the software to just record both, and being able to measure pulse widths is a nice side-effect.
Adding lastEventTime sounds like a possible option - what do others think?
However it's absolutely trivial to work around:
var lastTime;
function onWatch(e) {
var d = e.time - lastTime;
lastTime = e.time;
}
So I wonder if it's really worth slowing everything down and using more memory just to save 2 small lines of code?
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.
It's actually hugely useful when measuring pulse widths. Often you'd only want your JavaScript code to be called on (for instance) the falling edge, but you want to measure the width of the pulse. In that case only calling your JS once means you can handle signals that are (almost) twice as fast as you'd be able to otherwise, while keeping your code really simple.
As you suggest it's kind of a side effect of the debounce - in most cases (
edge:'both'
ordebounce!=0
) you need both edges, so it's easier for the software to just record both, and being able to measure pulse widths is a nice side-effect.Adding
lastEventTime
sounds like a possible option - what do others think?However it's absolutely trivial to work around:
So I wonder if it's really worth slowing everything down and using more memory just to save 2 small lines of code?