PB375A U盘读写芯片
  BF10-A 蓝牙模块(AT)
  BF10-I 蓝牙模块(IO)
BF10-SC 蓝牙模块(扫描)
RS232 蓝牙串口
  USB 蓝牙服务器

业务销售1 点击这里给我发消息

业务销售2 点击这里给我发消息<已满>

技术支持 点击这里给我发消息









(一)Host Controller Interface (HCI)

The HCI provides a command interface to the baseband controller and link manager, and access to hardware status and control registers. Essentially this interface provides a uniform method of accessing the Bluetooth baseband capabilities.The HCI exists across 3 sections, the Host - Transport Layer - Host Controller. Each of the sections has a different role to play in the HCI system.

(1)HCI Functional Entities

    The HCI is functionally broken up into 3 separate parts:


 蓝牙开发入门 - 深圳蓝色飞舞科技

1.1)HCI Firmware (location: Host Controller)

   HCI Firmware , is located on the Host Controller , (e.g. the actual Bluetooth hardware device). The HCI firmware implements the HCI Commands for the Bluetooth hardware by accessing baseband commands, link manager commands, hardware status registers, control registers, and event registers. The term Host Controller means the HCI-enabled Bluetooth device(Host Controller这一技术术语表示的是“人机交换”的蓝牙设备).

1.2)HCI Driver (location: Host)

HCI Driver , which is located on the Host (e.g. software entity). The Host will receive asynchronous notifications of HCI events, HCI events are used for notifying the Host when something occurs. When the Host discovers that an event has occurred it will then parse the received event packet to determine which event occurred. The term Host means the HCI-enabled Software Unit(Host这一技术术语表示的是“人机交互”的软件单元).

1.3)Host Controller Transport Layer   (location: Intermediate Layers)

    The HCI Driver and Firmware communicate via the Host Controller Transport Layer , i.e. a definition of the several layers that may exist between the HCI driver on the host system and the HCI firmware in the Bluetooth hardware. These intermediate layers, the Host Controller Transport Layer, should provide the ability to transfer data without intimate knowledge of the data being transferred. Several different Host Controller Layers can be used, of which 3 have been defined initially for Bluetooth : USB , UART and RS232. The Host should receive asynchronous notifications of HCI events independent of which Host Controller Transport Layer is used(Host接收HCI events事件通知与具体使用什么样的传输层无关).

2HCI Commands

   The HCI provides a uniform command method of accessing the Bluetooth hardware capabilities. The HCI Link commands provide the Host with the ability to control the link layer connections to other Bluetooth devices. These commands typically involve the Link Manager (LM) to exchange LMP commands with remote Bluetooth devices. The HCI Policy commands are used to affect the behaviour of the local and remote LM. These Policy commands provide the Host with methods of influencing how the LM manages the piconet. The Host Controller and Baseband commands, Informational commands , and Status commands provide the Host access to various registers in the Host Controller.(HCI commands就是Link commands,HCI policy commands,Host Controller and Baseband commands, Informational commands , and Status commands的合集)。

2.1)HCI-Specific Information Exchange

   The Host Controller Transport Layer provides transparent exchange of HCI-specific information. These transporting mechanisms provide the ability for the Host to send HCI commands, ACL data, and SCO data to the Host Controller. These transport mechanisms also provide the ability for the Host to receive HCI events, ACL data, and SCO data from the Host Controller. Since the Host Controller Transport Layer provides transparent exchange of HCI-specific information, the HCI specification specifies the format of the commands, events, and data exchange between the Host and the Host Controller.(Host Controller Transport Layer提供的透明传输机制,为Host向Host Controller发送指令和数据以及从Host Controller接收返回事件,提供了传输途径)。

2.2)Link Control Commands

    The Link Control commands allow the Host Controller to control connections to other Bluetooth devices. When the Link Control commands are used, the Link Manager (LM) controls how the Bluetooth piconets and scatternets are established and maintained. These commands instruct the LM to create and modify link layer connections with Bluetooth remote devices, perform Inquiries of other Bluetooth devices in range, and other LMP commands.(Link Control Commands 主要用于命令LM如何进行连接组网,设备发现等)

2.3)Link Policy Commands

   The Link Policy Commands provide methods for the Host to affect how the Link Manager manages the piconet. When Link Policy Commands are used, the LM still controls how Bluetooth piconets and scatternets are established and maintained, depending on adjustable policy parameters. These policy commands modify the Link Manager behaviour that can result in changes to the link layer connections with Bluetooth remote devices.

