Providing Bluetooth Functionality on

sanatoriumdrumΗλεκτρονική - Συσκευές

25 Νοε 2013 (πριν από 3 χρόνια και 8 μήνες)

184 εμφανίσεις





Providing Bluetooth Functionality on
Embedded Devices: A Survey of
Embedded
O
perating
S
ystems

and
Bluetooth Stacks


Literatur
e

Review

Name:
Brian Fox

Student No: g01f4315

Supervisors:

Dr Greg Foster

Prof. Peter Clayton


Rhodes University

Computer Scien
ce Department


2

Table of C
ontents:

1)

Introduction







Pg
3

2)

Embedded
Systems






Pg
3

3)

Embedded O
perating Systems




Pg
4

3.1)

Microsoft Windows CE .NET



Pg
5

3.2)

QNX

Neutrino






Pg
6

3.3)

Wind River

VxWorks





Pg
7

4)

Bluetooth Stacks







Pg
8

5)

Conclusion








Pg
10

6)

References








Pg
11


List of Figures:

Figure 1: The architecture of Windows CE .NET 4.2

Pg
5

Figure 2:
The architecture of QNX Neutrino



Pg
7

Figure 3: The architecture of Wind River VxWorks

Pg
8

Figure 4: The Stonestreet One Bluetopia Bluetooth

Stack Architecture






Pg
9

Figure 5: The Microsoft Bluetooth Stack Architecture

Pg
9


List of Tabl
es:

Table 1: An Overview of OS Po
rtability
of Selected

Bluetooth Stack
s







Pg
10



3

1)

Introduction

This literature review is designed to give the reader more information about embedded
operating systems (OS’s) and how Bluetooth functionality can be exposed. The revi
ew is
being completed in order to aid, and in part completion of, a project focused on the
development of a Bluetooth enabled headless device

and providing Bluetooth functionality to
an application programmer
. The project
is
part of a grander project which

hopes to design a
system whereby animal interaction can be tracked through the use of the Bluetooth collars
and a series of base stations. When animals come within range of each other, the devices will
log this “interaction” and synchronise any data they
may be carrying. If an animal comes
within range of a base station the data they are carrying will be
uploaded to a central
database.


The review first takes a look at what an embedded system is and some constraints that arise
out of the nature of the embe
dded system. It then takes a high level view of three of the major
embedded OS’s available today. It firsts looks at some of the similarities between each of the
OS and then at the process of building a custom image of the OS and the tools available to
aid

this pro
cess.
It then moves on to look at Bluetooth stacks and the
port
ability of some
commercial

stacks with the OS’s being discussed. Finally, the review will conclude reviewing
what has been said throughout the document.


2)

Embedded
Systems

An embedded s
ystem can be loosely defined as “hardware and software which forms a
component of some larger system and which is expected to function without human
intervention.”
[1]
There are several design constraints that
are inherent in embedded device
development. T
hese
need to be considered when desig
ning or choosing an
embedded
device
. Several of these revolve around the hardware upon which the final pro
duct will run;
what speed
and type
will the processor be, how much memory is needed or what peripherals
are requi
red
[7]
. Traditionally, one would need to decide on the final hardware before
choosing what
operating system (
OS
)

to run. This is not as important today as the use of
board support packages
(BSPs)
and simulated hardware have allowed for the concurrent
deve
lopment of both hardware and soft
ware. Other considerations that may affect the
development process include whether field upgrades

might need to be performed,

how the
platform will be debugged

[7]
, and where t
he device will source its power

(what type, how

much, how will it be recharged)
.

Embedded devices include devices which run on mains
power and/or some form of battery/alternate power source. Due to this, one needs to be
particularly
careful when building a mobile device that both hardware and software
are
designed for or provide measures for efficient

power
usage.



4

The next section will take a look at some of the embedded
OS’
s

available to a developer. It
will discuss the similarities between them before looking in more detail at the architecture of
the

OS and the process of creating a custom image.



3)

Embedded O
perating Systems

This section
will
look at

some of the many embedded
OS’s

available.
This selection of
OS’
s

has

been
chosen for
two main

reason
s
. The
y

are:

that Bluetooth functionality can be adde
d to
any of the
OS’
s

discussed below

and
that
all of them can operate in a headless environment
.
Bluetooth functionality
is most often
added
in the form of a 3
rd

