Bangle emulators (EMSCRIPTENx) versus jstimer

[mdoggydog]

Hi, @gfwilliams, in Espruino commit eb017e0, you mention that the emulator "doesn't implement jstimer". Could you elaborate on that?

• What are the ramifications of not having jstimer implemented?
  • E.g., Bangle.buzz() promise resolves without any delay, for one. What else?
  • setTimeout() and setInterval() do work, so... is that because they use some other timing mechanism? In general, or as a workaround in the emulator?
• Why is jstimer not implemented?
• The emulator does not seem to register long-presses/holds of the "physical" buttons (BTN1, etc) --- is that related to any of this?

[gfwilliams]

jstimer uses hardware timers and interrupts to get stuff to happen irrespective of what's going on in JS (eg normal JavaScript is synchronous - nothing preempts anything else) - so you want a buzz to always last a set amount of time regardless of what's happening in JS, you use jstimer.

Apart from the loading animations which are a separate app, nothing else uses jstimer afaik.

setTimeout() and setInterval() don't interrupt execution so don't use jstimer.

jstimer is not implemented in Emscripten because we don't really have such a thing as a separate timer. We'd have to have maybe a separate thread, or to add code that constantly polled during execution. It's be a massive pain to do, probably a big hack, and as we have no vibration motor anyway it didn't seem worth my effort implementing it.

At the end of the day, the emulator is just meant to be a quick tool for checking things and developing simple apps. I just don't have the time to spend ages making it behave exactly like the real watch.

(BTN1, etc) --- is that related to any of this?

I don't believe so, no. How are you trying to check for long presses? setWatch(print,BTN,{repeat:true,edge:"both"}) reports the time/lastTime so you can work out the length of a button press. Or do you mean the long-press that takes you back to the clock screen?

That is handled by peripheralPollHandler which isn't implemented on the emulator because, well, we don't have peripherals and again it's something that would effectively have to run in a separate thread which would be a pain to implement.

[gfwilliams]

... to add to that though, we could in theory do something in https://github.com/espruino/EspruinoWebIDE/blob/master/emu/emu_banglejs2.html#L112 which would hackily detect when the button had been pressed for a while and send a command like load() to the emulator making it appear to work the same way as it does on the watch

[mdoggydog]

Or do you mean the long-press that takes you back to the clock screen?

Yeah, that is what I was wondering about ('cause I was holding the mouse clicked on the emulated button and wondering "Isn't something supposed to happen by now?" 😄). It's starting to click: jstimer and peripheralPollHandler are both driven by interrupts triggered by hardware timers --- and there is no great way to implement interrupts in the emscripten environment.

...we could in theory do something in https://github.com/espruino/EspruinoWebIDE/blob/master/emu/emu_banglejs2.html#L112 which would hackily detect ...

That seems a bit toooo hacky to be worth it. (...because the frontend code there is just emulating the on/off states of hardware pins.)

On the other hand: earlier tonight I managed to implement "emulate long-press on touchscreen" in a nearby region of code --- but that is not actually very hacky at all, because the JS here is already emulating the output of the touchscreen hardware (injecting gesture codes into the emscripten machine), and it is the TS hardware itself that detects a long-press. (Hopefully I will have a PR to show in the next few days.)

Back to Bangle.buzz(): would it be feasible to emulate some kind of delay simply by synthesizing a setTimeout() call and returning a promise that resolves after that times out, instead of the promise that resolves immediately? That would at least make app JS behave more normally: code waiting on buzz() wouldn't get a chance to run until (at least) after the buzz would have finished. (If the JS is spinning its wheels in a loop, maybe the code never gets to run... but in that case it would never get to run on real hardware either.)

[mdoggydog]

On the other hand: earlier tonight I managed to implement "emulate long-press on touchscreen" in a nearby region of code ... ... ... (Hopefully I will have a PR to show in the next few days.)

FWIW, PR submitted: espruino/EspruinoWebIDE#311 (E.g., with this, the buttonsLong option to E.showPrompt() will work in the BJS2 emulator.)

[gfwilliams]

Thanks for the PR! It's good to have the long-press working - but the long press to reload still won't work? I think it would make sense to send the load() as well if the button is held for longer as I'd suggested.

Bangle.buzz(): would it be feasible to emulate some kind of delay simply by synthesizing a setTimeout()

Yes, absolutely. That would make a lot more sense. Probably the best thing would be to just use this in place:

return jspEvaluate("new Promise(r=>setTimeout(r,100))",true)

... but are there times when the lack of delay is noticeable? It feels like most buzzes are only a few milliseconds anyway

[mdoggydog]

It's good to have the long-press working - but the long press to reload still won't work?

Well, this PR is just for the touchscreen, not BTN1. Since the touchscreen hardware itself does long-press detection (emitting a long-press gesture), doing long-press detection in the browser for the emulator does not violate any abstraction barriers: the browser is simply emulating the touchscreen hardware more completely. Nothing at all has to change in the espruino code; now it simply sees the same data from the emulated touchscreen that it was already receiving from the hardware touchscreen.

The hardware BTN1 is just an on/off switch, which is already perfectly emulated by the browser. Doing press-duration measurements of BTN1 in the browser and using that to trigger events in espruino code violates all kinds of abstraction barriers --- and requires a level of understanding of the code that I don't have yet. (And, not a feature I need from the emulator today, so not a job for me, not today at least.)