2.4)Host Controller & Baseband Commands

   The Host Controller & Baseband Commands provide access and control to various capabilities of the Bluetooth hardware. These parameters provide control of Bluetooth devices and of the capabilities of the Host Controller, Link Manager, and Baseband. The host device can use these commands to modify the behaviour of the local device.

2.5)Informational Parameters

    The Informational Parameters are fixed by the manufacturer of the Bluetooth hardware. These parameters provide information about the Bluetooth device and the capabilities of the Host Controller, Link Manager, and Baseband. The host device cannot modify any of these parameters.


2.6) Status Parameters

   The Host Controller modifies all status parameters. These parameters provide information about the current state of the Host Controller, Link Manager, and Baseband. The host device cannot modify any of these parameters other than to reset certain specific parameters.


2.7)Testing Commands

   The Testing commands are used to provide the ability to test various functionality's of the Bluetooth hardware. These commands provide the ability to arrange various conditions for testing.



3HCI Events/ Error Codes/ Flow Control

3.1) Flow Control

    Flow control is used in the direction from the Host to the Host Controller to avoid filling up the Host Controller data buffers with ACL data destined for a remote device (connection handle) that is not responding. It is the Host that manages the data buffers of the Host Controller.


3.2) HCI Events

    A number of different events are defined for the HCI layer. The events provide a method to return parameters and data associated for each event. 32 HCI different events have been implemented so far, they range from Inquiry Complete Event to Page Scan Repetition Mode Change Event. See the main HCI specs for mode details.


3.3)HCI Error Codes

    A large number of error codes have been defined for the HCI layer. When a command fails, Error codes are returned to indicate the reason for the error. 35 HCI error codes have so far been defined, from Unknown HCI Command to LMP PDU Not Allowed.See the main HCI specs for mode details.


4  Bluetooth-defined Host Controller Transport Layers

4.1)UART Transport Layer

    The objective of the HCI UART Transport Layer is to make it possible to use the Bluetooth HCI over a serial interface between two UARTs on the same PCB. The HCI UART Transport Layer assumes that the UART communication is free from line errors. Event and data packets flow through this layer, but the layer does not decode them.


4.2)RS232 Transport Layer

   The objective of the HCI RS232 Transport Layer is to make it possible to use the Bluetooth HCI over one physical RS232 interface between the Bluetooth Host and the Bluetooth Host Controller. Event and data packets flow through this layer, but the layer does not decode them.


4.3)USB Transport Layer

   The objective of the Universal Serial Bus (USB) Transport Layer is to the use a USB hardware interface for Bluetooth hardware (which can be embodied in one of two ways: as a USB dongle, or integrated onto the motherboard of a notebook PC). A class code will be used that is specific to all USB Bluetooth devices. This will allow the proper driver stack to load, regardless of which vendor built the device. It also allows HCI commands to be differentiated from USB commands across the control endpoint.


Note, the above text contains excerpts from the Bluetooth SIG's Specification, as well as various interpretations of the Specs. For complete details of the various sections, consult the actual Bluetooth Specification.





Platform Builder for Microsoft Windows CE 5.0

Bluetooth Stack Architecture

The protocol stack makes up the core portion of the Bluetooth implementation. This stack enables devices to locate each other and establish a connection. Through this connection, devices can exchange data and interact with one another through various applications.

The following image map shows the supported layers within the Bluetooth stack. To link to topics that provide information about the elements in the image map, move your pointer over the element, and then choose the element.


OBEX (Object Exchange) is an object exchange protocol that is implemented on top of Winsock over Bluetooth and IRDA transports. For more information, see Object Exchange Protocol.

  • Obex client module: Obexapi.dll
  • Obex server module: Obexsvr.dll

TDI (Transport Driver Interface), in the Microsoft® Windows® CE operating system (OS) architecture, is an interface that serves as an adaptation layer to Winsock-based user APIs. It isolates the highly asynchronous callback-based architecture of the stack presenting a Windows Sockets Specification 1.1 interface.

COM Port Emulation, in Windows CE, enables virtual COM ports to be created over RFCOMM channels. It hosts dial-up and LAN access profiles. For more information, see Creating a Connection to a Remote Device Using a Virtual COM Port. The port emulation facility is included in Btd.dll.

SDP (Service Discovery Protocol) is a Bluetooth service discovery protocol that handles publishing and discovery of services running on top of the Bluetooth stack. The port emulation is included in Btd.dll.

  • SDP client module: Btdrt.dll
  • SDP server module: Btd.dll

