Avatar for Gordon


Member since Sep 2013 • Last active Sep 2023

Most recent activity

  • in Projects
    Avatar for Gordon

    This looks great! It'd be good to see this in the app loader!

    Do you think you could come up with a small self-contained example bit of code that you could post up here that runs really slow like you mentioned? It might be we can find a way to make it faster.

    What do you mean by "Moves Left" - does it actually try and run through each move each time to see how many would be needed to finish?

    Just a thought but even without using compiled code, if you could split the code up such that it could run as a function that gets called multiple times, you could update the screen immediately, and then run the calculation in the background. If the user interacted with the Bangle to make another move you could just cancel, redraw with the new state and start again.

  • in Projects
    Avatar for Gordon

    Great - thanks for all you work on this! Just for anyone else, this is now live on the main app loader: https://banglejs.com/apps/?id=waternet

  • Avatar for Gordon

    Hi - I think this is expected... Because the Pico doesn't know if it has a crystal or not it has to check, so I believe what it does is:

    • Powers up using the internal RC oscillator
    • Switches on the external oscillator
    • Starts executing code
    • After ~1 second it then looks at the external crystal and it it seems to be working it swaps over to using it.

    But that's complicated again, because on the Pico, we wanted to be able to get accurate timing (better than 32kHz), but that timing should also match the real time clock (which only runs at 32kHz).

    So we have some crazy logic that uses the processor's high speed clock counter, but then syncs that against the RTC - and it takes a while to adjust itself to the right speed, especially as it just started adjusting itself once to the internal RC oscillator and then has to readjust to the external one.

    So I'm afraid I don't think there's a great deal we can do to avoid that

  • in Bangle.js
    Avatar for Gordon

    :) yes - literally second line.

    Also, if you give us some idea of what search words you'd likely search for on the Espruino site to find the info then I can add those to the keywords list for the page so it comes up for more people.

    Same for any page really - I pretty much never get any PRs for this, but if there's a page that you found that didn't come up when you searched, there's a link at the bottom of the page that goes to GitHub (eg https://github.com/espruino/EspruinoDocs­/blob/master/info/Features.md) and you can add to the KEYWORDS list at the top of the file and do a PR

  • in Bangle.js
    Avatar for Gordon

    Is theming always global?

    Well, Graphics state is always global - you should always get in the habit of calling g.reset() before you start rendering in a function where you're not 100% sure of the graphics state it's called from.

    If you just do g.drawString then font, alignment, color, etc could be set to anything.

    The current solution is just a sensible compromise of complexity and memory usage... I guess potentially we could have a way to 'clone' a graphics instance into a variable where state for that var is kept separately - but I think the end result is it'd end up getting used pretty lazily and we'd end up storing loads of different graphics states for things that really didn't need it.

  • in Bangle.js
    Avatar for Gordon

    Without a complete mini example to look at I can't be sure, but any function that is defined (even arrow functions) will contain a link to the scope they were defined in. Espruino isn't smart enough to figure out when the function is defined if it actually references any local variables.

    So likely:

    setTimeout(function() {
    }, 3000);
    setTimeout(this.printMem, 3000);

    Will print two very different results. Could that be it?

  • in Bangle.js
    Avatar for Gordon

    Thanks - it is slightly concerning that it doesn't cause an error though.

    It seems that in Espruino, a=3 actually returned a reference to a when really it should have returned 3. So (a=2)=3 was possible when it shouldn't be according to the spec - I've just fixed this for cutting edge builds.

  • in Bangle.js
    Avatar for Gordon

    Ok, it should be fixed now in the development app loader.

  • in Bangle.js
    Avatar for Gordon

    Thanks for the backup! Just installed and I can reproduce.

    But it looks like you had Translations enabled. I just tested again here - if you enable translations and re-upload it breaks, but if they are disabled it's fine - so it should be easy enough for you to get working again.

    @Hank could you have been using translations too?

    Issue reported here too: https://github.com/espruino/Espruino/iss­ues/2417

  • in Bangle.js
    Avatar for Gordon

    Ok, so I'd be pretty sure that actually all the bonding info stays in place after a reboot. @user156416 so you actually checked what I said, and Android reported it was bonded?

    Because I'd have thought that even if Android remembered it was bonded, if the bonds were erased on the Bangle then it would refuse to connect.

    So I think the issue is probably the very recently added NRF.resolveAddress which tries to resolve the address: https://www.espruino.com/Reference#l_NRF­_resolveAddress

    (code for it is at https://github.com/espruino/Espruino/blo­b/cfbc4040dac6a7881e3465f60adc4dd8a1e45b­85/targets/nrf5x/bluetooth.c#L3654-L3673­)

    Maybe you could try calling it from the IDE along with NRF.getSecurityStatus() after a reboot (you can do remote access from a desktop via the App Loader in Gadgetbridge). I would imagine that if bonded, bonded would still stay true after a reboot but maybe resolveAddress(NRF.getSecurityStatus().c­onnected_addr) might not work for you?

    If so, perhaps while the peer info is all saved to storage, maybe the peer manager doesn't actually load it on boot, so pm_next_peer_id_get ends up not iterating over all saved peers?