Implementing Bluetooth in an Embedded Device.pdf

Implementing Bluetooth Wireless Technology In An Embedded Device

Author: Brian Senese, Extended Systems Inc.

Bluetooth technology provides a novel approach toward eliminating the inconvenience

associated with wired communication. Implementing such solutions however can be

fraught with difficulty given the design freedom that is concomitant with embedded

systems development.

Applications that are described in the Bluetooth specification can be supported by a

number of different hardware platforms. Cell phones, laptop computers, personal digital

assistants, and embedded devices are some of the devices in which this new wireless

technology is finding a home. Hardware platforms can be separated into two distinct

categories: Windows or Palm-based devices and those that are specialized embedded

systems.

Mainstream PCs, laptops and PDAs have a user interface that provides the end-users

with the capability to actively participate in establishing connections with other Bluetooth

devices, then using services offered by these devices. Applications usually provide a

fixed set of services which appeal to the mobile computer user. Third party Bluetooth

protocol stacks provided on these types of computing devices are generally provided in

executable form. Applications are virtually readymade supporting profiles that are

suitable to these devices. LAN access, wireless connection to modem or fax, file transfer

and legacy synchronization are some of the typical client services that can be provided on

portable computing devices. Modules containing the radio hardware are provided by a

variety of vendors, each having to develop their own driver software to communicate

with the Host Controller. Driver software is the largest part of the design and integration

task for this class of device.

Embedded systems, on the other hand, require much more design thought and

development time. These types of devices are unique in the sense that they are built from

a variety of pre-existing hardware and software. These devices are usually cost sensitive

influencing the Bill of Materials (BOM). They often have a limited user interface, if one

exists at all. Other restrictions that are imposed include the amount of memory used and

type of memory supported (FLASH, E2PROM etc. ). Once the hardware is chosen, the

Bluetooth protocol stack and operating system must be ported onto the new platform.

This requires the development of hardware drivers to facilitate communication and data

storage. Developing, integrating and debugging on a new embedded target is also an

interesting proposition, especially when time to market pressures are looming.

This paper addresses the specific issues that a design team will have to consider in

creating solutions for embedded devices. Starting with a generic architecture, issues

regarding the creation of the hardware target and concomitant software are presented.

Bluetooth system operation is then briefly discussed with the intention of taking into

account the unique needs of a wireless connection in structuring the application software.

Implementation issues are then discussed and closely followed up with development

ideas that are designed to not only contain the project burn rate but also to get the product

to market in as short a time as possible.

Embedded Architecture

Bluetooth radio hardware has been associated , at least in marketing terms, to a price

point of approximately five dollars, making this wireless link very cost effective. To

achieve this, hardware solutions consisting of Host and Host Controller will have to be

integrated onto a single chip and mass produced. This is unfortunately not the

commercial reality of today. Currently, solutions still consist of multiple components.

The Host is typically managed on a processor and the Host Controller consists of several

integrated circuits. Figure 1 illustrates a familiar architecture that is closely aligned with

descriptions as provided in the Bluetooth specification V1.0B. With regard to selecting

specific hardware components, one must first consider the application that is to be

developed.

Processor and memory

There are many tradeoffs to be considered when deciding on the hardware architecture.

Demanding applications, those that make heavy use of the upper protocol stack (running

on the Host) in transferring data, dictate that a 16 bit (or more) processor be used.

Memory limitations when using a more powerful processor are relaxed to the point where

the only restriction becomes the additional cost of adding memory in the form of Flash or

E2PROM. The option of providing non-volatile store required in the management of the

Device database is peripheral, yet determines the paradigm that will be used in providing

device security. The inclusion of a user interface can increase hardware cost in the BOM,

yet allows human intervention for the purposes of configuring the device as well as

respond to queries generated as a result of security procedures that may be triggered.

Lesser applications can be supported by a smaller 8 bit processor. Processing power is

unnecessary in handling sporadic messaging between Bluetooth units. Establishing a

connection, service discovery and application setup can easily be handled with less

processing power if the resulting utility is nothing more than the establishment of an

audio channel. Figure 1 illustrates a current architecture whereby the audio channel

(SCO) is supported by the Host Controller hardware and optionally by the Host. Once

this channel is requested by the Host application, the need for further Host processing is

minimized if not completely eliminated. Disconnecting the audio path requires minimal

processing as well.

Host

Bluetooth Application Code

OBEX

Audio

(optional)

RFCOMM

SDP

TCS

L2CAP

Voice

(optional)

Management

Entity

Security

Host Controller Interface

Device

dBase

HCI Transport and hardware driver layers (UART or USB)

Host Controller

HCI Transport and hardware driver layers (UART or USB)

Host Controller Interface

Link Management

Protocol

ACL

SCO

Audio in / out

Link Controller

Baseband Control / Processing

RF Hardware

