nRF51822 ?

Hey,

What's the chance of getting Espruino running on nRF51822? It's a tiny ARM Cortex-M0 with 256kB flash, 16kB RAM, and most importantly, built-in Bluetooth LE. Found in Estimote, RFduino, most iBeacon things, and also a lot of fingernail-sized boards on eBay for £5'ish.

I'm a newbie when it comes to hardware-level stuff, so I have no idea how practical this would be, but I expect it would fall on this spectrum:

1. No way in hell, it's a Cortex-M0 with only 16kB RAM!
   
2. Possible, but unlikely without a tonne of work.
   
3. Maybe.
   
4. Sure!
   
   

My guess is probably Point (1).

Anyway, I figured it was worth asking, as it's a nice little thing but I'd far prefer to be programming it with Espruino than messing about with gcc-arm-none-eabi and a Segger!

Tom

At one point I had been chatting to the RFduino guys, and I think mbed has a board that uses it too.

Basically: yes, I'd be pretty sure it will work. Actually getting Espruino running should be pretty easy, and while you're a bit limited with 16kB, you can still do an awful lot.

However the issue is support for I2c/SPI/PWM/Serial/Timers - that's something that's taken me a huge amount of time with Espruino/STM32, and is basically something that will need re-writing if you move away from STM32.

A few things to watch out for, from what I've gathered about it:

• The CPU is partially used for bluetooth. I believe there's some kind of RTOS that needs to run, so I guess that will take up some of the ROM and RAM too
  
• I heard that the bluetooth also takes absolute priority, which makes it hard to do anything timing critical - for instance you may have a timer firing off an interrupt to do something, but if the ARM is sevicing bluetooth then that'll get put off until a lot later. It's possible the situation is better now though.
  

Hi guys,

I'm actually planning on integrating a NRF51422 with the espruino. The NRF chips can be programmed to be communicated with using serial. From this I'd imagine every UART should be able to talk to these chips. The downside is that you'd have to program your NRF51x22 to handle your serial commands and do something with them. All the heavylifting can be done on the NRF chip, you create your own API and send it instructions with your espruino. This should be equally possible for both the NRF51822 and NRF51422 since they're basically the same except for and ANT license.

Regards,

Alex

EDIT: sorry I completely misread your topic. Nevermind :).

@Alex: yeah, slight digression, but I've considered putting an NRF51822 on an Espruino too.

Thing is, the HM-10 Bluetooth Low Energy thing is a pig to deal with: it's all through undocumented (or rapidly shifting documents, at best) AT commands and can't do custom characteristics worth a damn. So, basically it's an iBeacon, and that's about it.

On the other hand, the NRF51822 is a lovely little chip, but needs to be programmed in C. Even a fairly simple thing is a chore to do. It also has I/O limitations that aren't surprising considering the size/cost.

So, I was thinking of using the Espruino as the master, and an NRF51822 flashed with a fairly simple program so it can act as a more-capable BLE dongle.

The project I'm toying with right now requires a board with a much smaller footprint than the Espruino, but I'd far prefer to be uploading .js files rather than .hex.

I just received 10 HM-10's for a different project to use with espruinos... Are they that bad? Damn.. I figured they'd be up and running rather quickly.

Did you manage to flash the 51822 with the espruino firmware and still use the BLE?

Regards,

Alex

It might just be that I'm missing something. I've got about five HM-10's still in their bags for the same reason.

If you do manage to get the HM-10 doing more than basic iBeacon-type advertising, please do write it up. I'm sure it's possible to get it acting somewhat like an HC-05 as far as the serial port's concerned, but I didn't have much luck there either.

I was specifically wanting proper service/characteristic BLE functionality (for constructing, say, a heart-rate monitor), which neither the HM-10 or the RFduino seem to do very well. The 51822 is far more capable, but it's a much bigger job as you're writing a proper application with no Arduino/Espruino-like abstractions.

Getting the NRF51822 to run Espruino code directly is well outside my capabilities, to be honest. Instead, I'm looking at using the 51822 as a peripheral for just doing the BLE work, while the Espruino board does the proper intelligent stuff.

Hi Tom,

I've been playing with the HM-10's and they're kind of working. Is there anything in particular you'd like a write-up on? I'm not exactly sure what you mean by "proper service/characteristic BLE functionality", if you could expand upon this maybe I could help out.

Regards,

Alex

Hi Alex,

Well, both HM-10 (and RFduino, incidentally) seem to be well set-up to do iBeacon functionality. However, if you actually want to use BLE for something more useful (such as a sensor, like a heart rate monitor, temperature reporting, etc.) then you need to be able to construct services, characteristics, and so forth.

I can't see any documented way of doing this with HM-10, at least consistently. The furthest the datasheet goes is about major and minor numbers, which are part of the iBeacon functionality.

