implement of a bluethooth protocol stack on a low-cost microcontroller
TRANSCRIPT
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
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 2/4
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
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 3/4
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
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 4/4
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