Minimising the time required to implement Bluetooth connectivity

Pretty much every industrial, commercial or consumer design requires it in some form or another; it may also likely require multiple wireless protocols. Whether driven by the all-consuming Internet of Things trend or simply providing a user friendly control interface, there will certainly be some engineering challenges ahead as well as compromises concerning space envelope, use cases, and available power budget. Also, unless your design has the expectation of extremely large production volumes, you will likely implement the wireless connectivity using a pre-certified wireless module over that of a discrete wireless transceiver design.

Choosing to use a wireless module to implement, for example, a Bluetooth Low Energy link is a pragmatic approach and saves both engineering time and BOM cost. However, prior to making the decision to go with a particular wireless module, the engineer must carefully investigate how the interface to the module operates and any additional firmware, stacks or hardware resources required to initiate and transfer data over the wireless link.

Many Bluetooth modules use a serial interface such as UART, SPI or I2C for both link control and data transfer to a dedicated microcontroller. Some vendors opt to use a single chip wireless transceiver as a way of keeping the component count to a minimum. Provisioning the Bluetooth stacks may require computer resources of the host application while other modules, equipped with a more powerful microcontroller, host not only the stacks but also provide the ability to run your own application, such as a simple thermostat, within the module.

Whichever module approach is used, the engineer may be writing several pages of embedded code to make the design function as intended. However, a series of modules from the UK-based wireless module manufacturer Laird promises to significantly reduce the amount of required coding effort.

The Bluetooth Smart (Single Mode) BLE BL600 series and Bluetooth Smart Ready (Dual Mode) BT900 modules use an event driven programming language called smartBASIC to make link set-up and data transfer simple. The event driven nature of smartBASIC functions as a bridge between software and hardware and uses built-in BASIC ‘like’ functions to replace many hundreds of lines of C code.

No expensive compilers are required and code written within smartBASIC is transferable between the various wireless modules. The same code can be saved as templates to further simplify implementation across a number of different use cases or applications. With the smartBASIC code being capable of auto-running from power up, these modules are ideal for use in designs where a host does not have enough resources or is simply not required for any other purpose, thus creating a complete design within the wireless module.

Figure 1 – BT900 Classic BT & BLE module block diagram

From a hardware perspective, Figure 1 shows a block diagram of the BT900 BLE module. A comprehensive peripheral set includes multiple IOs such as GPIO interfacing with sensors or control actuators, module communications via SPI, UART or I2C, and an ADC. An ARM Cortex M3 device hosts the smartBASIC run-time engine and, as shown in Figure 2, provides a file system interface to non-volatile storage used by smartBASIC during operation.

Figure 2 – smartBASIC environment

Derived from the BASIC language, smartBASIC was designed to be highly efficient in terms of memory use which makes it well suited for low cost embedded systems with limited RAM and code memory. Maintaining the standard language functionality in terms of variables, arithmetic functions, string processing, I/O functions, conditional expressions and looping, smartBASIC also has a number of target specific functions. These instruct the wireless connectivity of the Bluetooth module through the various stages of link set-up and secure data transfer such as advertising, connecting, security encryption and authentication, power management and link status. Also, unlike the traditional sequential nature of a BASIC program, smartBASIC is event driven and operates in an interpretive environment. smartBASIC code can be compiled on a Windows PC and the resulting bytecode (tokenised) code is then ready to be stored within the flash-based file system on the module. The smartBASIC run-time engine accesses and interprets the application bytecode directly from flash. Application specific Bluetooth profiles, such as Health Thermometer Profile, and a host of other Custom Services and features can be imported as sample modules into any smartBASIC code. This includes a BLE cable replacement option called vSP (virtual Serial Port), available either in a hardware controlled active on power up mode or a more flexible smartBASIC controlled, run-time vSP option.

Figure 3 – module modes and transitions

There are three different modes of operation for a smartBASIC module - interactive, application load and run-time mode (see Figure 3). Within interactive mode, commands can be sent via a command interface (such as UART and SPI) and are executed immediately. Useful for debugging, configuration and file management, the command set is based around the popular Hayes modem AT+ instruction syntax. Within limited firmware space, this mode may not always be possible.

The final condition is the run-time mode that reads the pre-compiled smartBASIC applications and executes the commands from flash memory. Running from flash ensures that as much available RAM can be used for the application for manipulating data variables.

The operating mode is controlled by checking the status of one of the GPIO input pins on power up. If the pin is high and an $autorun$ bytecode application file is found, the module enters run-time mode and executes the application. Should a STOP or END instruction be encountered within the application, execution terminates and the module involves interactive mode.

An extract from an example smartBASIC application can be seen in Figure 4. The application reads and sends the temperature from the sensor on the development at a duration determined by the value of TEMPERATURE_POLL_MS. The code snippet shows the polling of the temperature sensor, sub InitTempSensor, and the main program loop sub OnStartUp.

Figure 4 – smartBASIC application to send a temperature value

Further speeding the development of a smartBASIC application, both the BL600 and BL900 modules offer a development board that provides easy access to GPIO and prototyping your design. A free terminal emulation program, UWTerminalX, is also available for connecting directly with the module and/or development board from Windows, Linux, or MAC and allows the loading of smartBASIC applications. A status panel indicates the condition of and settings for various serial communications parameters. The XCompile utility (provided free within UWTerminalX) manages the compilation and debugging of your smartBASIC code.

When it comes to attaching sensors to an IoT application or connecting a host of retro-fitted industrial automation or commercial equipment to M2M systems, the use of smartBASIC enabled modules makes light work of the task. A module can function as a complete IoT device without the need for any other hardware - something that saves significantly in development time and BOM cost.