Closed notEvil closed 1 year ago
I don't think that's anything to worry about. As I understand it, we poll the accelerometer for accelerometer events (rather than responding to an IRQ line). The accelerometer and Bangle clocks aren't in exact sync so every so often there is drift and when the Bangle checks for an event there isn't one there (hence the slightly longer than normal gap).
Is this causing you any problems?
Atm I'm just recording and hoped for consistent intervals so aligning the sequence with other sequences (e.g. mag and from Android) would be trivial (no time, insignificant offset/drift, ...).
So assuming its just a clock difference, all I need is a poll interval that is slightly faster than the acc so it wouldn't miss by chance. Took me a while to realize that, thanks :)
Almost ... while peripheralPollHandler
is triggered at almost repeatable intervals, jswrap_banglejs_idle
isn't.
I've changed peripheralPollHandler
to call a native function if defined, and added a function to set the native function (using jsvIsNativeFunction
and jsvGetNativeFunctionPtr
), to confirm this and get to the values. When JS is "busy", 'accel'
will skip some measurements for certain. Would you consider adding a native callback to poll? I would prepare a PR
Hi again, sry for the spam
I feel close to a working solution, and it does work for many minutes (~25) before it breaks. @fanoush helped me with a strange issue at https://forum.espruino.com/conversations/383232/ which might still be the reason. But I can't rule out the changes I did for this issue.
This is what I've changed:
based on fa34cf78f381572f39b0ff8200eb0f5ef2999d30
The approach is similar to setWatch(..., {irq: true})
, without touching the ref count. And thats how I use it:
Before the "fix" (initializing with 1), it would randomly alter magi
and therefore lead to corrupted memory and occasionally a hard reset. Now it just stopped calling on_poll
/changing acci
. I run process.memory()
every 5s to log memory consumption, if thats important.
Would you consider adding a native callback to poll?
Afraid not - native functions called from IRQs have all kinds of issues - you can't access JS vars in a reliable way so it ends up being a nightmare for all but the case where you have only assembler/inline C and don't call any other functions.
Also, what happens normally is that the poll handler runs, posts an event and the second it exits the IRQ, Espruino starts in the main thread and processes that event. If that isn't happening, it'll be because some JS code is running on Espruino already and taking a while to run, so it's possible that you could fix this just by ensuring that all the JS functions executed quickly.
There's also the issue that you're wanting to compare with the magnetometer and Android but I think that's handled in exactly the same way in the poll handler, queueing events - so everything should still be processed in basically the right order.
I guess one option to handle this without making things unreliable might be to add a timestamp to the accelerometer events? I don't think the accelerometer used on the Bangle has one built in but I guess the poll handler could add one.
... but then you know the accelerometer events happen 12.5 times a second anyway, so I'm not sure you really need a timestamp?
The limitations of native functions aren't a big deal in this case because its not about realtime JS but consistent readouts. To make JS functions quick so the events would be processed in time is virtually impossible outside a perfectly controlled environment. I just saw the health event causing a lag (the app "Health Tracking" does a lot to be fair).
Another angle would be to change accHistory
to int16_t
and provide access to it (accHistoryIdx
is already there in Bangle.dbg
). Don't know why I didn't consider this previously ...
:) I will test this the next days and see if there are any issues. You can add it if you want, but I don't mind carrying this forward in a fork if you decide not to. Thanks for the support!
Thanks - I think for now a fork might be best, and we see how it works for you.
Closing this issue for now as it appears it's just an issue with processing things at the right time
Hi,
I found that
'accel'
events are sometimes skipped. On my Bangle.js 1, after "Resetting without loading any code", the following prints 16ms at (semi-)regular intervals (cnt ~= 60).'mag'
is fine.