Linux has been around in various forms for about 30 years, and the kernel is the basis of other operating systems such as Android and Chrome OS. Supercomputers use it at one end of the computing spectrum and in embedded devices at the other. Linux is used on laptops, desktop computers, and servers in between these extremes.
And it’s also used in single-board computers — this category includes popular devices like the Raspberry Pi.
Therefore it’s fair to say that Linux has been widely adopted.
While microcontrollers and lean, mean software frameworks necessarily dominate small electronic products that are generally single-purpose devices and have modest processing requirements, Linux meets the needs of another important subset. Some products have multiple features that need to be available concurrently. Some cases may require significant processor power and need RAM measured in gigabytes rather than the kilobytes of RAM more typically found in microcontrollers. IP security cameras are based on Linux. They can stream live video, respond to motion detection events, identify human faces in video streams in real-time, record video to an SD card, transfer files over FTP, and host a web server for management and configuration purposes. That mix of concurrently available functionality requires both sufficiently powerful hardware and an operating system that supports multiple processes and threads, provides a capable file system, and has a wide selection of applications readily available for it. Linux is a perfect fit. And it’s open source and free.
Bluetooth Technology and Linux
Bluetooth® technology can be used on Linux. The controller part of the Bluetooth stack is typically a system on a chip that is either an integral part of the mainboard or implemented in a peripheral like a USB dongle. The host part of the Bluetooth stack runs as a system service, and the standard Linux Bluetooth host implementation is called BlueZ.
BlueZ supports both the Bluetooth LE Peripheral and Central roles using GAP and GATT and Bluetooth mesh, provided the underlying controller supports dependent Bluetooth features. And its multi-process architecture means that multiple Bluetooth applications can be running simultaneously on a single device, which offers some exciting possibilities.
But for a developer, working with Bluetooth technology on Linux for the first time can be challenging. BlueZ defines a straightforward, logical API, but the way a developer must use it in applications is dissimilar to how a developer works with Bluetooth APIs on most other platforms. This is a consequence of the system’s architecture, which, whilst not unique, is typically very visible to the developer and usually needs to be well understood so that those logical BlueZ APIs can be used.
The Architecture of a Linux System using BlueZ
BlueZ APIs are not called directly by applications. Instead, Linux applications that run as independent processes make inter-process communication (IPC) calls to BlueZ APIs via an IPC broker named D-Bus. D-Bus is a system service and a type of message-oriented middleware which provides IPC support for many Linux applications and services, not just BlueZ.
BlueZ runs as a system daemon, either bluetoothd to provide applications with support for GAP and GATT or bluetooth-meshd when the physical device is to be used to run applications that act as Bluetooth mesh nodes.
Using D-Bus, applications can send messages which cause methods implemented in remote services or applications to be called and the results returned in another message. Applications and system services can also communicate events that have happened in the system to other applications by emitting special messages known as signals.
Applications work with BlueZ by sending and receiving DBus messages and signals, so developers generally need some knowledge (or perhaps a lot of knowledge) of DBus programming.
You may have noticed that we are not making the most definite statements here. Why did we say that the developer usually needs to have a solid understanding of the architecture rather than always? Why do they generally need some knowledge of DBus programming and sometimes a lot of knowledge? The answer lies in the very nature of Linux and of the Linux ecosystem.
Developers of Android or iOS applications typically use one or two programming languages favored by the operating system (o/s) owner, in this example, either Google or Apple. The APIs are designed and documented by the o/s owner, and there’s a wealth of supporting information to help developers achieve results. But the world of Linux is not like that. It’s very modular and open, which means there’s an enormous choice in programming languages that can be used. There may be a choice of different APIs for the exact same purpose provided by different supporting libraries from different originators for any given language.
The degree to which the architecture is abstracted by the APIs for different languages, hiding details so that an application developer feels they’re working directly with BlueZ APIs rather than making remote method calls using DBus messages varies. Still, it’s not uncommon for the developer to have to deal directly with DBus from their code and to need to have a thorough understanding of DBus IPC.
Some BlueZ or DBus APIs are well documented, while some do not add to the learning curve developers need to ascend. And, in some cases, there’s no documentation at all, leaving the developer to figure things out through searching the web, scrutinizing library source code, and so on. This is fine if you like that kind of thing and OK if you have the luxury of all the time in the world to finish your project. But for most people, life’s not like that.
The Bluetooth Technology for Linux Developers Study Guide
To help Linux developers quickly ascend the BlueZ learning curve, we’ve created an educational resource known as a study guide to add to our growing collection.
It’s modular and includes hands-on exercises so you can test your growing understanding of the theory by writing code and testing the results.
If you’re completely new to Bluetooth® Low Energy (LE), there’s a primer module that will explain the key concepts to get you started. Subsequent modules explain how Bluetooth technology works on Linux, DBus programming concepts and techniques, how to develop LE Central devices, and how to develop LE Peripheral devices, in both cases using BlueZ and Python. The appendix provides step-by-step instructions for configuring your Linux kernel and for building and installing BlueZ from the source.
After completing the work in this study guide, you should:
Be able to explain basic Bluetooth LE concepts and terminology such as GAP Central and GATT client
Be able to explain what BlueZ is and how applications use BlueZ in terms of architecture, services, and communication
Understand the fundamentals of developing applications that use DBus inter-process communication
Be able to implement key functionality, typically required by GAP Central/GATT client Bluetooth devices