Antenna

Figure 1 : An embedded solution consisting of Host and Host Controller

Operating System

Selection of an operating system (OS) is just as closely related to the application to be

supported. Round-robin scheduling is by far the simplest, calling routines in a sequential

order, allowing them to run for as long as it takes to process all requests and events, then

returning control to the next routine which runs until complete. Figure 2 provides a

listing of this very simple routine. Predictability and ease of use are the two benefits

associated with this OS. Its suitability for simple applications makes this the OS of

choice; especially when its cost in terms of memory use is small and its pecuniary impact

on project budget is minimal. The headset profile is a candidate that can make use of this

simple OS.

while ( exitNow == FALSE ) {

for (i = 0; i < numThreads; i++ ) {

}

if (threads[i] ) threads [i] ();

}

Figure 2: Round robin operating system for simpler applications

Sophisticated applications such as LAN Access Points make greater demands on the type

of scheduling required to co-ordinate many different tasks which include:

• Bluetooth protocol stack;

• Application code;

• PPP and TCP/IP stack;

• and possibly an Ethernet interface.

Multiple threads, each requiring processor resource in a real time environment, each

running asynchronous operations is strong enough reason to dictate the use of this type of

OS. Whether you design your own pre-emptive OS, purchase one or use an existing

free OS ( such as Linux), there will be greater effort required in integrating the protocol

stack, OS and application onto the target.

An important component that must be selected to finalize a Bluetooth system is the Host

Controller. Its selection can be based upon a number of different factors that are again,

associated with the application being developed. For battery operated devices, power

consumption is a primary consideration. Power usage figures prominently into the way

the application is designed. Hold, sniff and park modes available for use by the Host

Controller will impact power drain. Less obvious in terms of saving power are other

configurable Host Controller modes such as discoverability and connectability settings.

By setting the Host Controller to be non-discoverable reduces power consumption. The

same effect is derived when the device is configured to be non-connectable. Both modes

are loosely related to the security paradigm to be implemented on the device which will

be discussed later.

Other factors can influence the selection of radio hardware. Availability, supported data

throughput rates , point to multi-point communication and audio support are to be

considered in determining a suitable Host Controller vendor.

Finally the form factor or footprint may be important, influencing the hardware

component selection. The use of commercially available Bluetooth Modules containing

both Host Controller and Host may be convenient for the sake of implementing a

Bluetooth solution quickly, yet are impractical in terms of supporting size sensitive

devices. The headset device is such an example.

Hardware selection will become more obvious as the Bluetooth system and concomitant

implementation issues are discussed in the following sections.

Communication Architecture

There are basically two elements that are of importance when discussing Bluetooth

system operation. Within the context of a piconet, there exists the notion of a Master –

Slave relationship. The Master initiates a radio connection at the Link manager level

(within Host Controller), and serves to control the radio link. Slaves respond to

connection requests, following the lead of the Master and adopting the Masters unique

hop frequency pattern. Such operation in a general sense, does not affect the application

code once an RF connection is made.

Figure 3 illustrates a different type of connection that has greater impact on the structure

of the software architecture, this being the establishment of a client server relationship as

is the case for the LAN Access Profile. This relationship is characterized by many other

different names in the Bluetooth profile descriptions. Servers are referred to as gateways,

audio gateways, LAN Access Points, and obviously servers. Clients become terminals,

headsets, data terminals and clients respectively. Regardless, peer to peer connections

established between upper layers of protocol (L2CAP, RFCOMM and eventually the

application) are initiated by the client

Servers are responsible for ‘registering’ the application on the server device such that it is

in a state of readiness for access by suitable clients. In addition to this, the y usually

implement a security paradigm that can take on a number of different responsibilities.

Identifying the client as friend or foe, governing access to specific services and encoding

data are the primary functions associated with this gatekeeper. Servers are often

associated with devices such as Fax machines, modems, printers or LAN Access Points

which are usually connected to the AC main power source. Memory restrictions are not

usually a problem for these devices. Memory availability is of importance and will be

discussed in the context of link key management when security operation is covered later.

Clients on the other hand can invoke the application software only after examining the

environment for BT enabled devices and determining if there are services of interest

available. They initiate connections at the physical layer and if established, attempt to

complete peer to peer connections at higher levels of the Bluetooth protocol stack.

Security barriers are not generally erected by the client, although they can be if desired.

Clients are often mobile devices that can be sensitive to size, cost, and power

consumption restraints.

Another consideration affecting software architecture on the server side is the need to

support concurrent Bluetooth sessions, or even multiple Host Controllers. The first

situation where multiple BT connections are to be supported for the purposes of offering

identical or even unique services to clients dictates the use of a ‘connection manager’ as

shown in figure 3 . This application component is responsible for managing the generic

access protocol procedures. It responds to requests from the user and determines if

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: