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. It’s used by supercomputers at one end of the computing spectrum and in embedded devices at the other. Sitting somewhere in between these extremes, it’s used on laptops, desktop computers, and servers. It’s also used in a class of computer which, for want of a better term, I shall just call single board computers. This category includes popular devices like the Raspberry Pi.
It’s fair to say, therefore, that Linux has been widely adopted.
Whilst microcontrollers and lean, mean software frameworks necessarily dominate small electronic products which are generally single-purpose devices and which have modest processing requirements, Linux meets the needs of another important subset. Some products have multiple features which need to be available concurrently and which, in some cases, may require significant processor power and need RAM measured in gigabytes rather than the kilobytes of RAM more typically found in microcontrollers. My IP security cameras are based on Linux and 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 which 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 which is either an integral part of the main board 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 at the same time on a single device, and this offers some interesting possibilities.
But for a developer, working with Bluetooth technology on Linux for the first time can be challenging. BlueZ defines a clear, logical API, but the way in which a developer must use it in applications is dissimilar to the way a developer works with Bluetooth APIs on most other platforms. This is a consequence of the architecture of the system which whilst not unique, is typically very visible to the developer and usually needs to be well understood in order that those logical BlueZ APIs can be used.
Bluetooth® Technology for Linux Developers
This self-study resource for Linux developers explains the architecture of Bluetooth® applications on Linux which use D-Bus and the open-source Bluetooth stack, BlueZ.
BlueZ APIs are not called directly by applications. Instead, applications which run as independent processes in Linux make inter-process communication (IPC) calls to BlueZ APIs via an IPC broker called 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, and so developers generally need some knowledge (or perhaps a lot of knowledge) of DBus programming.
You may have noticed that I’m not making the most definite of statements here. Why did I 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 favoured 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 it’s open, and this means there’s an enormous choice in programming languages which can be used, and for any given language, there may be a choice of different APIs for the exact same purpose provided by different supporting libraries from different originators.
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, but 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.
To add to the learning curve which developers need to ascend, some BlueZ or DBus APIs are well documented whilst some are not. 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 which 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 which use DBus inter-process communication
Be able to implement key functionality, typically required by GAP Central/GATT client Bluetooth devices
Learn about Bluetooth internet gateways, how to make them secure and scalable, and design and implement your own working prototype gateway and web application for use with either Bluetooth LE Peripherals or with Bluetooth mesh networks.