-
party stack implemented on
top of the OS
. M
icrosoft
, however

supply a Bluetoo
th stack with th
e
ir

OS

(see section 4)
.


Before going into the specifics of e
ach OS, and to avoid repetition
I
will briefly look at the
several similari
ties between the
OS’
s
.

T
he majority

of
embedded
OS’s

will have most if not all
of these
similarities in common as well.

i.

A
ll of the

OS’
s

looked at below

are highly m
odular & componentised
. This is due
to the nature of embedded devices and the memory constraints that are usually associated
with them. A highly modular OS allows the developer

to build up from a

minimal kernel,
only
including those modules which bear relev
ance to the particular project.
One e
xception
to this
is
Microsoft
Windows
XP Embedded
. XP Embedded attempts to provide the same
functionality as the desktop equivalent. Due to this,
the library files and driver
s occupy
a
large
amount of space. T
ypicall
y an
image
will
occup
y 4 Mb
of memory
.

This modular nature allows
for optimisation in terms of the size of the source code (the image is kept small as
unnecessary services are not installed) as well as the running
of the device (unnecessary
services are not running).

ii.

All of the
OS’
s

discussed
will run on a wide variety of proces
sors. The more
commonly supported varieties

are x86, ARM
, Strong ARM
, MIPS,
Hitachi
SuperH, PowerPC
.

Each of the
OS’s

requires a different B
SP
to be able to support operation on a different
processor. The BSP contains
software that implements the device drivers

required for the OS
to communicate with the hardware

and includes a boot loader for initialising and customising
hardware. A
s such,
i
t
is h
ighly hardware and OS dependant and is usually created through

a
combination of work from OEM

manufacturers

and OS
developers

[
16]
.

iii.

Power management

As was
mentioned
earlier
, power management is an inherent problem
of

embedded devices
and hence to t
he OS
.

A
gain
;

an

exception here is Windows XP Embedded which has been
designed for devices that will run on mains power and as such, all embedded
OS’
s

(XP
Embedded included) implement at lea
st one form of power management.

iv.

Each of the
OS
’s
looked at
can ac
t as a real
-
time OS supporting, in general, 256
different priority levels for processes.
The implementation of the real
-
time capabilities can
vary slightly however all of them support multi
-
tasking environments, various forms of
scheduling (e.g. pre
-
emptiv
e) and highly optimised context switching code.


5


3.1)

Microsoft Windows CE .NET

W
indows CE .NET and Windows XP Embedded are Microsoft’s two
major
embedded OS’s.
As mentioned before XP Embedded has been designed mainly around devices such as retail
kiosks which

are plugged into mains and do not have major memory constraints. CE .NET
has been designed specifically for mobile devices and as such incorporates

all of the features
mentioned a
lready. CE .NET is a
real
-
time, highly componentised

OS that, a
ccording to

M
icrosoft,
has a minimal kernel of approximately 200kb.

CE supports many forms of power
management ranging from quicker boot times, using multiple ROM Execute
-
In
-
Place regions
that allow for what Microsoft term “Instant
-
On”

[
17]
. Other power management feat
ures
include control of device
-
level power states, non
-
linear power needs and support for power
handling exceptions.

Microsoft offers BSPs for several development boards based on each of
the major processor types


ARM, MIPS, SuperH and x86. They will also

provide a standard
BSP which a developer can use as a base when using custom hardware, thus eliminating the
time to create a custom BSP.


An overview of the Windows CE .NET architecture can be seen in Figure 1. The figure shows
the main comp
onents of the
operating system.
The OEM Adaptation Layer (OAL) bootloader
module contains the BSP package
and
includes a boot loader for initialising and customising
hardware, device drivers and a corresponding set of configuration files
.

The Graphics,
Windowing and Eve
nts Subsytem (GWES) contains most of the core functionality. GWES
ha
s
been separated into two components; the first handles events and inputs, the second handles
graphical material. Microsoft is the only vendor which supplies their own Bluetooth stack with

the OS. As can be seen from figure 1 the Bluetooth stack is implemented directly on top of the
hardware and is accessed through an API such as Winsock.


