Implement of a Bluethooth Protocol Stack on a Low-Cost Microcontroller

7/29/2019 Implement of a Bluethooth Protocol Stack on a Low-Cost Microcontroller

http://slidepdf.com/reader/full/implement-of-a-bluethooth-protocol-stack-on-a-low-cost-microcontroller 1/4

IEEE AFRICON 2004 127

Implementation of a Bluetooth Protocol Stack

on a Low-Cost Microcontroller

C. G. C . R o c h e r a n d G . P. H a n c k e

Deporlmenl o Electrical, Ekclronic ond CrmpuhrEngineering. Universiv o/Preluria. Pretoria. SouthAfrica

Abslrocl-This pape r describes the creation andimplementation of a Bluetooth protocol stack for an eight-bitmicrocontroller, using only open-source or freely availablesoftware to keep costs at a minimum. The created stack wasused to successfully establish a Bluetooth-based connectionbetween a n Atmel microcontroller and a nearby computer.

Index Terms-Bluetooth, micro contro ller, protocol

I. INTRODUCTION

Bluetooth was introduced in 1998 as a short range,

wireless communication technology. It has been used

widely as a cable replacement technology, as i s

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 th e

market today containing an integrated microcontroller, hutthese 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 open-

source, 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 takesup to much memory would hinder development of other

applications that make use of it.

Manuscript received March 10,2004.

C. G. C. Rocher(e-mi1: [email protected]).

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

11. DESIGN AND IMPLEMENTATION

A . Hardware Design

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 16MHz.

The microcontroller is connected to a Mitsumi Bluetooth

module through a serial interface. The Bluetooth module isbased 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.

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 open-

source GCC compiler, capable of compiling C code for us e

on Atmel microcontrollers based on the AVR core. The

compiler provides for transparent use of common Cfunctions such as malloc andprin6 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

UCAP

IEEE AFRICON 2004

HCt Control

LinkMmgRR o l C c O l

&band

Radio

I, This implementation of the HCI Layer receives data from

] ower protocol stack

the microcontrollers serial po rt 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 eachof 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 f low of data through the LZCAP layers

functional units. When the LZCAP layer receives an A CL

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 ow n 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 ser i a l

inpvt

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-1S17.00 004 I EEE



Fig. 3 . A functional layoutof 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 arecompiled in such a way as to automatically load these

strings into the microcontrollers memory at startup, and this

quickly took up almost al l 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 m easure

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 ESTMG NDRESULTS

A . TeslSelup

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" i t to th e

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" excha nge 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 datapackets 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

between itself and the compu ter with the only limiting factor

being 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.

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 o f the system can he significantly

improved. Also, the removal of the debugging messages,which are constantly being processed, would increase the

available processing powe r significantly.

The 5v variant microcontroller could easily be used since

the slave hoard for the Bluetooth module provides for the

necessary voltage conversion, and thi s would allow an

increase in clock speed from 8 MH z to 16 MHz, also

boosting available processing power significantly.

129EEEAFRICON 2004

I

I

,

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



130 IEEEAFRICON 2004

ACKNOWLEDGMENT

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 ]

121

[3]

P. Bhagwal, 2001, "Blueloolh: technology for shon-range wireless

apps", hlernel Compul ing Vol. 5 . Issuc3,96-103

Bluetooth Special Interest Group, Specifications of the Blueloath

J. Beutel, 0. aslen, A minimal Blueioorh bosed compuling and

co mmuni co ,b n Pl OC nn. 2001, Available:

httn:ll~~ww.tik.ee.rthzchi-beotelioub.hlml

ATmegal28L Damheet, Almel microelectronics , 2003, Available:

htlp:llu?uu.slmel.com

Bluecore Product data sheet, CSR, 2002

h ~ l ~ : l l a f ~ ~ . x ~ u r c c f ~ ~ ~ . ~ ~ ~ ~ N ~ ~ - ~ ~ ~ l i ~ d ~ ~ . h l m l

system "1.1,20W

(41

[ 5 ][ 6 ] D. Kasalkin, AJJii in LI nuishell 2002, Available f rom

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

Implement of a Bluethooth Protocol Stack on a Low-Cost Microcontroller

Documents

Transcript of Implement of a Bluethooth Protocol Stack on a Low-Cost Microcontroller