Most recent activity
-
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
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