Bluetooth and audio applications were practically made for each other. The first decade of Bluetooth’s market success was almost entirely due to its integration into audio headsets. When smartphones came into the picture, Bluetooth was still a natural choice, finding an early spot on the dice of virtually every smartphone chipset. People love to stream music from their smartphones.
Bluetooth and smartphones continue to evolve, though — in something of a reversal of the normal sequence of events — and applications have been slow to catch up. However, that is changing as the era of one Bluetooth master talking to one Bluetooth slave device is quickly ending.
For design engineers, this means multiple protocols, multiple connections, multiple devices, and a brave new world of audio applications dawning. Smartphone users want more choices and Bluetooth is ready.
Point of departure: A2DP
The Bluetooth Advanced Audio Distribution Profile (A2DP) has been enabling convenient wireless stereo audio for a wide range of devices for more than a decade. However, now consumers want to use their smartphones to control audio entertainment in ways not originally imagined.
When combined with additional profiles, such as Audio/Video Remote Control Profile (AVRCP), smartphones can be used as a wireless remote control for other Bluetooth audio devices in the home, and the applications can become quite sophisticated.
While intended to be virtually seamless for the end user, these applications present design engineers with significant challenges in software development and certification, particularly when implemented on accessories requiring interoperability within an ecosystem.
Designers have two architecture choices. For the past decade, the prevailing architecture required the module to do most functions — pairing, connection and audio streaming — in hardware. In other words, the Bluetooth module was an audio codec hardwired to execute these functions. The other architectural choice is to execute virtually all functions in software; this is where the 32-bit MCU comes into play. Implementing the Bluetooth stack in software transforms the actual radio into a very thin layer in the architecture. This allows designers to access the data stream anywhere, any time, and for a large number of configurations.
Using Bluetooth’s Serial Port Profile (SPP) and Advanced Audio Distribution Profile (A2DP) simultaneously is something not possible for conventional Bluetooth modules. By enabling software access to the Bluetooth protocol stack, designers can create applications that maintain multiple device connections to the audio stream for listening, and also for control of the stream and other functions normally unrelated to audio. In other words, an audio stream and a control-data stream operating simultaneously without interruption to one or the other.
Combining audio with data control
A straightforward example is a combination desk lamp and speaker system that would allow users to control light levels from their smartphone handset while listening to music. A sophisticated extension of this application would allow control of a lighting system — its color, intensity, response to the music, and more, as well as controlling the audio stream — from a smartphone handset. Adding the “smart home” concept to the application broadens the control aspect to controlling thermostats, coffeemakers, garage-door openers, and other Bluetooth-enabled appliances from what was once a conventional audio codec.
Bluetooth control has a security advantage in these applications, because the data stream can be configured to be independent of the Internet of Things (IoT). Few people want to expose the simple process of controlling their garage-door opener to the uncertainties of operating in The Cloud, which would most likely be the case, for example, with a Wi-Fi solution.
Combining audio and data control in an application that already has multiple profiles operating simultaneously expands the new application even more. In the audio-entertainment domain, a software-enabled concept called “break-in” allows multiple handsets to control the same audio stream. At a party people could take turns choosing their favorite music from the same Bluetooth-enabled audio content library. Enabling a “juke-box” mode would allow end users to add their favorite tunes to a playlist. The MCU solution enables “break-in” mode to allow up to seven smartphones to control the same audio system with different independent audio streams and controls.
Marrying audio to control
Although the Bluetooth SIG has created and ratified more than 30 profiles, the following four are likely to be most important in the early evolution of the new application realm of Bluetooth audio + control.
- Serial Port Profile (SPP) — standard replacement for wireless RS-232 data transmission
- Advanced Audio Distribution Profile (A2DP) — most common profile for streaming multimedia audio. Streams audio via SBC codec and can support MPEG and AAC compression codecs.
- Audio Video Remote Control Profile (AVRCP) — standardized remote-control profile for TVs, home theater, etc. Commonly used in conjunction with A2DP. A recently ratified feature is audio sync, which means when, for example, volume is changed on the handset it is also respectively adjusted on the system being controlled by the handset.
- Hands-Free Profile (HFP) — remote phone calls
In a software implementation, multiple profiles can be active simultaneously, which gives the designer a great deal of flexibility to create new applications. In other words, the integration of a data stream with the audio stream enables the creation of advanced systems.
The design phase must include provisions for emulating, testing, and (not to be forgotten with Bluetooth) certification.
A complete development system, therefore, would go far beyond audio and integrate functionality for controlling displays, buttons, LEDs, microphones, and music. It would also include DSP capability for audio-processing functions. The control aspect of the system — not simply the music itself — creates a compelling reason to use a 32-bit MCU.
As a starting point for explaining the basic points of designing to create this type of functionality, Figure 1 shows the data path and primary elements of a basic Bluetooth audio system.
Viewing this illustration from the perspective of the new set of audio + control applications, the source side is the mobile phone, which is streaming encoded data (audio and control) that may be encrypted. The data eventually finds its way to the baseband layer (a Bluetooth radio). The data-stream that proceeds up the protocol stack on the sink side, which can be any of the devices/smart appliances discussed earlier.
The software solution includes both the multi-profile stack and an application layer that can be modified in source code. The stack handles the profile communication, and can interact with a variety of additional application elements, including audio decoders, digital filtering, source-rate conversion, and control features. Multiple decoders are available for audio that support Bluetooth A2DP audio streaming, including SBC, AAC, and MP3. This modular solution enables the device manufacturer to differentiate potential solutions based on features, controls, and memory costs.
Figure 1: Basic Bluetooth communication (Courtesy of Microchip Technology).
Vendor development kits
Creating development and starter kits for systems on the sink side of the communications link is a major undertaking. While making it easier for designers to develop applications, compatibility and interoperability testing is a critically important issue for any MCU vendor that offers these kits.
There are numerous mobile OS options including Android, Apple’s IOS, Microsoft’s Embedded Windows, and Blackberry, each with numerous versions of the OS. To ensure a viable end-user product, the kit vendor must run hundreds of compatibility and interoperability tests. Assurance that the design will pass these tests with minimal or no rework should be high on the list of questions for designers when choosing a kit.
is one of the players in this design space. It presently utilizes its PIC32MX3
devices in its Bluetooth audio development kits. The illustration in Figure 2 shows the basic hardware configuration.
Figure 2: Microchip basic kit hardware configuration (Courtesy of Microchip Technology).
A specific example is the company’s DV320032
Bluetooth Audio Development kit. It is powered by a 100 MHz mid-range 32-bit PIC device with up to 100 I/O and 512 KB Flash/128K RAM. The basic kit integrates a Bluetooth HCI Daughter Board that supports Cambridge Silicon Radio’s
CSR8811 Bluetooth transceiver (lower-cost modules are also available). Also included are a DAC daughter board with a 24-bit 192 KHz DAC and headphone output, USB host and device interfaces, a 2-inch color LCD display and button control functions. To make the developer’s task easier, the kit also drives numerous functions such as the Apple Authentication Adapter option, a debugging interface, and an SPI Flash memory.
A Programmable Interface Module (PIM) located on top of the MCU gives the developer the option of changing out the processor itself without losing valuable design time. It also provides the flexibility for the designer to replace the standard MCU with lower-cost or higher-performance devices in the future.
Firmware availability is always a key issue for development kits. Microchip provides the firmware shown in Figure 3.
Figure 3: Microchip development kit firmware available (Courtesy of Microchip Technology).
Microchip also fields a higher-end starter kit based on its flagship 32-bit MCU, the 200 MHz PIC32MZ2048ECH144
. The DM320006 PIC32MZ
Embedded Connectivity Starter Kit can be mated with another system to enable Bluetooth capability. The Multimedia Expansion Board 2 (DM320005-2) includes a controller-less graphics drive, 4.3 in. WQVGA display, multi-touch Projected Capacitive Touch (PCAP) button control, VGA camera, Wi-Fi, Bluetooth HCI module, 24-bit stereo audio codec based on the AKM Semiconductor
AK4953, 3-axis accelerometer, and a temperature sensor. A demonstration capability to work with Microchip’s MPLAB Harmony software framework is being integrated to support Bluetooth data and audio applications.
Which solution is right?
Admittedly, the sophistication and complexity of Bluetooth audio + control applications can leave developers a bit bewildered about how to start development. The critical device, of course, is the MCU itself. As previously mentioned, 32-bit MCUs and their 32-bit instruction sets are ideal for combining audio and control simultaneously. To make a first cut on which kit to use, developers can refer to Table 1, which describes applications and the corresponding memory and MIPS requirements.
Table 1: Examples of application resource requirements including application, Bluetooth stack, and graphical display elements (Courtesy of Microchip Technology).
|Bluetooth Stack (A2DP+AVRSPP+SBC) + Android Open Accessory audio Type-A USB connection support and Samsung audio with mini-B USB connection support.
|Bluetooth Stack (A2DP+AVRCP+SPP+AAC decoder) + Graphics. This demonstration uses the higher quality AAC audio decoder in place of the SBC decoder.
|Bluetooth Data Stack (SPP only). This data-only, non-audio demonstration provides no USB audio support.
|Bluetooth Stack (A2DP+AVRCP+SPP+SBC decoder) + Graphics.
|Bluetooth Stack (A2DP+AVRCP+SPP+AAC) + Android Open Accessory audio Type-A USB connection support and Samsung audio with mini-B USB connection support. This demonstration uses the higher quality AAC audio decoder in place of the SBC decoder.
The first column (Description) indicates which Bluetooth profiles and other applications are running. They are only examples for demonstration purposes, but as a group they make the point that memory and peak MIPS can vary significantly from the simplest application (Bluetooth Data Stack Only) to the most demanding (multiple profiles and high-quality ACC decoder).
A new era of Bluetooth development that combines data control with audio will foster the growth of many new applications featuring multiple Bluetooth profiles being activated simultaneously, multiple points of control, and multiple connections. These applications can be difficult to develop, particularly since they must pass Bluetooth interoperability and compatibility testing. Many of these applications also make the utilization of a 32-bit MCU a necessity, not necessarily for the data depth but for the instruction-set resources.
Development kits and firmware solutions offered by silicon vendors significantly reduce the engineering effort, but there is no one-size-fits-all solution. Developers must be careful to choose the right solution for their application with an eye toward firmware availability as well as hardware performance.
For more information about the parts mentioned in this article, use the links provided to access product pages on the Digi-Key website.
(Editor’s note: This article is based on a presentation by Michael Skow, Applications Engineering Group Lead of Microchip Technology’s MCU32 Division. Mr. Skow’s presentation will be delivered at Microchip’s 2014 MASTERs Conference, which will be held in August in Phoenix, AZ.)