蓝牙相关

1. 前言

自1994年由爱立信推出至今，蓝牙技术已经走过了20个岁月。从最初的Bluetooth V1.0，到Bluetooth V4.0（最新的为V4.1，2013年底发布），经历了近9个版本的修订后，发展为当前的状况。

说实话，如今的蓝牙4.1，简直是一个大杂烩：BR/EDR沿用旧的蓝牙规范；LE抄袭802.15.4；AMP直接使用802.11。而这一切的目的，就是以兼容性和易用性为基础，在功耗和传输速率之间左右为难。蜗蜗以为，这并不是优雅的设计。

不过没关系，存在即合理。因此蜗蜗就开出了这样一个专题，希望能够将蓝牙技术上上下下的知识，整理出来，以便在加深自己对蓝牙技术的理解的同时，能够给从事蓝牙相关工作的读者一点启发。

本文是这个专题的第一篇文章，主要基于蓝牙4.1规范（Core_V4.1.pdf），描述蓝牙技术的基本概念。

2. 蓝牙技术的概述

2.1 两种蓝牙技术：Basic Rate（BR）和Low Energy（LE）

蓝牙协议包括两种技术：Basic Rate（简称BR）和Low Energy（简称LE）。这两种技术，都包括搜索（discovery）管理、连接（connection）管理等机制，但它们是不能互通的！这也是蜗蜗抱怨蓝牙协议不优雅的原因之一。

厂商要么实现这两种技术中的一种，这时就只能和同样实现了这个技术的设备互通，而不能和实现另外一种技术的设备互通。如果厂商要确保能和所有的蓝牙设备互通，那么就只能同时实现两种技术，而不去管是否真的需要，这样就能碰到什么人说什么话了！

2.1.1 Basic Rate(BR)

Basic Rate是正宗的蓝牙技术，可以包括可选（optional）的EDR（Enhanced Data Rate）技术，以及交替使用的（Alternate）的MAC（Media Access Control）层和PHY层扩展（简称AMP）。说着真拗口，不过通过背后的应用场景，就好理解了：

蓝牙诞生之初，使用的是BR技术，此时蓝牙的理论传输速率，只能达到721.2Kbps。在那个年代，56Kbps的Modem就是高大上了，这个速度可以说是惊为天人了啊！但是科技变化太快了，BR技术转眼就过时了。那怎么办呢？缝缝补补一下，增强速度呗，Enhanced Data Rate就出现了。

使用EDR技术的蓝牙，理论速率可以达到2.1Mbps。这一次的升级换代，还算优雅，因为没有改变任何的硬件架构、软件架构和使用方式上的改变。

也许你也猜到了，EDR又落伍了，看看人家WIFI（WLAN），几十Mbps，上百Mbps，咱们才2.1Mbps，也太寒酸了吧！那怎么办呢？蓝牙组织想了个坏主意：哎，WIFI！把你的物理层和MAC层借我用用呗！这就是AMP（Alternate MAC and PHY layer extension）。艾玛，终于松口气了，我们可以达到24Mbps了。

不过呢，由于蓝牙自身的物理层和AMP技术差异太明显了，这次扩展只能是交替使用（Alternate）的，也就是说，有我（BR/EDR）没你（AMP）。嗯！不优雅！

埋个问题：只能交替使用，那它们怎么切换呢？蜗蜗会在后续的内容中，根据主流蓝牙芯片的解决方案，来探讨一下该问题。

【注1：细心的读者可能会注意到，这里特别强调了optional和alternate这两个字眼，这是蓝牙Spec的原话。它意味着，BR和EDR是可以同时存在的，但BR/EDR和AMP只能二选一。】

2.1.2 Low Energy（LE）

上面所讲的BR技术的进化路线，就是传输速率的加快、加快、再加快。但能量是守恒的，你想传的更快，代价就是消耗更多的能量。而有很多的应用场景，并不关心传输速率，反而非常关心功耗。这就是Bluetooth LE（称作蓝牙低功耗）产生的背景。

LE技术相比BR技术，差异非常大，或者说就是两种不同的技术，凑巧都加一个“蓝牙”的前缀而已。后面我们会详细的解释这种差异，以及LE的行为特征。

2.2 蓝牙系统的组成

