Avatar for DanTheMan827


Member since Jul 2020 • Last active Sep 2022
  • 13 conversations

Most recent activity

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

    The shop says it doesn't include it, but isn't it part of the NRF52832 soc?

    I also noticed that the board script for the firmware includes the NFC module.

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

    The script file for my project depends on a custom build of espruino, so I was wondering if there was a way I could just include the boot code with the espruino update itself and get both in one shot

    The puck.js Bluetooth update zip

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

    Is there any way to bundle a script with the Espruino update file?

    Ideally without clearing the entire storage with each update.

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

    Well, to get around malloc I just allocate a buffer from javascript and use a native setter function to set the pointer, so that's not a huge issue, memcpy I just re-implement, but that could probably be passed like the other functions that are in the firmware.

    Maybe it would be possible to set up the NFC interrupt so that it can execute native functions by their pointer that are assigned by NRF.on("nfcRx", myNativeFunction) if they match a certain signature?

    That could also be applied to any event handler really, but I haven't run into any timing-critical ones other than NFC.

    It's not so much that implementation of NFC protocols can't be done with inlineC, but more so that going through the event loop just adds a delay that causes issues, especially if you just end up calling a native method anyways.

    I know that the hardware is capable of it, there are different projects doing this with native firmware.

    It could certainly be a module implemented in the firmware, but for my specific purpose I want to add support for non-standard NFC commands for my own use... things like being able to rewrite the entire tag payload, change to different payloads entirely and such over NFC using a custom app... I use bluetooth right now to take care of that, but nfc rx/tx is so much faster.

    I'll try exposing all of the hal nfc method pointers so I can use them with inlineC and just make use of those directly... yes, I know at that point I should just make a native firmware or bake it into the espruino firmware, but even if debugging is limited it's still easier to iterate using the web ide for me at least anyways.

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

    I’m trying to write an NFC emulator that conforms to the NTAG215 spec and can do read / write, a “magic ntag” if you will.

    Functionality similar to what the chameleon mini provides.

    The issue doesn't seem to be entirely so much the time it takes to get to the event loop and execute the code, but rather the time it takes the code to execute.

    I’ve implemented a good portion of the spec in pure JavaScript but the more checks I add the less likely it is to successfully scan, this is why I want to get as native and as fast as possible without having to keep iterating with native firmware and re-flashing the whole shebang over Bluetooth (I don't have a debugger for one...)

    I’ve done some testing and built a custom firmware with those hal function pointers exposed and I was then able to write some inlineC code that can be called by passing it the pointer and length of the rx buffer, then I respond directly from native code, it works but it weirdly is less compatible than the same logic in pure JavaScript... is there more overhead to get the pointer and jump to the compiled inlineC function than there is to just keep it all in javascript?

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

    Hi! In some cases, inline c can be called a bit more 'directly' - eg setWatch(..., {irq:true}).

    However for NFC and Bluetooth stuff it's not really possible - they are designed around a message queue, which pushes data from interrupt-land down to the message loop. By the time you're in the message loop and have seen that you're calling inline c, it's too late.

    Would it be at all possible to call NRF.nfcSend or the native equivalent function from compiledC?

    I could be wrong, but it seems if hal_nfc_send, and hal_nfc_send_rsp were exported for web compilation that it could work purely from C without even another command once it jumps back to javascript

    I hope I'm not being too annoying with all these questions... just trying to figure out a way to write a fast script that doesn't require a custom firmware

    In a way it might be nice to have a bit of a standard library of functions (eg digitaWrite/etc) that can be called from Inline C

    Yes it would be...