...unless I'm missing something.

Put simply, with an HM-10, how would you configure it to advertise a sensor service and equip a smartphone app to connect and collect that sensor data? I can't see any way to do that with the HM-10, and it seems to be the primary use-case for BLE (not, as many think, the iBeacon capability)

Any insights you have would be appreciated.

(I'm still knee-deep in the NRF51822 SDK, which is a major chore: rather than being undocumented and possibly impossible like the HM-10, it's definitely possible, but even a basic sensor app is hundreds of lines of code for all the advertising, asynchronous connection/disconnection handling, service delivery, etc.)

Tom

Hi Tom,

You can use the AT commands to configure them as you like I believe. I was lucky enough that the manufacturers site was online yesterday and I got the latest datasheet. Since that site is offline now, I've reposted it on one of my websites http://avalondesigns.nl/dropbox/files/bluetooth40_en.pdf

You can have them as central or advertiser and you can set the advertising interval. Is that helpful?

Here is some code I used to set it up:

function switchToMaster() {
  setTimeout(function() {Serial1.print("AT+IMME1");},200);
  setTimeout(function() {Serial1.print("AT+NOTI1");},400);
  setTimeout(function() {Serial1.print("AT+ROLE1");},600);
}

function onInit() {
  Serial1.setup(9600,{rx:A10,tx:A9});
  console.log("Booting...");
  Serial1.on('data', function (data) {console.log(data);});
  setTimeout(function() {Serial1.print("AT+RENEW");},200);
  setTimeout(function() {Serial1.print("AT");},500);
  setTimeout(function() {console.log("Ready!");},600);
}

I have pin 23 on constant 3.3v with the 470k resistor and pin 24 rewired to A14 to use the LED2 of the espruino.

Regards,

Alex

Hi Alex,

I think that's just in relation to Bluetooth Classic, isn't it?

For BLE operation, I think the HM-10 only offers a single preset service and characteristic, along with preset support for internal temperature and possibly battery. I spent a few hours going through that datasheet and having a go, but other than rudimentary read and write of the single characteristic, I couldn't build anything more complicated (such as a set of multi-value characteristics within a single service, each with their own authorisation thingies)

I'm not surprised, to be honest, as the actual API for doing BLE on either the Nordic or TI chips is complex... I can't see how it would be sensibly mapped to a simplistic serial profile like the AT command set.

Tom

I saw some example code yesterday for BLE on the 51822 using mbed. It looked pretty nice - maybe they've managed to simplify the API a bit. It could be worth a try?

Hello Gordon, I'm also very interested if espruino could run on the nrf51822 even with a simplify API.

thx

Thanks - yes, it'd be cool.

Espruino is all open source, and is about as easy as possible to port to new platforms - so anyone is welcome to pick it up and try to port it.

Unfortunately real life gets in the way for me - I don't have much free time, and it'd be suicide to spend time porting to a platform that would then effectively cut off my only source of income :(

Gordon you did a terrific job with espruino. Now it's up to somebody to do roll the sleeves and work.

I imagine when you started thinking about Espruino and decided to do it, you evaluated in some way if smt32 would be able to do the job done (like flash size, speed, RAM etc) and once you evaluated and concluded that the chances of being successful with the given resources then you started your work.

I would like to try to port it but I have some questions
#1) Simplify API: What parts of the current espruino would you include ?

#2) RAM: You rightly mention about the 16Kb limiting and possible less as they have their library for the BLE (they call it softdevice). what do you think it's the minimum ram needed for a simplify API?

#3) Stages: I was thinking that to start this I would go port first the basic things and later I2c/SPI/PWM/Serial/Timers. Do you think any gotchas doing in that way?

Thx again for your time.

1) I'd start off without FAT, Graphics, CC3000, etc. You'll see from the Makefile how easy it is to disable them. Still, they shouldn't be big problems to enable afterwards.

2) 8kB is the minimum for it to be sensible. You could get a bit less (especially with the recent ram usage branch), but you'd be very limited with what you can do.

3) Not really. I'd make a point of porting Serial first, as that's your key to talking to Espruino. Once that's going, debugging the rest should be much easier.

I see now that Micro:bit is available, maybe we can also flash it to another boards like RedBearLab BLE, or Seeed BLE micro.
But - for the Micro:bit it produces a hex file, but we need a bin file for RBL/Seeed...
I think -DK versioun would work, but didn't try it yet.
@Gordon, what do you thing?

Yes, it would work - you'll have to build it yourself with your own board.py file though - because the nRF51 can have the serial port on any pin, every single board tends to use a different set of connections, so unless you plan to program over BLE you'll need a custom binary.

Thanks, RedBearLab BLE Nano works after minor modifications of the board.py.