The rise of wearable devices presents a significant challenge to system designers in a number of different ways. A wireless connection is vital to the design, but there is a challenge to maintain as long a battery life as possible while still providing a responsive system that updates seamlessly and securely in the background for the increasing range of wearable designs.
The new generation of specifications from Bluetooth® provides much of this capability. The Bluetooth Smart specifications of 4.0 and 4.1 provide specific support for security and power management, as well as enabling a series of profiles that provide code for specific applications such as fitness and movement monitors, heat and blood pressure monitoring, information updates and notifications in a smart watch and even the ability to act as a key to unlock doors to homes and vehicles.
Market research firm CCS Insight saw the shipment of wearable devices treble in 2014 to 29 million units, up from 9.7 million the year before, and is expected to jump further to 75 million units in 2015. This is being driven by fitness bands and smart watches. By 2018, the company expects the market to reach 172 million units per year, with wearable cameras and eyewear added to the mix of products.
Figure 1: The market for wearable devices is expected to grow to 175 million units by 2018 with significant growth in systems that use both a single chip transceiver and host processor. Source: CCS Insight
All of this is enabled by new families of single-chip Bluetooth wireless transceivers. These combine high performance RF front ends with extensive power management and a low-power 32-bit or 16-bit RISC processor core to implement the Bluetooth protocol stack. These also have additional memory space on the chip to run applications, particularly for single function designs such as fitness trackers. With multiple I/O pins and thin chip scale packaging, these can act as the controller for the system as well as the communications link for a simple application such as a tracker or a key. However, for more complex designs, such as smart watches, that have to implement a more sophisticated user interface, these single-chip designs also interface to a host controller, and these have different development strategies.
The DA14583 from Dialog Semiconductor, for example, is a fully integrated radio transceiver and baseband processor for Bluetooth Smart. It can be used as a standalone application processor or as the wireless interface to a host controller and supports flexible memory architecture for storing Bluetooth profiles and custom application code with the interface to a host controller via the SPI+ pins.
Figure 2: The block diagram of the DA14583 from Dialog Semiconductor shows the different processing blocks that have to be controlled.
The device supports coin battery cells with a typical voltage of 3.0 V and includes a 10-bit analog-to-digital converter (ADC) for accurate battery voltage measurement. For the screen-less wearable designs, it has 24 general purpose digital interfaces that can connect directly to sensors to simplify the system design, as well as a four channel 10-bit ADC to handle analog sensors.
The fully integrated 2.4 GHz CMOS transceiver uses a single wire antenna and there is no RF matching or transmit/receive switching required. This helps simplify the board design for wearable applications where space is critical.
The qualified Bluetooth Smart protocol stack is stored in a dedicated ROM. All the software runs on the 16 MHz ARM® Cortex®-M0 processor via a simple scheduler and the firmware includes the L2CAP service layer protocols, Security Manager (SM), Attribute Protocol (ATT), the Generic Attribute Profile (GATT) and the Generic Access Profile (GAP) that are needed to implement the various Bluetooth services and set up a wireless link. These are included in the profiles published by the Bluetooth SIG and the device supports the ability to develop custom profiles through the SmartSnippets Bluetooth Software platform. This includes a qualified single-mode stack on the chip as well as a range of profiles for consumer wellness, sport, fitness, security and proximity applications.
Figure 3: The separation of the drivers from the applications in the Hardware Abstraction Layer (HAL) in Dialog's SmartSnippets development environment.
Additional customer profiles can be developed by designers, as the software development environment is based on Keil's uVision development tools. These are mature and well tested and contain example application code for embedded modes.
Applications are written in C and compiled and delivered to the device via SmartSnippets. This is integral to the development kits, which come in three types, from basic through pro to expert, each with the I/Os mapped onto expansion connectors to easily link to other sensors. A debugger is provided on the kits that links via the UART or the JTAG ports to program and test the application.
SmartSnippets is implemented through the starter kits, linking to the SPI, UART or JTAG pins. The basic kit is a board with all the DA14580’s I/Os made available and mapped onto expansion connectors. For the PRO kit, the motherboard can be combined with one of several daughterboards depending on the type of package being used, whether a chipscale WL-CSP34, quad QFN40 or quad QFN48. An on-board debug chip gives access to dedicated circuits on the chip that allow developers to profile and fine-tune the power consumption of the application being developed.
The Expert kit is aimed at evaluating the RF performance of the chip via an SMA connector to the transceiver. Both the PRO and Expert kits can be used to profile the power consumption of the different blocks in the device via the SPI connection. This allows developers direct access to tweak the code to maximize the battery life of the design.
The connection between the wireless transceiver and the controller within the chip is a key area for this optimization, and one that STMicroelectronics has worked to improve with the BlueNRG-MS device.
The BlueNRG-MS offers the option of interfacing with external microcontrollers using the SPI transport layer, where ST has developed its own protocol. This defines a software protocol providing functions to access all the services offered by the layers of the embedded Bluetooth stack and provides more visibility of the ARM Cortex-M0 controller and the transceiver within the chip. This allows developers to profile the application code running on the host processor more accurately and so achieve more efficient operation and longer battery life.
Figure 4: The BlueNRG-MS from STMicroelectronics implements a dedicated Application Controller Interface (ACI) for improved access to the transceiver and the on-chip processing cores.
The application controller interface (ACI) uses a standard SPI slave interface running at 8 MHz as transport layer and uses five wires: two control wires (clock and slave select); two data wires with serial shift-out (MOSI and MISO) in full duplex; and one wire to indicate data availability from the slave, and ST makes the ACI commands available for developers to use.
Figure 5: The ACI interface sits between the Bluetooth Smart profiles on the host processor and the protocol stack running on the single-chip transceiver.
This means applications running on the main processor can send ACI commands to control the BlueNRG-MS over the SPI connection, but a key point is that the ACI interface also supports existing HCI commands. If a command is received, the ACI will check whether the command is for the host or for the controller. If the instruction is an HCI command for the ARM controller, the ACI will forward the instruction, bypassing it from the host. This has two advantages: this means the host can control the Link Layer or PHY without using the HCI commands, which improves performance; and user applications can still test the controller individually or set up some low-level hardware parameters with the HCI commands without having to go through the host.
Cambridge Silicon Radio, now part of Qualcomm, uses a custom 16-bit RISC processor called XAP for the controller in its CSR1013 single-mode Bluetooth low-energy chip. This provides everything required to create a Bluetooth low-energy product with the qualified Bluetooth v4.1 specification stack and customer applications of up to 50 Kbytes running on a single chip.
Figure 6: The CSR1013 from Qualcomm has its own proprietary instructions for interfacing to the transceiver and controller via its software development kit.
The chip scale WLCSP packaging allows the CSR1013 to fit into thin wearable designs and supports Li-polymer batteries, connecting directly to up 4.4 V supply voltage without external regulators.
CSR's µEnergy software development kit (SDK) provides a complete graphical code development environment for the application using its xIDE graphical code development environment with breakpoint, variable viewing and memory viewing. The SDK is based on a GCC compiler tool chain for the XAP core with command line build and make tools available for rapid development and regression builds.
The SDK also includes a programming tool for loading and configuring the devices via the SPI line and also support production line programming, test, configuration of Bluetooth address and trimming of crystal oscillators. Setting up the device requires only changing the Bluetooth address and crystal trim (which are provided with each device) and device name in the .keyr file in the tool.
Figure 7: For devices such as the CSR1013 the applications sit on top of the GAP and GATT firmware alongside the Bluetooth services.
Example applications and profiles within the SDK are Bluetooth SIG qualified and developers can use this code as part of the Bluetooth certification process to minimize software development complexity.
The CSR1013 also uses the SPI as a debug interface, and this is available in SPI slave mode to enable an external controller to access and control of the device, usually through the libraries and tools supplied by CSR. However, the protocol of this interface is proprietary and is used to configure and debug the device in production using 16-bit data and 16-bit address programming direct into the controller. Even if this is not used for the development, the four SPI lines have to be brought out to test points or to a header so that they are available for production testing.
Conclusion
Chipmakers have added significant capability to assist developers in implementing Bluetooth connections for wearable designs. The growth of smart watches means that separating out the access to the wireless transceiver and the controller through a variety of approaches will give the developer more options for optimizing the code and minimizing the power consumption.
