-
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.
You are reading a single comment by @Gordon and its replies.
Click here to read the full conversation.
DanTheMan827
@Gordon
That's odd. Not at all - inline C should be fast to execute.
They don't exist in Espruino :) It allocates everything in the JsVars area - if needed you could do the same using the functions that are exposed though.