Welcome back to our Bluetooth low energy blog. This time I would like to talk a bit about the different possible flavors that BLE chips can come in, and what the features and benefits are for each of them.
 
First, I would like to clarify a bit about what “single-chip” is. This term has been used to mean different things by different chip-makers over the years. When I first started working in this business, making a single-chip radio was a big deal. In those times, it was quite common to design your own radio by using PLL ICs, amplifier ICs and so on. This required a lot of design effort and took up significant PCB real estate. Chipcon’s first standard product, the CC400 (launched in 1999), provided a big improvement as it contained all the different bits and pieces, but you still had to use external passives for the PLL loop filter and the VCO. Later we integrated these components as well, and we could really say that we had a single-chip radio.
 
Today, a single-chip radio is not a big deal anymore in our market (obviously this may be a different matter for some other types of radio technology), and pretty much every device on the market can be termed to be so. The trend towards higher integration has continued, and today a lot of the focus is on so-called SoCs (System-on-a-Chips). Our definition of an SoC is that it is a device that not only includes the radio, but also includes an MCU (Microcontroller Unit, by analogy with CPU – Central Processing Unit). This means that the device not only takes care of sending your data over RF, but can also run the RF protocol as well as implement the application functionality you are implementing.
 
A typical BLE-related application would be a body-worn sensor. To take a simple example, let’s say you are trying to implement a body-worn thermometer, which will transmit the temperature data to another device (this could be a mobile phone, a watch or a PC). A true SoC, like our CC2540, has all the functionality you need to implement this type of device, except the sensor itself (actually, there is an on-chip temperature sensor on the CC2540, but this may not be accurate enough for an application like this). So you can find a suitable temperature sensor, connect it to the CC2540 using an analog or digital interface, and that’s all you need. The CC2540, with a voltage supply range of 2.0-3.6V, can run directly from a lithium coin-cell such as a CR2032, and includes an ADC, an operational amplifier, an analog comparator as well as digital interfaces such as SPI, UART or parallel and can therefore be directly interfaced directly to most types of sensors. On the software side, we are going to provide the entire Bluetooth low energy protocol stack, including the profiles, so you can concentrate on writing your application code (read the data from your sensor, convert it to the right format) and configure the stack (what profile you will use, how often you will send data etc.).
 
Now, you might say that we should have integrated sensors as well, but when you consider how many different types of sensors exist, this isn’t really that feasible. Also, a lot of sensors are not easily implemented in a semiconductor environment. Even when they can be implemented, for example using MEMS (MicroElectroMechanical Systems), the process technologies that are used may be quite different and integration may not make economic sense.
 
So, in many of the applications targeted by BLE, such as sensors and proximity devices, the CC2540 can implement almost the whole system, justifying the SoC moniker.
 
However, SoCs are not the only form that a BLE IC can take. The most basic BLE IC would be an RF transceiver. In this case, the IC only implements the basic radio, and the entire BLE protocol stack has to be implemented on another device, most commonly some form of MCU. This provides a lot of flexibility, but will may require a large MCU (capable of running both the protocol stack and the application), and also requires that the protocol stack is ported to run on the specific type of MCU used. Of course, you need two devices, which takes up more space and may cost more than a one-chip solution. There may also be issues with running time-critical RF code and time-critical application code on the same MCU.
 
The next step up would be a chip that contains the radio and the lower parts of the protocol stack (the Controller, in Bluetooth terms). This is much used in the Bluetooth BR/EDR (“regular” Bluetooth, as opposed to BLE) world, especially in mobile phones. There is even a standardized interface – HCI (Host Controller Interface), that can run over various serial interfaces as well as over USB. The upper part of the stack is known as the “Host”, as it usually runs on the host MCU in the Bluetooth world. An example would be the CC2560 HCI-level BR/EDR device offered by TI.
 
In a mobile phone, this approach makes a lot of sense, as they include powerful host processors that can run the Bluetooth stack as well as other software on the phone. Since the low-level code is run in the radio device, the main processor doesn’t have to deal with very time-critical low-level tasks. In the phone environment, the work related to protocol stack porting is not as great as in general embedded applications, as there are a lot fewer platforms. This approach also fits well in the PC world, where the Bluetooth Controller device can be connected via USB and the Bluetooth stack runs on the main PC processor. However, in the embedded world it is not so simple. The controller approach does remove the issue of time-critical code having to run on the main MCU, but you still need to port the stack and the resulting solution is not necessarily space- or cost-optimal.
 
The last approach is to make a device that contains the entire protocol stack (may or may not include the profile level) and interfaces to a host MCU using a serial interface. There is no standard name for this approach that I know of, but here at TI we usually call it a Wireless Network Processor (WNP for short). For example, our CC2480 is a ZigBee WNP. This approach provides a nice architectural split; the RF protocol lives on the RF device, the application lives on the host MCU. This means that it is a very unobtrusive way to add wireless functionality to an existing product, for example. You also have full flexibility to choose an MCU to fit your application needs, without having to worry about running the protocol stack as well. We are planning to offer a BLE WNP product, this will be called the CC2541S (previously, it has been known as both CC2584 and CC2560 - sorry for any confusion this has caused).
 
I hope this gave you a taste of what advantages and disadvantages the various types of BLE devices will have. When it comes to choosing between the CC2540 and the CC2541S, my advice would be that if the CC2540 fits your application needs, and you don’t mind porting your application over (assuming it already exists), the CC2540 is likely to be the optimum solution when it comes to cost and physical size. If you already have a favorite MCU (I know there are a lot of MSP430 fans out there, and there is also a lot of excitement around the Stellaris ARM CortexM3 devices that TI recently acquired), if the CC2540 doesn’t meet your application requirements (say you need more processing power or some peripheral the CC2540 doesn’t have) or if you would like to add BLE support to your existing design with minimal hassle, then I think the CC2541S is going to be a good fit.
 
As a parting note, I would like to ask you to keep these different flavors in mind when you compare pricing. Some people have been known to mention the Bluetooth AUP (average unit price), as reported to analysts, when comparing BLE to regular Bluetooth. However, the Bluetooth AUP prices are heavily skewed towards the Bluetooth Controller-type chip, as this is the type used in mobile phones, which are the major consumer of Bluetooth chips. Comparing the price of an SoC directly to the price of a Controller chip is not fair, as with the Controller chip you need to add an MCU capable of running both the Bluetooth Host stack as well as your application to get equivalent functionality to the SoC. Make sure you are comparing apples to apples.
 
I hope you have had a nice summer so far (I’m assuming most of you out there are in the northern hemisphere) and please keep your comments and questions coming.
 
Best regards,
 
Karl