OEM Hardware
Embedded Shell
Applications
Applications
WIN32 APIs
COREDLL, WINSOCK, OLE, COMMCTRL, COMMDLG, WININET, TAPI
Windows CE Shell Services
Remote
Connectivity
WIN32 APIs
COREDLL, WINSOCK, OLE, COMMCTRL, COMMDLG, WININET, TAPI
Windows CE Shell Services
Remote
Connectivity
Kernel
Library
Blue
-
tooth
GWES
Device
Manager
File
Manager
TCP/IP
Kernel
Library
Blue
-
tooth
GWES
Device
Manager
File
Manager
TCP/IP
OAL
Bootloader
Drivers
Device
Drivers
File Drivers
OAL
Bootloader
Drivers
Device
Drivers
File Drivers

Figure 1: Architecture of Windows CE .NET 4.2



6

Platform development for CE .NET takes place through

use of their integrated development
environment

(IDE).
This IDE, Platform Builder, is the only set of tools that, Microsoft claims,
“a developer needs to complete the entire platform development process”
[18]
.
Platform
Builder offers 12 pre
-
configured bas
e platforms for various platforms


such as mobile phones
or handhelds, gateways, digital media receiver or just a basic tiny kernel. The pre
-
configured
platforms offer the developer a base from which to customise and design their own unique
device without

having to add all the services/applications manually. Platform Builder
also
comes with a built
-
in simulator that allows developers
to
develop the platform without the
need for additional hardware development.


Platform creation is done through the “New Pl
atform Wizard” which
guides the user through
the following tasks: choosing a BSP, selecting a base OS configuration and selecting initial
OS features (e.g. network support).

Platform creation

and development
can
also
be
performed ‘manually’ through use of

the Platform Builder command line. This
, however,

is a
longer process as it r
equires the developer to edit various

build files specifying wha
t
applications,

drivers
and/or directories
are included
in the image
through
use of
environment
variables (e.g. Se
t SYSGEN_FREECELL = 1 will add the application Freecell to your image).
All of this is unnecessary as Platform Builder provides a nice GUI where adding or removing
components
once the platform has been created
is as
simple as dropping and dragging.


3.2)

QNX

Ne
utrino

QNX Neutrino has been designed around creating an OS which delivers “the open systems
POSIX API
in a robust, scalable form for a wide range of systems”
[
6
]
. The POSIX API
provides methods
for accessing resources/
the
OS
. QNX is centred around a micro
kernel
which controls all other processes.
Inter process communication in

QNX occurs via message
passing handled by the microkernel.
By providing developers with the standard POSIX API’s
Neutrino offers good interoperability with other devices using these
API’s and shortens the
time needed for a developer to learn
how to write applications for the

OS.


Figure 2 shows the architecture
of a typical QNX Neutrino image.

The figure shows how QNX
has taken the approach of looking at the OS as a kind of software

bus. Thus one can
dynamically “plug in/out OS modules whenever they’re needed”
[6]
.
The Neutrino microkernel
is responsible for thread, signal, message
-
passing, synchronisation, scheduling, timer and
process management services. However, unlike threads Ne
utrino is never scheduled for
execution. Any execution of code in the kernel results only in response to a hardware interrupt
or an “explicit kernel call”
[6]
m
ade by a thread.



7


Figure

2
: The QNX Neutrino architecture


QNX
supply an IDE, Mo
mentics Professional Edition

(PE)
,
which comes with the OS, and

performs many of the same funct
ions Platform Builder does.
It
, as with all I
DEs,
is primarily
designed to reduce the development time for embedded devices using the QNX Neutrino OS.
It allows for application development in multiple languages, as well as driver development,
and will run on a range of host machines

[8].

Momentics PE

includes tools that optimize the
size of your image by searching the image for unused libraries, adding missing libraries and
put you system “on a diet”. By putting your system on a diet, the IDE, will search all shared
libraries and remove any functions
that do not get called; decreasing the overall size of the
image.


Manual creation of a custom OS image is done through use of the mkifs (
m
ake image
filesystem) command. This command reads in a list of parameters and uses a buildfile to
create the image. T
he buildfile consists of a bootfile, a script and a list of links and folders to
include in the image
[7]
. This image may need to be made into a flask filesystem image if the
targeted device uses a flash filesystem. This is done using the mkefs command and

is fairly
easy to do once the main image has been created.



3.3)

Wind River VxWorks

The standard architecture of Wind River VxWorks (shown in figure 3)
is very similar to both
OS
’s

already discussed. As can be seen, the OS is
highly modular, based around a
mi
crokernel, like QNX Neutrino, with modules for multiprocessing, graphics, etcetera
implemented, if needed, o
n top of the kernel.
The debug agent seen in the fi
gure is used by
the IDE when
debug
gin
g

