蓝牙对象交换协议(OBEX) - 概念介绍

 零.声明

本专栏文章我们会以连载的方式持续更新,本专栏计划更新内容如下:

第一篇:蓝牙综合介绍 ,主要介绍蓝牙的一些概念,产生背景,发展轨迹,市面蓝牙介绍,以及蓝牙开发板介绍。

第二篇: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)

Null0x00)结尾的的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版本
时间戳。4Byte版本(用于兼容)

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来决定的长度。后续在上层协议我们就能看到应用!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Wireless_Link

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值