RFCOMM (Serial Cable Emulation Protocol) is Bluetooth's adaptation of the TS07.10 protocol. It serves as a base for COM port emulation facilities and derived point-to-point protocols. Multiplexing and flow control between devices and applications are also implemented here. The RFCOMM layer is included in Btd.dll.

PAN (Personal Area Network) profile defines procedures to support standard IP-based network services deployed over the Bluetooth transport layer. For more information, see Personal Area Networking (PAN) Profile.

HID (Human Interface Device) profile defines procedures to support human interface devices such as keyboard and mouse. For more information, see Human Interface Device (HID) Profile.

L2CAP (Logical Link Control and Adaptation Protocol) is a lower connection-based Bluetooth communication protocol that implements multiplexing. L2CAP does not implement flow control. It relies on a reliable device-to-device baseband link provided by Bluetooth hardware. The L2CAP layer is included in Btd.dll.

HCI (Host Controller Interface) is a basic interface to Bluetooth hardware, responsible for controller management, link establishment, and maintenance. For more information, see Host Controller Interface. The HCI layer is included in Btd.dll.

Bluetooth Universal Transport Manager (BthUniv) is an intermediate transport driver between the HCI layer (Bluetooth transport drivers in the Bluetooth stack )and the transport layer  (HCI Transport Layer) . It detects the Plug and Play (PnP) device and loads the appropriate transport driver. For more information, see Supported HCI Transport Drivers. The Bluetooth Universal Transport Manager is in Bthuniv.dll.

HCI Transport Layer is a transport layer that delivers HCI commands to the Bluetooth hardware. For more information, see Bluetooth HCI Transport Layer. For more information about the modules that implement this layer, see Supported HCI Transport Drivers.

LMP (Link Manager Protocol) is the protocol that handles link establishment between Bluetooth devices, which include authentication and encryption.

BB (Baseband) enables the physical radio frequency (RF) link between Bluetooth units that form a piconet.

Each layer, with the exception of the HCI transport, is implemented as a separate entity that exposes its interfaces up and down through tables of callbacks. Each interface is well defined. There are no other interrelationships between parts of the stack; every layer is replaceable.


Host Controller Interface

The host controller interface (HCI) provides a uniform interface method for accessing Bluetooth hardware capabilities.

During the initialization sequence, the HCI creates read and write threads, establishes a connection to the Bluetooth transport, and performs a reset and read of device buffer sizes. It then enters an initialized state and is ready to accept clients.


Bluetooth HCI Transport Layer

The HCI Transport is designed to abstract and simplify physical communication between the Bluetooth stack and the controller. Microsoft Windows CE supports transport drivers for several interfaces including, UART, USB, SDIO, and BCSP.

A transport only implements a few functions; schematically, Open, Read, Write, Close and two for bookkeeping; Read and Write are blocking. The Bluetooth stack uses these functions to send Bluetooth commands and data packets, and receive data packets and events.

This interface is defined by Bt_hcip.h. The following topics discuss the HCI transport layer in more detail:


Supported HCI Transport Drivers

The following list shows some of the supported transport drivers that can be found in %_WINCEROOT%\Public\Common\Oak\Drivers\Bluetooth\Transports.

  • USB - Bthusb.dll
  • UART - Bthuart.dll
  • BCSP - Bthcsr.dll
  • Socket - Bthsc.dll
  • AmbiCom - Bthamb.dll

Windows CE also supports the transport driver for the SDIO interface.

Bluetooth Universal Transport Manager

Microsoft® Windows® CE provides the Bluetooth Universal Transport Manager (BthUniv) that is an intermediate transport driver between the HCI transport layer and Bluetooth transport drivers in the Bluetooth stack. It supports both built-in and PnP transport drivers and loads the appropriate transport driver.

Note   BthUniv always checks for PnP drivers before the built-in drivers.

BthUniv performs the following tasks:

  • Detects insertion or removal of PnP Bluetooth cards.
  • Thunks HCI transport interface calls.
  • Dynamically loads the underlying transport driver.

You can configure BthUniv though registry settings. For more information, see Bluetooth HCI Transport Driver Registry Settings.