the kernel.


8


Figure 3: The Wind River VxWorks architectur
e


Wind River suggest
s

that p
latform development be done with the Tornado IDE

although it can
be done manually. Tornado, much like Pla
tform Builder, allows the developer to quickly create
a base platform through use of a wizard. The developer can then add/
remove OS
components through use of the IDE before going on to build
, download and debug
the image.
The manual platform creation process is much like that for CE .NET or Neutrino and involves
manually editing the config.h and configAll.h files amongst othe
r things. ConfigAll.h controls
global configuration while config.h controls BSP
-
specific information.

One of the benefits of
using the IDE to create a platform, this is a benefit to all the
OS’s’ IDEs,

is that the IDE
automatically determines dependencies

between components. Thus, when you add a
component like
ANSI time

the IDE will automatically add
POSIX clocks

as this module is
needed for
the previous

to run. Similarly if you remove
POSIX clocks

then anything that is
dependant on the module (e.g.
ANSI t
ime
) would be removed as well.
Tornado also comes
complete with a simulator which will run on the host hardware providing a simulated
environment in which your custom OS image can run and be tested without additional
hardware expenditure.


4)

Bluetooth Stack
s

Bluetooth stacks are the means by which the
OS and applications access and control the
Bluetooth hardware.
All Bluetooth

stacks are modular in concept and allow themselves to be
trimmed down for optimal performance. This allows for unused modules to be r
emoved;
reducing ROM and RAM size. Teleca claim that their Bluetooth stack, tBlue, has a fully
functional implementation which occupies 30Kb ROM and 2Kb RAM on a small OS
-
less 8
-
bit

9

CPU
[14]
.

A

good idea of the basic structure of most Bluetooth stacks can
be gained by
looking at the architecture for the Stonestreet One Bluetopia Bluetooth stack (See figure 4).

As can be seen, an API is exposed that allows for control and operation of each of the various
modules. These in turn, will control the hardware via
the HCI.



Figure 4: The StoneStreet

One Bluetopia Bluetooth Stack structure



The Microsoft stack is slightly different in that Microsoft has chosen to use an existing API,
Winsock, to control
most of
the stack. Figure 5 shows how Microsoft have encapsul
ated the
functionality of the st
ack allowing access to it via
Winsock
or
COM Port Emulation API
.




Figure 5: The Microsoft Bluetooth Stack Architecture



10

The Bluetooth Qualifications Board
(BQB)
supply a set of specifications by which stacks must
comply.
These revolve around which stack layers must be

implemented and which profiles
are mandatory or optional. All core stack layers must be provided along with the Generic
Access Profile and the Serial Port Profile for Bluetooth Qualification.

The Bluetooth
sp
ecification also offer
s

guidelines for implementing various profiles.
The core stack layers
consist of the Logical Link Control and Adaptation Protocol (L2CAP), Radio Frequency
Communications Protocol (RFCOMM), Service Discovery Protocol (SDP), Telephony C
ontrol
Specification (TCS),


There are numerous Bluetooth stacks
,
qualified

and unqualified,
available on the market
today.

The following table shows some of the Bluetooth stacks available and which of the
three operating systems discussed they can be imp
lemented on.

Most of the stacks will also
support other major embedded OS’s (e.g. Linux, Nucleus).
One must be careful though as not
only the operating system that is supported need be considered. One must also consider the
target hardware and the stacks c
ompatibility with the Bluetooth chip in use.


Manufacturer/Developer

Bluetooth
Qualification

Supported Operating Systems

Microsoft


Windows CE .NET

Extended Systems

V1.2

VxWorks & QNX

Stonestreet One

V1.2

Windows CE .NET, QNX & VxWorks

Teleca tBlue

V1.
2

Windows CE .NET & VxW
orks natively although
can be easily ported to QNX

Widcomm

V1.2

Windows CE .NET & VxWorks natively although
can be easily ported to QNX through use of a
generic kernel interface

Adamya

V1.2

Windows CE .NET

IVT

V1.2

Windows CE .NET

& VxWorks

ImpulseSoft

V1.2

None of the three operating systems in question

Table 1
: An Overview of OS Portability of Selected Bluetooth Stacks


5)

Conclusion

