Adding BLE seems trivial: buy a module, implement support, fire up a test app and voilà. Especially when chasing time to do a POC (Proof of Concept).

But, as in life, the devil is in the details. Those who already have a few embedded projects on their shoulders know that it won't be easy. Sooner or later we start to wonder about:

• Costs: Ironically, these "small" modules can hit the budget hard.
• Plate space: Sometimes what we would like to pack in and what actually fits are two different stories.
• Microcontroller resources: Flash and RAM are our gold, and CPU time is our time. It is necessary to allocate all this wisely.

And so on and so forth. Each project throws up new challenges.

Choosing BLE is not just a technical issue, but a strategic one. You have to know the terrain well - from hardware to software to budget constraints. BLE gives us cool possibilities, but like any technology, it requires a prudent approach.

Before we delve into the meanderings of the

Before jumping in at the deep end, it's worth taking a look at the basics of BLE. While the options are endless, we'll focus on a few key aspects, starting with a brief introduction to the structure of BLE.

BLE from the inside out

A BLE device is not just a piece of hardware, but a well-thought-out structure consisting of three layers, each with its own purpose. Today we're basing our discussion on these three pillars, but for the sake of order I'll also take a look at their internal mechanisms - without going into too much technical detail.

APP - This is where the magic happens. This is the layer where our business logic meets data. From here we control the Bluetooth stack and give life to our application, shaping it according to our needs.

HOST - This is the brain of operations, where protocols and work organization are defined. It consists of several key elements:

• GAP (Generic Access Profile) - Here the roles of the device (broadcaster, observer, central, peripheral) are established.
• GATT (Generic Attribute Profile) - Manages services and characteristics, acting as a server and/or client.
• ATT (Attribute Protocol) - Attribute protocol that defines how to identify and work with characteristics.
• SM (Security Manager) - Oversees the security of data and connections.
• L2CAP (Logical Link Controller and Adaptation Protocol) - Adapts data to the Bluetooth standard by dealing with multiplexing.
• HCI - This is the bridge between HOST and CONTROLLER, defining the rules of communication.

CONTROLLER - This is where the hardware takes matters into its own hands, splitting into:

• LL (Link Layer) - Manages connections, broadcasting and maintenance of connectivity.
• PHY (Physical Layer) - Directly controls the radio in the 2.4 GHz ISM band, being the heart of the hardware part of BLE.
  ‍

What opportunities do we have?

Knowing the structure of BLE, we can isolate three main approaches to implementation:

1. All in one microcontroller: Simple, but demanding, as microcontroller resources are limited.
2. Application and Host on one microcontroller, Controller on another: Gives more flexibility and allows for resource optimization.
3. Application on one microcontroller, Host and Controller on the other: Minimizes the load on the application microcontroller, but requires more PCB space.

Option 1: All under one roof

We have two main paths of action before us:

1. Using a standard single-core microcontroller to implement the entire BLE stack yourself - this approach requires a lot of work and time if you decide to build everything from scratch by hand.
2. Using off-the-shelf libraries to implement the BLE stack (for example, bluekitchen/btstack), which allows more efficient use of available tools and faster implementation of the project. However, such a method consumes a significant portion of the microcontroller's resources (Flash, RAM, processing power), which may limit the capabilities of our main application.

Alternatively, we can opt for a dual-core microcontroller that offers a dedicated core for BLE support, such as the STM32WB55. By using the IPCC (Inter-processor communication controller) interface, inter-core communication is possible, which greatly simplifies management and reduces the burden on resources dedicated to user applications.

If you choose a single microcontroller for the entire solution (whether you choose to implement it yourself or use off-the-shelf libraries), it might seem like the most economical option. However, keep in mind that comprehensive support for the BLE stack requires adequate microcontroller resources, which may mean choosing a model with more Flash and/or RAM, or even a specialized microcontroller with built-in BLE support.

One advantage of this solution is the potential space savings on the PCB, provided that the microcontroller chosen takes up less space than the alternative configuration with two separate chips.

‍

Option 2: Split tasks - Application and Host on main microcontroller, Controller on separate chip

In this configuration, the Controller layer is moved to a separate chip, leaving on the main microcontroller both the application and the part of the BLE stack referred to as Host. An example of a chip that can act as a controller is the CC2564C from Texas Instruments, which communicates via the UART interface.

This division of labor gives us flexibility in component management. The ability to swap out a controller module for another as needed, without disrupting the rest of the system, is a key advantage here. Thanks to the standard HCI protocol, we have a free hand in choosing the most suitable chip for our needs.

At the same time, the entire Host layer, including the management of roles, accesses, as well as the definition of attributes and characteristics, is implemented on the main microcontroller. This means that we have to reckon with the need to allocate appropriate microcontroller resources, such as RAM, Flash memory and processing power.

Also note that the use of two separate circuits requires additional space on the PCB. When designing smaller devices, limited board space can be a challenge.

In short, this option offers more flexibility and the ability to optimize resources, but requires careful board space planning and microcontroller resource management.

‍

Option 3: Separate the BLE application and stack into two circuits

In this configuration, our application runs on the main microcontroller, while the entire BLE stack is handled by a separate chip. This solution differs from the previous one in that it dedicates an entire single chip exclusively to managing BLE communications, leaving the application with the full resources of the main microcontroller.

Advantages and challenges of this approach:

• PCB space: We need to find space for both circuits and ensure they communicate effectively, which can be a challenge in space-constrained designs.
• Costs: Using two separate chips can increase production costs compared to using a single, more advanced microcontroller.
• Resource optimization: Moving the entire BLE stack to a separate chip significantly reduces the load on the main microcontroller, allowing it to better utilize its resources for the application.
• Flexibility in choosing a BLE chip: Although off-the-shelf BLE chips often have a predetermined communication protocol, which can make them difficult to replace, choosing one allows the system to be more easily upgraded and scaled.

To summarize the capabilities of BLE

In today's discussion, we focused on different approaches to implementing BLE communication in devices.
Choosing the right approach requires consideration of several key factors:

• Available PCB space: For projects of limited size, integrating the application and the BLE stack into a single microcontroller can be the most efficient solution, saving valuable space.
• Ease of implementation and management: It is important to choose a solution that not only facilitates rapid implementation of the project, but also ensures ease of maintenance and updates in the future. This is key to staying on schedule and getting the product to market quickly.
• Available microcontroller resources: Evaluate whether your microcontroller has sufficient resources (Flash memory, RAM, processing power) to support both your application and the BLE stack. In some cases, it may be necessary to use a more advanced microcontroller.
• Production costs: In the context of larger-scale production, component costs can significantly affect the overall project budget. In situations where unit production is more expensive, but mass production is planned, it may be more cost-effective to integrate everything into a single microcontroller.

‍References

• BLE Fundamentals
• BLE Core Specification

#GoodByte #BLE

‍

‍

‍