Developing devices with Bluetooth low energy

[Dajgoro]

Hi.

Recently I got into a few projects that require a connection with a smartphone and the obvious choice is BLE.
I got the CC2650 LaunchPad development board which looks like the perfect choice for IoT devices.
I managed to get the board working, but the example code to just turn on a led is HUGE.
The thing has a RTOS which is not trivial and nothing seems to be trivial when it comes to developing something for the CC2650.
All I need is to send a few bytes over BLE, and for that I have to create characteristics, deal with GAP & GATT, assign tasks to the os scheduler, go through a bunch of queues, setup function pointers, etc...
On the other hand one of those cheap bluetooth serial modules from places like ebay are super simple to use which behave like a uart.

So my question is, since I do not need anything fancy, is there a low power mcu like the CC2650 that handles bluetooth in a manner that is more simple to use
which resembles something like writing code for a regular microcontroller without dealing with a complex RTOS?

[dferyance]

Yeah I've also looked at the TI BLE code and was overwhelmed. I don't know if that is just an initial impression or if it is complicated in general.

Well there are a lot of BLE options these days. I don't know enough about your project to know what matches it though. I've used the Bluegiga ble113 that was very easy to get up and running. The trick is that they use a scripting language to run your code on the MCU which is limiting or you are stuck communicating to the chip over a separate MCU.

I've since been using the Cypress PSoC / PRoC BLE modules. They aren't as simple as the Bluegiga but you have full C code capabilities and you don't have to figure out the details of the BLE stack. I'd recommend them but of course it depends on your needs.

Microchip also has a BLE solution but I haven't tried it to have any opinions.

For something really simple, there is the rfduino. It is very limiting what you can do with GATT but at least is very simple to get code running on it. I wouldn't recommend this in general though due to all the BLE limitations.

For more advanced components, there is the Intel Curie as well as the Intel Edison.

[Dajgoro]

Yeah I've also looked at the TI BLE code and was overwhelmed. I don't know if that is just an initial impression or if it is complicated in general.

I've been poking with it for a week and it still looks complicated.

Well there are a lot of BLE options these days. I don't know enough about your project to know what matches it though. I've used the Bluegiga ble113 that was very easy to get up and running. The trick is that they use a scripting language to run your code on the MCU which is limiting or you are stuck communicating to the chip over a separate MCU.

I would prefer to use something that runs C since I would like to use some existing generic C libraries.

I've since been using the Cypress PSoC / PRoC BLE modules. They aren't as simple as the Bluegiga but you have full C code capabilities and you don't have to figure out the details of the BLE stack. I'd recommend them but of course it depends on your needs.

I'll give it a look.

Microchip also has a BLE solution but I haven't tried it to have any opinions.

I saw something about that, but it did not look very friendly either.

For something really simple, there is the rfduino. It is very limiting what you can do with GATT but at least is very simple to get code running on it. I wouldn't recommend this in general though due to all the BLE limitations.

I am trying to avoid arduino things in my projects. I just don't like the the arduino tools.

For more advanced components, there is the Intel Curie as well as the Intel Edison.

That is way too big for what I am aiming for.
My projects are of the scope of something that a regular PIC, 8051 or AVR could do.

I also saw that silabs has the Gecko with BLE, but for some reason the download speed from their webpage is 10kb/s and the devboard is 100$ so I skipped that for now.

[lujji]

All I need is to send a few bytes over BLE, and for that I have to create characteristics, deal with GAP & GATT

That's how BLE stack works. Even such a trivial task like "sending a few bytes over BLE" is achieved by establishing a client-server relationship. On the client side you implement a BLE profile and provide GATT characteristics. Each characteristic has it's own UUID and data transmission is achieved by reading or writing into the characteristic. An easier way would be to implement advertiser and observer roles - this way an advertiser sends data (visible to all devices) and observer simply parses the packets coming from an advertiser with specific UUID.
I used to work with CC254x parts before. TI example code was pretty good. The only downside is that IAR was the only compiler available. If I had to work with BLE again, I would consider something from Nordic mainly because of GCC support and large community.

[Psi]

Have a look at nordic nRF52
The datasheets are a lot better than cc2540 and im guessing cc26 as well.

Also its arm core not 8051 with a few mods tacked on the side.

They have example projects and you dont have to use the rtos

[Psi]

