传统蓝牙RFCOMM多路控制帧(MULTIPLEXOR FRAMES)介绍

零. 概述

本文章主要讲下蓝牙RFCOMM协议多路控制通道(MULTIPLEXOR FRAMES),包括一下几种

• PN—DLC parameter negotiation.

• Test—Checks communication link.

• FCon / FCoff—Aggregate flow control on all connections.

• MSC—Modem status, used for flow control per connection.

• RPN—Remote Port Negotiation.

• RLS—Remote Line Status.

• NSC—Non-Supported Command (response only).

一. 声明

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

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

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

-------------------------------------------------------------------------------------------------------------------------

CSDN学院链接(进入选择你想要学习的课程):https://edu.csdn.net/lecturer/5352?spm=1002.2001.3001.4144

蓝牙交流扣扣群:970324688

Github代码:https://github.com/sj15712795029/bluetooth_stack

入手开发板:https://item.taobao.com/item.htm?spm=a1z10.1-c-s.w4004-22329603896.18.5aeb41f973iStr&id=622836061708

蓝牙学习目录https://blog.csdn.net/XiaoXiaoPengBo/article/details/107727900

--------------------------------------------------------------------------------------------------------------------------

二. 多路控制帧(MULTIPLEXOR FRAMES)

多路控制通道主要在DLCI=0发送的,主要用来控制RFCOMM的连接,来协商一些参数,主要有以下类型:

• PN—DLC parameter negotiation.

• Test—Checks communication link.

• FCon / FCoff—Aggregate flow control on all connections.

• MSC—Modem status, used for flow control per connection.

• RPN—Remote Port Negotiation.

• RLS—Remote Line Status.

• NSC—Non-Supported Command (response only).

主要基于UIH control frame来发送,多路控制的数据格式如下,红框为多路控制帧的格式

Type参数格式如下图所示:

当EA为1时表示这是最后一个字节,当为0时则表示有扩展的字节表述,如下图:

T位代表类型编码下面我们就来一一说下每个command。

2.1 PN—DLC Parameter Negotiation

在 DLC 建立之前,要用 PN 进行参数协商,整个PN的封包格式如下:

Length一直为8

后续的value格式如下:

其中D1~D6是DLCI

I1~I4定义了在指定 DLC 上传输信息帧的类型,如下,但是我们此部分只选择UIH帧

CL 1~4位定义了在指定 DLCI 上的汇聚层类型,如下表所示:

P1~P6位表示在指定 DLC 上所分配的优先级,范围从 0 到 63,0 的优先级最高:

T 位表示 acknowledgement timer (T1)的值

N 位表示 maximum frame size (N1)的值。

NA-位表示 maximum number of retransmissions (N2)

K 位表示纠错模式下窗口大小

来一个sample后续的value如下:

2 .2 Test Command (Test)

测试命令,类型代码是 000100,长度字节为 0,后面没有参数。

2.3 Flow Control On Command (FCon)

流控开启命令,类型代码为 000101,长度字节为 0,后面没有参数

2.4 Flow Control Off Command (FCoff)

流控关闭命令,类型代码为 000110,长度字节为 0,后面没有参数

2.3/2.4的命令都没有参数,格式如下:

2.5 Modem Status Command (MSC)

用 MSC 命令来传输 V.24 控制信号,它在基本选项下面使用。MSC 命令包含一个 mandatory control signal(强制的控制信号)字节和一个 break signal(暂停信号)字节。在建立了 DLC 之后,发送用户数据之前,发送 MSC 命令。

参数有address以及V.24,address已经在前面介绍,我们来看下V.24的格式

EA:扩展位,功能如前所述。

FC:flow control,当设备不能接受帧数据的时候,设定为 1。

RTC:ready to communicate,当设备准备好通信时,把这位设定为 1。

RTR:ready to receive,设备准备好接收数据时,设定为 1。

IC:incoming call indicator,当有呼入时,设定为 1。

DV:data valid,发送了合法数据,设定为 1。

其他位保留。我们来看个btsnoop截图:

2.6 Non Supported Command Response (NSC)

当接收实体接收到了一个不支持的命令类型时,对发方发送 NSC。其类型代码为 001000,当只有一个不支持的命令类型时,长度字节为 1,后面的参数是代表不支持的命令类型的代码,其格式为:

2.7 Remote Port Negotiation Command (RPN)

我们来贴下

在来贴下从Baud rate的结构:

B1-B7 代表的是波特率,其具体含义见下表:

D1-D2 表示数据位的长度。 00 表示 5bit,01 表示 6bit,10 表示 7bit,11 表示 8bit。

S 表示停止位

P 表示校验,P=0 有校验,P=0 无校验

PT1-PT2 表示校验类型

FLC1-FLC6 D 默认值为 0, 没有流控制

Bit1 XON/XOFF on input

Bit2 XON/XOFF on output

Bit3 RTR on input

Bit4 RTR on output

Bit5 RTC on input

Bit6 RTC on output

XON1-XON8 XON character (default DC1)

XOF1-XOF8 XOFF character.(default DC3)

PM1-PM8 parameter mask

用parameter mask来表示对方的哪个参数需要进行协商。如果是命令, parameter

mask用0表示不改变,1表示要改变。如果是应答,0表示不接受建议值,1表示接

受并并使用建议值

第 7、8 个字节的 bit mask 表示

Bit1 bit rate

Bit2 data bits

Bit3 stop bits

Bit4 Parity

Bit5 parity type

Bit6 XON character

Bit7 XOF character

Bit8 reserved

PM9-PM18: Parameter mask continued

Bit1 XON/XOFF on input

Bit2 XON/XOFF on output

Bit3 RTR on input

Bit4 RTR on output

Bit5 RTC on input

Bit6 RTC on output

所有的参数默认为 0,接收方接到后对此忽略。

Mask整理如下

2.8 Remote Line Status Command (RLS)

类型代码为 001010,长度字节的值为 2,有两个参数。第一个参数为 DCLI的值,具体格式跟一般的 DCLI 格式一样。第二个参数的格式入下表所示:

L1-L4 表示链路状态,如果 L1 为 0,则表示没有错误发生,若 L1=1,则表示发生了错误

如下:

• 0b1100—Overrun error, a received character has overwritten a character which had

not yet been read.

• 0b1010—Parity error, the parity was wrong on a received character.

• 0b1001—Framing error, a character did not end with a stop bit.

  • 4
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

Wireless_Link

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

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

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

打赏作者

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

抵扣说明:

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

余额充值