Specifications

Major Changes in BlueLab3 Relative to BlueLab2

blab-srn-005Pa

This material is subject to CSR’s non-disclosure agreement.

Page 12 of 48

_äìÉi~Ä»=îPKQ= Software Release Note

5 Major Changes in BlueLab3 Relative to BlueLab2

BlueLab3 builds on many years of experience with BlueLab1 and BlueLab2. Many components have been

redesigned and replaced to make it easier and faster to build the sort of applications CSR’s customers are now

working on.

5.1 Tool Changes

The most visible change in BlueLab3 is the addition of xIDE, a complete integrated development environment.

xIDE allows projects to be created, code to be edited, VM applications to be compiled, and Kalimba DSP code to

be assembled within a single environment.

xIDE replaces the Java-based appdebug from BlueLab2. It also replaces the Matlab-based kaldbg which was

provided as part of BlueLab v2.85 and later. The requirement to install Cygwin and Java has also been

eliminated.

xIDE supports on-chip debug of applications over BlueCore’s SPI debug interface, making it possible to debug

applications which take control of the USB or UART interface on BlueCore. Such applications include serial-cable

replacement and USB dongles.

The Matlab-based kalasm from BlueLab2.85 and later has also been replaced by a new version, kalasm2.

A new C compiler based on gcc3.3.3 has replaced the gcc 2.95 compiler used in BlueLab2 and typically yields a

10% improvement in code density.

5.2 Library Changes

The most significant change in BlueLab3 is the introduction of the new connection library which supports any

combination of RFCOMM, L2CAP and SCO connections (and, soon, TCP and UDP) serving multiple profiles. For

example, a single application implementing both AV and HF profiles is now possible. (The single connection and

single profile limitations imposed by the cm_rfcomm library in BlueLab2 no longer apply.)

The lower level libraries have been completely rewritten to support the new connection library. Notification of

asynchronous events, either from the firmware or from lower-level libraries, is now uniformly handled by the

delivery of messages. Tasks are now dynamically created and combine message handlers with local state. The

scheduler library in BlueLab2 has been replaced by a simplified message loop, cutting latency on message

delivery by a factor of five.

The upper level libraries, which correspond to Bluetooth profiles, have also been completely rewritten as tasks

which use the new connection library. This makes it possible to combine multiple profiles in a single application.

For example an application can now open multiple SPP connections simply by creating multiple instances of the

SPP profile.

5.3 Application Changes

BlueLab2 and BlueLab3 applications look significantly different. In general a BlueLab3 application is much

simpler than the corresponding BlueLab2 application, especially when multiple connections or profiles are being

used. A typical BlueLab3 application simply arbitrates between the user-interface logic and the profile instances it

creates.

However, the extensive changes to the libraries make it impractical for the same code to work with both BlueLab2

and BlueLab3. An existing BlueLab2 application will have to be partly rewritten to work with BlueLab3.