Idea: fully native code

Posted on
  • I know you already have inline c, but what about adding the option in the IDE for fully native c code that bypasses the javascript interpreter entirely?

    I know it's possible to build a custom firmware from scratch, but that requires setting up an entire toolchain and using dfu to flash (and reflash...)

    Just a thought...

    I don't think you can access the native firmware calls from inline c as it currently is?

  • What would you expect fully inline C looks like? Basically just the entire editor being C?

    I think you can actually access the native interpreter calls from C at the moment (https://github.com/gfwilliams/EspruinoCo­mpiler/blob/master/src/utils.js#L74), but it's just not very well documented :)

    But honestly I think if you're not using JS at all, it's going to be pretty painful to write anything useful

  • I don't think you can access the native firmware calls from inline c as it currently is?

    what you mean by native firmware calls (that bypasses the javascript interpreter entirely)? can you provide example of what you think is not possible/available?

  • Yeah, basically just having the entire editor be C with the nrf calls directly accessible, essentially main.c

    perhaps to keep things a little easier, have the firmware call a loop method.

    Something similar to the arduino IDE where you have main and loop methods and those are called from a lower level

    you could still have the firmware handle all the existing loop logic to keep all the RF and running, but then it would call the loop method of the IDE code directly

    the console could be bound to something like the Serial module from arduino, and for re-programming from the IDE, or accessing files, you could momentarily skip processing the loop call.

    really just an advanced mode more-less that presents lower level functionality and performance with the ease of the web ide.

    inline c is nice, but it ultimately is only as fast as the time it takes to go from the javascript interpreter to the native module, and if you're doing something that requires a lot of performance javascript isn't always the best, but setting up the toolchain and going for a full firmware is a bit more difficult than the web ide.

    The hardware has potential, but the javascript interpreter slows things down considerably, yet the web IDE is one if the selling points of the hardware

  • ...to keep things a little easier, have the firmware call a loop method.

    ...is the defeat of an event driven, on lowest power operated system.

    @DanTheMan827, just as you say in next paragraph: Arduino. I agree absolutely that this is 'simpler' for to start with because one has not to deal with events: logic is only status / flags (variable) comparison whether to do something or not... (reminds me of key concept of conditions in RPG, 1959..., and the birth of PLC, 1968). Limitations though hit very quickly...

  • @fanoush It's not so much about what isn't available, the features are all available in the IDE, but javascript is slow...

    I have a NTAG215 NFC emulator, but the time to process it purely in javascript takes too long and some devices time out, at the same time, if I move the logic for processing the RX data and creating the response to inline C, it also takes too long to call that native method from the javascript side of things.

    So to get the performance I would need, the javascript interpreter loop would essentially have to be disabled, but if I were to write a full firmware I would have to re-implement all of the methods for processing the NFC and Bluetooth loops

  • I'm suggesting a compromise between gcc building for the chip directly and having javascript be interpreted.

    Have the loop in the espruino firmware call the loop of your code after processing all the RF signals in the same fashion it calls the loop of the javascript interpreter, that way you could provide faster code execution along with some of the convenience that the javascript bindings provided.

    That could also be used for interrupting your code when you want to do something like have the IDE reprogram the device or printing console output to the web ide over bluetooth.

  • @DanTheMan827, I see where you are going... I resolved this issue with having dedicated processors just for the time critical things... That was one of the reason ESP8266-ESP1 connected serially was such a success. Even the 8-Bit Arduino could do things and have great connectivity. ESP-32 was the integrated answer: two processors, on for time critical things in low level implementation and one for high-level, where times of a different magnitude matter. Having a single processor is always a challenge.

  • True, but in my case the puck is almost fast enough to do all I need in javascript, but the interpreter will always add a delay as it jumps between native and processing the javascript.

  • 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.

  • Yes, we'd talked about that - and it's definitely possible, but I can imagine it'd be pretty easy to end up using the wrong file.

    Right now we have this table for exports: https://github.com/espruino/Espruino/blo­b/master/src/jswrap_process.c#L74

    And it could definitely be extended, but I think that if you're writing something that you want to integrate with the Espruino firmware on any more than the most basic level, you should probably just build your own firmware and it'll save time in the long run.

  • Yes, just mentioning it because you mentioned that Arduino on top of Espruino idea which is new use case for this. Otherwise one can indeed write native code as part of building the firmware.

  • Would making boards for the espruino products available to the Arduino IDE like Adafruit does be something to consider perhaps?

    I did see that Adafruit has a NRF52832 board available for the arduino ide, but they don't include any of the lower level NRF SDK calls in it, and I wasn't able to actually get it working with my puck.js, maybe it was something with the bootloader

    For me (and I'm guessing a number of people), the value is in the hardware package, not necessarily just the IDE.

    I don't know if you would want to maintain two sets of documentation or not though.

    The other option would be to have the IDE send the code to the web service to compile a full bootloader+firmware file to flash like an update currently is.

  • Would making boards for the espruino products available to the Arduino IDE

    I this case, you'd want to completely overwrite Espruino with your Arduino code?

    It's possible, but it feels like a support nightmare waiting to happen - for instance you'd definitely want libraries for the accelerometer/etc. It is just a standard nRF52 in the Puck though, so it should basically work as-is if you wanted it.

    Having said that, trying to develop code while uploading wirelessly is super painful, and not something I'd recommend. If you were willing to solder to the Puck's SWD pads and GND (so just 3 wires) you could hook it up to a programmer and have a reasonably good experience with it right now - I believe https://learn.sparkfun.com/tutorials/nrf­52832-breakout-board-hookup-guide would work.

    I wasn't able to actually get it working with my puck.js

    As I understand it, Adafruit actually uses their own bootloader that's based on a very early Nordic bootloader, so it wouldn't work with Espruino's more 'normal' one. I guess you might be able to upload with NRF Connect.

    If I could do something where programming with the Arduino IDE was a nice experience then I'd definitely be interested in it - but I really think trying to write C code and upload via a wireless connection is going to be a super slow, painful process.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

Idea: fully native code

Posted by Avatar for DanTheMan827 @DanTheMan827

Actions