Developing devices with Bluetooth low energy - Page 1
Forum section: electronics / general

author: Dajgoro
author_rank: Frequent Contributor
timestamp: October 12, 2016, 01:14:21 pm
content: 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 usewhich resembles something like writing code for a regular microcontroller without dealing with a complex RTOS?

author: dferyance
author_rank: Regular Contributor
timestamp: October 12, 2016, 02:14:17 pm
content: 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.

author: Dajgoro
author_rank: Frequent Contributor
timestamp: October 12, 2016, 02:53:41 pm
content: Quote from: dferyance on October 12, 2016, 02:14:17 pmI've been poking with it for a week and it still looks complicated.QuoteI would prefer to use something that runs C since I would like to use some existing generic C libraries.QuoteI'll give it a look.QuoteI saw something about that, but it did not look very friendly either.QuoteI am trying to avoid arduino things in my projects. I just don't like the the arduino tools.QuoteThat 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.

author: lujji
author_rank: Contributor
timestamp: October 12, 2016, 06:36:14 pm
content: Quote from: Dajgoro on October 12, 2016, 01:14:21 pmThat'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.

author: Psi
author_rank: Super Contributor
timestamp: October 13, 2016, 05:51:28 am
content: Have a look at nordic nRF52The 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

author: Psi
author_rank: Super Contributor
timestamp: October 13, 2016, 05:54:11 am
content: But your never going to get simpler than a 8bit mcu and cheap $1 bluetooth serial port

author: Dajgoro
author_rank: Frequent Contributor
timestamp: October 13, 2016, 09:15:40 am
content: Quote from: lujji on October 12, 2016, 06:36:14 pmYes, 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.QuoteQuoteLooks nice. I think I will order the devkit for the nR52.QuoteYes, but that has the habit of being clunky and not very compact.

author: janekm
author_rank: Unknown
timestamp: October 13, 2016, 04:42:54 pm
content: 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.

author: coppice
author_rank: Super Contributor
timestamp: October 13, 2016, 05:18:41 pm
content: Quote from: Psi on October 13, 2016, 05:51:28 amThe 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.

author: richardman
author_rank: Frequent Contributor
timestamp: October 13, 2016, 09:23:10 pm
content: 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.

author: ralphrmartin
author_rank: Frequent Contributor
timestamp: October 17, 2016, 08:27:54 pm
content: Try looking at PSoC BLE.

author: linux-works
author_rank: Super Contributor
timestamp: October 19, 2016, 02:52:57 pm
content: 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).

author: jnz
author_rank: Frequent Contributor
timestamp: October 19, 2016, 07:55:42 pm
content: 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.

author: Dajgoro
author_rank: Frequent Contributor
timestamp: October 21, 2016, 10:12:35 am
content: I got the nRF52 and I am now fiddling with it.QuoteYes, that is what I am looking for, a example that will get me something working quickly.

author: Dajgoro
author_rank: Frequent Contributor
timestamp: October 21, 2016, 12:16:32 pm
content: 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?

author: alexanderbrevig
author_rank: Frequent Contributor
timestamp: October 21, 2016, 05:51:07 pm
content: One more vote for PSoC BLE or nRF52.BLE is not standard comms. It's low energy, and yes - complex with steep learning curve.

author: Dajgoro
author_rank: Frequent Contributor
timestamp: October 24, 2016, 11:17:36 am
content: 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 appAnd 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.

author: jnz
author_rank: Frequent Contributor
timestamp: October 24, 2016, 07:27:40 pm
content: 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.

author: Wimberleytech
author_rank: Super Contributor
timestamp: October 25, 2016, 01:38:10 am
content: 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.

author: janekm
author_rank: Unknown
timestamp: October 25, 2016, 03:19:49 am
content: Quote from: jnz on October 24, 2016, 07:27:40 pmAs 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 convenientMy usual logic tends to be something like:respond to interrupt from sensor, set a flagread flag in main loop, activate SPI/I2C peripheral transactionget interrupt from peripheral, set flagread flag in main loop, process dataThat 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.

author: jnz
author_rank: Frequent Contributor
timestamp: October 25, 2016, 05:17:46 pm
content: Quote from: evb149 on October 25, 2016, 02:40:39 amJanekm 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.