Particle Mesh | NRF52840

Hi there,
I just ordered some Particle Mesh boards. First "mass production" boards with NRF52840. Would be very nice to get Espruino ported on those.
There is a referral program, my referral link is https://particle.io/mesh?referral=YKAM5S. I will donate everything - i.e. bonus boards - I get to @Gordon. Perhaps he could help on porting ;-).
IMHO it would be nice to get these boards for a few dollars more directly from @Gordon with Espruino installed (There was a discussion about this in the Patreon section of this board). They comply to the Adafruit Feather specs.
Cheers,
René

Nice - thanks!

There will definitely be an nRF52840 port because I'm planning on releasing an nRF52840-based board, and I'm aiming to bring Bluetooth Mesh to Espruino as well (even on nRF52832 devices like Puck.js).

Actually getting that going on the Particle board should be trivial and I can provide some pointers, however I'm afraid I wouldn't be building/hosting firmwares myself for other people's hardware unless Particle were willing to help support it like Seeed/Ruuvitag/ST/etc do, so if you wanted custom builds you'd still have to do them yourself.

It's a pain but it's just what I'm having to do now - since it's all open, what I build and host on Espruino.com is about the only leverage I've got to encourage companies to help support my work on it.

Just to add, there's some very cool Nordic stuff just around the corner that I may well end up doing something with too. I think there's a good likelihood that LTE-M will roll out across a whole bunch of countries very quickly.

Do you know when you might have a nRF52840 module available ? My project scope has changed and things are starting to get tight inside the MDBT42Q !

I do have some modules here that I'll be testing with soon, but because the nRF52840 has quite a bit more IO on it the module is finer pitch with lots of pins in the middle - I'm not sure if that'd cause you problems or not?

If you want I could take a look at the code (you could PM it to me) and see if I have any suggestions? Usually uploading to flash will reduce the RAM usage massively (especially if you minify), and it might be possible to increase the size of the saved code area if you were able/willing to have a special firmware image.

There's also the ability to upload pretokenised code. It's something I haven't done in the IDE yet but it'd take quite a lot off the code size.

If I can achieve running at boot my bootloader, using Storage to save a new remotely loaded version to flash, then eval from flash then I should be OK as there will be plenty of RAM available.

But if in the above scenario I will run into the issue of the code getting shuffled and so cannot run, then I will have a problem. I don't need to store a second copy of code. If my bootloader detects a new version from remote source, it can delete the current version from Storage (if that helps)

So you didn't have any luck with the suggestions in that other thread then?

When were you having problems with the code moving? During the bootloader or when you attempted to save updated code?

I could probably add a flag to files in 'Storage' that said 'don't reorganise' - which might be enough to help you out.

It seemed to be an issue while running bootloader and on saving a second, new copy of the code before deleting the original. It did work if i deleted original code first.

I have not got back to further testing because in the meantime some external changes have meant i need to put a lot more code into the mdbt42. So i am just hoping when i am done that the bootloader plus code save will still work fine. I will let you know when I get there.

A dont reorganize flag may end up being useful

If you're crashing in the bootloader itself and no other code is loaded then we can definitely make sure nothing bad happens with the re-org. Saving the bootloader as:

eval(`
your_bootloader_code_here
`)

would fix it, as would using the normal save() to save the bootloader, rather than the 'save on send'.

@Gordon I love flexibility of Espruino and how PuckJS enabled me to explore various scenarios. However next education and PoC goal for me would be mesh networks like BlueTooth Mesh and (Open)Thread.

Are you getting closer to releasing nRF52840 (MDBT50Q?) board and bringing Nordic nRF mesh SDK features to Espruino JavaScript world, please?

Bluetooth Mesh should actually be possible on the existing nRF52832 chips - but as I've mentioned in a few other threads it's not actually as great as you might expect from the name.

Basically:

• Actual Bluetooth Mesh nodes that do meshing can't be battery powered as the radio is on the whole time, drawing >10mA - so then a BLE->WiFi bridge starts to look a lot more appealing.
  
• If you have the Bluetooth Mesh nodes set up right then they can actually talk to normal Bluetooth LE devices from the mesh, so Espruino devices are actually compatible with Bluetooth Mesh as-is.
  
  

I am looking at a new product with the nRF52840, but honestly it'll be a long long time before I start to replace existing products with nRF52840.

Having said all that OpenThread actually looks really good and does seem to be a proper mesh solution - what Bluetooth Mesh should have been. And that one really does only work on nRF52840.

Very well said about BLE Mesh, almost no point having BLE but not possible to use battery. But my biggest nRF52840 feature to have is actually the higher TX power, where I did a quick test for the range is absolutely phenomenal. On that topic, do you have plan for MDBT50Q?
Thanks.

If I do a new product with nRF52840 it'd almost certainly use the MDBT50Q as I've been very impressed with Raytac. There's nothing planned for the next 6 months though I'm afraid.

Sorry to revive an old thread, & I'm sure you're busy with Bangle, but you can mark me down as a "would buy" if you ever released a MDBT50Q breakout similar to the MDBT42Q one :) The improved RAM and TX make it interesting to me! I'd be double-chuffed if you managed to fit a little LiPo charger/PMIC on there too, even if it slightly increased the size/price - power management is always a pain.

This thread was originally about the Particle Mesh. Can someone give an update. I wrote about the particle debugger being very useful on this thread.

http://forum.espruino.com/comments/15372006/

From @Gordon
"Having said all that OpenThread actually looks really good and does seem to be a proper mesh solution - what Bluetooth Mesh should have been. And that one really does only work on nRF52840."

Has anyone got OpenThread working with Espruino?

No, no movement on this so far I'm afraid. Bangle.js and the new Puck have been taking up most of my time.