Smarter programming can ease developers Bluetooth burdens
10-05-2017 | By Nick Robins
Bluetooth connectivity has become so widely available these days it almost seems like a consumer right. Spare a thought though for developers who have to implement the Bluetooth interfaces that enable this connectivity, especially in tightly constrained embedded systems.
The good news however is they can avoid many complex RF integration issues by using certified Bluetooth interface modules to implement the hardware. But once the hardware is completed the interfaces still need programming to correctly interact with the Bluetooth protocol.
The challenge here is two-fold. The first is since Bluetooth interfaces are supposed to be low cost, their hardware resources can be very limited, demanding careful optimisation of program code to get the most out of them. The second is that Bluetooth is quite complex so implementing it takes a detailed knowledge of the wireless protocol and the ability to reflect that in efficient code.
Laird modules tackle the first challenge by having enough computing power on-board, thanks to an ARM Cortex M0 microcontroller and related memory resources to store and run applications independent of a host.
The second challenge is tackled by supporting smartBASIC, a version of the BASIC language originally developed in the 1960s as a way of teaching computer programming.
Better Than The Original
This language has been customised to overcome some of the drawbacks of the original BASIC, such as a lack of structure that tended to lead to ‘spaghetti code’. It has also been designed to reflect the fact user applications will run unattended, and so encourages users to write code that is driven by events, rather than simply by the sequential processing of program statements as in many classic BASIC applications.
This means a typical smartBASIC application is likely to start with variable declarations and initialisations, followed by subroutine definitions, event handler routines and then the startup code. Code runs until it reaches a WAITEVENT statement where it does just that until a new event happens and the appropriate event handlers can be called to deal with it.
BASIC is an interpreted language, so the source code’s meaning is worked out by the computer as the program runs. smartBASIC respects systems that have limited hardware resources to run the interpreters that do this work, by enabling source code to be translated into a compact bytecode format on a host PC. Once the bytecode has been downloaded into the module, it can be interpreted using fewer resources than the equivalent source code would need.
At this point we have certified Bluetooth interface modules, with enough resources to interpret bytecode versions of source code, and an accessible programming language that has been tuned to encourage the authorship of well-structured, event-driven code. The next hurdle is actually writing code that can work efficiently with the complexities of the Bluetooth protocol and smartBASIC addresses this issue by implementing functions, routines and drivers to help.
The exact set of smartBASIC extensions available depends on the version of the Laird Bluetooth modules with which the language and programming environment is shipped. For example, in the case of modules that implement the Bluetooth Low Energy (BLE) protocol, the extensions include functions to support features such as the ability of BLE peripheral devices to advertise their presence; connection protocols; security features such as encryption and authentication; plus system issues such as power management and wireless status reporting.
Careful Optimisation
The end result of this careful optimisation of the hardware module, the customisation of the smartBASIC programming language to make it an accessible event-driven programming environment, and the provision of canned functions, routines and drivers, is to make it much easier for developers to add Bluetooth to their designs.
What can you do with it? Since the modules can be set to launch an application when they power up, developers can use them to implement a complete design, linking a radio interface at one end right through to the physical interfaces (GPIO etc.) supported by the module at the other.
Developers can also make it easier to create product variants by defining a standard application programming interface (API) to their host system, and then writing applications that work with the API at one end and a variety of wireless functions at the other.
A similar approach can be used to replace a wired interface in an existing design with a wireless Bluetooth interface. Firstly, work out how the wired interface is driven by the host, then mimic that interface in the on-module application to simplify the switchover from wired to wireless.
The right to a Bluetooth connection is never going to be enshrined in law however rising consumer expectations of trouble-free wireless connectivity is making the rapid implementation of Bluetooth interfaces a growing responsibility for many developers and the availability of the right Bluetooth modules and smartBASIC programming tools should make meeting that responsibility less of a burden.