Document date / Year-Month-Day Approved Revision Document No 2010-August 13 Scott Hansen
This guide is targeted to help a Bluetooth Member or their BQE understand the role of the iAnywhere Blue SDK 4.x and Profile SDKs in a complete Bluetooth wireless product being integrated for qualification. The Bluetooth Program Reference Document requires that all Bluetooth Components have a Reference Integration Note (RIN) as a pre-requisite for qualification. This RIN has been uploaded to the Bluetooth SIG Qualification Listing Interfaces for the Qualified Design ID [list QD ID here] prior to qualification of this design and is available for Member use when creating new Bluetooth products by integration of this product into their product implementation. PRODUCT OVERVIEWThe iAnywhere Blue SDK 4.x and Profile SDKs are software development kits that are used to add Bluetooth capabilities to various embedded and non-embedded products. The SDKs can be ported to specific hardware and operating systems, and applications can be added using the Blue SDK and Profile SDK APIs.
The iAnywhere Blue SDK 4.x and Profile SDKs provide core functionality supporting the Bluetooth 3.0+HS specification, and certain lower level profiles and protocols, including L2CAP, A2MP, SDP, SDAP, GAP, SPP, and RFCOMM. This QD ID covers the following profiles and protocols: A2DP, AVCTP, AVDTP, GAVDP, PAN, and BNEP. Product Type DeclarationThe iAnywhere Blue SDK 4.x and Profile SDKs is listed as a Bluetooth Component Product type. If you use this product to implement Bluetooth in your product’s design, further qualification and listing is required in accordance with the Bluetooth Qualification Process (ref. PRD 2.0). To start the process for a new qualification, please visit https://bluetooth.org/TPG. Software OverviewThe iAnywhere Blue SDK 4.x and Profile SDKs provide source code that can be ported to various architectures and operating systems that provide Bluetooth core and Bluetooth profile functionality. Once the software has been adapted to the operating system and hardware, applications are then written or modified to use the provided interfaces. In some cases the iAnywhere Blue SDK 4.x and Profile SDKs can be used in place of default Bluetooth stacks provided by hardware vendors to give the applications greater simplicity, more control, and more power over their application’s interactions with the Bluetooth link. ApplicationThe iAnywhere Blue SDK 4.x and Profile SDKs can be used in any device that uses Bluetooth, such as Bluetooth enabled automotive head units, cellular phones, printers, digital cameras, and so forth. Block DiagramThe iAnywhere Blue SDK 4.x and Profile SDKs is a set of software building blocks that can be stacked together to create a custom Bluetooth application. Each component is provided as portable source code, designed to compile successfully in almost any C-based target environment. Because there are differences between compilers and CPU architectures, we are careful to use a specific subset of ANSI C functionality so that our code behaves identically in the vast majority of target architectures. The diagram below illustrates the basic component layout. Areas bounded by the green boxes indicate components provided by the iAnywhere Blue SDK 4.x and Profile SDKs. Blue components are provided by a Blue SDK licensee building our SDK into a new environment. In addition to the Profile SDKs shown in this diagram, iAnywhere has many other Profile SDKs designed to work with the iAnywhere Blue SDK 4.x Stack. Software FeaturesThe iAnywhere Blue SDK 4.x includes the following components:
Software ArchitectureThe iAnywhere Blue SDK 4.x and Profile SDKs provide the ability to for implementers to add or remove functionality as needed. For example, the HCI transport can be changed, profiles can be added or removed, unwanted optional features can be compiled out, and OS interfaces are incapsulated so porting to various operating systems is made easier. In addition, the code is processor agnostic, allowing it to be used on many different hardware architectures. InterfacesInterface requirement details and support can be obtained using the contact information found in section , Contact Information. There are three interfaces that interact with the rest of the system:
The Hardware InterfaceThe Hardware Interface includes the Baseband Bluetooth Radio Hardware Interface and the AMP High Speed Hardware Interface. Baseband Bluetooth Radio HW Interface The iAnywhere Blue SDK 4.x and Profile SDKs relies on the published HCI specification. Therefore, the Blue SDK creates well-formed HCI commands and data, and expects well-formed HCI events and data in return. HCI commands, events, and data are delivered as packets to a transport-specific layer called a “transport driver”. The transport driver, in turn, sends and receives streams of data through a “hardware driver” which communicates directly with the Bluetooth radio hardware.
The AMP Controller Layer provides a standardized way for AMP controller hardware to communicate with higher-level protocol stack implementations. The AMP Controller architecture allows both HCI based AMP Controllers and those with PALs running in the host to be easily integrated into the stack. The AMP controller architecture consists of the following modules: The iAnywhere Blue SDK 4.x and Profile SDKs requires integration with a “host controller” (sometimes referred to generally as a “Bluetooth radio”). The host controller must include the following components:
If integrated Bluetooth hardware fails to conform to any of the above stack specifications, particularly HCI, the Blue SDK stack may behave in an undefined or non-compliant manner. An implementer is free to use several different transports to connect the host controller’s HCI layer to the Blue SDK’s HCI layer. For example, this may be done over UART, USB, any other Bluetooth-specified manner, or in any manner specific to the hardware (including a software-only HCI on a one-chip solutions). As long as the iAnywhere Blue SDK 4.x and Profile SDKs’ HCI API contract is met the system will behave in a compliant manner. The Operating System InterfaceThe iAnywhere Blue SDK 4.x and Profile SDKs defines a set of OS-specific APIs that must be provided by the implementer. These APIs provide basic system services such as a timer, a semaphore to prevent reentrancy, memory copy routines, persistent storage for security link keys, and some debugging functions. The iAnywhere Blue SDK 4.x and Profile SDKs uses only those endpoints to access local operating system functionality. The “operating system” must supply the following basic tools. Most embedded OS’s provide this level of basic functionality.
These features can also be easily provided when no actual operating system is present. The Application InterfaceWhen building an application that uses the iAnywhere Blue SDK 4.x and Profile SDKs, the implementer need only include the iAnywhere Blue SDK 4.x and Profile SDKs modules that are relevant to the target functionality. For example, a network access point implementer could include BNEP and PAN modules without including RFCOMM. Once the relevant modules are included, the implementer has access to a large set of application APIs that provide access to stack functionality. The APIs are carefully designed so that if the user follows basic rules of usage published in the API specification, it is difficult or impossible for the API user to cause the component to violate the associated protocol specification. Profiles are implemented by connecting protocol or profile APIs to a user interface. The implementer has considerable discretion about how the application’s user interface appears or works. The implementer may refer to our sample applications to get ideas about how an application could interact with the iAnywhere Blue SDK 4.x and Profile SDKs. Application RequirementsAs specified by section , “The Application Interface”, applications are responsible for fulfilling the API contract specified by the iAnywhere Blue SDK 4.x and Profile SDKs. This includes invoking API functions in the proper order, providing the appropriate arguments to function calls, and making proper responses to callback events. Applications are also responsible for presenting an application user interface to the end-user. Sample PortingsFor information about how to adapt or port the iAnywhere Blue SDK 4.x and Profile SDKs to a relevant environment where it is to be used so that the implementations execute without errors, refer to the following sections of this document:
Hardware / Software Reference PlatformsThe following table lists the environment which was utilized in qualifying this design. (Not all of the combinations were used on all of the tests.)
Note that although this table does show some of the environments were the iAnywhere Blue SDK 4.x and Profile SDKs has been successfully ported, it is not a representative list of the numerous successful portings achieved by our customers, which include custom applications, embedded operating systems, and diverse hardware platforms. Components in our iAnywhere Blue SDK 4.x and Profile SDKs are qualified running with samples for each of the external components illustrated in section , Block Diagram. Our design goal is to make all interfaces to each external component completely clear so that the components in the iAnywhere Blue SDK 4.x and Profile SDKs behave exactly as documented in a new implementation. This reduces the testing burden for new implementations that include our iAnywhere Blue SDK 4.x and Profile SDKs. Contact InformationUse the following contact information to obtain additional details relevant to the support of this design: iAnywhere Solutions Mobile Device Solutions Group bluesdk@ianywhere.com RIN Datasheet 2010-08-03 Download 60.69 Kb. Share with your friends: |