IEEE AFRICON 2004

127

Implementation of a Bluetooth Protocol Stack on a Low-Cost Microcontroller

C. G. C. Rocher and G. P. Hancke
Deporlmenl o f Electrical, Ekclronic ond Crmpuhr Engineering.

Universiv o/Preluria. Pretoria. South Africa

Abslrocl-This paper describes the creation and implementation of a Bluetooth protocol stack for an eight-bit microcontroller, using only open-source or freely available software to keep costs at a minimum. The created stack was used to successfully establish a Bluetooth-based connection between an Atmel microcontroller and a nearby computer.
Index Terms-Bluetooth,

11. DESIGN AND IMPLEMENTATION

A. Hardware Design

microcontroller, protocol

INTRODUCTION Bluetooth was introduced in 1998 as a short range, wireless communication technology. It has been used widely as a cable replacement technology, as is demonstrated in various wireless headsets available for cell phones, and wireless printers which make use of Bluetooth technology. The ability to communicate to almost any electronic device wirelessly has widened the scope of applications for small microcontrollers. They can now easily be used for remote sensors, short-range communication and security applications, to name but a few [I]. Various one-chip Bluetooth solutions are available on the market today containing an integrated microcontroller, hut these are usually very limited in their performance, and it is preferable to implement the upper section of the Bluetooth protocol stack [Z] on a separate microcontroller. This makes more processing power available for applications by allowing more powerful processors to be used and provides a greater level of control over the wireless connection. The cost involved with developing Bluetooth capable products can be quite high. This includes the cost of the Bluetooth hardware, and other sofhvare necessary to add Bluetooth capability to a small system. To address this problem, we created a small Bluetooth capable embedded system using almost exclusively opensource, or freely available software. One of the main factors taken into consideration during development was to limit the amount of memory used by the stack. A stack that takes up to much memory would hinder development of other applications that make use of it.
I.

The initial design of the system, especially with regards to the hardware, is based on the work done by Beutel and Kasten [3]. The Ahnel ATmegalZSL microcontroller [4] was used as a host controller, and provides an 8-bit AVR RlSC microcontroller with 128 KB of in-system programmable program memory and 4 KB S U M . It also has two serial ports, which allows the Bluetooth module to he connected to one port, whilst the other port can he used to send various data to a connected computer, depending on the application. During development, state information regarding the Bluetooth protocol stack was sent via the serial port to monitor the intemal workings of the protocol stack The ATmegalZBL is a low-voltage ( 3 . 3 ~ ) capable microcontroller running at 8 MHz. It was chosen to be compatible with the Bluetooth module, which also runs on a low voltage. A 5v variant of the microcontroller is also available, which is capable ofrunning at 16 MHz. The microcontroller is connected to a Mitsumi Bluetooth module through a serial interface. The Bluetooth module is based on C S R s Bluecore technology [ 5 ] . Although the module is capable of hnctioning as a single-chip Bluetooth solution, for the purposes of this project it was set up with only the sections of the Bluetooth protocol stack helow the HCI layer.

Manuscript received March 10,2004. C. G. C. Rocher(e-mi1: c.rocher@tuh.co.za).

G. P.Hancke (e-mail:ghaneke~~eng.up.ac.za).

B. Sofmare Used A number of open source and freely available software packages were used in order to reduce the total cost of development. I) A VR-GCC AVR-GCC is a modified version of the popular opensource GCC compiler, capable of compiling C code for use on Atmel microcontrollers based on the AVR core. The compiler provides for transparent use of common C functions such as malloc a n d p r i n 6 with certain restrictions imposed to reduce memory usage. 2) A VRDUDE After a program is successfully compiled, it needs to be transferred to the microcontroller. AVRDUDE does this by making use of the microcontrollers in-circuit programmability. No additional programming hardware is required, except a simple parallel cable, reducing development cost considerably.

0-7083-8605-1 /$17.00 2004 IEEE

128

IEEE AFRICON 2004

This implementation of the HCI Layer receives data from the microcontrollers serial port When a complete packet has been received, it is determined whether the packet is either an ACL or event type packet. The packet data is then sent to is relevant processing function. A number of different events can be received from the Bluetooth module, and a processing function exists for each of these. Depending on the event, a command in reply can either be immediately generated by the HCI layer, or the date sent to the LZCAP layer for further processing. ACL packets are immediately forwarded to the L2CAP layer for processing. 2) L2CAP Layer The LZCAP layer controls basic connection establishment, as well as allowing for connection multiplexing. It keeps track of each connection by assigning each a unique connection identification number. Fig. 3 shows the flow of data through the LZCAP layers functional units. When the LZCAP layer receives an ACL packet, the packet is processed to determine what type of packet it is. ACL packets can he either signaling packets, or data packets. Continuing the method used in the HCI layer, these packet types each have their own processing functions that handle them. Signaling packets are used to communicate various requests and responses ranging from connection request and responses used to establish an L2CAP level connection to echo requests and responses used when pinging a Bluetooth device. Separate, and different from signaling packets are indication, response and request functions. Where signaling packets are sent as ACL data from one Bluetooth device to another, the HCI layer on the same device calls the indication functions. This typically occurs when an HCI level connection is successfully established, and the HCI layer notifies the LZCAP layer of the existence of the HCI level connection with an indication function. The L2CAP layer then acknowledges the indication with a response
From serial
inpvt

I ,

UCAP
HCt Control

