Amritendu Mondal

Deepankar Patra

Mahesh Gupta

Re-engineering & Integrating

Bluetooth 3.0 Device Driver in MOOL

Linux Bluetooth Driver Architecture

10-08-2013 2

Bluetooth stack is divided into two parts

Controller Stack:

Implemented in the silicon device containing Bluetooth radio &

a µ-processor

Device Specific

Host Stack:

Implemented as a part of OS.

Bluetooth Applications interact with this

Controller Stack (Device Specific)

10-08-2013 3

Contains following interfaces

ACL (Asynchronous connectionless link)

SCO (Synchronous Connection Oriented link)

LMP (Link Management Protocol)

HCI (Host Controller Interface)

LELL (Low Energy Link Layer)

Host Stack (OS Specific)

10-08-2013 4

L2CAP (Logical Link Controller and Adaptation Protocol)

Passes packets to either HCI or on a host less system directly to

the link manager / ACL link.

BNEP (Bluetooth Network Encapsulation Protocol)

Bound to L2CAP

Used for delivering network packets on top of L2CAP

RFCOMM (Radio Frequency Communication)

Bound to L2CAP

Provides simple reliable data stream to users

Host Stack (OS Specific)

10-08-2013 5

CMTP (CAPI Message Transport Protocol)

Used to transfer common ISDN application interface messages

Data is transferred via L2CAP

HIDP (Human Interface Device Profile)

Provides support for Devices such as Keyboard, mouse etc.

Designed to provide low latency link with low power

requirements.

SDP (Service Discovery Protocol)

Bound to L2CAP

Our Work

10-08-2013 6

Re-engineering Bluetooth 3.0 device driver from C to object

oriented C++ code

Integrating Re-engineered Bluetooth 3.0 in MOOL

Why Integrating Bluetooth 3.0 and

What’s new in it?

10-08-2013 7

It gives 8 times more speedup than the previous version

L2CAP is enhanced(EL2CAP), which adds an additional

ERTM(Enhanced Retransmission Mode) to the core

specification.

A new feature AMP(Alternate Mac/Phy) is added to increase

the transmission speed

All the stack protocols are affected due to these changes

Why Re-engineering?

10-08-2013 8

Changes in signature of multiple functions, and in many cases

change in the implementation of the same also in Bluetooth

3.0 made it difficult to integrate it in MOOL

Newly introduced features, like AMP, require significant

effort to update the current code, as the code is not

modularized.

Why Re-engineering?

10-08-2013 9

Some functions written only for the use of Bluetooth device,

can be extracted into a different class and reused in other

device drivers also(e.g. CRC extraction from packets).

Re-engineering Bluetooth 3.0

10-08-2013 10

Controller Stack:

Controller Stack is device specific.

Each driver file is implemented by different vendors

independently.

usb_driver instance is common which is initialized with function

pointers.

Each such function pointer has specific action.

But the implementation differs as the device does, so no

function level abstraction is possible at controller stack level

Re-engineering Bluetooth 3.0

10-08-2013 11

Host Stack:

This is OS specific and common for all devices

Lots of scope was there for OO abstraction

All the procedures related to one Protocol, kept in one file

initially, was broken up into multiple classes according their

functionalities

An Example of Code Modularization

10-08-2013 12

Previously the entire L2CAP protocol was implemented in two files l2cap_core.c and l2cap_sock.c.

We divided the functions in l2cap_core.c into some classes, which are:

L2cap_core_channel

L2cap_core_seq_list

L2cap_core_sls

L2cap_core_connection

L2cap_core_signalling

L2cap_core_hci

Code Conversion Steps

10-08-2013 13

Take a specific protocol

Extract feature wise independent functions

Put them into unique classes

Make static functions private, and non static ones public

Write wrapper functions for the public methods and call the

class functions inside them

Put all the class definitions in a .h file and their

implementations in a .cc file

Problems Faced

10-08-2013 14

C++ keywords used as variable names in C drivers

Structure declarations inside sizeof() is allowed in C, but not

in C++

enum constructs were not supported and replaced with

macros

(void *) casting needed to be casted to a specific type

Support for some built-in C functions is not there in C++,

e.g. __builtin_choose_expr(evaluates one of two expressions

based on compile time evaluated condition)