精华内容
下载资源
问答
  • 本文章主要讲下蓝牙RFCOMM协议部分流控介绍 一. 声明 本专栏文章我们会以连载的方式持续更新,本专栏计划更新内容如下: 第一篇:蓝牙综合介绍 ,主要介绍蓝牙的一些概念,产生背景,发展轨迹,市面蓝牙介绍,...

    零. 概述

    本文章主要讲下蓝牙协议栈RFCOMM协议部分流控介绍

    一. 声明

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

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

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

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

    二. RFCOMM流程介绍

    我们来介绍下一个例子,从RFCOMM signaling通道的连接到其他server channel的连接,数据交互,以及断开的流程来整个分析下,分别会包含flow以及raw data介绍,主要是达到回顾下上面说的内容,对知识点做一个巩固

    整个交互流程如下:

    主要步骤整理如下:

    1)RFCOMM对方(之所以成为对方,是因为那个箭头)来来连接signaling通道,我们回应

    2)交互PN UIH封包

    3)对方来连接server channel 9

    4)发送UIH给对方credit card

    5)交互MSC UIH封包

    6)交互UIH帧

    7)我们主动断开server channel13

    8)我们主动断开server channel13

    9)我们主动断开server channel9

    由于对方来连接signaling channel,也就是rfcomm channel0,所以对方是initiator,我方是responser.这是大前提要记住!

    另外,我们再来贴下整个rfcomm的封包结构

    其中address格式为:

    control格式为:

    Length的格式如下:

    多路控制通道的格式为:

    步骤1)RFCOMM对方来来连接signaling通道,我们回应

    ①对方来连接我们,rfcomm raw data为03 3F 01 1C(hex数据)

    03 = 0000 0011b 那么EA=1,C/R=1,也就是command,DLCI为0,也就是signaling channel

    3F = 0011 1111b ,也就是SABM,P/F为1

     

    01 = 0000 0001b,EA=1,也就是只有1个byte,也就是L1~L7标示后续封包的长度,也就是0

    1C ,FCS

    为了验证下,我们来跟btsnoop对比下

    ②我们回应对方的signaling channel的连接,rfcomm raw data为03 73 01 D7(hex数据)

    03 = 0000 0011b,那么EA=1,C/R=1,也就是command,DLCI为0,也就是signaling channel

    73 = 0111 0011,UA帧,p/f为1

     

    01 = 0000 0001b,EA=1,也就是只有1个byte,也就是L1~L7标示后续封包的长度,也就是0

    1c也就是fcs

    为了验证下,我们来跟btsnoop对比下

    步骤2)交互PN UIH封包

    ①对方发PN UIH,rfcomm raw data为03 EF 15 83 11 12 F0 00 00 FA 03 00 00 70(hex data)

    03 = 0000 0011b,那么EA=1,C/R=1,也就是command,DLCI为0,也就是signaling channel

    EF = 0111 1111b,UIH帧,P/F为1

     

    15 = 0001 0101 ,EA=1,所以只有1个byte代表长度,0001 010b代表长度,也就是10byte

    83 = 1000 0011,是多路控制的type,可以看到EA=1,C/R=1,type是PN

    11 = 0001 0001b ,EA=1,len = 0001 000,也就是8byte

    剩下的就是PN具体的格式,先列一下格式再分析raw data

    12 = 0001 0010b,也就是DLCI为01 0010b,DLCI为0x12,server channel为0x12>>1,也就是9

    F0 = 1111 0000b,也就是UIH帧,CL为0

    00 = 0000 0000b,priority为0,也就是最高优先级

    00 = 0000 0000b,T为0

    FA 03, N也就是0x3FA,也就是最大的frame size为1018byte(上层协议会用到此部分)

    00 ,NA为0

    00,K为0

    70->FCS

    我们来看下btsnoop是否跟我们分析的一样

    可以看到完全一致

    ②我们发PN UIH

    参照①所讲,都是PN分包,不做具体分析

    步骤3)对方来连接server channel 9,我们回应

    ①对方来连接server channel9,rfcomm raw data为4B 3F 01 32(hex data)

    4B = 0100 1011b,那么EA=1,C/R=1,也就是command,DLCI为0100 10,也就是0x12,由于我们前面讲了DLCI是D+server channel,initiator连接responder算法应该是DCLI=0+ server chanel<<1,所以部分就是signaling channel应该为9,D=0

    3F = 0011 1111b,P/F为1,是SABM帧

     

    01 = 0000 0001b,EA=1,也就是只有1个byte,也就是L1~L7标示后续封包的长度,也就是0

    32也就是fcs

    我们来看下btsnoop

    ②我们回应对方的连接,rfcomm raw data为4B 73 01 F9(hex data)

    4B = 0100 1011b,那么EA=1,C/R=1,也就是command,DLCI为0100 10,也就是0x12,server channel为9

    73 = 0111 0011b,P/F=1,UA帧

     

    01 = 0000 0001b,EA=1,也就是只有1个byte,也就是L1~L7标示后续封包的长度,也就是0

    F9也就是fcs

    我们来看下btsnoop

    步骤4)发送UIH给对方credit card

    在这里又回牵扯到一个知识点,credit,如果UIH是在signaling通道发送,并且P/F=0那么就会普通的user数据,如果P/F=1,那么就是给对方credit,credit给对方10,那么在我们不补充的情况下,对方只能发送10包rfcomm数据,同样道理,对方也会给我们credit

    Raw data为49 FF 01 07 08(hex数据)

    49 = 0100 1001b,那么EA=1,C/R=0,也就是response,DLCI为0100 10,也就是0x12,server channel为9

    FF = 1111 1111b,P/F=1,UIH帧,也就是给对方补充credit card

     

    01 = 0000 0001b,EA=1,也就是只有1个byte,也就是L1~L7标示后续封包的长度,也就是0

    07 也就是给对方补充7个credit

    08也就是fcs

    Btsnoop如图

    可以看到给对方补充了7个credit

    另外,raw data解析如图:

    步骤5)交互MSC UIH封包

    ①我方发送MSC封包,rfcomm raw data为01 EF 09 E3 05 4B 8D AA(hex data)

    01 = 0000 0001b,那么EA=1,C/R=0,DLCI为0

    EF = 1110 1111b,P/F=0,为UIH帧类型

     

    09 = 0000 1001b,EA=1,length为0000 100b也就是只有4个byte

    E3 = 1110 0011b,也就是MSC帧

    05 = 0000 0101b,EA=1,length为0000 010b,也就是2个byte

    4B = 0100 1011b,EA=1 CR=1,D=0,server channel=9

    8D = 1000 1101b,此部分为V.24的格式,如图

    可以对比看到EA=1,FC=0,RTC=1,RTR=1 IC=0,DV=1

    截个btsnoop看下

    ②对方回复MSC UIH

    此部分不再做raw data说明,一样的分析流程

    步骤6)交互UIH帧

    前面已经讲过,我们就不做介绍

    步骤7)我们主动断开server channel13

    ①我们主动断开server chanel13,rfcomm raw data为6D 53 01 A5(hex data)

    6D = 0110 1101b,EA=1,C/R=0,DLCI=0110 11,D=1,server channel = 13

    53 = 0101 0011b,P/F=1,为DISC帧

    01 = 0000 0001b,EA=1,也就是只有1个byte,也就是L1~L7标示后续封包的长度,也就是0

    A5也就是fcs

    我们来看下btsnoop

    ②对方回应我们发送的断开消息,rfcomm raw data为6D 73 01 8F(hex data)

    6D = 0110 1101b,EA=1,C/R=0,DLCI=0110 11,D=1,server channel = 13

    73 = 0111 0011b ,P/F=1,UA帧

    01 = 0000 0001b,EA=1,也就是只有1个byte,也就是L1~L7标示后续封包的长度,也就是0

    8f也就是fcs

    我们来贴下btsnoop

    步骤8)我们主动断开server channel9

    可以直接参照步骤7

    展开全文
  • 蓝牙全套5.2协议: Core 4.0~5.2:L2CAP、HCI、无线部分 A2DP AVCTP AVDTP AVRCP BIP BNEP CGMP CPS CSS CTN CTS DIS DUN FTP GATT GAVDP GOEP GPP HDP HID HSP IRDA LLS MAP ...RFCOMM SPP VDP 等等
  • RFCOMM简单介绍

    2021-05-31 14:48:36
    RFCOMM可模拟RS-232串行端口的串行电缆线路设置和状态。RFCOMM通过L2CAP来处理单连接上的多路复用,并提供到多个设备的连接,从而提供多个并发连接。 RFCOMM依赖蓝牙基带提供可靠的字节流序列传送。它没有任何纠正...

    RS-232串行端口有9条线路,可用于传输数据和信令。RFCOMM可模拟RS-232串行端口的串行电缆线路设置和状态。RFCOMM通过L2CAP来处理单连接上的多路复用,并提供到多个设备的连接,从而提供多个并发连接。
    RFCOMM依赖蓝牙基带提供可靠的字节流序列传送。它没有任何纠正错误的能力。RFCOMM的流控也使用基带的功能。
    RFCOMM数据速率将限制在涉及物理串行端口(类型2设备)的设备中。实现可以选择在虚拟串行端口(类型1设备中)上对数据进行调整。在允许范围内,RFCOMM将提供尽可能高的数据速率,尽管在存在多个连接时,最高数据速率可能是一个复杂的实现(见第18章)。

    RFCOMM是一种简单、可靠的传输协议,具有帧、复用和以下附加规定:
    • 调制解调器状态 RTS/CTS、DSR/DTR、DCD、铃声。
    • 远程线路状态 中断、溢出、奇偶校验。
    • 远程端口设置 波特率、奇偶校验、数据位数等。
    • 参数协商(帧大小)。

    10.1串行端口和UART

    通常,串行端口发送和接收数据线连接到UART(通用异步收发器)。UART的任务是在电缆下发送的串行数据和设备使用的并行数据处理之间进行转换。uart使用缓冲区在串行和并行数据之间进行转换。这样可以减少处理器的负载。UART在电缆和缓冲区之间传输位,而不必为电缆中发送的每一个位中断处理器,那么处理器只需在有整个缓冲区需要处理时才需要参与。
    来自UART的信号是连接在一起的,因此它们出现在系统地址映射中。一些处理器为I/O保留一个特殊的地址范围;其他系统可以将它们映射到正常内存的任何部分。因为UART看起来像微处理器的内存区域,所以可以通过获取内存区域并设置由UART设置的值来模拟软件中的串行端口。
    蓝牙RFCOMM规范讨论了仿真RS-232串行端口的9个电路,并指定了如何住址串行数据流。但是,由于RS-232端口的串行数据流在通过UART后由微处理器查看,因此处理串行端口的软件实际上是在处理并行数据。类似地,RFCOMM软件处理由蓝牙堆栈底层交付的并行数据。
    UART连接到一些硬件:导线或缓存。RFCOMM通过L2CAP连接到软件栈的底层。

    10.2 RFCOMM设备类型

    RFCOMM支持两种类型的设备:
    • 类型1–内部模拟串行端口(或等效端口)。
    • 类型2–带物理串行端口的中间设备。
    !在这里插入图片描述
    图10-1左侧显示了1型RFCOMM设备的协议栈。端口仿真实体将系统特定的通信接口(API)映射到RFCOMM服务。这可以用于连接到如图所示的其它应用程序,也可以用于连接到专门为蓝牙编写的应用程序。类型1设备通常是通信路径的末端,例如PC或打印机。
    图10-1右侧显示了2型RFCOMM设备的协议栈。端口代理将数据从RFCOMM中继到与另一个设备连接的RS-232接口。类型2设备是位于通信路径中间的中间设备。调制解调器是2型设备的一个例子。

    10.3 RFCOMM帧类型

    RFCOMM基于GSM TS 07.10,这是一种由GSM手机使用的一种非对称协议,可以将多个数据流复用到同一个物理串行电缆上。RFCOMM是对称的,使用TS 07.10特征帧和命令的子集通过L2CAP发送TS 07.10帧。TS 07.10的一些功能适用于蓝牙。
    RFCOMM使用帧进行通信,RFCOMM帧作为L2CAP数据包中的有效负载数据。有五种不同的帧类型:
    • SABM—Start Asynchronous Balanced Mode (startup command). 设置异步平衡模式
    • UA—Unnumbered Acknowledgement (response when connected). 未编号的确认信息
    • DISC—Disconnect (disconnect command). 断开连接
    • DM—Disconnected Mode (response to a command when disconnected). 断开连接模式
    • UIH—Unnumbered Information with Header check. 未编号的带校验头的信息
    SABM, UA, DM和 DISC是底层的控制帧,RFCOMM使用信道,每个信道有一个数据连接链路标识(DLCI),UIH帧上的 DLCI = 0时用作发送控制信息, DLCI≠0时用作发送数据。

    10.4 连接和断开连接
    因为RFCOMM的帧承载于L2CAP数据包中的有效载荷中,在RFCOMM连接建立之前,L2CAP的连接必须建立
    RFCOMM为L2CAP有一个保留的协议和服务多路复用器(PSM)值,这在蓝牙核心规范中定义为0x0003。任何在L2CAP接收帧的PSM字段中使用此值将被发送到RFCOMM进行处理。
    在RFCOMM信道上发送的第一帧是SABM帧;这是个开始异步平衡模式命令。如果响应设备的RFCOMM已经连接,则会进入异步平衡模式(ABM),并发回一个UA帧。如果响应设备的RFCOMM没有连接,它将通过发送DM帧来拒绝连接。图10-2显示了RFCOMM信道设置拒绝的方式。
    在这里插入图片描述
    当发送RFCOMM命令后会启动一个60秒的定时器,如果定时器超时时未收到确认信息,则连接将被关闭。这与GSM 07.10不同,GSM 07.10在定时器超时时重新发送命令。在RFCOMM机制中,蓝牙基带提供了可靠的链路,因此如果第一次未被确认,第二次也不会被确认。对于SABM命令,超时时间可以延长,因为安全程序可能意味着此命令的处理时间比其他命令长。如果RFCOMM超时断开连接时,为防止另一侧认为它还处于活动状态,它必须在原来的SABM帧上发送与服务器相同的DLCI的DISC(断开连接)命令。图10-3显示了初始化超时通道被关闭。
    在这里插入图片描述
    如果连接成功,响应方用UA帧回复SABM帧,此时在初始方和响应方,开始参数协商的流程,如图10-4所示。
    在这里插入图片描述
    一旦DLCI=0的连接建立,就可以用于RFCOMM signalling信道。要传输数据,必须建立其他RFCOMM信道。图10-4所示。
    建立的第二个RFCOMM信道用来传输数据。在这种情况下,信道需要身份验证,因此在SABM命令帧和UA响应帧之间,有一个暂停以进行LMP身份验证和加密,一旦收到UA帧,模式状态命令被转换成控制信号通信状态。然后可以立即传输数据并显示,也可以进行转换的PN命令和响应来配置新连接的参数。
    用户数据应该包括MSCs(Modem Status Commands),用于串口控制信号的状态的通信。
    要关闭RFCOMM连接,将发送DISC命令。当最后一个数据链路关闭时,应在DLCI=0上发送DISC以关闭多路复用器。
    当然,无论哪个设备关闭多路复用器都要响应L2CAP信道断开连接命令。

    10.5 RFCOMM帧数据结构

    RFCOMM借鉴了GSM07.10标准的帧结构。图10-5显示GSM 07.10帧结构的基本选项(还有一个高级选项,缺少长度字段;RFCOMM始终使用基本选项)。

    在这里插入图片描述
    图10-6显示了RFCOMM帧的结构。这与GSM07.10基本选项框,除了RFCOMM去掉了开始和结束标志,因为L2CAP数据包的大小的限制,RFCOMM必须限制一个数据包中的字节数。
    在这里插入图片描述
    RFCOMM不需要开始和结束标志,因为每个RFCOMM帧都是在一个L2CAP包中。且无需从网络中选取RFCOMM帧数据流,因此不需要标志位来标记帧的开始和结束位置。

    10.5.1 Address 字段

    RFCOMM帧以地址字段开头。这标识了多个多路复用的帧所属的各自的通道。地址字段分解,如图10–7所示
    在这里插入图片描述
    EA(扩展地址)字段可用于对地址的扩展。如果EA=0,则其后有更多的地址字节;如果EA=1,则这是地址的最后一个字节。蓝牙规范规定服务器应用程序可被分配一个1到30之间的服务通道号,因此RFCOMM地址帧分配有5bit用于服务通道,因为从来不需要使用扩展寻址,所以在RFCOMM地址字段中EA位始终设置设置为1。
    C/R((Command/Response)bit表示是命令帧还是响应帧。它的值不仅取决于帧是命令帧或响应帧,同时也包括是在哪个通道发送的帧。发起连接的设备(在DLCI 0上发送SABM命令)称为发起者,响应设备(在DLCI 0上发送UA响应)称为响应者。只要交互流程遵循这个基本模式,C/R bit是1,来自发起方的命令和来自响应者的响应C/R=1;将方向交换后,C/R bit为0,即来自响应者的命令和来自发起者的响应C/R=0。发送数据时,发起方设置C/R=1,响应方设置C/R=0。图10-8说明了如何设置C/R bit。
    在这里插入图片描述
    C/R位之后是数据链路连接标识符(DLCI)。在GSMTS0.10中,这是一个不可分割的字段,但是在RFCOMM中,它被分为方向位和服务通道号。启动器始终将方向位设置为1(D=1);响应者始终将方向位设置为0(D=0)。作为C/R位,发送SABM帧来启动连接的设备称为发起者,否则称为响应者。
    服务通道号有5bit,其范围031,但0和31是保留的,所以只能分配130作为服务的服务通道号。通道0用于发送控制信息;通道31为TS07.10预留。蓝牙避免使用TS 07.10预留的通道,以保持与TS 07.10应用程序的兼容性。
    DLCI是在建立数据链路连接之前计算一次。响应设备中的RFCOMM服务通道号用于DLCI。由于服务通道号1~30可用,因此一个设备最多有30个可使用RFCOMM的服务。

    10.5.2 Control 字段

    如图10-6所示,RFCOMM帧中的下一个字段是控制字段。这是用来识别帧的类型。RFCOMM帧中使用的控制字段值如表10-1所示。(与GSM TS 07.10对应帧中使用的值相匹配。)
    P/F是Poll/Final位,在命令中,它被称为P (Poll)位;在响应中,它被称为F(Final)位。
    在这里插入图片描述
    当需要从链路终端设备发出一个响应或一系列响应时,使用P位设为1的命令。响应设备应将F位设为1发送回响应者。等待响应时只有一个命令帧的P位设置为1。
    不管P/F位的状态如何,DM包都会被处理,如果P/F位设置为零,SABM或DISC命令和UA响应都会被丢弃。

    10.5.3 长度字段

    长度字段以EA位开始,如图10-9所示。如果EA=1,那么它后面是7bit的长度,所以长度字段是1字节长。如果EA=0,那么它后面是15bit的长度,所以长度字段是两个字节长。RFCOMM帧的默认长度是32字节,最大长度为32767。
    在这里插入图片描述
    10.5.4数据

    数据字段只在UIH帧中出现,数据长度不超过32767字节。大小限制是由L2CAP数据包上的最大传输单元(Maximum Transmission Unit, MTU)设置的,如果系统具有较小的L2CAP MTU, RFCOMM数据的大小同样受到限制。

    10.5.5帧检查顺序

    计算FCS:
    计数k, FCS将被计算的比特数。对于SABM、DISC、UA和DM帧,帧检查序列是根据地址控制和长度字段计算的。对于UIH帧,它是根据地址和控制字段计算的。
    接着:
    (a)计算Xk (X7 + X6 X5 + X4 + X3 + X2 + X1 + 1)模2除以生成多项式(X8 + X2 + X + 1)的余数。
    (b)在插入任何启动和停止元素之前,以及在插入任何其他额外位之前,取FCS计算的帧内容。乘以X8并除以生成器多项式(X8 + X2 + X + 1)。
    ©将(a)和(b)的结果取2的模,取1的补,得到FCS。
    因为UIH帧只计算地址和控制字段上的FCS,它们的数据字段不受FCS的保护。这可能是可靠数据传输的一个缺点,但它的优点是可以为所有正在使用的DLCI预先计算FCS模式。此预计算可在通道建立时进行。

    10.6多路复用帧

    在DLCI = 0时发送多路复用命令和响应。它们用于控制RFCOMM链路。有七种类型的命令或响应:
    • PN-DLC参数协商。
    • Test-Checks通信链路。
    • FCon / FCoff 所有连接的总流控制。
    • MSC-Modem状态,用于每个连接的流量控制。
    • RPN 远程端口协商。
    • RLS 远程线路状态。
    • NSC不支持的命令(仅响应)。
    多路复用命令和响应作为消息携带在RFCOMM UIH帧内,如图10-10所示。可以在一个RFCOMM帧中发送多个多路复用命令消息,或者将一个多路复用命令消息拆分到多个帧中。
    在这里插入图片描述
    10.6.1 PN-DLC参数协商

    PN命令用于协商数据链路连接的参数。在打开新的数据链路连接之前交换PN命令,这不是强制的。如果没有发送PN命令,将为连接使用默认参数。
    PN命令由图10-11所示的类型字段标识。此类型字段是UIH帧中承载PN命令的第一个信息字节(见图10–11)。EA位是1,因为类型字段占用一个字节。C/R位用于指示消息是命令还是响应。
    在这里插入图片描述
    PN消息中的长度字段总是设置为8,值字段包含8个字节,如图10-12所示。这些字节定义了将在数据链路连接上使用的参数,如下所示:
    在这里插入图片描述
    • 6个DLCI bit标识正在协商参数的数据链路连接。
    • DLCI后面有2个填充位始终设置为零;插入这些参数是为了避免跨字节拆分参数。
    • 4个I位表示用于在信道上传输信息的帧类型。在RFCOMM中,使用值0b1000表示UIH帧。
    • 4个CL位提供了要使用的汇聚层。在1.0b之后的版本中,RFCOMM使用Type 1(非结构化的字节流)= 0b0000,这也可以设置为0x0F以启用基于信用的流控制。
    • 6个P位为数据链路连接分配优先级:0为最低优先级,63为最高优先级。
    • P位之后有两个始终设置为零的填充位;插入这些参数是为了避免跨字节拆分参数。
    • 8个T位给出确认计时器的值,在GSM 07.10中,此被用于触发重传;在RFCOMM中,如果计时器超时,连接就会关闭。计时器的值不可协商,但固定为60秒。此字段设置为0表示计时器不可协商。
    • 16个N位表示帧的最大大小。
    • 8个NA位给出了最大的重传次数。由于蓝牙基带为RFCOMM提供了可靠的传输层,因此RFCOMM不会重传,该值设为零。
    • 3个K位定义错误恢复模式的窗口大小。RFCOMM使用基本模式,因此RFCOMM不诠释这些位。
    • 5个填充位设置为0,填充最后一个值字段的剩余部分,将值舍入为整数字节数。
    所有正在协商的参数都以LSB发送第1个bit的;这是RFCOMM信息的一般规则。
    值得注意的是,RFCOMM遵循GSM 07.10标准的约定,并将帧中的位以1~8从最低有效位到最高有效位进行编号。这可能会让那些习惯于看到字节中从0到7的位的人感到困惑。
    一个设备发送一个PN消息,另一个设备用另一个PN消息响应。响应可能不会改变DLCI、优先级、收敛层或定时器值。响应可能返回一个不同的定时器值。在这种情况下,发送第一个PN消息的设备将仍然使用它建议的定时器,但是连接另一端的设备将使用它在消息中发送的值。
    对于最大帧大小,以一个较小的值响应,但它可能不会为这个参数提出一个更大的值。
    在GSM 07.10中,PN消息是可选的。在RFCOMM中,对PN消息及其响应的支持是强制的,如果默认参数令人满意,则不必发送PN消息。PN消息可以一直交换,直到发送第一个消息的设备对发回给它的参数满意为止。一旦应答中有了一组满意的参数,它就可以继续建立连接。

    10.6.2测试

    test命令用于检查RFCOMM的连接状态。正常情况下,长度字节给出后面的字节数。字节的数量不是固定的,它被用来保存测试模式。链路的远端返回相同的字节。
    测试命令类型字段如图10-13所示。因为只使用一个字节,EA位被设置为1。C/R位用于指示消息是命令还是响应。
    在这里插入图片描述
    10.6.3 FCon / fcoffo -所有连接的总流量控制

    RFCOMM有一个流控制机制,适用于两个RFCOMM实体之间的所有通道。当任何一个RFCOMM实体无法接收到RFCOMM信息时,它会发送一个流控制关闭(FCoff)命令。当它能够再次接收数据时,当它能够再次接收数据时,它会发送一个流控制开启(FCon)命令。
    两个流控命令的type字段结构如图10-14所示。两者都以EA位开始,EA位是1,表示命令类型中只有一个字节。携带该命令的帧中的长度字段被设置为零,因为该帧中没有其他数据。C/R位用于指示消息是命令还是响应。
    在这里插入图片描述
    10.6.4 MSC调制解调器状态命令

    RFCOMM还有一种流量控制机制,一次只能应用于一个通道。这是调制解调器状态命令(MSC),由图10-15所示的类型字段表示。EA位是1,因为类型字段占用一个字节。C/R位用于指示消息是命令还是响应。
    在这里插入图片描述
    MSC的命令字段包含虚拟的V.24控制信号,也就是说,如果RFCOMM数据是通过导线而不是通过蓝牙连接传输的,RS-232控制线将具有的设置。命令字段中的信号如下:
    • EA扩展地址,设置为1表示只有1个字节的命令。
    • FC流控制位,当设备无法接受任何RFCOMM帧时设置为1。当设备能够再次接收时,它发送另一个流控制位设置为0的MSC。
    • RTC准备通信位,当设备准备通信时设置为1。
    • RTR准备接收位,当设备无法接收数据时设置为0,当设备可以接收数据时设置为1。
    • IC来电,1表示来电。
    • DV数据有效,设置为1表示正在发送有效数据。
    这些值在发送的包中似乎没有意义,但这是因为它们映射到RS-232接口的线路上。明显的,当一个包被发送时,它将拥有有效的数据;谁会费心去发送一个包含无效数据的包呢?然而,在处理物理串口线时,这样的信号更有意义。一个表示有效数据正在发送的信号可以用来激活电路来处理数据。MSC命令只是模拟V.24信号的值,这将用于有线RS-232接口。
    来自MSC的信号映射到RS-232信号,如下所示:
    • RTC映射到DSR (Data Set Ready)和DTR (Data Terminal Ready)。
    • RTR映射到RTS (Request To Send)和CTS (Clear To Send)。
    • IC映射到RI (Ring Indication)。
    • DV映射到DCD (Data Carrier Detect)。
    图10-16显示了如何在命令的控制字段中传输信号。
    在发送任何数据以确定RS-232控制信号的状态之前,MSC通过连接发送。当需要改变信号时,也应该发送它。
    在MSC中,发送该命令的设备信号的状态被发送。响应只携带来自命令的信号的副本。
    在这里插入图片描述
    10.6.5 RPN远程端口协商

    远程端口协商(RPN)命令用于在数据链路连接的远程端设置通信设置。如果在连接过程中需要更改任何通信设置,可以重新发送RPN命令来更改。
    RPN类型字段如图10-17所示。
    在这里插入图片描述
    EA位是1,因为类型字段占用一个字节。C/R位用于指示消息是命令还是响应。
    RPN命令中的字节长度为1或8。如果长度为1,则有一个包含连接的DLCI的单值字节,该消息被解释为对链接参数的请求。在这种情况下,远程端使用链接上的当前参数进行应答。如果长度字节被设置为8,那么接下来是8个字节是链接参数。如果它们是在命令中发送的,那么它们就是设置链接参数的请求。
    图10-18所示,长度字节设置为8时,RPN命令中的取值顺序。
    在这里插入图片描述
    参数掩码定义消息正在更改哪些参数。图10-19显示了RPN参数掩码中位的位置。
    在这里插入图片描述
    在RPN命令中,如果参数掩码位设置为1,则表示应更改的特定参数。如果设置为0,则不会更改参数,可以忽略该值。
    在RPN响应中,如果参数掩码位设置为0,则表示在RLS中发送的建议未被接受。相反,参数掩码位设置为1表示新值已被接受,响应的发送方现在使用新值。
    RLS命令中各个字段的值与GSM 07.10中的含义相同。

    10.6.6 RLS—远程线路状态

    当设备需要将错误告知链路的另一端时,它会发送远程线路状态(RLS)命令。
    RLS命令由类型字段标识,如图10-20所示。EA位是1,因为类型字段占用一个字节。C/R位用于指示消息是命令还是响应。
    在这里插入图片描述
    长度字节设置为2,因为有两个字节:第一个字节携带EA位C/R位和所有多路复用器命令消息共用的数据链路连接标识符;第二个字节在其前四个位中携带错误状态,如下所示:
    如图10-21所示。
    在这里插入图片描述
    线路(L)状态位可以表示三种不同的错误,如下所示:
    • 0b1100溢出错误,接收到的字符覆盖了尚未读取的字符。
    • 0b1010奇偶校验错误,接收字符的奇偶校验错误。
    • 0b1001帧错误,字符未以停止位结束。
    如果第一行状态位设置为0,那么RLS命令只是简单地报告该线路上没有错误。
    当接收到RLS命令时,将返回一个响应,其中包含从该命令复制到响应中的线路状态。
    RFCOMM实现必须识别并响应RLS命令,但如何处理线路状态信息则由实现者决定。

    10.6.7 NSC–不支持命令(仅响应)

    当设备接收到不支持的命令时,会发送不支持的命令(NSC)响应。
    用于标识包含NSC的消息的类型字段如图10-22所示。EA位是1,因为类型字段占用一个字节。C/R位用于指示消息是响应。如果消息来自通过发送SABM启动连接的设备,则C/R=0。如果消息来自响应初始SABM的设备,则C/R=1。
    在这里插入图片描述
    10.7服务记录

    提供RFCOMM支持服务的蓝牙设备,必须在其服务发现数据库中有一个如何通过RFCOMM连接的条目。
    RFCOMM服务器通道号是动态的。也就是说,服务的通道号可以改变。虽然服务的通道号在服务使用时不会改变,但可以在服务不使用时重新分配。
    通过RFCOMM连接到服务所需的最少信息是服务名称(用于标识服务类型)和传输数据的通道号。许多服务具有连接到服务所需的其他附加参数。通过查询SDP记录,设备可以找到通过RFCOMM连接到服务所需的所有信息。
    表10-2显示了一个最小的服务记录,它可以用来提供通过RFCOMM连接到服务所需的信息。ServiceClassIDList提供服务的名称。ProtocolDescriptorList给出了支持的协议。由于RFCOMM依赖于L2CAP,因此每当RFCOMM存在时,L2CAP服务就一定存在。这个服务还有一个文本名称,以便在用户界面上表示它。
    在这里插入图片描述
    有关更多信息,请参阅第11章,表11–1,其中显示了如何为耳机应用程序显示RFCOMM信息。耳机应用程序还使用RFCOMM服务来设置和控制耳机连接。

    10.8总结

    RFCOMM提供串行端口仿真,可用于连接到传统应用程序,也可用于蓝牙配置中的一些数据传输。
    RFCOMM支持两种类型的设备:类型1设备是通信路径的末端,支持RFCOMM之上的应用程序;类型2设备是中间设备,具有RFCOMM之上的物理RS-232串行端口。
    要建立RFCOMM连接,必须首先建立L2CAP连接。RFCOMM帧在L2CAP包的有效载荷字段中发送。一旦建立了L2CAP连接,就会回送RFCOMM控制帧,以建立数据链路连接标识符(DLCI)设置为0的信令信道。在此基础上,建立后续传输数据的通道。最多可以设置30个数据通道,因此RFCOMM理论上可以同时支持30种不同的服务。(实际上,大多数蓝牙设备都没有足够的资源来支持30种不同的服务。)
    RFCOMM基于GSM07.10标准,在蓝牙连接和GSM移动电话连接之间有一些细微的差别。

    本文翻译自:
    Bluetooth: Connect Without Cables
    By Jennifer Bray and Charles Thurman
    © 2001 by Prentice Hall PTR
    Prentice-Hall, Inc.
    Upper Saddle River, NJ 07458

    仅供学习使用,请勿用于商业用途。

    展开全文
  • RFCOMM

    千次阅读 2017-06-23 17:16:29
    八、RFCOMM ...1. RFCOMM ...先来看看RFCOMM在协议栈层次体系中的位置。从下图可以看出RFCOMM处于传输层。...处于其上层的会话层中的OBEX,SPP等大部分协议通常都采用RFCOMM作为传输协议。因此RFCOMM传输协议在蓝

    http://www.cnblogs.com/fbli/p/5930383.html

    八、RFCOMM

    1.      RFCOMM

    先来看看RFCOMM在协议栈层次体系中的位置。从下图可以看出RFCOMM处于传输层。与AVCTP,TCS-BIN处于同一层次。处于其上层的会话层中的OBEX,SPP等大部分协议通常都采用RFCOMM作为传输协议。因此RFCOMM传输协议在蓝牙协议栈中占据重要一席。

     

    RFCOMM提供了基于L2CAP协议的串行(9针RS-232)模拟,支持在两个蓝牙设备间高达60路的通信连接。

    1.1       RFCOMM使用示例——SPP

    SPP(Serial Port Profile)定义了一系列协议和过程,蓝牙设备通过该协议实现RS232串行线缆的仿真。很多老式设备都工作在串行模块下面,使用SPP协议可以帮组连接这些老式设备。先来卡纳看SPP在蓝牙协议体系里面的位置:

     

    从上图可以看出,SPP协议是大部分应用层协议都采用的会话层协议,常用的GOBEX以及HSP都采用了SPP协议。再来看看SPP协议所处的层次以及服务模型:

     

    SPP按角色分为DevA和DevB,其中DevA是连接的发起者(initiator),DevB是等待连接的到来。从应用层角度看,SPP涉及到三个主要的过程:建立链路并设置虚拟串口连接、接收链路和建立虚拟串口连接、本地SDP数据库注册服务记录,其中第一项对DevA来说是强制实现的,后两项对DevB是强制实现的。

    1.1.1    核心过程

    1、建立链路并设置虚拟串口连接

    该过程包括以下步骤:

    1. Submit a query using SDP to find out the RFCOMM Server channel number of the desired application in the remote device. This might include a browsing capability to let the user select among available ports (or services) in the peer device. Or , if it is known exactly which service to contact, it is sufficient look up the necessary parameters using the Service Class ID associated with the desired service.

    2. Optionally, require authentication of the remote device to be performed. Also optionally, require encryption to be turned on.

    3. Request a new L2CAP channel to the remote RFCOMM entity.

    4. Initiate an RFCOMM session on the L2CAP channel.

    5. Start a new data link connection on the RFCOMM session, using the aforementioned server channel number.

    After step 5, the virtual serial cable connection is ready to be used for communication between applications on both sides.

    Note: If there already exists an RFCOMM session between the devices when setting up a new data link connection, the new connection must be established

    on the existing RFCOMM.

    2、接收链路和建立虚拟串口连接

    该过程主要包括以下步骤:

    1. If requested by the remote device, take part in authentication procedure and, upon further request, turn on encryption.

    2. Accept a new channel establishment indication from L2CAP.

    3. Accept an RFCOMM session establishment on that channel.

    4. Accept a new data link connection on the RFCOMM session. This may trigger a local request to authenticate the remote device and turn on encryption, if the user has required that for the emulated serial port being connected to (and authentication/encryption procedures have not already been carried out ).

    Note: steps 1 and 4 may be experienced as isolated events when there already exists an RFCOMM session to the remote device.

    3、本地SDP数据库注册服务记录

    该过程涉及到向本地SDP数据库为虚拟串口注册一条服务记录。这也意味着服务数据库的存在,以及对SDP查询的支持。

    1.1.2    连接消息序列

    先来看看DevB的初始化流程图。上层应用通过调用SppStartService()开始注册和初始化SPP服务,其中涉及到RFCOMM通道注册,SDP服务搜索等交互过程,在上层应用收到SPP_START_SERVICE_CFM表示服务初始化完成,下一步是等待DevA的连接到来。

     

             再来看看典型的连接过程涉及到的消息交互流程图。DevA通过调用SppConnectRequest ()开启连接过程,DevB在接收到SPP_CONNECT_IND消息时决定是否接受该连接,并作出响应SppConnectResponse()。在DevA收到SPP_CLIENT_CONNECT_CFM,DevB收到SPP_SERVER_CONNECT_CFM后,表示SPP通信会话正式建立。

     

             在走读ADK代码时候,你会发现一个奇怪的现象——通信模块(如L2CAP,RFCOMM,SPP等)里找不到数据收发的接口,传统的通信模块,比如SOCKET通信例程中,当通信链路建立后,会提供read/write,read_from/write_to等之类的显示读写函数帮助收发数据。这是因为ADK提供了流的机制,引入sink/source/transform概念。这样,当一条L2CAP/RFCOMM数据链路建立的同时会创建对应的sink实体,用于收发数据。Sink实体在有数据达到或者数据可以接受状态时向已注册任务(task)发送MESSAGE_MORE_DATA/MESSAGE_MORE_SPACE消息。以SPP为例,在DevA收到SPP_CLIENT_CONNECT_CFM,DevB收到SPP_SERVER_CONNECT_CFM后,例程将会保存已创建的sink实体,并进行配置。

    Sink sink    = (Sink) StreamRfcommSink(cfm->conn_id); /*从RFCOMM会话ID获取sink引用*/

    SourceConfigure(StreamSourceFromSink(sink), VM_SOURCE_MESSAGES, VM_MESSAGES_ALL);

             其实真正的sink实体创建于L2CAP链路创建成功的时候??这一点还只是猜测。

    void connectionHandleL2capConnectCfm(const L2CA_AUTO_CONNECT_CFM_T *cfm){

             Sink                sink = StreamL2capSink(cfm->cid);

             MessageSinkTask(sink, appTask);   /* Associate the task with its sink */

    }

             目前还不清楚sink实体是何时创建的,总之,在SPP建立连接后,就拥有了一个数据收发的sink实体,通过该实体,配合BlueCore发送过来的MESSAGE_MORE_DATA和MESSAGE_MORE_SPACE等消息进行数据传输。

    1.1.3    消息处理

    SPP库例程中,DevA(Client)定义了一个回调函数——sppcConnectionHandler,用来接收下层的消息,并进行处理和转发。DevB(Server)定义了两个回调函数,一个用来处理连接时候的消息,一个用于处理服务相关(如SDP查询等)的消息。

    spp->c.task.handler = sppcConnectionHandler;

    spp->c.client_task = theAppTask;

     

    TaskData sppsServiceTask = { sppServiceHandler };

    spp->c.client_task = theAppTask;

    SppConnectResponse()->

    spp->c.task.handler= sppsConnectionHandler;

    1.1.4    多串口仿真

    两个使用RFCOMM通信的蓝牙设备可以同时打开多个串口仿真 ,RFCOMM支持多大60路,但是一个设备实际能打开的数据依实现而定。

    ADK例程中怎么没有发现多串口复用相关的内容呢???


    展开全文
  • 本文章主要讲下蓝牙RFCOMM协议(bluetooth rfcomm)的概念以及在整个蓝牙协议栈中的起的作用 一. 声明 本专栏文章我们会以连载的方式持续更新,本专栏计划更新内容如下: 第一篇:蓝牙综合介绍 ,主要介绍蓝牙的...

    零. 概述

    本文章主要讲下蓝牙RFCOMM协议(bluetooth rfcomm)的帧格式,包括Address,Control,Length Indicator,Information,FCS等

    一. 声明

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

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

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

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

    二.RFCOMM帧格式

    2.1 参数Address:

    EA参数:这部分在蓝牙RFCOMM协议中一直为1

    C/R参数:此部分是代表RFCOMM的command还是response,官方解释如下:

    这个理解起来稍微我有绕,我翻译一下:

    C/R(命令/响应)位表示帧是命令还是响应,它的值不仅取决于帧是否携带命令或响应,还有信道的哪一端发送帧。建立连接的设备(通过在DLCI 0上发送SABM命令)称为initiator。响应的设备(通过在DLCI 0上发送UA响应)称为responder。网络上都对这个地方说明的模凌两可,对于上面的这段话其实也说的模棱两可,我来总结下:

    1)对于(SABM,UA,DM,DISC)帧,这些统称为命令帧,initiator发送给responder,C/R=1,response相应initiator C/R也为1。

    2)对于(SABM,UA,DM,DISC)帧,这些统称为命令帧,response发送给initiator C/R为0,initiator响应给responder,C/R=0.

    3)对于UIH帧,这个称为数据帧,initiator发送给responder,C/R=1,response发送给initiator C/R为0.

    总结图标如下:

    为了便于我上面的总结理解,那么加一个流程图,来加深你们的印象

    下面我们用BTsnopp来一一看下以上个3case:

    1)对于(SABM,UA,DM,DISC)帧,这些统称为命令帧,initiator发送给responder,C/R=1,response相应initiator C/R也为1。

    分别解析如下:

    从截图看出是对方来连接我们signaling,所以对方是initiator,所以对方发送SABM种的C/R是1,而我们回复的UA帧中的C/R也为1

    以下例子都是以对方为initiator来说明

    2)对于(SABM,UA,DM,DISC)帧,这些统称为命令帧,response发送给initiator C/R为0,initiator响应给responder,C/R=0.

    从1)中我们可以看到我们是responder,对方是initiator,所以按照我们发送给对方的SABM帧的C/R是0,对方回应我们的也是0

    3)对于UIH帧,这个称为数据帧,initiator发送给responder,C/R=1,response发送给initiator C/R为0.

    上图解析如下:

    可以看到对方给我们的UIH帧C/R为1,我们给对方的UIH帧C/R为0

    讲到这里你应该明白了C/R位了吧,我感觉我是全网在这里说明最清晰的。

    D参数:这个同样比较绕,我们来看下官方解释

    D其实就是DLCI中的direction bit

    网上也没有一个特别明确的说明,我自己总结了下,感觉也是比较清晰:

    建立连接的设备(通过在DLCI 0上发送SABM命令)称为initiator。响应的设备(通过在DLCI 0上发送UA响应)称为responder,这点在上面我们也已经说明了。initiator自己的D=1,responder自己的D=0,所以如果在DLCI已经建立连接后,后续initiator连接responder某一个profile的时候(比如HFP),那么应该是DCLI=0+ server chanel<<1,如果是responder连接initiator的某一个profile,那么应该是DCLI=1+ server channel<<1

    后续交互封包的UIH的DCLI一直不变

    举几个例子来说明下这里(remote是initiator,local是responder):

    来一个initiator连接responder的btsnoop

    可以发现server channel是9,那么按照算法应该是0+9<<1,所以DCLI应该是0x12

    来一个responder连接initiator的btsnoop

    可以发现server channel是13,那么按照算法应该是1+13<<1,所以DCLI应该是0x1B

    Server channel:说白了就是上层profile的rfcomm channel

    注册到SDP中,整个流程就是SDP问询对方的RFCOMM channel,然后再发起RFCOMM的连接(比如HFP,HSP,SPP,OPP等),连接完毕交互完参数,就相当于上层profile连接成功

    2.2 Control参数

    主要是标示RFCOMM frame type是什么,截图如下:

    帧分别作用如下:

    SABM:异步平衡模式设置指令 SABM 命令可以用在异步平衡模式下,并且它的控制字段只能有一个字节。设备通过首先发送 UA 应答来确认接收到 SABM命令,DLC 发送和接收状态变量都必须设定为 0。用大白话讲就是连接命令

    UA:未加编号的确认应答。 UA 应答用在设备对接收到 SABM 和 DISC 后的确认应答

    DM:断开连接模式应答。DM 应答是用来报告设备从数据链路逻辑地断开连接这么一种状态的。在断开模式下,不支持任何命令,直到收到了 SABM 命令,然后停止断开模式。在断开模式下,接收到了 DISC 命令,则要向对方发送一个 DM 应答。

    DISC:断开连接指令。用 DISC 命令可以用来结束一个正在运行或者刚刚开始的模式。它就是通知一方另一方悬置操作,设备必须假定一个逻辑断开模式。在执行这个命令之前,接收设备要通过发送 UA 应答来确认接受 DISC 命令。在DLCI0 中,DISC 命令的发送也和其他的 DLCI 具有同意的意思。

    UIH:带头校验的未编号信息命令和应答用 UIH 命令/应答可以通过不影响V(S)或 V(R)变量来相互发送信息。UIH 是用在传输一些信息的完整性没有它要在正确的 DLCI 上传输重要的情况下的。 FCS 只在地址和控制字段进行计算。 UIH用于对差错码要求不是很高的场合,如语音。

    P/F Bit:P/F是Poll/Final位

    在Commands中,被称为P(poll)位;而在Responses中则被称为F(final)位,大概用法我自己总结如下:

    1)对于(SABM,UA,DM,DISC)帧,这些统称为命令帧,command跟response都设置为1就好。

    2)对于UIH帧,除了给对方credit设置为1外,UIH user帧以及UIH多路控制帧都设置为0就好了。

    2.3 Length Indicator参数

    L1 到 L7 位表示数据字段的长度,其默认值为 31 字节。同样,它可以根据 EA位进行扩展。当 EA=0 时,它接下来的字节如下表表示就可以表示 15 个数字。也就是RFCOMM的后续len是32~32767 byte的字节。

    2.4 Information Field参数

    UIH帧数据,只对UIH帧有效,后续再一一介绍下UIH的格式

    2.5 FCS参数

    帧校验序列(FCS)根据不同帧类型在不同域集上进行运算.下面列出需要进行帧运算的字段:

    对于 SABM、DISC、UA、DM 帧:在地址、控制和长度标志字段上进行运算;

    对于 UIH 帧:在地址和控制字段上进行运算。

    展开全文
  • 蓝牙RFCOMM协议

    2021-01-14 19:15:02
    本文章主要讲下蓝牙RFCOMM协议(bluetooth rfcomm)的帧格式,包括Address,Control,Length Indicator,Information,FCS等 一. 声明 本专栏文章我们会以连载的方式持续更新,本专栏计划更新内容如下: 第一篇:...
  • 将您的蓝牙 USB 加密狗插入您的机器并检查它是否被识别。 从 Linux 命令行,运行“lsusb”。 root@dev:/home# lsusb Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. Bus 001 Device 001: ID 1d6b:...
  • 本文章主要讲下蓝牙RFCOMM协议(bluetooth rfcomm)的概念以及在整个蓝牙协议栈中的起的作用 一. 声明 本专栏文章我们会以连载的方式持续更新,本专栏计划更新内容如下: 第一篇:蓝牙综合介绍 ,主要介绍蓝牙的...
  • 相似功能:经过PuTTY测试的硬件:BlackBerry 9900和两种SPP蓝牙传感器。 经过测试的软件:BlackBerry OS 7.1。 1.在BlackBerry 9900上安装后。2.打开应用程序。 3.连接到BT传感器。 4.键入芯片代码。 5....
  • rfcom层介绍,很详细,值得一读。讲解了蓝牙rfcomm层的协议。
  • Bluetooth RFCOMM介绍

    2019-05-09 09:53:35
    Bluetooth RFCOMM介绍 阅读目录 1. 介绍 2. 服务 3. 接口 4. 帧类型 5. 帧格式 6. Multiplexor Frames 回到顶部 1. 介绍 RFCOMM提供了基于L2CAP协议的串行(9针RS-232)模拟 RFCOMM支持在两个蓝牙设备间...
  • 蓝牙学习笔记之RFCOMM协议

    千次阅读 2019-10-25 10:26:45
    以下蓝色为hci部分、绿色为l2cap部分、红色为RFCOMM部分,这里我只针对RFCOMM协议进行解析,如果你对其他协议有兴趣,可以去看我的其他协议的数据分析 1、Master:SABM(Frame Type) 00000010 00000010 00100000 ...
  • RFCOMM协议概览 协议浅述 服务概述 RS-232控制信号 无调制解调器仿真 多串口仿真 RFCOMM帧类型 RFCOMM帧格式 Address字段 Control字段 Length字段 Data字段 FCS字段 RFCCOMM协议数据分析 RFCOMM协议...
  • RFCOMM(一)

    2021-09-13 21:55:18
    1、RFCOMM协议就是在L2CAP上进行串口(RS-232 9针)仿真,这个协议以GSM 07.10为基础,但是只使用了其中的一部分。此外,还增加了一个RFCOMM特定的延伸:基于credit的流控方案 2、RFCOMM协议最大支持在两个蓝牙设备...
  • Bluetooth RFCOMM

    2011-10-26 09:33:46
    介绍了RFCOMM的定义,设备和帧结构,连接方式用java操作蓝牙的API
  • android 11 蓝牙协议栈rfcomm 连接流程图。
  • 本文章主要讲下蓝牙RFCOMM协议多路控制通道(MULTIPLEXOR FRAMES),包括一下几种 • PN—DLC parameter negotiation. • Test—Checks communication link. • FCon / FCoff—Aggregate flow control on all ...
  • RFCOMM/HFP协议

    2019-09-10 17:12:33
    RFCOMM Set Asynchronous Balanced Mode (SABM) command向对方请求建立异步平衡模式(ABM)的建立 Unnumbered Acknowledgement (UA) response 对SABM或者DISC的响应帧,表示确认收到 Disconnected Mode (DM) ...
  • 蓝牙—RFCOMM协议

    2018-12-28 09:48:00
    RFCOMM是一个简单的协议,其中针对9针RS-232串口仿真附加了部分条款.可支持在两个蓝牙设备之间同时保持高达60路的通信连接.RFCOMM的目的是针对如何在两个不同设备上的应用之间保证一条完整的通信路径。 1....
  • RFCOMM蓝牙

    2011-12-15 15:16:31
    介绍蓝牙协议栈RFCOMM的文章,希望对蓝牙开发爱好者有用
  • 参考:RFCOMM_SPEC_V12 DLCI:Data Link Connection,下行链路连接 1. RFCOMM帧 (1)帧类型: Set Asynchronous Balanced Mode (SABM) command:异步平衡模式设置指令 Unnumbered Acknowledgement (UA) ...
  • rfcomm.pdf

    2011-09-09 11:41:32
    fcomm pppd dun lan ncp lcp
  • let { RfcommDeviceService, RfcommServiceId } = Windows.Devices.Bluetooth.Rfcomm; let { DeviceInformation } = Windows.Devices.Enumeration; let { StreamSocket, SocketProtectionLevel } = Windows....
  • 树莓派是一个是基于Linux的单片机电脑,现在树莓派不仅可以装Linux系统,也可以安装Windows 系统。即树莓派就是一台小电脑,可以把它当作一个开发板进行学习或者玩耍。树莓派可以进行深度开发,但需要专业的知识和...
  • 蓝牙RFCOMM剖析(一)

    2018-11-13 19:01:46
    蓝牙RFCOMM剖析(一)
  • Bluetooth技术学习笔记 ——RFCOMM(1)

    千次阅读 2019-03-22 18:05:52
    参考:RFCOMM_SPEC_V12 DTE:Data Terminal Endpoint,通信终端 DCE: Data communication Endpoint,数据通信端 DLCI:Data Link Connection Identifier,数据链路连接标识。 1. RFCOMM是什么 (1) RFCOMM,Radio ...
  • 我的需求就是手机端连接设备的蓝牙,设备收到手机端连接后自动创建/dev/rfcomm0节点,断开后自动清除,同时自己写的应用可以通过检查/dev/rfcomm0的有无来确定设备与手机是否连接成功。 刚开始的想法很简单,运行...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 4,962
精华内容 1,984
关键字:

RFCOMM