• @Gordon, a quick thought for a - first minimal, but quite useful - setWatch enhancement is:

    Could the setWatch be given a simple (compiled - for speed) callback in the options? That callback would in this case just read the interrupt relevant registers and pass them - as object - to the existing interrupt handling. The handling would then stick it with the usual information into the JS event/interrupt queue?

    In other words: provide a hook for the application to contribute to the event payload... by extending the existing option with a custom interrupt handler function property. The existing Espruino interrupt handling would - in addition what it already does - invoke the function and stick its return value/object with the other stuff in the JS event/interrupt queue and deliver it as payload to the setWatch callback.

    I understand your 'voiced' concern about '...it could make Espruino instable...' (as any JS -
    and other code anyway already does... because it hogs the single and only processor / execution tread).

    I do not know the struct of the Js event/interrupt queue entries, but I'm sure that it can hold a reference to an object... This object would then include all what is needed as payload when invoking the setWatch callback. (If it is just one object, then this object would include the current information plus the reference to the additional object. I appreciate if it also includes the setWatch handle and the options object, because it comes handy for the application in the setWatch callback (no extra - globals / variables would then have to hang around).


Avatar for allObjects @allObjects started