To conclude we shall briefly look at what has been covered in this review. The review firstly
took

a look at the nature of embedded systems and some constraints that arise out of this. It
then moved on to look at some of the major embedded OS available today and their
similarities and features. It also looked at the process of creating a custom image b
oth
manually and through use of an IDE for each of the OS’s under discussion. It then look
ed

at
the concept of a Bluetooth stack and the basic structure of a stack was outlined. Finally the
review looked at the compatibility between some commercially avail
able Bluetooth stacks with
the OS’s discussed
p
r
eviously
.


11

6)

References

[1]
Howe D, “
F
ree
O
n
L
ine
D
ictionary of
C
omputing Definition of Embedded System”,
[Accessed 19 June 2004],
<
http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=embedded+system
>


[2]
Senese B, “
Implementing Bluetooth i
n
an Embedded D
evice



[3]
Wang CL, Yao B, Yang Y, Zhu Z, “A
Survey of
E
mbedded O
perating
S
ystem”, [Accessed
5 June 2004] <

http://3c.nii.org.tw/3c/silicon/embedded/2003
-
03/0228/Survey%20of%20Embedded%20OS.pdf
>


[4]

How to
Use the Command L
ine to
Create Customise and B
uild a
P
latform
”, [Accesse
d 15
May 2004],

<
http://msdn.microsoft.com/library/default.asp?url=/library/en
-

us/wcepb40/html/pbconHowToDevelopP
latformUsingCommandLine.asp
>


[5]
QNX Systems Homepage
, [Accessed 1 June 2004],

<
http://www.qnx.com
>


[6]
QNX Systems,

QNX Realtime Operating System:

System Architecture

,
[Published
2003], [Accessed 2 June 2004],

<
http://www.qnx.com/developers/docs/momentics621_docs/neutrino/sys_arch/about.html
>


[7]
QNX Systems,

QNX Realtime Operating System: Building Embedded Systems

,
[Published 2003], [Accessed 3 June 2004],

<
http://www.qnx.com/developers/docs/momentics621_docs/neutrino/building/about.html
>


[8]
QNX Systems,

QNX Moment
ics Professional Edition
:

User Guide

, [Published 2003],
[Accessed 4 June 2004],

<
http://www.qnx.com/developers/docs/momentics621_docs/ide_en/user_guide/about
.html
>


[9]
Wind River Systems Inc., “
VxWorks Programmer’s Guide 5.4 Edition 1


, [Published ],
[Accessed 18 June 2004],
<
https://spacegrant.colorado.edu/
slash/training/vxworks/docs/vxworks/guide/index.html
>


[10]
Wind River Systems Inc., “
Tornado User’s Guide (Unix Version) Edition 1


, [Published ],
[Accessed 18 June 2004], <
https://spacegrant.colorado.edu/slash/training/vxworks/docs/tornado/unixguide/index.html
>



12

[11]
Bluetooth Stack Implementation in Windows CE
, [Accessed 21 June 2004],

<
http://msdn.microsoft.com/library/default.asp?url=/library/en
-
us/wceddk40/html/cxconbluetoothdriverimplementationinwindowsce.asp
>


[12]
Microsoft
Bluetooth Stack Architect
ure
, [Accessed 17 May 2004],
<
http://msdn.microsoft.com/library/default.asp?url=/library/en
-
us/wcebluet/html/ceconBluetoothSt
ackArchitecture.asp
>


[13]
Stonestreet One Bluetopia Bluetooth Protocol Stack
, [Accessed 21 June 2004],
<
http://www.stonestreetone.com/bluetooth/products/stack/index.shtml
>


[14]
Teleca tBlue
, [Accessed 20 June 2004],
<
http://www.teleca.com/PSUser/servlet/com.ausys.ps.web.user.servlet.Authorized
PageServle
t?nodeid=4131&pageversion=2
>


[15]
Bluetooth Core Specification v1.2
, [Accessed 5 March 2004],
<
https://www.bluetooth.org/foundry/adopters/docu
ment/Bluetooth_Core_Specification_v1.2
>


[16] Microsoft, Microsoft Windows CE .NET Help System


[17] Microsoft Windows CE .NET 4.2 Multiple XIP Support, [Accessed 22 June 2004],
<
http://msdn.microsoft.com/library/default.asp?url=/library/en
-
us/wcemain4/ht
ml/cmconMultipleXIPSupport.asp
>