Ok, great! Is OpenEmu running on the same Mac you're developing with?
sometimes as 'unknown' and sometimes as 'Puck.js 80b6'
I think this is because there's not enough space in advertising for the HID information and the name. There are ways around this but probably you see 'Puck.js 80b6' just because the Mac remembered the name from before.
I've pretty aggressively been disconnecting the puck from bluetooth after flashing it with my program, so I think the bluetooth stack is automatically restarting in HID mode
Yes, that sounds perfect.
Only thing I'd say is:
Maybe try NRF.sendHIDReport([buttons, x, y], () => { inside a try { ... } catch... - it could fail if you're sending too many HID reports. When the Puck first connects the connection won't be running that quick until it negotiates it up, and that might cause an error which then stops the interval from running. You could add a little LED flash in your code so you can see if update is still executing correctly
I'd remove the print statements. The Puck still has the UART service so it'll be trying to send data over it to the Mac (which I guess won't be listening!). That could cause some issues?
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Ok, great! Is OpenEmu running on the same Mac you're developing with?
I think this is because there's not enough space in advertising for the HID information and the name. There are ways around this but probably you see 'Puck.js 80b6' just because the Mac remembered the name from before.
Yes, that sounds perfect.
Only thing I'd say is:
NRF.sendHIDReport([buttons, x, y], () => {
inside atry { ... } catch...
- it could fail if you're sending too many HID reports. When the Puck first connects the connection won't be running that quick until it negotiates it up, and that might cause an error which then stops the interval from running. You could add a little LED flash in your code so you can see ifupdate
is still executing correctlyprint
statements. The Puck still has the UART service so it'll be trying to send data over it to the Mac (which I guess won't be listening!). That could cause some issues?Hope that helps!