Link MmgR R o l C c O l &band

Radio

Lower protocol stack

EX",

Command

Command

Fig. 2. A functional layout of the HCI layer. This figure describes the flow of data through the HCI layer from the micmconWllers serial interface with the Bluetooth module.

function. In the same manner, whenever an L2CAP level connection is established an indication is sent to the higher layers, and a response expected. Since the higher layers were not implemented in this project, the responses are

0-7083-8605-1 IS1 7.002004 IEEE

IEEE AFRICON 2004

sender. When the computer received a response, it would modify the received data and re" it to the sender. This would start a sort of ''tennis match" exchange of data between the microcontroller and computer, which would continue indefinitely. Due to the reception buffer used on the microcontroller, and the limited size thereof, the data packets used were small to prevent a buffer overflow. At the same time, the microcontroller would be outputting a large amount of protocol stack related data to another computer connected directly to the microcontroller through its serial port.
B. Results The microconholler successfully created an LZCAP level connection between itself and the computer and data was successfully exchanged in both directions. The microcontroller was able to handle up to three simultaneous, yet functionally separate, logical connections Ibetween itself and the computer with the only limiting factor Ibeing the amount of memory available on the microcontroller. The cost reduction achieved by using open-source software for development was significant. Firstly, not a cent was spent on any software, which can easily exceed thousands of rands using commercial product. Also, the cost of the programming hardware was approximately R30, which is a noteworthy reduction from the R800 that the Atmel commercial programmer costs. The only limiting factor with not using the commercial programming hardware is the lack of advanced debugging functionality, which made tracking down problems somewhat harder. The final stack implementation required a mere 32 KB of program space, leaving approximately 96 KB available for other applications. This included a large amount of predefined text strings used for debugging purposes. If used in a final product, these strings can easily be removed, and reduce the required program space. The compatibility between the various Atmel AVR based microcontrollers also means that the stack can easily be transferred to any other AVR based microcontroller, providing it has sufficient program memory.

129

Fig. 3. A functional layout of the LZCAP layer. The main functional section$ ofthe LZCAP layer i s shown here.

simulated. In order to keep track of the internal workings of the stack during development, a large amount of debugging messages were output to another computer through the microcontrollers serial port. By default programs are compiled in such a way as to automatically load these strings into the microcontrollers memory at startup, and this quickly took up almost all of the available memory. To prevent this from happening, these debugging messages were coded to only load into a pre-defined section of memory when needed. Using Kasatkins documentation [6] three basic test programs were written to test the functionality of the system throughout development. All these programs ran on a Linux based computer using the Affix stack. The Affix stack was used on the computer since it allowed easy development of programs using Bluetooth technology, and was one of the most up to date open-source protocols available at the time of development. Communicating with different implementations of the stack also provides a good measure of compatibility for the final system. A server program was created to listen for incoming Bluetooth connections, as well as a client program that would attempt to connect to a Bluetooth device with a known IP. The third program was a detection program, which would use a Bluetooth module attached to the computer to locate any Bluetooth devices within range, and read their IP addresses.
111. FINAL TESTMG AND RESULTS
A. TeslSelup

IV. CONCLUSION
Using open source software to develop Bluetooth based products is not only viable, but a very effective method of reducing development costs. With the addition of flow control between the microcontroller and Bluetooth module, and some additional memory, the performance of the system can he significantly improved. Also, the removal of the debugging messages, which are constantly being processed, would increase the available processing power significantly. The 5v variant microcontroller could easily be used since the slave hoard for the Bluetooth module provides for the necessary voltage conversion, and this would allow an increase in clock speed from 8 MHz to 16 MHz, also boosting available processing power significantly.

The Linux based computer was used as a sender, with a custom test program written for final testing. The test program would ahempt to connect to a Bluetooth device with a known IP, which in this case was our microcontroller. When a connection was established, a string of data read from the keyboard would he sent to the microcontroller via the Bluetooth connection. The microcontroller was set up to listen for an incoming connection. When a connection was created, it would take the received data, modify it slightly to show that it did indeed pass through the microcontroller, and re" it to the

0-7083-8605-1 /$17.00 2004 IEEE

130
ACKNOWLEDGMENT

IEEE AFRICON 2004

We would like to thank D. Johnson and the CSIR for their assistance in setting up and integrating the Bluetooth module as well as the use o f their slave board design for the Bluetooth module. REFERENCES
[I] P. Bhagwal, 2001, "Blueloolh: technology for shon-range wireless

apps", hlernel Compuling Vol. 5 . Issuc3,96-103 121 Bluetooth Special Interest Group, Specifications of the Blueloath
system "1.1,20W

[3]

(41

J. Beutel, 0.Kaslen, A minimal Blueioorh bosed compuling and communico,bn PlOCnn. 2001, Available: httn:ll~~ww.tik.ee.rthzchi-beotelioub.hlml ATmegal28L Damheet, Almel microelectronics, 2003, Available:

htlp:llu?uu.slmel.com [ 5 ] Bluecore Product data sheet, CSR, 2002 [6] D. Kasalkin, AJJii in LI nuishell 2002, Available from h ~ l ~ : l l a f ~ ~ . x ~ u r c c f ~ ~ ~ . ~ ~ ~ ~ N ~ ~ - ~ ~ ~ l i ~ d ~ ~ . h l m l

0-7083-8605-1 / $17.00 2004 IEEE