You are reading a single comment by @Gordon and its replies. Click here to read the full conversation.
  • I've actually been wondering about this - effectively exposing an Arduino environment that runs on top of Espruino (maybe even using the Arduino IDE). The idea being initially to get more folks writing Bangle.js apps.

    However there are a few issues:

    • I can't expose all the nrf* API calls - their location changes every time a firmware is compiled, and the only simple way around that is to have a table of their locations. I can't afford to have a massive table of the 100s of nrf calls sitting in flash on every device - and sometimes calls aren't even there (they aren't compiled in, or are inlined).
    • As you note with NFC, you're seeing a delay executing because of the event loop. I can't disable that event loop because that's basically what Espruino is, so even though you could write your code in C, you might still see a bit of a delay between calling of loop.

    I think the delay between calls to loop is to be expected in many devices (regardless of Espruino). If you need time critical you really need to write code that runs in interrupts. In your case (and I think I mentioned this before when you were asking about NFC) I think you really just need to make the changes inside the Espruino firmware in the interrupt handler.

    It's actually pretty easy to compile Espruino, and you get access to all the nrf functions, plus you'll definitely be able to service the NFC command quickly regardless of what else is going on.

    So I think having the ability to write native code would be really cool, and I'm interested in doing it - but I think in your case with NFC it probably wouldn't help you anyway

  • I can't expose all the nrf* API calls - their location changes every time a firmware is compiled, and the only simple way around that is to have a table of their locations. I can't afford to have a massive table of the 100s of nrf calls sitting in flash on every device - and sometimes calls aren't even there (they aren't compiled in, or are inlined).

    Both issues can be solved in a way.

    The table can be exported to file as part of build and published together with firmware and compiler would need to import it - wrong version of table would crash it at runtime of course. (could be even put into dfu zip as extra file?) so either people would need to pick matching file to use this or the compiler service would access published fw versions based on detected device board/version. Is is a bit fragile however.

    API would need to be marked to not be inlined, so not random nrf* driver calls but something like jsh* ,jsv* could be enough (?) and those are not inlined anyway.

About

Avatar for Gordon @Gordon started