蓝牙系统的组成，涉及到Bluetooth Application、Bluetooth Core、Bluetooth Host、Bluetooth Controller等词汇，不知道是因为对英文理解的歧义，还是因为蓝牙规范本身定义的歧义，蜗蜗理解这些词汇时感觉有点别扭。因此特意在这个章节中，对相关概念及其背后的意义进行说明。

蓝牙系统组成上图描述了蓝牙系统的组成， 我们需要注意如下特点：

1）图中所描述的蓝牙系统的组成部分，如Bluetooth Core和Bluetooth Application，如Host和Controller，都是指“逻辑实体”。所谓的“逻辑实体”，需要和日常生活中的“物理实体”区隔开。如在做电路设计时，一个蓝牙芯片、一个主控CPU，就是指物理实体。而蓝牙协议所描述的这些“逻辑实体”，不一定会和物理实体一一对应，如在实际应用中，Host和Bluetooth Application可能会位于同一个物理实体中（主控CPU），而Controller单独位于另一个物理实体中（蓝牙芯片）。

2）蓝牙协议规定了两个层次的协议，分别为蓝牙核心协议（Bluetooth Core）和蓝牙应用层协议（Bluetooth Application）。蓝牙核心协议关注对蓝牙核心技术的描述和规范，它只提供基础的机制，并不关心如何使用这些机制；蓝牙应用层协议，是在蓝牙核心协议的基础上，根据具体的应用需求，百花齐放，定义出各种各样的策略，如FTP、文件传输、局域网等等。

3）Bluetooth Core由两部分组成，Host和Controller。这两部分在不同的蓝牙技术中（BR/EDR、AMP、LE），承担角色略有不同，但大致的功能是相同的。Controller负责定义RF、Baseband等偏硬件的规范，并在这之上抽象出用于通信的逻辑链路（Logical Link）；Host负责在逻辑链路的基础上，进行更为友好的封装，这样就可以屏蔽掉蓝牙技术的细节，让Bluetooth Application更为方便的使用。

4）在一个系统中，Host只有一个，但Controller可以一个，也可以有多个。如：单独的LE Controller；单独的BR/EDR Controller；单独的LE+BR/EDR Controller；在单独的BR/EDR Controller或LE+BR/EDR Controller基础上，增加一个或多个额外的AMP Controller。

【注2：有关Bluetooth Core的详细描述，蜗蜗会在下一篇文章中描述，本文就不再深入介绍了。】

3. BR/EDR vs LE vs AMP

我们先从下面图片对BR/EDR、AMP和BLE三种技术有些更进一步的认识（点击这里可以查看放大后的原图）：

BT_RF_Baseband_Overview.gif

 

该图片是对Bluetooth Core的一个Overview，从RF的Physical Channel，到Baseband的Physical Link、Logical Link、LMP、L2CAP等概念，都有一些粗略的介绍。由该图片可以看出，BR/EDR、AMP、BLE等技术有如下的特点：

1）BR/EDR技术，过于侧重“点对点”通信，以至于虽然在协议的底层（如Logical Link）有提及多播（Unidirectional）和广播（Broadcast）的概念，但在上层的应用场景中，几乎不存在（也不可能存在）相应的应用。

2）但随着物联网的发展，业界对简单的、不需要连接的多播或广播通信的需求越来越迫切，因此BLE技术在RF和Baseband的协议中，就做出了修改，以适应这种需求，即：修改原有的79个channel的跳频方式，将channel的个数减少为40个，并保留了不少于3个的固定channel，用于广播通信。为仅仅在剩下的37个data channel上跳频。

3）正因为这种改变，原有的搜索/连接/配对等概念，在BLE上就不再存在了，取而代之的是Advertisor、Initialor等概念。但在之后的数据通信的层次上，尽量保持了一致。

4）对于AMP来说，是基于BR/EDR的controller，在完成通常的点对点连接之后，两个蓝牙设备商议，是否需要将后续的数据通信，转移至AMP controller上。这就是Bluetooth 3.0引入的AMP技术。

我们暂时在这篇文章中对蓝牙技术做一个感性认识，在后续的文章中，会基于各个层次的协议，一步一步展开、推进，争取能把蓝牙技术分析透彻。

 

 

 

蓝牙Host Controller Interface笔记

