零.声明
本专栏文章我们会以连载的方式持续更新,本专栏计划更新内容如下:
第一篇:蓝牙综合介绍 ,主要介绍蓝牙的一些概念,产生背景,发展轨迹,市面蓝牙介绍,以及蓝牙开发板介绍。
第二篇:Transport层介绍,主要介绍蓝牙协议栈跟蓝牙芯片之前的硬件传输协议,比如基于UART的H4,H5,BCSP,基于USB的H2等
第三篇:传统蓝牙controller介绍,主要介绍传统蓝牙芯片的介绍,包括射频层(RF),基带层(baseband),链路管理层(LMP)等
第四篇:传统蓝牙host介绍,主要介绍传统蓝牙的协议栈,比如HCI,L2CAP,SDP,RFCOMM,HFP,SPP,HID,AVDTP,AVCTP,A2DP,AVRCP,OBEX,PBAP,MAP等等一系列的协议吧。
第五篇:低功耗蓝牙controller介绍,主要介绍低功耗蓝牙芯片,包括物理层(PHY),链路层(LL)
第六篇:低功耗蓝牙host介绍,低功耗蓝牙协议栈的介绍,包括HCI,L2CAP,ATT,GATT,SM等
第七篇:蓝牙芯片介绍,主要介绍一些蓝牙芯片的初始化流程,基于HCI vendor command的扩展
第八篇:附录,主要介绍以上常用名词的介绍以及一些特殊流程的介绍等。
另外,开发板如下所示,对于想学习蓝牙协议栈的最好人手一套。以便更好的学习蓝牙协议栈,相信我,学完这一套视频你将拥有修改任何协议栈的能力(比如Linux下的bluez,Android下的bluedroid)。
-------------------------------------------------------------------------------------------------------------------------
蓝牙视频教程(跟韦东山老师合作):
https://item.taobao.com/item.htm?spm=a1z10.1-c-s.w4004-22329603896.20.5aeb41f98e267j&id=693788592796
蓝牙交流扣扣群:765961169
Github代码:GitHub - sj15712795029/bluetooth_stack: 这是一个开源的双模蓝牙协议栈(bluetooth.stack)(btstack),可以运行在STM32,Linux.,包含HCI,L2CAP,SDP,RFCOMM,HFP,SPP,A2DP,AVRCP,AVDTP,AVCTP,OBEX,PBAP等协议,后续会继续维护,以达到商用的目的
入手开发板:https://shop220811498.taobao.com/category-1542116976.htm?spm=a1z10.5-c-s.w4010-22329603913.7.39ca7dbe2EA0K3&search=y&catName=%C0%B6%D1%C0%BF%AA%B7%A2%B0%E5#bd
蓝牙学习目录:一篇文章足够你学习蓝牙技术,提供史上最全的蓝牙技术(传统蓝牙/低功耗蓝牙)文章总结,文档下载总结(2020/12/11更新)_Wireless_Link的博客-CSDN博客_蓝牙eir
--------------------------------------------------------------------------------------------------------------------------
一. OBEX概念
1. 概念
OBEX全称为Object Exchange,是对象交换协议,蓝牙的OBEX是IrOBEX的子集,其中对象是一个柔性概念,可以包括文件,诊断信息,电子商务卡片(Vcard),银行的存款,短信消息等等。Objects在这里没有高级的技术含义,而是视你的应用而定。我们来看下OBEX在整个蓝牙中的位置。
这张图是蓝牙SIG官网最新的IRDA的spec,但是这幅图片还是有欠缺的,其实OBEX应该可以走RFCOMM的,但是这张图示中并没有体现出来
2. Headers
对象模型回答了对象是如何在OBEX协议描述的。这个模型必须包括被传输的对象和对对象的描述。为了做到这点,OBEX定义了Headers的概念。
一个Header反映了对象的一个方面,例如名字、长度、描述文字或者对象本身。例如,一个文件对象demo.txt会包含它的名字,一个类型标示为“text”,长度和文件本身。
Headers的构成
Headers简单的由<Header ID>和<Header Value>组成,简称为<HI>和<HV>。
HI由一个字节组成,指出了Header包含的内容以及它的格式。HV包含了一个或者多个字节,其结构由HI所决定。
所有的Header都是可选的,取决于设备的类型和事务的种类。你可以使用所有的Header,或者一些,或者没有。ID可以使Header可解析以及与传输顺序无关,也可以使不支持的Header被忽略掉。
HI又可以分为两部分,高2位和低6位。高2位确定了HI的编码方式(见表二),低6位确定了HI的意义(见表三)。两个表都是我从IrOBEX中的表摘抄并部分翻译过来的。
HI的第8和第7位 | 意义 |
0b00(0x00) | 以Null(0x00)结尾的的Unicode文字。2个字节的无符号整数长度前缀。 |
0b01(0x40) | Byte块,2个字节的无符号整数前缀。 |
0b10(0x80) | 1Byte容量。 |
0b11(0xC0) | 4Byte容量,以高位先传输为原则。 |
HI | Header名称 | 描述 |
0xC0 | Count | 连接中用于指名对象的数量。 |
0x01 | Name | 对象的名字。一般为文件名。 |
0x42 | Type | 对象的类型。例如text,html,binary,manufacture specific |
0x44 0xC4 | Time | 时间戳。ISO 8601版本 |
0x05 | Description | 对对象的文本描述 |
0x46 | Target | 操作的目的服务名 |
0x47 | HTTP | 一个HTTP1.x头 |
0x48 | Body | 对象的一部分 |
0x49 | End of body | 对象的最后一部分 |
0x4A | Who | OBEX Application标识,用于表明是否是同一个应用。 |
0xCB | Connection ID | 用于OBEX多路连接的标识 |
0x4C | App.Parameters | 扩展的应用层请求和回复信息 |
0x4D | Auth.Challenge | Authentication digest-challenge |
0x4E | Auth.Response | Authentication digest-response |
0x4F | Object Class | 对象的OBEX对象类 |
0x10 0x2F | Reserved | 保留 |
0x30 0x3F | User defined | 用户自定义的。 |
二. OBEX请求(Request)& 响应(Response)
1. Request格式
包含1个byte的opcode,2个byte的packet length,0-N byte的data
其中opcode有以下值:
2. Response格式
包含1个byte的response code,2个byte的response length,0-N byte的response data
其中resonse code有以下值:
3. Request-Response Parameters
另外,在这里我们着重提下Application Request-Response Parameters
这个是上层应用的,基于Tag-length-value模型,其中tag id跟length都占用1个byte,value是根据length来决定的长度。后续在上层协议我们就能看到应用!