-
Ok, fixed - looks like there's a bug in the chip's NFC hardware that needs a workaround. Rather than check for the specific chip model, Nordic checked whether you were using their development board when compiling.
If you were using their development board, they fixed it. The second you compiled something for a real device, they disabled it :( I've re-added the definition for the workaround for Puck.js, so it should now work fine - it may in fact fix a lot of this sort of issue.
-
Wow, yes. Just tested. In my case literally just using NFC on a completely clean device running 1v92 bumped the power consumption up to over 1mA. That's really bad news.
I had a quick check with
setSleepIndicator
and it doesn't seem to be increasing the amount of wakeups/second - so it's presumably some bit of NFC hardware being left on.I've filed an issue for it on GitHub - not sure if I'll get to look into it today, but I'll see if using the NFC code from the newer SDK fixes it. If not, I guess it's time to see if I can reproduce it with the nRF52DK and see if Nordic can find a solution.
-
-
@Gordon what does
BLE Connected, queueing BLE restart for later
actually entail?The bluetooth stack on Puck.js's chip was never designed for devices that modified their services on the fly, and as a result it can only ever add services to the end of the list of services.
So when you enable bluetooth HID, which requires a bunch of changes, Puck.js has to actually restart the bluetooth stack to wipe out all existing services so it can then start again and re-add them in the right order. If it did that when you were connected then the connection would drop - hence the message.
All you need to do is disconnect BLE from the IDE and the BLE stack will restart, then when you reconnect everything will be sorted.
So usually you'd do:
- Connect with the IDE
- Upload HID code (possibly save it if you want to so it'll work again at power-on)
- Disconnect
- Now Pair/connect using your operating system's Bluetooth menu
And you're sorted. I think that you can then also connect with the IDE while it's a bluetooth HID device, but I'm not sure if that works on all platforms yet.
- Connect with the IDE
-
The fact that it resets the Espruino board makes me think that something might be wrong with the wiring? Bad connections would usually make things like I2C functions fail with an error, but not make the board reboot.
Are there pins that can tighten to fit snug in the holes?
There are, but honestly they're pretty evil. You usually have to clamp them in with a vice, and when I looked at it (I originally wanted to ship Espruino boards like it) I felt it was much more likely folks would damage boards doing that than if they just soldered.
If you're going for it then buy a soldering iron (one with a reasonably thin tip), solder, and then some protoboard and whatever cheap pinned components you can find - you can then do a bit of practice first with stuff you won't care about. After the first few you'll be fine with it :)
Also I'd get a 'solder sucker' - it's dead easy to put too much solder on when you're starting off, and it'll be a pain trying to get it off. For a few dollars a solder sucker will easily take off extra solder if it all blobs together.
-
-
And yes - the 'compile' option only works for ARM-based micros, and I don't think it works on nRF51(perhaps not even nRF52) because of the way functions are linked in at the moment.
To be honest it uses significantly more memory compiling. I did some tests, and minified JS code is actually significantly more efficient than almost everything else, including Mozilla's bytecode.
As an aside, one interesting option is actually to ban the use of character codes 128 and up in normal (non-string) code (which I don't think is even an issue) and to then use those in a similar way to your JS packer to pre-tokenise reserved words. It could allow Espruino to store code in an amazingly compact way, while increasing execution speed quite a lot.
Of course it'd then blow away comments, formatting, etc - but on some platforms I guess that wouldn't be a problem.
-
-
-
There's no better option than the BLE UART if you want to do it wirelessly. You could implement your own characteristics, but it'd be just as slow - if not more so.
The issues with writing while Puck.js is transmitting could just be a buffer overflow - if it's waiting to send data while also receiving stuff.
When you're writing code I'd definitely try doing what the IDE does though, which is to send character code 16 at the start of line for each new declaration (which disables echo for that line). You can get the
espruino
NPM package (the CLI tools) to output the exact characters it would have sent to a file, which might help you there.Otherwise you can just send
"echo(0)\n"
before everything to totally turn echo off for all commands.I'm afraid I'm not up to speed on the Android BLE APIs so I don't know if there's a faster way to do BLE - but I guess there must be if Web Bluetooth can do it. It might be worth looking at the sourcecode for the Nordic UART app and seeing if they do something different?
-
-
Yes,
_basic
could work. Shame that it still had trouble even with a cut-down driver.It is frustrating about the 16k/32k variant - instead of 3.6k for JS code you'd have had nearer 20k!
I guess Nordic were giving the chips away for free, but if they'd been purchased it wouldn't have made much difference to the BOM at all. -
That's a shame - yes, I guess adding modules can suck up a lot of memory. Doing the 'save on send' and 'modules as functions' tricks in the IDE can free you up a lot of RAM though.
DS18B20 is interesting - the module itself could be insanely simple (just a few lines) but it's been added to over the years with features most people won't use. I guess it might make sense to add a DS18B20_minimal module? Same for a few others... any thoughts about naming?
-
-
With the same error message of 'not bonded'? Does it get very far with the upload or does it fail immediately?
I can't remember seeing the message before - do you have another phone or tablet you could try the upload with? and are you sure it's espruino_1v92_puckjs.zip you're using and not espruino_1v92.zip?
-
-
Hi, Thanks!
I reckon you can use
NRF.sleep()
andNRF.wake()
to stop advertisements. However that will make the device unconnectable when it's not advertising.Also you really want to let it send quite a few advertisements (so leave make 2 seconds between
wake
andsleep
). It's radio so there's absolutely no guarantee that a single message will get through to the Pi.I wouldn't be too worried about the battery usage of advertising though - it's not that huge. You can always reduce the advertising interval to once a second or so, which will really reduce the battery usage without you having to do anything painful with
wake
andsleep
. -
Yes, that sounds like a good plan - just as easy to use, and at least it's not costing you anything :) I guess you could stick something on HttpToHttps.com asking if anyone uses it, so you see what the level of interest is?
Very cool that it's all being served off a local machine though - I never trusted my connection enough to do anything like that :)
-
Out of interest, are you using the CLI from NPM, or GitHub?
Those modules are built-in, and this usually happens if the CLI hasn't been able to work out what type of board is connected (it queries
process.env
when it connects) so it doesn't know that the libraries are actually built in.There was a bug in the order in which the CLI did things that messed this up, but I thought that was fixed - it's entirely possible I haven't updated it in NPM though, and I'll try and do that today.
-
Hi - did you try typing
save()
into the left hand side of the IDE? Normally when you upload code it goes into RAM, and is only saved when you explicitly ask it to be.(You can turn on 'save on send' in the IDE, but sometimes it's handy to be able to fiddle with the code in RAM before saving it)
Just to add - connecting to a USB battery pack or mains adaptor should work great. The only time it wouldn't is if the battery pack doesn't think Espruino is drawing enough power and so turns itself off - but that usually only happens after a delay.
-
I use JLinkGDBServer too and my gdbinit is something like this:
target extended-remote :4242 file espruino_1v92.12_nrf52832.elf break Reset_Handler break HardFault_Handler
If you edit
boards/PUCKJS.py
and rip out some of the libraries you don't want like NET and GRAPHICS, you can then build with DEBUG=1 which will help you loads :)It should work fine - the real gotcha is that the softdevice has a watchdog timer in it, and if you break into something with GDB, the watchdog will fire. The second you then try and continue execution the CPU will restart.
As far as I know there's no real way around that - it's just one of the nightmares of trying to develop embedded stuff.
-
Have you tried doing this: http://www.espruino.com/Puck.js#i-can-t-reconnect-to-my-puck-js-on-mac-os
I guess it might be that the Mac is trying to reconnect to the device even when it's in DFU mode, and that is messing things up. You see the red LED on the Puck when it's in bootloader mode?
Do you ever see it change to the Blue LED light? -
-
Unfortunately I'm yet to update the documentation - it's got a lot easier recently :)
As of 1v92, you can use
require("neopixel").write
: http://www.espruino.com/Reference#l_neopixel_writeThe Puck's current
SPI.send4bit
implementation isn't fast enough to send all the data without gaps (especially when the Bluetooth stack kicks in), so it was easier to use a specific function to handle it. I took the opportunity to make something that works the same across all devices.Only gotcha is there's still some annoying bug where the first LED seems to be set to random colours. Other than that it all works great though.
In terms of voltages, an opto is probably great. You can connect it direct if you're running Neopixels off of 3.5-4v (so directly off a LiPo), but yeah - if you try and run them off 5v you'll hit problems, and the Puck's IO isn't 5v tolerant so you can't do the resistor + pulldown trick that you could on STM32 boards