蓝牙Controller框架梳理

蓝牙协议分host和controller两个部分，Host是正真意义的蓝牙协议，Controller为蓝牙底层，或者说是基带芯片。基带芯片又可以分为三个部分，Radio，Link Layer和HCI。

Radio

Radio可以理解为一个独立的协处理器，负责调制解调2.4G裸数据，完整的Radio功能应该包括，数据组包拆包，CRC校验，白话，调制解调等功能。

根据Controller的设计需要，Radio协处理器被设计为一个小型状态机，下图为Nordic 52810 Radio内核状态机状态，该状态机分为9种状态，Radio会输出下图9种状态给SOC芯片，SOC芯片根据相应状态机状态，进行处理，协处理器和SOC之间共用数据总线。

Link layer架构

Link Layer决定蓝牙所处的状态，蓝牙可以分为idel（standby），adv，scan，init以及connection状态，connection又可分为master或者slave。状态之间可以相互转换。

Link Layer允许多种状态同时并存，一个piconet可以支持多种状态，即Combination States。Combination States并不是任意若干种状态的结合，其中有限制存在，比如一个piconet不可能同时支持master和slave状态，比如两个scan不能同时存在，下图多多状态的二维组合分布图。

HCI架构

蓝牙和蓝牙WIFI二合一芯片HOST和Controller早期都是两类芯片厂家分开提供，两颗芯片交互需要采用统一标准，HCI层由此而来。Host蓝牙协议只需要按照蓝牙联盟规范的HCI指令即可控制蓝牙controller。

Controller宏观认知

ADV广播

SCAN扫描

INIT初始化

Connection连接

Controller核心框架

核心架构

Link Layer和芯片Radio设计相关度较大，根据与PYH（radio）传输接口的不一样，可以分为：

• Radio负责packet，即硬件只提供收或者发一个包的接口。

• Radio负责frame，即硬件提供包含一个IFS的一组收发的接口。

• Radio硬件负责event，即硬件提供控制整个event内，若干组收发的接口（CEVA BLE IP的实现采用的就是这种）。

三种方案数字设计的复杂度是递增的，灵活性是递减的，对CPU的处理能力需求是递减的。

LL调度机制-Radio负责packet

以Radio负责packet的方案介绍LL的整体设计思路：

根据Radio状态机的9种状态，设计Link Layer中的adv，scan，init，master，slave 事件，事件之间的存在如下相互转换关系：

每个事件结束后，调用任务调度机，决定ll下一个状态，下一个ll状态可能是当前状态的延续，可能是新的状态，也可能是当前状态和新的状态的Combination，所以ll调度机不光决定一个状态，还需要考虑多状态能否共存，Scheduler确定是否能执行下一个状态后，启动该任务，执行该任务。

谈到状态共存，adv，scan，init必须给connection事件让步，在这个时间内，哪些事可以提前做，哪些事需要推迟做，这是Scheduler需要考虑的。

总结

LL事件，Scheduler任务调度，HCI组包解包是构成Radio的三大模块， 弄清楚整个控制框架，配合时间戳要求，才能把controller玩转起来，controller时间戳同步也是一个非常头疼的话题，特别是搅合在任务调度一起，到此了。

 

参考资料

Ble_101_frontline

Nordic52810 spec

蓝牙5.2spec