• it seems if hal_nfc_send, and hal_nfc_send_rsp were exported for web compilation

    Yes, that would work. OR if you know the firmware version you're using then you could figure out the address of hal_nfc_send and just include it directly in your code.

    However, as I'd said above, having the faster function won't help you, since the compiled function will be called like a normal JS function - from the event loop rather than as an interrupt.

    Are you trying to do something extremely special, or do you just want to emulate the standard NFC tag format that we currently do, but with the ability to write data?

    If it's the latter I think it makes sense for me to just add the functionality inside core Espruino

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

About