低功耗蓝牙BLE学习记录.docx
- 文档编号:23952381
- 上传时间:2023-05-22
- 格式:DOCX
- 页数:25
- 大小:958.68KB
低功耗蓝牙BLE学习记录.docx
《低功耗蓝牙BLE学习记录.docx》由会员分享,可在线阅读,更多相关《低功耗蓝牙BLE学习记录.docx(25页珍藏版)》请在冰豆网上搜索。
低功耗蓝牙BLE学习记录
RW_BLE_CORE记录
传输信道
BLE的传输信道在频段有40个channel。
包括2种物理信道:
广播信道和数据信道。
数据帧中设置AccessAddress用于标识该信道,防止信道碰撞。
ChannelMAP如下:
数据帧通信
蓝牙帧结构如下:
Preamble:
根据AccessAddress而定,假设AA的LSB〔最右bit〕bit为1,则前导便是10101010b,反之则为01010101b。
AccessAddress:
广播帧的AA为:
0x8E89BED6。
其他情况可以是一个32bit的随机数。
AA需满足以下条件
·不超过连续6个1或者0。
·与广播帧的AA不同bit超过1个。
·不能4byte相同。
·01跳变不能超过24次
·MSB6bit01跳变超过2次。
以下逐个介绍PDU。
一、AdvertisingChannelPDU
蓝牙广播帧帧结构
其中Header的帧格式如下:
其中,
a、广播帧类型〔PDUType〕分为以下几类:
•ADV_IND:
connectableundirectedadvertisingevent
•ADV_DIRECT_IND:
connectabledirectedadvertisingevent
•ADV_NONCONN_IND:
non-connectableundirectedadvertisingevent
•ADV_SCAN_IND:
scannableundirectedadvertisingevent
b、Length:
3~37bytes
广播帧分为很多种,其区别就是payload所代表的意义不同,以下分别对几种广播帧作分别阐释:
1、ADV_IND
ADV_IND的payload格式如下:
在广播帧帧头中的TxAdd位是广播地址的标示位:
TxAdd==0:
AdvA地址为公用地址;
TxAdd==1:
AdvA地址为随机地址。
AdvData则是广播HOST的广播数据。
2、ADV_DIRECT_IND
这种帧用于直接接入的广播事件。
ADV_DIRECT_IND的payload帧格式如下:
其中AdvA的意义与ADV_IND相同。
InitA为广播发起者地址:
RxAdd==0:
发起者地址是公用地址;
RxAdd==1:
发起者地址是随机地址。
注意:
该帧不包含任何HOST数据。
3、ADV_NONCONN_IND
用于不可接入不直达〔non-connectableundirected〕的网络。
其payload意义与ADV_IND类似。
4、ADV_SCAN_IND
用于可扫描不直达网络。
Payload意义与ADV_IND类似。
二、ScaningPDUs
1)SCAN_REQ:
这是扫描请求帧,处于广播状态的接收设备接收这种帧。
此处,
ScanA为扫描者的地址,其地址由TxAdd控制是公共地址还是随机地址。
AdvA为该扫描帧的目的地址。
由RxAdd控制意义。
2)SCAN_RSP
扫描确认。
处于广播状态的设备在收到扫描请求后,需要回复扫描确认帧。
AdvA地址意义由TxAdd确定。
ScanRspData为广播端的附带数据。
三、InitiatingPDU
该部分为连接发起协议。
发起的帧格式仅一种:
CONNECT_REQ。
由发起方发送该帧,广播方接收该帧。
1)CONNECT_REQ
CONNECT_REQ帧格式如下:
TxAdd确认InitA地址为公共地址还是随机地址;
RxAdd确认AdvA地址为公共地址还是随机地址。
LLData的数据格式如下:
AA:
AccessAddress
CRCInit:
CRC校验的初始值,它应该是LinkLayer产生的一个随机值。
WinSize:
发送窗长度参数。
transmitWindowSize=WinSize。
WinOffset:
发送窗起始偏移量。
TransmitWindowOffset=WinOffset。
上述两个window意义如下:
Interval:
确定connectinterval的时间长度。
connInterval=Interval*1.25ms。
Latency:
connSlaveLatency=Latency。
TimeOut:
connSupervisionTimeout=Timeout*10ms〔100ms~32s之间〕,当两帧数据之间的时间间隔超过6*connInterval或者connSupervisionTimeout时,则认为连接丧失。
ChM:
即ChannelMAP,一共0~36个信道。
LSB代表channel0,哪一个是1,则哪一个信道有效。
Channel37~39保留。
Hop:
5~16之间的随机值,用于设置HopIncrement。
用于计算不使用的信道编号。
unmappedChannel=(lastUnmappedChannel+hopIncrement)mod37
如果计算结果是属于保留信道,则通过下式计算:
remappingIndex=unmappedChannelmodnumUsedChannels
SCA:
设置Master睡眠时钟精确度的最大值。
对应表如下:
四、DataChannelPDU
数据信道的帧格式如下:
其中包括16bitHeader,长度可变的Payload,和一个信号完整性确认字段〔MIC〕。
1、关于Header和MIC
Header的数据格式如下:
每个字段的意义如下:
MIC字段使用的时候,有两个条件:
1、不能使用于非加密的数据帧;2、数据帧payload长度不能为0。
字长为4byte。
2、关于Payload
Payload分为两类,LLDataPDU和LLControlPDU〔LLID==11b〕。
LLDataPDU里面又分为两类,一类是完整数据帧或帧碎片起始帧〔LLID==10b〕,另一类是帧碎片〔LLID==01b〕。
其中,帧碎片帧的帧长度可以为0,而完整〔起始〕帧的长度不可以为0。
下面具体介绍LLControlPDU:
LLControlPDU的帧格式如下:
其帧长度不能为0,其中包含两个字段:
Opcode和CtrData。
Opcode用于确定控制帧类型:
假设收到的LLCPDU格式不支持或者是无用帧,则回复LL_UNKNOWN_RSPPDU,此时的Type字段需设置成收到的无用的opcode。
LL_CONNECTION_UPDATA_REQ:
该帧的帧格式如下:
这些信息的意义在下一章的四中有详述。
LL_CHANNEL_MAP_REQ:
LL_TERMINATE_IND:
这个ErrorCode在蓝牙协议中有具体制定意义。
[Vol2PartD]
LL_ENC_REQ:
和加密相关的请求帧
LL_ENC_RSP:
和加密相关的回复帧
LL_START_ENC_REQ:
没有CtrData字段
LL_START_ENC_RSP:
没有CtrData字段
LL_UNKNOWN_RSP:
LL_FEATURE_REQ:
LL_FEATURE_RSP:
LL_PAUSE_ENC_REQ:
没有CtrData字段
LL_PAUSE_ENC_RSP:
没有CtrData字段
LL_VERSION_IND:
LL_REJECT_IND:
关于蓝牙通信协议的理解
一、时钟要求
Active状态下小于±50ppm。
SleepMode下小于±500ppm。
二、设备过滤
除了仅支持不可连接的广播系统〔non-connectableadvertising〕,其他模式均需支持设备过滤。
广播、扫描、连接发起均具有各自独立的过滤机制。
如果芯片不支持这几种模式的话,那就可以不支持设备过滤。
设备过滤是为了尽量减少不必要的数据通信。
设备过滤时需要具备一个白名单,白名单内容包括不过滤设备的地址和地址类型〔公共或随机〕。
白名单内容由HOST设置。
以下对各种过滤模式作一个介绍:
1、广播过滤
支持过滤方式如下,一次仅支持一种方式:
·广播设备仅处理来自白名单的设备的扫描、连接请求。
·广播设备处理一切设备的扫描、连接请求。
〔复位值〕
·广播设备处理所有设备的扫描请求,仅处理白名单的连接请求。
·广播设备处理所有设备的连接请求,仅处理白名单的扫描请求。
2、扫描过滤
支持过滤方式如下:
·扫描设备仅处理来自白名单设备的广播帧。
·扫描设备处理一切设备的广播帧。
假设广播方已经过滤该扫描设备的话,通信不能成功。
3、发起过滤
支持过滤方式如下:
·被发起设备处理来自白名单内所有设备的连接发起请求。
·被发起设备忽略白名单,仅处理host给出设备的连接发起请求。
三、非连接状态简述
1、standby
Standby是复位后的芯片初始状态,由它可以进入广播、扫描和连接状态。
2、advertising
进入广播状态后,便开始发送广播帧。
在发送完一帧广播帧以后,advertisingevent将被关闭,来适应其他功能。
广播事件有以下几种类型:
第一帧广播帧应该在channelindex中的最低的广播信道发送。
广播事件是否有回复帧由广播帧类型决定,具体如下表:
当收到错误的返回帧时,广播端会在下一个广播信道发送广播帧,或直接停止广播事件。
广播事件间隔必须是625us的倍数,范围在,其设置方式如下:
T_advEvent=advInterval+advDelay
scannableundirected和non-connectableundirected事件,advInterval长度必须大于100ms;connectableundirected事件,advInterval长度必须大于等于20ms。
advDelay是0~10ms的伪随机数。
连续广播帧发送示意图如下:
a〕ConnectableUndirectedEventType
如图接收到CONNECT_REQ之后,广播方便退出广播状态,进入Slave状态。
b〕ConnectableDirectedEventType
c〕ScannableUndirectedEventType
d〕Non-connectableUndirectedEventType
1、scanning
检测状态是用来监听广播帧的,其状态由HOST控制,分为主动扫描和被动扫描。
扫描状态下有两个参数scanWindow、scanInterval用于设置一次扫描的时间。
扫描时间不能长与,scanWindow 被动扫描〔PassiveScanning〕: 只接收帧,不发送帧。 主动扫描〔ActiveScanning〕: 监听广播帧,根据广播帧格式,回复相应帧。 ADV_IND/ADV_SCAN_IND->SCAN_REQ ADV_DIRECT_INDPDU/ADV_NONCONN_IND不回复SCAN_REQ 扫描需进行退避操作。 具体看文档吧,就不贴进来了。 2、initiating initiating没有channelindex的限制。 当收到一个在过滤白名单内的ADV_IND或ADV_DIRECT_IND,发起者将会发送一个CONNECT_REQ给广播方。 发送完CONNECT_REQ后退出发起状态,进入连接状态。 四、连接状态简述: 当发起者发送CONNECT_PDU或者广播方收到CONNECT_REQ,则认为连接被创建,但此时并非认为已经建立连接。 只有当正式开始数据通信后,才认为连接已经被建立。 连接建立后,连接中有两个角色: Master和Slave。 Master主控connectionevent的时序。 每次connectionevent便是Master和Slave的一次同步结点。 1、连接事件〔ConnectionEvents〕 一次连接时间,使用同一个channelindex。 每次连接至少进行一次数据传输。 Slave端在接收到来自Master的数据帧后,无论CRC是否正确,均需要回复数据,除非多次连续CRC不正确。 Master也是不管Slave发过来的帧是否正确,均需回复数据,没有除非。 无论CRC是否正确,我们都认为Header是对的。 Master收不到来自Slave的数据,则关闭connectionevent。 Master和Slave都能关闭此次connection。 连接事件持续时间长度由connInterval和connSlaveLatency决定。 每次连接事件的起始点称作anchorpoint。 在anchorpoint,Master开始发送数据,Slave开始接收数据。 connInterval便是本次连接的持续时间。 Master必须确保本次连接时间在下次anchorpoint之前间隔T_IFS的时间关闭。 connInterval长度必须是的倍数,长度在不等。 connInterval由发起者通过CONNNECT_REQ传送给广播方。 connSlaveLatency是Slave端允许的监听延时时间,其长度范围如下: 0~((connSupervisionTimeout/connInterval)-1)且必须小于500。 也就是说,假设connSlaveLatency=0,则Slave需要在每个anchorpoint时刻监听。 没收到设置connSlaveLatency的帧时,亦如是。 Master和Slave均有一个16bit的计数器connEventCounter每有一次connectionevent,计数器就加一,假设溢出则循环。 它是用于LinkLayer作同步时用。 Slave在等待connSlaveLatency时,该计数器亦计数。 2、连接超时〔SupervisionTimeout〕 蓝牙系统为了检测连接丧失,便设置了一个SupervisionTimeout计数器TLLconnSupervision。 每次接收到数据帧,则计数器清零。 SupervisionTime超过以下几个范围则认为超时: ·大于6*connInterval ·大于connSupervisionTimeout connSupervisionTimeout为10ms的倍数,范围是100ms~32s,并且小于(1+connSlaveLatency)*connInterval。 Timeout以后,设备停止发送,进入Standby状态,并且上报中断。 3、发送窗〔TransmitWindow〕 TransmitWindow的信息包含在CONNECT_REQ中,传送给发起者。 发送窗起始是在收到CONNECT_REQ之后transmitWindowOffset5ms, transmitWindowSize定义发送窗的宽度。 transmitWindowOffset范围的倍数,0ms~connInterval。 transmitWindowSize范围的倍数,1.25ms~10ms|connInterval-1.25ms。 4、主设备〔MasterRole〕 建立连接后,发起的一方成为Master。 连接状态建立以后,Master重新设置TLLconnSupervision,LinkLayer确认连接已经建立。 随后Master在transmitwindow时间内开始发送第一个数据帧,Master的第一帧长度可以超过transmitwindow。 Master决定第一个anchorpoint, 下一个anchorpoint=connInterval+firstanchorpoint。 以下是一个例子: 5、从设备〔SlaveRole〕 建立连接后,广播的一方成为Slave。 Slave一方也相同,重新设置TLLconnSupervision,LinkLayer确认连接已经建立。 连接建立后的第一帧,无论CRC是否收对,都把它作为第一次连接事件的anchorevent。 假设第一个transmitwindow没有收到数据帧,则准备在下一个transmitwindow下接收数据,而此时事件同步计数器connEventCount亦加一。 6、关闭连接事件〔ClosingConnectionEvents〕 Header中的MD位标识是否该次事件之后还有数据发送。 假设MD置位,则Master接着发,Slave接着收。 任何一方收不到对方的帧了,均关闭连接事件。 连续两次收到数据CRC不对,也关闭连接事件。 总结如下: 7、发送窗拓宽〔WindowWidening〕 由于发送端接收端都存在晶振频偏,所以可能会导致Slave端anchorpoint不同步,因此Slave每次接收完一个数据帧,均需同步一次anchorpoint。 接收端需要根据发送端的频偏MasterSCA和接收端频偏SlaveSCA来计算接收端的接收窗拓宽参数,以保证数据成功接收。 计算方式如下: 其值应小于((connInterval/2)-T_IFSus)。 假设到达这个值,则认为连接丧失。 8、信道列表选择〔DataChannelIndexSelection〕 Master端需要给此次连接的信道分类: 使用信道和不使用信道。 使用信道最少为两个。 信道分类由HOST产生。 而Slave的ChannelMap通过CONNECT_REQ帧接收到本地。 连续的connectionevent每次需要获取两个参数unmappedChannel和lastUnmappedChannel。 前者是此次连接没有使用过的信道列表,后者是前一次连接未用过的信道编号。 未用信道编号计算方法如下: unmappedChannel=(lastUnmappedChannel+hopIncrement)mod37 假设unmappedChannel为usedChannel的话,则此次的ChannelIndex则根据这个unmappedChannel得到该次connection所使用的Channel。 假设unmappedChannel为unusedChannel,则根据下面公式计算得到一个remappingIndex。 remappingIndex=unmappedChannelmodnumUsedChannels 总结如下列图: 9、确认机制和数据流控制〔AcknowledgementandFlowControl〕 数据确实认依靠transmitSeqNum〔SN〕和nextExpectedSeqNum〔NESN〕来控制。 NESN用于确认前一帧是否接收正确,是否需要重发。 刚刚进入连接状态,SN和NESN均需设置成0。 控制方式如下列图: NESN在一种情况下不会被更新,就是接收BUFFER不够的情况。 这会使发送端重传该帧,如此实现数据流控制。 五、LinkLayer控制描述 LLCP〔LinkLayerControlProtocol〕是用来控制两个LinkLayer之间的控制和协商的。 其中包括连接控制,加密控制等等。 1、LinkLayer连接更新和ChannelMap更新 每次进入连接状态后,设备均需更新connInterval,connSlaveLatency和connSupervisionTimeout。 Master通过发送LL_CONNECTION_UPDATE_REQ帧来实现参数更新,Slave不能发送这种格式的帧,它通过使用L2CAP信道回复更新确认来确认参数更新。 参数更新之前使用老的参数,更新之后使用新参数。 Slave端收到LL_CONNECTION_UPDATE_REQ之后,假设 connEventCountmod65535小于32767,并且不等于本地的connEventCount,此时它需监听所有的ConnectionEvent,直到确认Master收到自己的REQACK。 Slave在确认两边connEventCount相等之前的ConnectionEvent均需要监听。 假设connEventCountmod65535大于32767,则Slave认为与Master丧失连接,回到Standby状态,并上报主机。 Master这边,需要在第一个TransmitWindow内发送数据,它发送的这帧数据作为此次Connection的anchorpoint。 Master在这个anchorpoint以后更新它的connInterval,并清零TLLconnSupervision计数。 假设使用自动发送LL_CONNECTION_UPDATE_REQ,则Timeout参数不跟新,与前次LL_CONNECTION_UPDATE_REQ或者CONNECT_REQ设置时相同。 其他参数亦如是。 自动更新机制用于Master由于其他需求,需要更改anchorpoint时间。 ChannelMap的更新由LL_CHANNEL_MAP_REQ完成, 2、加密 加密参数设置通过LL_ENC_REQ和LL_ENC_RSP 开始加密: LL_START_ENC_REQ和LL_START_ENC_RSP 结束加密: LL_PAUSE_ENC_REQorLL_TERMINATE_INDPDUs EmptyPDUsorLL_PAUSE_ENC_RSPorLL_TERMINATE_IND 3、FeatureSetExchange 进入连接状态以后,蓝牙设备之间需要交换各自所支持的功能参数。 该过程通过LL_FEATURE_REQPDU和LL_FEATURE_RSPPDU交换信息。 数据帧交换时间关系如下: 具体的Feature对应位如下列图所示: 4、VersionExchange 主从之间交换设备所支持的蓝牙协议版本信息,通过LL_VERSION_IND来交换信息。 其信息包括: VersNr: 所支持的蓝牙协议 CompId: 认证信息 SubVersNr: Controller的实现版本号。 5、TerminationProcedure 终止通信,通过LL_TERMINATE_IND来交换信息。 IP架构 以下是几个理解上的难点: 一、关于ExchangeTable和ControlStructure ExchangeMemory是一个动态的存储器件,其中包括了ExchangeTabel、ControlStructure、T/RxDescriptor、T/RxBuffer,它们之间的连接都是由指针完成。 关系大概如下: 首先需要将ControlStructure和TRXDescriptor在EM中配置完成后,再配置ExchangeTabel。 其可配置的空间如下列图所示: 也就是说首先需要在0x0050~0xFFFF地址内配置ControlStructure、Descriptor和DataBuffer,然后在0x0000~0x001F内配置C
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 功耗 蓝牙 BLE 学习 记录