But your never going to get simpler than a 8bit mcu and cheap $1 bluetooth serial port

[Dajgoro]

That's how BLE stack works. Even such a trivial task like "sending a few bytes over BLE" is achieved by establishing a client-server relationship. On the client side you implement a BLE profile and provide GATT characteristics. Each characteristic has it's own UUID and data transmission is achieved by reading or writing into the characteristic. An easier way would be to implement advertiser and observer roles - this way an advertiser sends data (visible to all devices) and observer simply parses the packets coming from an advertiser with specific UUID.

Yes, I am aware of that, I am just looking for something which has that preset in a way that is more easy to handle than how it is setup on the TI mcu.

I would consider something from Nordic mainly because of GCC support and large community.

Have a look at nordic nRF52
The datasheets are a lot better than cc2540 and im guessing cc26 as well.

Looks nice. I think I will order the devkit for the nR52.

But your never going to get simpler than a 8bit mcu and cheap $1 bluetooth serial port

Yes, but that has the habit of being clunky and not very compact.

[janekm]

NRF52 (and its precursor, NRF51) is a beautiful chip, really nice architecture.
The BLE stack is still complicated (and the examples are very much so) though if you really want something simple the mbed BLE libraries on top of NRF51 is as simple as I've seen.
The Nordic chips have good isolation between the lower-layer BLE stack (called soft-device) and the higher-layer libraries and example code.
The Nordic chips are also impressively good value in volume. There's a reason why they are in nearly every shipping BLE device I've seen torn down.

[coppice]

Have a look at nordic nRF52
The datasheets are a lot better than cc2540 and im guessing cc26 as well.

Also its arm core not 8051 with a few mods tacked on the side.

They have example projects and you dont have to use the rtos

The old CC25xx is 8051 based, but the CC26xx is ARM based.

The CC26xx is pretty straightforward to use for a BLE chip, but BLE is generally a PITA to work with. Every application has its own profile, and requires code on both the client and server side to support that profile. Its a lot more work than a TCP/IP app that works over a sockets interface that looks pretty similar on every platform.

[richardman]

What are you using BLE for? I got the ST BlueNRG stack compiled in just a day's work. Much easier than the nRF8255 SDK.

[ralphrmartin]

Try looking at PSoC BLE.

[linux-works]

there's also the intel curie chip that you can get on a dev board (arduino 101).  I've used it before and done some ble work but I have to say, I'm not a fan of BLE and its insanely complex way of doing 'simple' network i/o.

I hope BLE dies and a new standard comes out.  bt classic is not too bad, but ble is a travesty.  was designed by an obj-oriented weenie who clearly is too young to know how real datacom works (sigh).

[jnz]

I went with the Nordic over the TI for a bunch of reasons.

