Selecting a Bluetooth Microcontroller:
A Developer’s Perspective

There are two major branches of Bluetooth^® application development. One is mobile platform development like smartphones and tablets running on iOS, Android or other mobile operating systems. The other is embedded application development. I often get questions from Bluetooth low energy developers who are curious, “how can I select a suitable Bluetooth LE embedded microcontroller for my prototype or product?” In this blog, I outline some tips for choosing the right one.

Module/Chipset

Most Bluetooth low energy modules are fairly simple to use. On the module itself, most of them already include a Bluetooth^® low energy chipset, chip antenna and other necessary components like an oscillator, resistors and capacitors. We just need to provide a power supply, flash the firmware, and then start working with it. This allows developers to focus on firmware design while skipping hardware design. Most module suppliers already have some qualifications like CE and FCC, so buying a module helps developers save time on product releases.

For Bluetooth low energy chipsets, if a developer has hardware design skills, especially RF design, it might be a good choice. On the chipset, not only does a designer need to layout the Bluetooth low energy chipset, but also needs to add extra parts like an oscillator, resistors, capacitors, power supply, balum and antenna. Although it’s more complicated than simply using a module, developers have much more flexibility to design their product exactly as they want. However, going the chipset route is cheaper than a module route but it involves skills and time that many developers don’t have, which could quickly take up any cost advantage of “designing your own” with a chip.

RAM—Random Access Memory

The selection of an embedded platform for your Bluetooth low energy device is application-oriented. For any kind of embedded application development, it needs to consume RAM (Random Access Memory).

In Bluetooth^® low energy application development, a developer not only needs to consider RAM consumption for the application layer, but also for the Generic Attribute layer of GATT—a main point for developers to calculate how many bytes of RAM will be consumed in a Bluetooth low energy design. The GATT profile in your application most likely has several services—and several characteristics in each service. The size of these characteristics can be pretty big. For example, 50-100 bytes (in Bluetooth 4.2 the maximum length of an attribute value is 512 bytes). At this point, you should pay attention that the RAM capacity of the chipset or module can meet your technical requirements—the proper margin there will make your application upgradable and flexible.

Dual-Core, Coprocessor

Some applications have tough requirements for real-time abilities; some applications have very complicated computational algorithms; and some applications need very rapid responsiveness. Sometimes, a Bluetooth^® low energy microcontroller can’t meet all of the technical requirements, so the developer could adopt a dual-core approach in the design. In this architecture, the Bluetooth low energy microcontroller acts as a co-processor which takes on the responsibility of Bluetooth connectivity maintenance; the other core, the host microcontroller, takes the responsibility for high-capacity computing and real-time responsiveness. Between the dual cores, there is a data bus. It could be UART, SPI or I2C, and the host microcontroller can control the co-processor through this bus.

Peripheral

Most Bluetooth low energy applications need to interact with sensors, buttons, a touch screen and so on. When a developer starts to select an embedded microcontroller, he/she should guarantee the mandatory peripheral interface is there.

Security

Before selecting a Bluetooth^® microcontroller, you should think about security. Some applications need more powerful Bluetooth security protection, like a smart lock. The Bluetooth 4.2 specification provides a new pairing method: Bluetooth LE Secure Connections. LE Secure Connections provides a more reliable and robust pairing protection.

Some microcontrollers provide native, hardware enabled crypto engines like AES128/256 to provide more flexibility for developers to design the security module to fit their product’s needs.

Program Memory Size

A lot of microcontrollers use flash memory for program memory. Typical things stored in this memory area are the bootloader, Bluetooth Stack and application firmware. When developers start a selection for a Bluetooth microcontroller, they should consider:

• Current bootloader size and Bluetooth stack size
• The application firmware code size
• OTA package size—if supporting over-the-air upgrades (OTA). Developers should also plan for a margin of the program memory for future upgrades like bug fixing and feature improvements

Community

If you are new to Bluetooth^® application programming on embedded platforms, you should consider selecting a platform with a mature community. In a mature community, there are a lot of answers to commons questions and FAQs which can kick start your programming adventure. The problems you meet today may have already been solved by other developers yesterday, so it will help you a lot.

At the end

I hope these guidelines help you select a suitable and useful embedded microcontroller for your Bluetooth^® product. To be honest, the more features supported in the chipset/module, the more expensive they usually are for purchase. So there is a tradeoff between cost and functionalities.

Think about it carefully, and good luck. For more information on Bluetooth developer tools, visit the website.