-
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?
-
-
I'm trying to implement a custom ntag215 emulator with the bulk of it in C, but I'm having an issue passing the received data to my C function.
Here's the function signature:
// int processRx(int, int) int processRx(int rxLen, unsigned char *rx)
I've tried this since it was the same general code that I used to point the C code to my storage array, but accessing rx[0] from the C code just reads 0
NRF.on('NFCrx', function(rx) { var rxAddr = E.getAddressOf(rx); if (!rxAddr) throw new Error("RX not a flat string"); var txLen = ntag.processRx(rx.length, rxAddr); console.log(rx); console.log(txLen); }
the console logs the full expected rx array, but the C function doesn't see the expected values, I'm assuming it's something related to a data type mismatch between the javascript and c code.
-
I don't actually need bluetooth at this very moment, what I'm doing is writing a NTAG215 tag emulator that has a couple different slots that can be swapped with the button that also has a backdoor NFC command that allows rewriting the entire "tag".
I might add in bluetooth later so that I can just manage the tag data directly from an app, but I don't even have that implemented in javascript yet.
After looking into inline c, that could potentially be all I need, but I am curious if I could call the NRF.nfcSend() directly from the C code in some way, that would certainly simplify and speed up things in that respect by not having to pass the response data back to the javascript side of things.
it's not that I dislike the javascript environment, it's just not fast enough it seems to process and send the ntag215 response back within the few ms required.
As far as debugging, I have pin headers on my puck and just connect over uart.
here's what I have so far, it does work, but not all devices are very accepting of the timings.
-
I'd rather just write the code in native C instead of dealing with anything the JS to C transpiler might introduce.
I don't have an issue with C code, I'm just a little confused with how the compile process works, especially when you consider that the puck.js has secure dfu
My code when you really boil it down can be condensed into a single switch statement on the first byte of the received data since all NFC commands are one byte
-
So I found out that javascript isn't quite performant enough for my project and I want to jump off the deep end and write my code in native C, but for programming micro controllers I've only ever used the Arduino IDE.
Is there any sort of blink example project already configured with a Makefile that builds a DFU image for the Puck.js?
I don't really have a need for the additional sensors that the puck includes, I only have a need for NFC related functions at the moment.
I'm no stranger to Linux either.
-
Yeah it's a v2, it was in a pocket inside of its case and went through a full wash cycle and then the dryer.
I still have the original holder and button, I was able to solder one of the ground legs back on and it worked and the IDE was able to connect, but I removed it again just so there wasn't a risk of it tearing the remaining pad off from the stress.
I do have my doubts on if the NFC antenna is still 100% though... my code that was previously working now fails to read/write completely with it failing with a generic NFC error on my corresponding app for the puck, that would unfortunately make it unusable for the intended purpose of being a NFC tag emulator with a backdoor for rewriting after locking the "tag"
Looking at this image, the left side of the battery holder tore the pad right off the PCB, and the button is gone
-
So, my puck.js went through the washing machine and dryer and that resulted in the button and battery holder falling off.
I'm wondering what kind of button I could get to replace the damaged one since the pads for the button are still intact (the battery holder pads however...)
I figured I'll just add some pin headers and give it at least some use as a dev board if I can't somehow secure the battery holder since one of the mounting pads are gone.
-
-
I'm trying to create and advertise a BLE service that I can read and write binary data to, but I can't seem to get the service to actually present itself to a connected device, it does advertise however...
This is the code I've been trying to get working without any success...
var test = "No data"; NRF.setServices({ "78290001-d52e-473f-a9f4-f03da7c67dd1": { "78290002-d52e-473f-a9f4-f03da7c67dd1": { value : [0, 0, 0, 0, 0, 0, 0, 0,], maxLen: 8, readable : true, writable : true, notify: true, indicate: true, onWrite : function(evt) { test = evt; } } } }, { uart : false, advertise: ["78290002-d52e-473f-a9f4-f03da7c67dd1"] }); setWatch(function() { NRF.setServices({ }, { uart : true }); }, BTN, { repeat: false, edge:"rising", debounce:50 });
My end goal is to have a service that I can write to and then respond back to the device writing the data, I think I could do this by updating the value in the onWrite callback?
I've been testing with the NRC Connect app and I have the newest firmware on the puck
-
Oh, I misread, it was potentially 5 years without advertising...
http://forum.espruino.com/conversations/297334/
My usage when actually connecting to the puck would be to connect, transfer about 572 bytes of data, then disconnect... I definitely don't need high-bandwidth mode so that's good to know.
I suppose I could also increase the advertising interval and lower the BLE transmit power since it'll only need to function within a foot or two of the device that's writing to it and it doesn't need to be detected immediately since the application itself will be scanning in the background for it.
I don't have a target for the battery life, but I also don't want it to go flat prematurely if I can do simple things to prevent it.
-
I'm working on a project that simulates NTAG215 tags from the puck.js which will communicate over BLE for managing the NFC tag data, but my question is how long would the expected battery life be in this situation?
I've read that with just a simple BLE beacon that the battery life is 1-5 years but I don't know how that would be affected by having NFC enabled.
-
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