蓝牙开发蓝牙模块蓝牙4.0 WiFi PB375A 蓝牙模块远距离工业医疗串口

深圳蓝色飞舞科技提供蓝牙模块整套解决方案，更多技术支持请与我们联系。

此处讲述的是蓝牙HCI相关的部分，并不是特指某个具体的蓝牙协议栈，只是对蓝牙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.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事件通知与具体使用什么样的传输层无关）.

（2）HCI 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.

（3）HCI 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.

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.

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.

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.

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.

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:

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

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.

之前没有摸过蓝牙,这回的项目里面有蓝牙模块.而我目前对蓝牙只知道的有: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,USB和sdio等pnp设备,如果没有就根据注册表取默认的设备接口.最后被选定的接口会被安排到这里[HKEY_LOCAL_MACHINE\Software\Microsoft\Bluetooth\HCI]

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

刚才说到如果没有扫描到pnp的蓝牙设备就使用默认的,这个默认的接口在哪里?其实也是根据注册表来找接口,看看下面的内容吧:1代表优先级别.name=COM2,baud=1c200,这很明显,就是以115200的波特率打开COM2口了.

对于HCI接口,它向上提供了一个访问底层硬件的统一接口.比如提供给l2cap.其实不用关心HCI内部怎么实现的,只要懂得怎么使用就可以,更进一步,如果所有应用都是在l2cap上的,连HCI接口也没有必要知道.比如我们的应用只是基于winsock,rfcomm,或者obex,这些都是l2cap的上层,就不要关心HCI的上层接口.它是透明的,当它不存在好了.

如果好奇HCI的上层(比如l2cap)如何使用hci接口?其实是使用HCI_EstablishDeviceContext()这个函数来获得接口,并注册相关回调函数和事件响应函数.这些模块源代码都在WINCE500\PRIVATE\WINCEOS\COMM\BLUETOOTH\目录里面.

对于一些特殊的应用,比如你有一些蓝牙耳机这样的应用,就不是通过l2cap了,那么就要从hci层扩展.还是使用同样的接口方法,只是参数不同了.耳机这样的应用是要处理的是同步的连接SCO数据包,于是透过参数告知hci,将sco数据发给自己来处理.具体来说就是第2个参数BTH_CONTROL_ROUTE_BY_LINKTYPE,第5个参数BT_LINK_TYPE_SCO,以次来调用HCI_EstablishDeviceContext().

三:协议层.这一层包括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标准的子集.没有听过这个标准.反正,这个模块的作用是使得上层就像操作串口一样使用蓝牙.

蓝牙协议栈的实体究竟在哪里?WinCE实现了2个动态链接库来实现,一个是btd.dll另外一个是btdrt.dll，由device.exe加载。btd.dll包含了协议栈各个层，而btdrt.dll提供了一组api来访问各个层.btdrt.dll其实是一个runtime库。

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

蓝牙耳机功能,也就是bluetooth headset /headfree profile,实现起来比想象的复杂.早期的蓝牙规范只定义了headset的profile, 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_AUDIO给AG服务,继而,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。

定义Profiles的目的就是定义一些标准规则，这些规则指导具体的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:

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	None.
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

蓝牙开发资料