RoadTest: TI SimpleLink™ Bluetooth® LE CC2640R2F LaunchPad
Author: abrain
Creation date:
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: STEVAL-IDB005V1 - Farnell 2709519 - Microchip DM182022 - Farnell 2499936 - Both considerably more than the CC2640R2F
What were the biggest problems encountered?: SimpleLink academy not easily viewable on iPad - CC2640R2F SDK not available for Mac OS-X - Fuel Gauge II BoosterPack not compatible with CC2640R2F
Detailed Review:
This is my first RoadTest, and my first experience with a TI Development kit. I'd set myself some reasonably high expectations of what I could achieve in the time, with quite a steady plan that added functionality in incremental steps:
- getting the kit and the development environment installed
- blink an LED
- enable a serial console
- read some sensors (temperature, humidity, etc).
- establish Bluetooth comms
- transfer data across the Bluetooth link
- add battery power
- deploy system remotely
There were about 8 weeks to do the project, with a week at the end to write up and tidy up loose ends, and 8 steps in the plan. so we had to tick off one a week, which ought to be manageable....
First impressions are good, the TI SimpleLink™ Bluetooth® LE CC2640R2F LaunchPad arrives in a tidy protective box that wishes you Happy Coding, along with the necessary USB cable and a quick start card that gives you the pin out where to go to download or use some software. There is a web based development environment, but I prefer things to be available off line, so went for the downloads.
More good news appeared there, in that TI's Code Composer Studio (CCS) is available for Mac OS-X, so we set about downloading that whilst we started reading on TI's SimpleLink Academy pages. I quite like to be able to read that kind of documentation on my iPad, especially so I can have that to one side whilst I follow along on my laptop. However, that wasn't quite possible with this, as although you could read the first paragraph on the iPad, the frames it was all displayed in didn't really support scrolling, so I couldn't ready beyond that. Not a great start! It's only a small thing really, but when you're new to the whole environment, it is off-putting.
Still, we're not easily put off, so we carried on reading on my laptop.
I couldn't wait for the download to finish, so eventually I simply plugged the USB cable into a power supply and got the board fired up. LEDs on, and I'd already got the LightBlue LE app on my iPad, so I started that and it found the board! Great, a good example installed and ready to go. We could subscribe to some notifications when we pressed the buttons, and write to some values to turn LEDs on and off, so a great demonstration of what's possible, and at least some of the development environment is up and working.
Two hours in and Code Composer's finally downloaded, and we've read all about Project Zero and the SDK associated with the CC2640R2F. Back to the downloads and looking for the SDK, where we find it's only available as a Windows MSI installer. Not really Mac friendly, and I wish I'd found that before downloading CCS....
So, still undaunted, we fire up Parallels and a Windows 10 Virtual Machine, and start the downloads again...
Ok, so a nice Eclipse based IDE gets installed, not as an Eclipse plugin, a total IDE. I guess that allows TI to have more control, and they've done quite a good job. You get a nice welcome screen, with a video, but also some advice that you should use "Simple mode". That isn't what you'd call good advice, as pretty much everything you read or watch suggests you go to this thing called Resource Explorer, and it takes you a while to realise you don't get that in Simple Mode....
We'd set a fair bit of time aside to get the development environment set up, and it needed it. It's not a great feeling when you've spent all that time and are just about ready to think about compiling some code, but it does always take longer than you'd want, and this was about average I'd reckon. We'd have saved a couple of hours if we'd just started on Windows though.
So, CCS installed and we're getting a little more familiar with the Resource Explorer now, so we work through the instructions to download a local copy of Project Zero and install it into the IDE.
We get to see the source code that was behind the demo software we connected to earlier, and we work out how to connect a serial console to the UART of the built in USB debugger, so are now getting a nice set of debugging log messages as we connect over BlueTooth, read and write LED settings, etc.
This is a little more sophisticated than your usual Hello World or blinking an LED, but does the job of being sure we’ve got the right compiler installed and configured, can connect to and program the development board, and also receive some serial debugging information, so at this point we’re happy we can make a start on some code. We’re also still on plan.
Having read through all the labs associated with the CC2640R2F’s BlueTooth capabilities, we’ve found that the last one includes reading the temperature from the Sensors BoosterPack we were planning on using, so that ought to make us some progress.
For the first step of this lab, we download some more code locally and install that in the IDE, and that gives us a very simple application which reads the temperature over I2C and outputs it over the serial console twenty times. Getting the source code is a little bit of a bother, as you keep navigating away from where you need to be in the Resource Explorer, but the answer lies in being able to have more than one Resource Explorer window open.
The second phase of the lab is a lot more sophisticated, as it involves some automatically generated code that you need to cut and paste into various files within Project Zero, but the end result does work, we can connect over BlueTooth using the LightBlue LE explorer on my iPad, read the temperature, and even figure out that the byte order is reversed when the data is sent, which when you go and look at the code is exactly what you’d expect.
The Labs are pretty good, I've got a fair bit of experience with micro-controllers and associated protocols, such as I2C, SPI, etc, and it's still just a little on the challenging side, but not too much. There’s some comments in the code, but other things are left for you to work out, such as setting a simple define to get the debug output onto the serial console. These take some time to figure out, but mean I’ve been onto TI’s E2E forum where there are a lot of useful threads, and it looks like quite an active community with TI employees responding too.
We decided to press on and read data from more of the I2C devices on the Sensors BoosterPack. This is a great board, offering non-contact temperature, temperature, humidity and air pressure, ambient light, a 6-axis inertial measurement unit and a 3-axis geomagnetic sensor too. There’s a lot of possibilities for this board,
Some of these were easier to implement than others, mostly down to the complexities of the I2C interfaces, but also in deciding which to add as new tasks and BlueTooth profiles, and which ones to group together. We ended up bouncing back and forth between the Project Zero Bluetooth enabled app, and the much simpler app that simply read the sensor and write output to the console, so we could split out the I2C from the BlueTooth aspects. TI provided good links to the documentation for each of the sensors, but they all just took some time to digest and understand, and in the end we didn’t get all of them done as they weren’t relevant to our intended application, which was broadly some environmental monitoring outdoors. In amongst reading these datasheets on my iPad though, I managed to get TI’s Code Academy on the iPad but not in frames view, so although it didn’t have the navigation capabilities, it was at least readable.
I think you tend to learn more from what doesn’t work, and in adding the sensor code from the labs, then modifying that to read the other sensors using I2C I learnt a bit more about TI’s underlying RTOS, and how to add new threads and new variables into the BlueTooth profile, which ought to have been good preparation for the next stage of the development.
Feeling good with our progress so far, we’re looking forward to adding some battery power, in the form of the Fuel Gauge Mk II BoosterPack, which means we’ll be able to read some information such as the temperature, battery voltage and remaining charge, and the average current consumption of the boards too.
We set about modifying the existing code, pretty much following the same steps from the last lab to read the Sensors board, but with a different I2C address and a whole host of different parameters, writing these both to the serial console and ready for a BlueTooth connection.
So, we plugged the Fuel Gauge board in, and basically nothing worked. We couldn’t even make a connection to download the code. Had we bricked the board somehow? The forum’s suggested this was possible. Had we simply run out of space on the stack? That also looked a common problem. If we removed the Fuel Gauge board, the system worked again, so was it something about the I2C code locking things up? Was it in fact an issue between the debugger and the battery board supplying the power?
It seems so obvious now, but we finally came across an entry in the forum that suggested TI’s BoosterPack compatibility checker. Yes, it’s a great idea, and a nice tool too, but when you don’t know something exists, somehow you don’t look for it….
Anyway, they’re not compatible! TI knew that, and we’d confirmed it.
That pretty much brought us to a halt, as that was a key step in being able to deploy the system remotely and test out the range of the communications, and gather some real-world data in a good final demonstration of the system. We’d also wasted a fair bit of time in trying to debug the Fuel Gauge board and add the additional sensors data, so it was really time to stop and write all this up.
Well, we didn’t quite get to where I wanted to, or where we suggested we would when we put forward this RoadTest, but we’ve learnt a lot about the TI development environment and some of the capabilities of the CC2640R2F, and hopefully I’ve managed to give you a flavour of that here.
If you’ve some micro-controller experience but you’re new to TI, and want to prototype some BlueTooth LE communications, and are using Windows, this would be a good starting point, as Project Zero will get you off the ground and up and running quite quickly. There’s also the sub 1-GHz radio I didn’t explore, and TI’s RTOS looks like it’d make a great foundation for embedded systems too, so this board has a lot of potential beyond just BlueTooth LE. With a good download speed, you could have Project Zero up and running by the end of your first day, and have done the Sensors demo by the end of the second, which is pretty good I think.
If you are new to micro-controllers and the embedded world, though, this isn’t a great starting point. TI have made a lot of resources available, but I didn’t really find a great “Start here” type one, just getting you going with the IDE and blinking an LED, then building from there. I think they could do with that, probably on a simpler board, just to help tempt across some of those from planet Arduino, before they move onto the more advanced devices.
I didn’t achieve what I’d set out to do, but it’s not put me off, I will consider TI’s devices and CCS for future projects, even on my Mac, so in that respect this LaunchPad’s probably done its job.
One thing I forgot to mention, and seems to be common to many BlueTooth devices, is that when I've got BlueTooth enabled, my WiFi drops out, and I'm pretty sure it's because they're both not managing to share the 2.4GHz space. It's pretty annoying when you\re trying to develop some BLE devices and would like to look something up on the Internet at the same time! I'm going to try a 5GHz WiFi router, I'll let you know if this fixes it.