之前没有摸过蓝牙,这回的项目里面有蓝牙模块.而我目前对蓝牙只知道的有:1.我们的设计里蓝牙模块是连接在串口上的.2.蓝牙不是蓝色的牙齿.呵呵, ,我不得不提前开始接触一下蓝牙协议栈.粗看起来还挺复杂庞大的.单蓝牙组织公布的规范1.1多达1084.先上面给出的图;东西很多,先分类吧!从底向上看,蓝牙的协议和规范可以分这些大类:

:最底层.就是上图蓝色部分.其中有射频规范,基带规范和链路管理层(Link Manager Protocol).一个好消息是,不要管这部分内容.因为这部分都在蓝牙模块里面实现了.可能需要稍微了解下的就是链路管理协议主要是负责认证,加密,链路管理和控制这些功能.还有一些有趣的信息,一个主设备最大和7个从设备建立链接,从设备之间不能互通.主设备到从设备的最大数据传输速率为723.2kbps,反向57.6kbps.也可以配置为双向433.9kbps.

:接口层.协议栈和硬件之间的接口.WinCE,它也包括了3个部分:第一,HCI(Host Controller Interface),第二,Bluetooth Universal Transport Manager,第三,HCI Transport layer主机控制接口层.第一层向上提供一个接口,第三层是和硬件的接口,比如连接到Host的是串口,那第三层就是一个串口的抽象的传输层,那为什么还需要第二层呢?第二层叫统一传输管理,是因为WinCE是一个开放的平台,它也不知道蓝牙究竟是连接串口,usb,sdio甚至一些pcmcia等其他的pnp设备,等等,而且作为HCI的上层也不想知道你用什么物理接口.于是它抽象出来这么一个东西来统一管理.简单说就是大一统所有的接口了,它先去扫描PCMCIA,USBsdiopnp设备,如果没有就根据注册表取默认的设备接口.最后被选定的接口会被安排到这里[HKEY_LOCAL_MACHINE\Software\Microsoft\Bluetooth\HCI]


WINCE500\PUBLIC\COMMON\OAK\DRIVERS\BLUETOOTH\TRANSPORTS\目录下面,那个univ目录的就是Universal Transport Manager,其他是各个具体的Transport layer的实现.














:协议层.这一层包括L2CAP,SDP,RFCOMM.首先要说L2CAP,之前已经提及这个协议,它建立在HCI上面.全名是逻辑链路控制和适应协议(Logical Link Controller and Adaption Protocol)看看它的功能:分发数据给更高层,数据包分段和重组...看过tcpip协议栈,感觉这一层像ip.如果想基于L2CAP上做第3方扩展应用,就要知道如何使用L2CAP接口.其实就是使用L2CAP_EstablishDeviceContext()来获得L2CAP层的接口,这是不是和HCI的接口太像了呢?接下来是SDP,这是一个服务发现协议(service discovery protocol)蓝牙设备是要组网的,就是用这个协议来寻找和定位其他蓝牙设备.另外一个RFCOMM是模拟串口协议,ETSI TS07.10标准的子集.没有听过这个标准.反正,这个模块的作用是使得上层就像操作串口一样使用蓝牙.



蓝芽协议栈的最上部是各种应用模型(Profile)。其中较典型的有服务发现 (Service Discovery Application),互通(Intercom),无绳电话(Cordless Telephony),传真(FAX),拨号网络(Dial-up Networking),耳机(Headset),局域网访问(LAN Access),文件传输(File Transfer),同步(Synchronization),Object Push等。各种Profile从协议栈中选取不同的协议组合来完成特定的功能。 下面列出各种Profile需要的协议组合,协议排列顺序按照从上到下的顺序: 服务发现(Service Discovery Application),包括SDPL2CAPLMPBaseband; 互通(Intercom),无绳电话(Cordless Telephony),包括TCSSDPL2CAPLMPBaseband;传真(FAX),拨号网络(Dial-up Networking),耳机(Headset),包括SDP/RFCOMML2CAPLMPBaseband; 局域网访问(LAN Access),包括TCP/IPPPPSDP/RFCOMML2CAPLMPBaseband; 文件传输(File Transfer),同步(Synchronization),Object Push,含OBEXSDP/RFCOMML2CAPLMPBaseband




