|Product Performed to Expectations:||10|
|Specifications were sufficient to design with:||7|
|Demo Software was of good quality:||7|
|Product was easy to use:||8|
|Support materials were available:||9|
|The price to performance ratio was good:||9|
|TotalScore:||50 / 60|
Firstly, I want to thank Texas Instruments (TI) for providing the SimpleLink Bluetooth LE CC2640R2F development kit and Element14 for allowing me the chance to review this product. My aim, for this review, was to evaluate the degree of effort it takes to use the SimpleLink CC2640R2F platform to develop a proof-of-concept (POC) prototype.
It was for this reason that I created a blog describing my first impressions unboxing and trying out the getting started demo. The basis for the blog was to begin to determine whether “all the ducks are in a row” to allow a person to quickly get up to speed and develop an application. The link to the blog is here: Getting to know the CC2640R2 LaunchPad from TI
For this road-test review, I have also tried to take the same “ducks in a row” view by assessing how easy it was to navigate and learn the ins and outs of this new development board, based on the documentation and training material provided by TI.
As such, I have broken out my review into sections, which hopefully tie in all the different elements that make up the TI SimpleLink Platform.
Figure1. embedded image source ti.com
Let me start by summarising where my starting point is and why I felt it necessary to review learning resources as part of a road test. I have never been formally trained using any of TI’s development platforms and so all my learning has been based solely on what is provided online by TI and to a small degree by others such as from the Element14 portal and from YouTube, for example.
So from this perspective, my observation was that the detail I found, such as specifications, was excellent but the overall documentation structure that was provided online was very confusing at times because not all the knowledge pools have been joined up or clearly explained, especially if one started the learning process from the product’s getting started guide. In my opinion, the getting started guide did not properly link in, or at least explain to a new user any of the learning resources and what they contain (e.g. Resource Explorer). You can often find yourself going round in circles. This was a big time waster for me as had to stumble around online trying to fathom what is worth reading to get going. Hopefully this graphic illustrates the point.
Figure 2. embedded image sources ti.com
The non-technical or non-specification type documentation can be quite verbose at times and often repeated itself as a way to sell you a concept. So within this documentation I struggled to find the technical detail as it was not properly linked into the marketing documentation (e.g. understanding how XDS110 debugger worked and also how the SimpleLink SDK framework structure worked).
It took me a good while to work out that the Resource Explorer is one of the better places to start learning from. I found the portal itself to be very well designed, from a software design perspective (e.g. intuitive and easy to navigate around), and there is even a very helpful tutorial explaining how the portal works and the different menu options.
However, from a novice perspective, the Resource Explorer also failed to explain the documentation structure of all the information contained within, i.e. there was no headline explaining documentation structure – although a clue is given under the web page title. Namely, it provides... “Examples, libraries, executables and documentation for your device and development board”. In my opinion, the landing page for Resource Explorer was too product focused (i.e. there are clickable graphic icons for different products and product SDKs). If only they provided a more comprehensive explanation on how they have structured this information portal, this would have saved me some time getting to understand what is contained within. For example:
Figure 3. embedded image source ti.com
Where I found TI Resource Explorer most useful, was the information found within the Software Documents folder, in particular the "Documentation Overview for SimpleLink CC2640R2 SDK" document. Within this folder is a sub-folder, “SimpleLink CC2640R2 SDK v:1.40.##.##”, where another Quick Start Guide can be found. This guide describes a very useful work flow as a suggested means to get started with TI’s SimpleLink Bluetooth low energy (BLE) development environment. They illustrate the workflow as follows:
Figure 4. source ti.com
Another vital learning resource that I missed initially was finding the SimpleLink Academy page. It would have been really helpful is this link was provided in the getting started guide. As Resource Explorer explains “SimpleLink™ Academy provides a comprehensive set of training tools that allow users from beginners to experienced developers to learn about the SimpleLink MCU Platform.” It really is useful for those who like structured learning (and have the time) to go through all the learning resources. I tried out the “TI Drivers Project Zero” learning module. I find this to be a good example to work from if you want to learn more about GPIO, I2C & UART handling, rather than BluetoothLE aspects. There is also a very helpful intro on using the GUI Composer to create a dashboard. This GUI Composer can interface with your MCU via the XDS110 debugger.
Otherwise, the only weakness I uncovered with Resource Explorer is that it could improve on the accuracy of the search facility (I got caught out in Resource Explorer because of this when searching for information about I2C – I posted the issue on the forum). Similarly, when I search for information about using a tone Buzzer, it could not find an example if I have selected the CC2640R2 as the product.
However, if I do not choose the CC2640R2 product and search for “buzzer” then it does find an example for you for your device. The previous issue, which I had posted on the TI forum, was similar but in that it was only showing the available examples and not any available supporting documentation. I am not sure if there is any supporting documentation supporting buzzer.c and buzzer.h files. So, although an example was found in this case, no information is provided about how to best incorporate within the SimpleLink framework – this issue is mentioned in part 3 (software review).
One really clever trick I spotted with the dev.ti.com landing page, was that when I connect my CC2640R2 Launchpad to my PC via USB cable, it automatically detects my device and provides me with a range of learning and discovery options (although the 2nd option to browse examples sends you to the dev tools link which does not provide you with examples).
Figure 5. source ti.com
So, once you get past that initial stage of getting lost, you will slowly but surely begin to find your way around. The more familiar you become with product the quicker it gets at finding the correct detail, once you know where to look. You are really provided with everything specification wise (I cannot remember when last I saw a +1000 page technical document on a MCU wireless platform).
The unboxing of my CC2640R2F LaunchPad is covered in my blog (which also includes pictures).
For me, learning about the hardware, started with the “Getting Started Guide”. Here you are presented with the Launchpad pinout.
You are then given a URL which directs you to the CC2640R2 Launchpad page within the “Kits and Boards” section in TI Resource Explorer.
In the introductory text you are then provided with a URL directing you to the LAUNCHXL-CC2640R2 product page on ti.com (more on that later) and in the menu section you are provided with a link to a zip file (titled schematics), which are the design files containing schematics and Gerber files for the PCB.
The schematics provided contain details on both the CC2640R2 MCU RF and the XDS110 Debugger (based on the TM4C1294NCPDTT3R MCU), as shown below, as well as the BoosterPack Headers & Peripherals (such as the 8Mbit external flash) and the XDS110 Debugger Interface. As I am not an Electronics Engineer, I cannot provide critique on these schematics.
The LAUNCHXL-CC2640R2 web page provides you with an overview of the hardware. Here is a summary:
There is no mention on this web page as to of what else is contained on this Launchpad, such as the 2 LED’s (red and green), the two pushbuttons (BTN1 and BTN2), the SPI 8Mbit external flash and the XDS110 debugger and its interface.
As such, I would recommend you also look at this CC2650 Launchpad picture (as found in TI Resource Explorer – A closer look at the hardware), as provides all the necessary detail:
Figure 6. source ti.com
The webpage on the CC2640R2F MCU itself (http://www.ti.com/product/cc2640r2f) is much more detailed. For normal operation that MCU can be powered from 1.8V up to 3.8V. So an LDO, or equivalent, would be needed if wanting to use with a fully charged LiPo battery (@ 4.1V).
I did not have a chance to test the power consumption characteristics, which are listed as follows:
A core feature that is mentioned here is that this sensor controller is ideal for interfacing external sensors and for collecting analog and digital data autonomously while the rest of the system is in sleep mode. It also notes that the Bluetooth low energy controller and host libraries are embedded in ROM and run partly on an ARM® Cortex®-M0 processor.
Other MCU features highlighted include:
The webpage also includes this very helpful diagram for guidance:
Figure 7. source ti.com
So to summarise, this Launchpad is packed with performance enhancing features within the MCU, and with the BLE 5 and 4.2 stack, and I have only begun to scratch the surface getting to know it. The speed of this “getting to know you” process will of course be dictated by the ease of creating firmware.The SDK and the IDE is reviewed in the next section.
The CC2640R2 Launchpad comes with a range of demos and examples. Please read my blog which describes the upload process and quick test of Project0 and the Out of Box (OoB) demo.
Prior to reviewing this product, the only TI development platform I had used in the past was the CC3200 Launchpad where I used the Energia IDE and Code Composer Studio (Eclipse based IDE). This past experience helped me get past the first hurdle of understanding the pros and cons of each IDE option available, although back then the CCS Cloud IDE option did not exist.
So I decided to give the CCS Cloud IDE a go, as I did not really enjoy using the CCS desktop option and Energia is not CC26XX ready. I must say I had no problems with CCS Cloud and this is now my preferred option, especially with developing prototypes / proof of concept applications. However, please be aware there are some limitations with CCS Cloud IDE, which I am only now discovering. For example, the “Bluetooth 5 2Mbps PHY” tutorial, as found in the SimpleLink Academy Lab, can only be done using the desktop CCS option. Maybe there are other CCS Cloud limitations, but I do know that if there is a problem, you can readily download your code for use in your desktop CCS version.
The only major downside I found with the CCS Cloud IDE is that it severely limits you on the number of applications / code examples you can have in your workspace. This is very restrictive as sometimes you need to test different code elements quickly and uploading ready examples is often the quickest method for me. Compared to competitor cloud IDE options (e.g. MBED and Electric Imp IDE) I thought this is very limiting. At least it has automated change tracking for version control (see File menu and File Revision History... or ctrl B), which is a very nice to have feature. You can import or clone from a Git repo, but no export option, which is a pity. You can download, which creates a zip file of your project folder and there is also an option to share on Dropbox and to export your workspace.
My previous CC3200 experience has also helped me quickly build upon my earlier knowledge of the TI-RTOS basics and understand the nuances of the Simplelink framework, and the changes that have made since the launch of CC3200. I have observed significant improvements and enhancements that have been made since then, such as with TI Resource Explorer and CCS Cloud. The overall workflow between these two toolsets is quite streamlined, as shown in this TI graphic:
Figure 8. source ti.com
So, to demonstrate how really easy it is to find an example off TI Resource Explorer, upload it into CCS Cloud and then flash your CC2640R2 Launchpad, I created a 5-minute home-made video, which with a little crude video editing is shrunk down to 3 minutes:
As summarised in the Figure 3 (in section 1), a good number of examples are provided within TI Resource Explorer (note there is also a menu option provided in CCS Cloud IDE that allows you to browse projects, although this option simply takes you back to the TI Resource Explorer landing page). The examples are found within the Software folder, under the following menu structure (for version:1.40.00.45):
So there is certainly plenty to choose from. However, the one example, which I have seen competitors provide, is a data throughput example. This is something sorely missed. Updated Note this initial observation that there was no throughput example is an error on my part as I subsequently found that this has been added to the TI SimpleLink Github repository, which also includes a range of other new examples. Usually, I find that if a vendor decides to use Github then ALL examples are included here. So, if this is not planned then please add the Github examples to TI Resource Explorer as it helps to have a single complete resource portal rather multiple resources with different bits of information.
I note that a “rfPacketErrorRate” example is provided under the "TI Drivers" folder, which could also serve to evaluate RF performance, but the readme document states that “The Packet Error Rate (PER) example showcases different RF transfer modes of the CC13xx.” So, with my limited knowledge of the CC2640R2, I would not know if this example is meant to be included with the CC2640R2 examples and if so, how to amend just yet.
Updated Note that I have subsequently realised (post initial version of this road test) that the above structure relates to an old version (v.1.40....) and that a new version v.1.50.00.58 had been released but I was not sure how to update. So for the benefit of others this is what you will see in TI Resource Explorer, if you hover your mouse over the highlighted SDK. You will get a message "Newer version available, go to Package Picker to select version"
There is a Package Picker icon! Then select the version you wish to update.
Updated The result of this new SDK version is that the ble5stack and the blestack examples are now merged into one folder "blestack". The examples are the same. I also note that the “rfPacketErrorRate” example has been removed from TI drivers example list.
If, like me, you are new to the SimpleLink platform, then I would recommend following the TI Drivers Project Zero example. As they note in the readme introduction: “This workshop is a simple introduction for using TI Drivers within the Simplelink™ SDK. The goal for this project is to get you familiarized with your TI LaunchPad™ development kit, introduce you to TI Resource Explorer and the content delivered within, as well as create & compile a simple code example using CCS Cloud”. If you follow this through it also introduces you to the GUI Composer and how to use this with the XDS110 debugger interface. I think this would be useful for debugging sensor projects as it is a nice way to visualise your data.
Finding the GUI Composer example was something I stumbled across as it is not listed on the TI Drivers ProjectZero page. To find this go to the SimpleLink Academy menu on the left and click on “Labs” then “TI Drivers” and it is second on the list, titled “GUI Composer”.
The next tutorial I tried was the “Bluetooth Low Energy Sensors BoosterPack” tutorial, as I wanted to try out an I2C based sensor example to help me get started on a project idea I had. This tutorial can be found within the SimpleLink Academy > Labs >> Bluetooth LE folder.
I did not have the Sensors BoosterPack and so attempted to amend the example so that I could use my SeeedStudio Grove Temperature Sensor (or TH02 sensor). This was a partial success, in that I could get the Launchpad to communicate with the TH02 sensor, but it was not always reading the temperature and humidity sensor values correctly. The issue stemmed from the way you request for the temperature and humidity values to be calculated and then you poll the TH02 sensor until it tells you it has values ready in the registers for reading. I think the TH02 is not really conducive to asynchronous programming techniques for requesting and reading sensor values, which is what you want if you want to use TI-RTOS properly (as in you want to minimise blocking code as much as possible).
Updated Nevertheless, I did eventually get it working - a case of once you know how, it is then quite straightforward. It really helps to read the API documents. In this case the I2C.h file reference document is required.
The first Bluetooth example I tested was the “micro_eddystone_beacon” example. Both the ble5stack and the blestack examples worked with my phone. I have not explored the reasons why, but after a quick glance at the documentation it looks like both the BLE 4.2 and the BLE 5 options could be using the same Micro BLE Stack.
Updated Here is an overview of the ReadMe document which outlines exactly how it works. I have now subsequently learnt that it pays to read these readme documents carefully, in particular the usage instructions. These readme docs also usually offer other document references that will help you build an application. In this case there are 2 application notes and a link providing information about the BLE Stack and the relevant micro-BLE stack.
Here is a video highlighting the process of uploading to CCS Cloud, modifying the code and then there is a demo of the outcome.
Updated The one thing I find that slows you down initially is trying to make sense what parts are "under the hood" and do not really need to be touched for a Proof of Concept (POC) project and what parts can readily be changed to develop something unique. In the Eddystone example, the options really only relate to:
The next step planned for my Eddystone app example is to change the business logic of the code and add in the button and allow the button to interleave the UID packets with the URL packets, rather than switching off the URL packets altogether. The idea is then to use this POC as a fun way to request another cup of coffee in a coffee shop, for example, while working on your next great TI project on CCS Cloud.
Finally, I wanted to close off by demonstrating the Heart Rate sensor example.
Updated Let's review the ReadMe document first as this introduces some really interesting insights about how the flash and ROM memory architecture is configured. This is not really necessary to understand at the start, if like me, you just want to experiment with a heart rate application. It is on this level that the power of the CC2640R2 architecture shines, especially when your app starts to push on the boundaries are what space is available in the flash.
Updated Another thing I have discovered is that it is not possible to change AUTO_ADV to TRUE when using CCS Cloud. It appears many of the examples are still designed for the desktop version of CCS which is rather unfortunate. So if like me you want to enable Advertising at the start then you will probably need to create your own global variable to manage this, or something along those lines.
What is still outstanding with this demo is the inclusion of code to handle a tone buzzer. The idea being that if the heart rate is above or below certain thresholds, it would trigger a different alarm tone depending on whether the heart rate is higher than your maximum threshold or lower than your minimum threshold.
In this case the buzzer code I found from one example (see search example in section 1) was not totally portable and threw up two errors when compiling for my CC2640R2 Launchpad. I am in the process of resolving these at the moment.
The first one was easily resolved by changing #include <driverlib/timer.h> to #include <ti/devices/cc26x0/driverlib/timer.h>, although I am not sure if this solution then restricts this code to only 26XX Launchpads (still much to learn). I also received a suggestion from the TI forum of changing the include path, but still not sure how to implement this suggestion within CCS Cloud. The second error related to this function PINCC26XX_setMux(hPin, Board_BUZZER, IOC_PORT_MCU_PORT_EVENT0); and the use of “Board_BUZZER”.
Updated The second error was eventually resolved. It simply required inclusion in the pin definitions, which are found in the Board.h file. Here is a very simple demo where the buzzer routine was added to the watchdog example.
Updated Thus to summarise my software review; as there is so much information provided, it is sometimes difficult to work out which documents to read first as it is not always clear and in some cases the information you require is found elsewhere which is not always spotted. A key document I have subsequently found to be very useful is “SimpleLink MCU SDK User's Guide”, which is found within TI Resource Explorer document section in the Software folder. This document provides a very good design overview, rather than a users manual in the traditional sense, and an explanation of the different elements that would make up an application. If I had read this sooner it would have resolved many of my earlier issues, which were described in this section. Hence, if you want to make headway with the SDK, then READ THIS DOCUMENT.
This Launchpad has real potential but there is a very steep learning curve to grasp all the SimpleLink concepts and follow the TI SDK methodologies. Reading and understanding the API documentation is a prerequisite to creating your own applications. So it will take time initially to get going.
The learning resources now available and the CCS Cloud are welcomed improvements since I last tested a Launchpad with the launch of CC3200, although I do feel that there are just too many little niggles and teething issues with the CC2640R2 information provided (I found a few 404’s – bad html links). Hopefully these get resolved soon as can be distracting from what is a good product.
So overall, I do like this device and I will certainly be more inclined to use it and continue with developing my ideas off it.