http://blog.sina.com.cn/s/blog_69b5d2a50101eikk.html


1.概述
HCI提供了一个统一的使用蓝牙控制器（BR/EDR Controller，BR/EDR/LE Controller，LE Controller，AMP Controller等）的方法，它屏蔽了蓝牙的基带部分，提供了统一的数据进入基带的方法。
首先，蓝牙的BaseBand部分有以下几种控制器：
• BR/EDR Controller
• BR/EDR/LE Controller
• LE Controller
• AMP Controller
前三种称为primary Controller，AMP是蓝牙3.0后加上的，支持High Speed传输。
 
下图为简单的架构：
蓝牙Host <wbr>Controller <wbr>Interface笔记
两个设备间数据的流向如下图：


2.COMMANDS AND EVENTS
通过HCI接口，Host与controller通过Command和Event的形式进行通信，其中command是Host传给controller的，Event是controller反馈给Host的，如下图所示：

Command和Event根据不同的类型进行了以下分组，具有以下几种：
蓝牙Host <wbr>Controller <wbr>Interface笔记
每一组内有一个或者对个Command和Event，举例如下：



可以看出，Generic event组内有三种Event，Device SetUp组内只有一种reset Command。Command和Event的种类很多，这里不具体介绍，参考Spec704-1000的具体说明。
 
