Avatar for DanTheMan827


Member since Jul 2020 • Last active Apr 2021
  • 8 conversations

Most recent activity

  • in Puck.js, Pixl.js and MDBT42
    Avatar for DanTheMan827

    If I use inline c to compile a function, and then I attach it to to say, the NFCon, NFCoff, and NFCrx callbacks, what would happen?

    Would the callback see that it's a native function and execute it directly, or would it jump into the javascript interpreter just to jump back into the native code?

    In my experience with inlineC, the time required to call it from javascript is more than the time to execute it, so it's faster to just keep everything in javascript, but if inlineC attached to a native callback stays native, well...

    If this isn't an allowed behavior, maybe it wouldn't be a terrible idea to have a way to attach native c functions to callbacks directly that don't jump out to the javascript interpreter for at least some of the more time sensitive ones (like NFC)

    also, is it possible to output to the console from inline c at all?

  • in Puck.js, Pixl.js and MDBT42
    Avatar for DanTheMan827

    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.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for DanTheMan827

    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.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for DanTheMan827

    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.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for DanTheMan827

    @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

  • in Puck.js, Pixl.js and MDBT42
    Avatar for DanTheMan827

    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

  • in Puck.js, Pixl.js and MDBT42
    Avatar for DanTheMan827

    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?