- better documentation
- newer community
- the "softdevice" on the nordic is an upgradable solution vs the dual core ARM on the latest TI devices where the M0 core is un-upgradable (BUT... on the TI this allows greater latency and better deterministic timing as your main core isn't processing BLE functions, that said the Nordic is pretty good at interupt switching to the BLE stuff then back)
- cheaper parts
- more cutting edge developments (BLE 4.2+, this is because of the upgradable softdevice)
- secure bootloader included with source
- better devkit
- easier to find pre-made modules

... YMMV. That said... Classic Bluetooth is out if you want to work with IOS. And no, there really isn't a "quick" way to "just" send a couple of bytes you need all the components in place, but there are examples that will almost immediately get you online if that's all you want to do.

[Dajgoro]

I got the nRF52 and I am now fiddling with it.

... YMMV. That said... Classic Bluetooth is out if you want to work with IOS. And no, there really isn't a "quick" way to "just" send a couple of bytes you need all the components in place, but there are examples that will almost immediately get you online if that's all you want to do.

Yes, that is what I am looking for, a example that will get me something working quickly.

[Dajgoro]

For the nRF52 devboard I am using Keil uVison 5.
I tried some of the examples, some seem to work (ble led ones).
I am having issues with the programming/loading of the compiled code via jtag, sometimes it says "Error: flash download failed "cortex m4" ", sometimes it programs a wrong build.
I tried fiddling with the project target menu, but did not help.
How do I set up that it writes/loads the proper build every time without the random errors?

[alexanderbrevig]

One more vote for PSoC BLE or nRF52.

BLE is not standard comms. It's low energy, and yes - complex with steep learning curve.

[Dajgoro]

I got the nRF52 UART demo working now.
I had a little issue because of putty and flow control settings, once I disabled flow control in the example code everything worked fine.
For anyone trying to get this working, here is what I did exactly:
- Install Keil 5
- Install the Nordic SDK pack for Keil 5
- Install Sagger J-Link
- Load the ble_app_uart_s123_pca_10040 from the Pack Installer menu, Examples tab
- In static void uart_init(void) I replaced APP_UART_FLOW_CONTROL_ENABLED with APP_UART_FLOW_CONTROL_DISABLED
- Installed the nRF Toolbox app from appstore
- Set putty to baud 38400, correct to correct com port
- Connect to board via app
- Type text in putty and manually added char 10 (L-ALT + 10 on numlock)
- Type text in app
And it works, I can now send text/bytes back and forth.
Flow control settings are just probably an issue with interfacing with putty, should work otherwise.

The code of the example is way easier to work with than the TI board.
I tired fiddling with the example code, and its easier to find what is where and modify accordingly.

[jnz]

I figured the nRF52 would be your best bet. Sounds like you're on your way.

My issue is the BLE stuff will have to co-exist with my app code, and RTOS isn't really recommended. So that means I'll need to be pretty particular about how my code works. Esp since I'll have SPI and comms to another chip and that will get interrupted at any time.

This is all SORT OF an advantage with the TI or other chips where it's a separate core that does the BLE work that you still have a place to run any code with any timing or any OS you like. Nordic SAYS the support RTOSes, but when it comes to it they recommend their scheduler instead which will make some things easier no doubt but isn't a straight up RTOS.

[Wimberleytech]

I am a little late to this thread...looks like problem solved.  Nevertheless, I will throw my weight behind Nordic.  I ported Nordic Arduino code and libraries to a Silabs MCU several years ago and used the NRF Toolbox to test functionality.  Was not trivial but Nordic code got me 90% to the finish line.

[janekm]

I figured the nRF52 would be your best bet. Sounds like you're on your way.

My issue is the BLE stuff will have to co-exist with my app code, and RTOS isn't really recommended. So that means I'll need to be pretty particular about how my code works. Esp since I'll have SPI and comms to another chip and that will get interrupted at any time.

This is all SORT OF an advantage with the TI or other chips where it's a separate core that does the BLE work that you still have a place to run any code with any timing or any OS you like. Nordic SAYS the support RTOSes, but when it comes to it they recommend their scheduler instead which will make some things easier no doubt but isn't a straight up RTOS.

As others pointed out, Nordic do provide some active support for some RTOSs, but there is certainly an overhead, both in terms of memory/CPU/code size but also in terms of complexity of execution flows (and accordingly predictability of behaviour).

If the needs of the application are the typical "read some sensor over SPI/I2C, aggregate/filter the values, [store in flash], "notify" to the companion app over BLE, I would propose that in most cases using the Nordic SDK without an RTOS will be simpler and more easy to reason about.

The recent versions of the SDKs have support for asynchronous use of the I2C/SPI peripherals and on NRF52 both support "EasyDMA" so co-operation with the softdevice is not such a big issue any more. Though it was fine on older SDKs and NRF51 too, just not quite as convenient

My usual logic tends to be something like:

• respond to interrupt from sensor, set a flag
• read flag in main loop, activate SPI/I2C peripheral transaction
• get interrupt from peripheral, set flag
• read flag in main loop, process data

That way all the interrupt routines are very short which is good for co-operation with the softdevice.

BTW the "dev zone", Nordic's forum, is really good and Nordic engineers answer questions quickly there.

[jnz]

The NRF52 SDK has ports of FreeRTOS and RTX right inside the SDK archive.
So they are supported, granted, with some restrictions due to their own softdevice's requirements and somewhat less than voluminous documentation / examples for them.

Janekm explains well above this, but I wanted to point out a couple of things.

Yes, Nordic does including RTX and FreeRTOS code - it just doesn't work. At least it hasn't for typical GATT reads and writes with RTX on the 132 softdevice and the nrf52. There is a BIG difference between them including some code - and it working - and even more between being supported.

Nordic themselves told me if I can at all avoid an RTOS to do so. I could really use "two" state machines in my application so I'm not sure if I can yet - but I'll give it a go without for now.