蓝牙耳机功能,也就是bluetooth headset /headfree profile,实现起来比想象的复杂.早期的蓝牙规范只定义了headsetprofile, headset的实现原理是在hci层之上扩展一个接口,传输sco面向连接的同步音频数据包.限定音频流只能是单声道8k的话音级别的pcm. 随着需求发展,明显已经不能满足了,于是又补充了a2dp协议,a2dp协议在l2cap上层,使用sbc压缩并使用acl异步数据包传输,可以支持cd级别的音频流.但是wince5并不支持a2dp,wince6才有.上面2种都是透过hci层来传送音频流,这意味着还要受到hci总线带宽的限制.hci接口常见的有uart,spi,usb.为了突破这个限制,有一些设备会使用独立的pcm总线来传音频流.比如csr的芯片就有独立的pcm总线.我们的设计中,将蓝牙芯片的pcm接到了音频芯片的pcm,这提供了最大的灵活性.

如果你想实现headset,那么就要使用AG(audio gateway)服务btagsvc.dll,并且创建一个蓝牙音频驱动btscosnd.dll.在你的应用中使用DeviceIoControl发送IOCTL_AG_OPEN_AUDIOAG服务,继而,AG服务会建立sco连接并使用waveOutMessage()发送WODM_BT_SCO_AUDIO_CONTROL给蓝牙音频驱动.蓝牙音频驱动于是建立了对hci层的连接,透过参数告知hci要处理的是sco数据,最后创建了一个线程处理sco的事件.

这个过程不会很顺利,一般会遇到一些问题.尤其是自己板上已经有另外一个音频设备的时候.google中搜索你会体会到很多人在解决这个坎坷的问题.哪些问题呢?假设板载的音频设备是device0,在透过wave api来使用驱动时候,希望使用device1,却无法成功.这个问题是微软造成的.上面提到AG会使用waveOutMessage发消息给音频驱动,waveOutMessage的发送对象竟然是固定的0.也就是device0.所以这限制蓝牙音频驱动必须是device0.如何决定谁成为device0?并不是注册表中的Index,那只是决定了WAV0还是WAV1.答案是order.因此,本质就是,第一个被加载的音频驱动才是device0.

通过以上方法,成功在wince5上实现了蓝牙headset profile.但是音质的确不很满意.







什么是“profiles”:已经被标准化的services被称为 “profiles”;例如:FTP,DUN,A2DP等。每一种service由唯一的GUID所标识;标准化的services 就是蓝牙的profiles protocols。用户可以按照需要扩展自己的services



The profiles have been developed in order to describe how implementations of user models are to be accomplished. The user models describe a number of user scenarios where Bluetooth performs the radio transmission. A profile can be described as a vertical slice through the protocol stack. It defines options in each protocol that are mandatory for the profile. It also defines parameter ranges for each protocol. The profile concept is used to decrease the risk of interoperability problems between different manufacturers' products. 

Bluetooth Profile Dependencies:

 The Bluetooth profile structure and the dependencies of the profiles are depicted above. A profile is dependent upon another profile if it re-uses parts of that profile, by implicitly or explicitly referencing it. Dependency is illustrated in the figure: a profile has dependencies on the profile(s) in which it is contained ?directly and indirectly. For example, the Object Push profile is dependent on Generic Object Exchange, Serial Port, and Generic Access profiles

By using various protocols and profiles, Bluetooth can be implemented to perform the following tasks:

  • Connect to a modem through a cellular phone.
  • Connect to a local area network (LAN) access point.
  • Connect to a personal area network (PAN).
  • Connect to a wireless keyboard or mouse.
  • Connect to a wireless headset or a hands-free device.

OS Design Information

The following table shows the operating system design information for Bluetooth.

Concept Description
Dependencies None.
Hardware considerations Bluetooth interface (USB, UART, BCSP, SDIO, SC, and Ambicom).

The following table shows the components and modules that implement the Bluetooth technology in Windows CE.

Item Module Component
Libraries btd hci, l2cap, sdp, rfcomm, portemu, tdi, sys, univ, btpan
  btdrt sdpuser, bthns
Transport drivers btsdio, bthusb, bthamb, bthuart, bthsc, bthcsr, bthuniv
Bluetooth serial drivers sio950, wendyser, wcestreambt None.
Bluetooth Gateway Configuration Utility btgw and btconfig if the OS design includes the Web Server (HTTPD) None.
Bluetooth profiles btagsvc, btmodem, bthhid bthidsvc, hidparse, kbdhid, conshid



0755-29739852 13242922466

13728690655 QQ:923920247



zoom of kinect 物联网解决方案 U盘电子称方案 单片机读写U盘 体感放大器单片机读写SD卡

蓝牙4.0模块 无线门铃 门铃 不用电池的无线门铃Copyright © 深圳蓝色飞舞科技有限责任公司 All Right Reserved