-
The antenna is under the battery, the “sticker” is a shield, and yes, you have to place the device button side down for it to read on some scanners like the Nintendo Switch.
The intended purpose of the AmiiboLink branded ones is to emulate amiibo dumps, so they definitely have NFC connected, and it works with espruino just fine… I’m not sure about NFC on the round BLE beacon PCB.
-
Here's the board definition I've made. LED1, and LED2 are functional as red/green. Speaker is in the definition, but it doesn't show up in espruino for some reason... I just use D14 directly.
There are multiple boards all being sold under the AmiiboLink name, but they include different firmwares and have different physical layouts. Pin assignments so far appear to be the same.
https://imgur.com/a/K8Wp6Rp
https://imgur.com/a/72CGuWt
https://imgur.com/a/rcPw5CiSomeone else has also taken pictures of another variant with rechargeable battery.
-
If it’s not enabled by default, I think it should definitely be behind an ifdef, or maybe enabled some other way. Maybe a DFU update that flips a byte flag somewhere?
It’s hard though, because you’re trying to secure functionality through a repl console that should ultimately be password protected by the user… I get what you’re saying though
-
I’m looking for a way to reboot into DFU mode without having to hold the button.
Is this possible? I’ve tried poking various 32-bit values into the address that should be GPREGRET, but it immediately reboots with all three LEDs on, and then back into espruino.
0x4000051c is the address I’ve been using, but I’m not so sure that’s correct.
-
I have a device called the “Amiibo Link”, it’s a board that can be found for around $8 or less on AliExpress.
Inside is an NRF52832 512/64KB, red / green LEDs, speaker, button, and an NFC antenna.
I have a board definition, but I’m not sure of the process involved, or if you’d even want to add it.
SWD pins are accessible through an unsoldered header, or even with oscilloscope clips if you’re careful to not scratch the solder mask on the ground plane.
Although I’m not quite sure how to assign a device like the speaker in the definition. To use it, 50% PWM at various frequencies changes the tone, and high or low on the pin seems to disable it altogether. Different PWM values do also change the tone and volume slightly.
-
Well, I was referring to the BLE UART, not a physical serial connection.
Flushing the transmit buffer isn’t a huge deal, I currently just set a timeout, but if there was a way to pause js execution until the last BLE UART packet has been sent, it could definitely simplify things and eliminate guessing.
I only really have one situation where I don’t want the buffer combined with previous repl output, but that’s just when I move it to Serial1 and send a string to let other end know I’m ready.
The receive buffer has the workaround mentioned above, although one thing that might be helpful is a way to tell espruino to not fire the next on(data) event until so many bytes have been received, with the option of a timeout.
Maybe something like this to receive 500 bytes with a max timeout of 100ms between rx events Bluetooth.receive(500, 100, dataReceived, rxTimeout)
My project might not be typical, but I chose to forego the REPL console on Bluetooth for the additional speed of sending data.
An example of an exchange is
-> 0x03 0x01
<- 0x03 0x01
-> (572 bytes)
<- 0x03 0x01 -
Is there a way to force the buffers to immediately flush?
Sometimes I want to send just a specific chunk of data as a uart update.
On the other end, I have a function called from an on data callback that adds another temporary listener to combine the output of multiple packets into one buffer. The issue is that the initial packet sent to the first callback is still in the buffer by the time I run the code, so it becomes part of the start of the combined buffer.
There’s a workaround I’ve found to wrap it in a timeout of 0, but that’s not the cleanest to deal with
-
In the Bluetooth.on callback, would it be safe to assume that the data received event will be called in order of being received?
If I have a callback that takes longer, will the firmware wait to call the callback for the next chunk of data, or is there a chance that multiple instances of the same callback could be running at the same time?
If I sent 572 bytes of data in 28 characteristic updates, would it cache all 28 updates, or would you risk having some lost?
Sorry for all the questions.
-
What I would like to do is have a function I call that allows me to attach my own handler to the BLE UART RX/TX and basically disable the espruino interface until the device disconnects.
Is this possible?
Being able to send JavaScript over UART is convenient, but it’s not ideal if you’re sending binary data back and forth.
I’ve somewhat implemented what I want, but it doesn’t actually use the UART, but rather alternative characteristics that behave similarly
Ideally I would just keep UART and add my two additional characteristics with advertisement, but as things are now, I have to change out the services
-
-
-
-
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.
-
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?
-
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
, andhal_nfc_send_rsp
were exported for web compilation that it could work purely from C without even another command once it jumps back to javascriptI 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...
-
I have a watch set to trigger on the rise with a 50ms debounce and in 2v08 I can repeatedly press it and the action goes off just fine.
But with my code on 2v09 I have to wait a couple hundred ms before I can press it again...
If I make a new sample project it doesn't exhibit any issue, but for whatever reason my code doesn't work the same with 2v09.
https://raw.githubusercontent.com/DanTheMan827/ntag215-puck.js/master/ntag215.js
I've tried putting console log statements at various places and they all seem to trigger at the speed they should, but there's still that pause that needs to be between presses...
Any idea what could be causing this behavior?
-
-
-
I'd like to dive into writing some native firmware for the puck.js but I've only ever messed around with devices that supported the Arduino IDE.
I'm not a stranger to coding in C++, but I'm a little at a loss when it comes to setting up toolchains for embedded stuff like this.
I've tried looking at the espruino repository, but that supports so many different boards that it's a little difficult to figure out what build process is for what board.
What I definitely don't want to happen is me somehow managing to bork the bootloader and have a puck that I can't flash (if that's even possible)
A repo with a couple examples in C++ that builds a firmware bin for the puck.js that could be flashed over DFU would be quite helpful.
-
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?
-
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.
-
-
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.
-
@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
Does anyone know how I could define a SPEAKER in the board config? As it is now I just use D14 directly, but it would be nice for compatibility if there was just a way to define it as SPEAKER. It seems like espruino should support it, but it doesn’t seem to for me