3.HCI Data Format
由上可知，HCI有三种数据，Command、Event和Data，这三种类型的HCI Data分别有不同的格式。需要注意的是，HCI Data都是Little Endian formats的，负数的存储形式为2进制补码。
在Host和Controller之间由HANDLES来识别不同的通道，一共有三种：
• Connection Handles
• Logical Link Handles
• Physical Link Handles
其中，Connection Handles用于primary controller(除AMP外），另外两用用于AMP Controller。一旦一条Logical Link建立，primary controller会给Host分配一个Connection Handle。
下面分别是Command packet、Event Packet和Data packet,其中Data Packet分为HCI ACL Data Packet和HCI Synchronous Data Packet，HCI ACL Data Packet有Automatically-Flushable和Non-Automatically-Flushable两种类型。具体说明如下：
 
(1) HCI Command packet
蓝牙Host <wbr>Controller <wbr>Interface笔记
OpCode Field分为两个Field：OCF和OGF：
OGF Range (6 bits): 0x00-0x3F (0x3F reserved for vendor-specific debug commands)
OCF Range (10 bits): 0x0000-0x03FF
 
(2) HCI ACL Data Packet
蓝牙Host <wbr>Controller <wbr>Interface笔记
参数HANDLE的定义如下：
蓝牙Host <wbr>Controller <wbr>Interface笔记
参数PB的定义如下：
蓝牙Host <wbr>Controller <wbr>Interface笔记
参数Broadcast_Flag的定义如下：
蓝牙Host <wbr>Controller <wbr>Interface笔记

蓝牙Host <wbr>Controller <wbr>Interface笔记

（3）HCI Synchronous Data Packets
蓝牙Host <wbr>Controller <wbr>Interface笔记
Packet_Status_Flag参数定义如下：
蓝牙Host <wbr>Controller <wbr>Interface笔记

（4）HCI Event Packet
蓝牙Host <wbr>Controller <wbr>Interface笔记
注意,LE控制器使用的是sub-event Code。
4.HCI Configuration parameters
主要用来对HCI连接进行一些必要的配置，种类比较多，参考Spec681-703。
 
5.常见的Command和Event
(1) Link Control commands(OGF = 0x01)，用来进行连接。
该组包含Inquiry Command等44个Command，具体参考Spec。
(2)LINK POLICY COMMANDS（OGF = 0x02），对连接进行配置，如park、sniff、Roll Switch等
该组包含14个command
(3)CONTROLLER & BASEBAND COMMANDS（OGF = 0x03），改变本地Controller的行为。
该组包含Set Event Mask Command等79个command
(4)INFORMATIONAL PARAMETERS（OGF = 0x04），用来读取本地的设备商的控制器、LM等的信息，这些信息无法改变。
该组包含Read Local Version Information Command等7个command。
(5)STATUS PARAMETERS（OGF = 0x05），状态参数是由controller来修改的，Host可以通过一些特定的参数来进行修改。
该组包含Read Failed Contact Counter Command等10个Command。
(6)TESTING COMMANDS（OGF = 0x06），对Host提供对蓝牙硬件的测试用的。
该组包括Read Loopback Mode Command等7个Command。
(7)LE CONTROLLER COMMANDS（OGF = 0x07），Host通过这些命令来影响LE的工作。
该组包括LE Set Event Mask Command等30个Command。
常见的Event：
包括Inquiry Complete Event等65种Event。

 

蓝牙配置文件

https://en.wikipedia.org/wiki/Bluetooth_profile#Health_Device_Profile_.28HDP.29

蓝牙协议栈 bluethooth stack 

https://en.wikipedia.org/wiki/Bluetooth_stack

1.通用型 如 linux bluez

Linux bluez 支持的profile

http://www.bluez.org/profiles/

Supported Profiles

Lower level Host Stack

  • Core specification 4.2. Not (yet) 3.0+HS. Includes GAP, L2CAP, RFCOMM and SDP.

Profiles

Provided by BlueZ:

  • A2DP 1.3
  • AVRCP 1.5
  • DI 1.3
  • HDP 1.0
  • HID 1.0
  • PAN 1.0
  • SPP 1.1

GATT (LE) profiles:

  • PXP 1.0
  • HTP 1.0
  • HoG 1.0
  • TIP 1.0
  • CSCP 1.0

OBEX based profiles (by obexd):

  • FTP 1.1
  • OPP 1.1
  • PBAP 1.1
  • MAP 1.0

Provided by the oFono project:

  • HFP 1.6 (AG & HF)

2. 嵌入式协议栈

1. BlueCode+  Stollmann 图斯曼 支持HDP

http://www.stollmann.com.cn/_d275492581.htm

2. Dotstack  支持HDP

http://searanllc.com/

dotstack, a Bluetooth stack by SEARAN, is a good fit for low cost and low power embedded devices, tested with iPhone (uses SEARAN’s IAP), Android and other mobile platforms. dotstack™ is qualified as V2.1 + EDR, V4.0 with SPP, GAP, HID, Headset, HFP, FTP, HDP, PBAP, Simple Secure Pairing, A2DP, AVRCP, BLE (GATT), Heart Rate profile. dotstack is ported to platforms from TI (MSP430, C5000 etc.), Microchip (PIC24, dsPIC, PIC32), Renesas (RX, SH-2A), NXP (LPC), Energy Micro (EFM32), ST Micro (STM32L, STM32F2, STM32F4) and tested with Bluetooth RF controllers, CSR BlueCore 4 & 6, TI CC2560/2564, Intel/Infineon PMB8753, Marvell Avastar 88W8790. dotstack has FreeRTOS and no RTOS integration. Min RAM requirement for SPP 3KB with RTOS and app.[17]

3. OpenSynergy 的Blue SDK 支持HDP

http://www.opensynergy.com/produkte/blue-sdk/

专注于嵌入式汽车系统开发 ，BlueSDK 也是双模

芯片厂商提供的stack

IT 

  • SimpleLink 低功耗蓝牙 CC2541 和 CC2543 无线 MCU 通过 TI 的 BLE-Stack 获得支持。
  • SimpleLink Bluetooth双模 CC2564 和 WiLink 8 组合型连接解决方案由 Stonestreet One 公司的 Bluetopia 堆栈提供支持。
  • 面向汽车应用的 WiLink 8Q 和 BL6450Q 解决方案由 Cybercom blueGO 和 OpenSynergy Blue SDK 堆栈共同给予支持。

microchip 使用dotstack ，只有BLE单模模块 ，支持常用的基于GATT的协议

http://www.microchip.com/pagehandler/zh-cn/technology/bluetooth/thirdparty/dotstack.html

RN4042模块

CSR

自己的 称为"CSR Synergy" ,但不包含 HDP

Nordic  

实现了基于GATT的 Heart Rate Profile (HRP) , Heart Rate Service (HRS)

参见 https://developer.bluetooth.org/TechnologyOverview/Pages/HRS.aspx

Stollmann 的BlueMod+S 就是采用了Nordic的nRF51822 （M0)，但采用了Terminal I/O Profile  类似SPP 模拟终端操作

Dialog 的DA14581 （M0 号称能跑到96 MHz），2015-4-7 推出，最小的芯片2.5mm X 2.5mm ，还带无线充电功能 ，支持标准profile  

http://www.dialog-semiconductor.com/products/bluetooth-smart/smartbond-da14581 

 

昆天科 -被NXP 收购了

http://www.cn.nxp.com/products/microcontrollers/product_series/qn902x/#products

 

iDevice的模块 ，尺寸6.5mmX6.5mm  上层协议是否实现未知

该模块基于broadcom

http://idevicesinc.com/module/

 

常见的prefile

https://developer.bluetooth.org/TechnologyOverview/Pages/Profiles.aspx#Protocols

Headset Profile (HSP)

This is the most commonly used profile, providing support for the popular Bluetooth headsets to be used with mobile phones. It relies on SCO for audio encoded in 64 kbit/s CVSD or PCM and a subset of AT commands from GSM 07.07 for minimal controls including the ability to ring, answer a call, hang up and adjust the volume

Serial Port Profile (SPP)

This profile is based on ETSI 07.10 and the RFCOMM protocol. It emulates a serial cable to provide a simple substitute for existing RS-232, including the familiar control signals. It is the basis for DUN, FAX, HSP and AVRCP. SPP maximum payload capacity is 128 bytes.

 

Attribute Profile (ATT)

The ATT is a wire application protocol for Bluetooth Low Energy specification. It is closely related to Generic Attribute Profile (GATT).

 

Health Device Profile (HDP)

Health Thermometer profile (HTP) and Heart Rate Profile (HRP) fall under this category as well.

Profile designed to facilitate transmission and reception of Medical Device data. The APIs of this layer interact with the lower level Multi-Channel Adaptation Protocol (MCAP layer), but also perform SDP behavior to connect to remote HDP devices. Also makes use of the Device ID Profile (DIP).

https://developer.bluetooth.org/TechnologyOverview/Pages/HDP.aspx

这个是基于BR/EDR 的 ，要想使用该协议，device需要使用双模芯片  ，要基于GATT使用BLE的话 ，需要使用BLP协议 参考https://developer.bluetooth.org/TechnologyOverview/Pages/BLP.aspx

Human Interface Device Profile (HID)

Provides support for devices such as mice, joysticks, keyboards, as well as sometimes providing support for simple buttons and indicators on other types of devices. It is designed to provide a low latency link, with low power requirements. PlayStation 3 controllers and Wii remotes also use Bluetooth HID.

Bluetooth HID is a lightweight wrapper of the human interface device protocol defined for USB. The use of the HID protocol simplifies host implementation (ex: support by operating systems) by enabling the re-use of some of the existing support for USB HID to also support Bluetooth HID.

Keyboard and keypads must be secure. For other HIDs security is optional.[6]

A2DP 

A2DP全名是Advanced Audio Distribution Profile 蓝牙音频传输模型协定! A2DP是能够采用耳机内的芯片来堆栈数据，达到声音的高清晰度。有A2DP的耳机就是蓝牙立体声耳机。声音能达到44.1kh，一般的耳机只能达到8kb。如果手机支持蓝牙，只要装载A2DP协议，就能使用A2DP耳机了。还有消费者看到技术参数提到蓝牙V1.0 V1.1 V1.2 V2.0——这些是指蓝牙的技术版本，是指通过蓝牙传输的速度，他们都是支持A2DP具体要看蓝牙产品制造商是否使用这个技术。
　　
A2DP定义了ACL(Asynchronous Connectionless 异步无连接)信道上传送单声道或立体声等高质量音频信息的协议和过程.
　　A2DP取决于GAP(Generic Access Profile 通用接入协议)和GAVDP(Generic Audio /Video Distribution Profile 通用音视频分布协议).后者定义音频,视频流等建立所需要的过程.A2DP则定义建立音视频流所需要的参数和流程.

FTP（File Transfer Protocol），是文件传输协议的简称。用于Internet上的控制文件的双向传输。同时，它也是一个应用程序（Application）。用户可以通过它把自己的PC机与世界各地所有运行FTP协议的服务器相连，访问服务器上的大量程序和信息


 

posted @ 2015-07-06 14:18  fastwave2004  阅读(973)  评论(0)  编辑  收藏  举报