蓝牙BLE: GATT Profile 简介(GATT 与 GAP)

一. 引言

现在低功耗蓝牙(BLE)连接都是建立在 GATT (Generic Attribute Profile) 协议之上。GATT 是一个在蓝牙连接之上的发送和接收很短的数据段的通用规范,这些很短的数据段被称为属性(Attribute)。

二. GAP

详细介绍 GATT 之前,需要了解 GAP(Generic Access Profile),它在用来控制设备连接和广播。GAP 使你的设备被其他设备可见,并决定了你的设备是否可以或者怎样与合同设备进行交互。例如 Beacon 设备就只是向外广播,不支持连接,小米手环就等设备就可以与中心设备连接。

2.1 设备角色

GAP 给设备定义了若干角色,其中主要的两个是:外围设备(Peripheral)和中心设备(Central)。

外围设备:这一般就是非常小或者简单的低功耗设备,用来提供数据,并连接到一个更加相对强大的中心设备。例如小米手环。
中心设备:中心设备相对比较强大,用来连接其他外围设备。例如手机等。

2.2 广播数据

在 GAP 中外围设备通过两种方式向外广播数据: Advertising Data Payload(广播数据)和 Scan Response Data Payload(扫描回复),每种数据最长可以包含 31 byte。这里广播数据是必需的,因为外设必需不停的向外广播,让中心设备知道它的存在。扫描回复是可选的,中心设备可以向外设请求扫描回复,这里包含一些设备额外的信息,例如设备的名字。(广播的数据格式我将另外专门写一个篇博客来讲。)

2.3 广播流程

GAP 的广播工作流程如下图所示。

从图中我们可以清晰看出广播数据和扫描回复数据是怎么工作的。外围设备会设定一个广播间隔,每个广播间隔中,它会重新发送自己的广播数据。广播间隔越长,越省电,同时也不太容易扫描到。

2.4 广播的网络拓扑结构

大部分情况下,外设通过广播自己来让中心设备发现自己,并建立GATT连接,从而进行更多的数据交换。也有些情况是不需要连接的,只要外设广播自己的数据即可。用这种方式主要目的是让外围设备,把自己的信息发送给多个中心设备。因为基于GATT连接的方式的,只能是一个外设连接一个中心设备。使用广播这种方式最典型的应用就是苹果的iBeacon。广播工作模式下的网络拓扑图如下:

三. GATT

GATT 的全名是 Generic Attribute Profile(姑且翻译成:普通属性协议),它定义两个 BLE 设备通过叫做 Service 和 Characteristic 的东西进行通信。GATT 就是使用了 ATT(Attribute Protocol)协议,ATT 协议把 Service, Characteristic遗迹对应的数据保存在一个查找表中,次查找表使用 16 bit ID 作为每一项的索引。

一旦两个设备建立起了连接,GATT 就开始起作用了,这也意味着,你必需完成前面的 GAP 协议。这里需要说明的是,GATT 连接,必需先经过 GAP 协议。实际上,我们在 Android 开发中,可以直接使用设备的 MAC 地址,发起连接,可以不经过扫描的步骤。这并不意味不需要经过 GAP,实际上在芯片级别已经给你做好了,蓝牙芯片发起连接,总是先扫描设备,扫描到了才会发起连接。

GATT 连接需要特别注意的是:GATT 连接是独占的。也就是一个 BLE 外设同时只能被一个中心设备连接。一旦外设被连接,它就会马上停止广播,这样它就对其他设备不可见了。当设备断开,它又开始广播。

中心设备和外设需要双向通信的话,唯一的方式就是建立 GATT 连接。

3.1 GATT连接的网络拓扑

下图展示了 GTT 连接网络拓扑结构。这里很清楚的显示,一个外设只能连接一个中心设备,而一个中心设备可以连接多个外设。

 一旦建立了连接,通信就是双向的了,对比前面的GAP广播的网络塔扑,GAP通信是单向的。如果你要让两个外围设备能通信,就只能通过中心设备中转

3.2 GATT 通信事务

GATT通信的双方是C/S关系。外设作为GATT服务端(Server),它维持了ATT的查找表以及service和characteristic的定义。中心设备是GATT客户端(Client),他向Server发起请求。需要注意的是,所有的通信事件,都是由客户端(也叫主设备,Master)发起,并且接收服务端(也叫从设备,Slava)的响应。
一旦连接建立,外设将会给中心设备建议一个 连接间隔(Connection Interval),这样,中心设备就会在每个连接间隔尝试去重新连接,检查是否有新的数据。但是,这个连接间隔只是一个建议,你的中心设备可能并不会严格按照这个间隔来执行,例如你的中心设备正在忙于连接其他的外设,或者中心设备资源太忙。

下图展示一个外设(GATT服务端)和中心设备(GATT客户端)之间的数据交流流程,可以看到的是,每次都是主设备发起请求:

3.3 GATT 结构

GATT事务是建立在嵌套的Profiles,Services和Characteristics之上的,如下如所示:

  • Profile Profile并不是实际存在于BLE外设上的,它只是一个被Bluetooth SIG或者外设设计者预先定义的Service的集合。例如心率Profile(Heart Rate Profile)就是结合了Heart Rate Service和Device Information Sercvice。所有官方通过GATT Profile的列表可以从这里找到。

  • Service Service是把数据分成一个个的独立逻辑项,它包含一个或者多个Characteristic。每个Service有一个UUID唯一标识。UUID有16bit的,或者128bit的。16bit的UUID是官方通过认证的,需要花钱购买,128bit是自定义的,这个就可以自己随便设置。

    官方通过了一些标准Service,完整列表在这里。以Heart Rate Service为例,可以看到它的官方通过16bitUUID是 0x180D,包含3个Characteristic:Heart Rate Measurement,Body Sensor Location和Heart Control Point,并且定义了只有一个第一个必须的,它是可选实现的。

  • Characteristic 在GATT事务中的最低界别的是Characteristic,Characteristic是最小的逻辑数据单元,当然它可能包含一个组关联的数据,例如加速度计的X/Y/Z三轴值。与Service类似,每个Characteristic用16bit或者128bit的UUID唯一标识。你可以免费使用Bluetooth SIG官方定义的标准Characteristic,使用官方定义的,可以确保BLE的软件和硬件能相互理解。当然,你可以自定义Characteristic,这样的话,就只有你自己的软件和外设能够相互理解。

    举个例子,Heart Rate Measurement Characteristic,这是上面提到的Heart Rate Service必需实现的Characteristic,它的UUID是 0x2A37。它的数据结构是,开始8bit定义心率数据格式(是UINT8还是UINT16?),接下来就是对应格式的实际心率数据。

    实际上,和BLE外设打交道,主要是通过Characteristic。你可以从Characteristic读取数据,也可以往Characteristic写数据。这样就实现了双向的通信。所以你可以自己实现一个类似串口(UART)的service,这个Service中包含两个Characteristic,一个被配置只读的通道(RX),另一个配置为只写的通道(TX)。

更多内容

参考链接


蓝牙BLE: GATT Profile 简介(GATT 与 GAP)

I2C总线协议图解

I2C 总线在物理连接上非常简单,分别由SDA(串行数据线)和SCL(串行时钟线)及上拉电阻组成。通信原理是通过对SCL和SDA线高低电平时序的控制,来产生I2C总线协议所需要的信号进行数据的传递。在总线空闲状态时,这两根线一般被上面所接的上拉电阻拉高,保持着高电平。

I2C通信方式为半双工,只有一根SDA线,同一时间只可以单向通信,RS485也为半双工,SPI和UART为双工。

继续阅读I2C总线协议图解

白皮书:ARM big.LITTLE 系统的软件技术

ARM big.LITTLE 系统的软件技术

Robin Randhawa,首席工程师2013 4

简介

移动应用已经发生了显著变化,当今的消费者更多地将智能手机应用于大部分互联生活。其中既包括高性能任务,例如网络浏览、导航和游戏,也包括那些要求不太苛刻的“始终在线,始终连接”后台任务,例如语音呼叫、社交网络和电子邮件服务。因此,移动电话已经成为很多消费者必不可少的计算设备。同时,平板电脑等新型移动设备也在重新定义计算平台,以应对消费者的需求。这一趋势为消费者创造了全新的内容互动方式,将以往只可能在固定设备上实现的应用带到移动设备上。这才是真正的智能下一代计算。

摩尔定律将如何往下发展?人们过去预测集成电路上可容纳的晶体管数目每隔 18 个月会增加一倍,直至从数千个增加至数十亿个晶体管,但如果真正审视单个处理器,却会发现它的性能增长停滞不前,因为您可以在系统中消耗的电能已经达到峰值。

对于未来的任何一款处理器,散热必然会限制其速度的大幅提高。一旦达到器件的热障,器件会融化,如果是在移动电话上,设备会开始发热,让用户感到不适。除了物理散热问题之外,能效也会变得相当低。如果调节处理器实施,使其速度逐渐加快,则其能耗将呈指数级增长,而为了增加最后这一丁点的性能,却会导致成本大幅提升。过去,尺寸增大一倍也意味着速度提高一倍,但到了现在,尺寸增大一倍却只能将速度提高几个百分点,因此出于复杂性的原因,效益不复存在,这也是单核系统的速度达到极限的原因之一。

如果您无法让单核运行更快,则必须增加核心的数量。这样做的好处还包括让每个核心能够匹配其承担的工作负载,这正是 ARM big.LITTLE™ 处理概念的用武之地。

Big.LITTLE处理技术可以解决我们当前面临的一个最大难题:扩展消费者的“始终在线,始终连接”移动体验,同时改进性能,延长电池续航时间。实现这一目标的方式是将“big”多核处理器与“LITTLE”多核处理器配合使用,根据性能要求,为适当的任务无缝选择适当的处理器。重要的是,这种动态选择对在处理器上运行的应用程序软件或中间件是透明的。 设备中采用的最新一代big.LITTLE 设计将高性能Cortex™-A15 多处理器集群与高能效Cortex-A7 多处理器集群组合在一起。这些处理器保持了 100% 架构兼容性,并且具有相同的功能(支持 LPAE 和虚拟化扩展,以及 NEON™ VFP 等功能单元),这使得针对一种处理器类型编译的软件应用程序能够在其他处理器上运行,而无需进行修改。
继续阅读白皮书:ARM big.LITTLE 系统的软件技术

Ti CC1310 SDK版本兼容

在开发Ti CC1310应用的时候遇到了SDK版本兼容问题。早期的应用都是从SDK 1.60版本的例子中修改得来的,最近在升级到SDK 2.x版本的时候遇到了编译不通过的问题。主要是某些变量名的定义改变了。

但是,翻遍了代码也没找打一个SDK版本宏。

于是只能通过ti/devices/cc13x0/driverlib/driverlib_release.h文件里面的DRIVERLIB_RELEASE_BUILD的版本号来进行区分,根据数字的不同来使用不同的代码,例子如下:

其他的就是动态链接库的位置不同,导致链接的时候报告找不到链接库,需要重新设置一下,或者简单的移除一些找不到的库即可,例子中并没有用到全部的链接库。

Code Composer Studio 8.2运行时对象查看器Runtime Object View (ROV)

Code Composer Studio 8.2提供的Runtime Object View (ROV)是一个非常好用的功能,能动态监视系统的运行情况。

该功能需要使用TI-RTOS的应用才可以正常使用。

下面是官方的参考文档:
继续阅读Code Composer Studio 8.2运行时对象查看器Runtime Object View (ROV)

GCC支持在代码中对头文件是否存在的判断(__has_include)

我们在实际编写代码的时候,经常需要判断当前编译环境是否存在我们需要的头文件,如果不存在,则使用其他头文件代替。

以前这个操作都是通过外部的configure文件生成Makefile的时候指定。

最近的GCC已经增加了__has_include这个内置函数判断头文件是否存在。

这个功能最早是Clang实现的,现在GCC终于补上了这个功能。

例子如下:

Code Composer Studio 8.2.0.00007 ,GCC 5支持这个内置函数。

参考链接


解决Ti CC1310上I2C驱动能力不足(稳定性)问题

在使用Ti CC1310的硬件I2C与外部设备进行通信的时候,无法长时间稳定运行,尤其是平时的测试开发板,使用杜邦线连接的情况下。

同等情况下的SPI总线,一般不会发生此类问题,因此怀疑是GPIO管脚的驱动能力不足导致的。

我的工程是通过简单修改Ti CC1310 SDK自带的Code Composer Studio的例子工程而创建的,因此存在已经进行过默认配置的CC1310_LAUNCHXL.cCC1310_LAUNCHXL.h这两个文件。用Code Composer Studio完全重新创建的工程,缺乏必要的默认配置。因此,我们还是建议根据Ti CC1310 SDK自带的例子进行修改,而不是完全从头创建工程。

我们研究I2C初始化GPIO管脚的代码在simplelink_cc13x0_sdk_2_30_00_20/source/ti/drivers/i2c/I2CCC26XX.c,相关的代码如下:

从上面的代码中,我们发现GPIO管脚的驱动能力没有设置,根据CC13x0, CC26x0 SimpleLink ™ Wireless MCU Technical Reference Manual中的介绍,我们发现,如果不设置,默认情况下是PIN_DRVSTR_MIN(< (*) Lowest drive strength)。这个驱动模式下,最省电,但是当有干扰存在的情况下,最容易导致出现错误。

查找Ti CC1310提供的I2C驱动程序,没有找到可以设置管脚驱动能力的接口。

网上有人通过直接修改Ti CC1310提供的I2C驱动程序,也就是simplelink_cc13x0_sdk_2_30_00_20/source/ti/drivers/i2c/I2CCC26XX.c里的初始化代码(见上面的代码段)增加驱动能力属性来实现这个功能。

但是这种修改方式不推荐,修改的侵入太强。

GPIO的操作函数中,我们找到如下函数:

我们尝试从上层找到I2C驱动使用的GPIO管脚,然后调整其驱动能力。

从上面我们看到I2C句柄的.object指针指向了I2CCC26XX_Object类型的结构体,这个结构体在simplelink_cc13x0_sdk_2_30_00_20/source/ti/drivers/i2c/I2CCC26XX.c里的static int I2CCC26XX_initIO(I2C_Handle handle, void *pinCfg)函数中被初始化,这个结构体记录了详细的GPIO操作句柄。

因此我们可以使用如下的代码对GPIO管脚的驱动能力进行调整:

参考链接


Raspberry Pi Zero W解决调试信息不足的问题(以libzmq-dev为例)

最近在参照 树莓派实时系统下脚本语言的选择(应当使用Lua而不是Python) 调用调试lua-zmq的时候,发现使用PAIR模式进行线程之间通信,长时间运行后会出现死锁的情况。

当我们需要跟踪问题的时候,使用apt-get安装的版本缺乏必要的调试信息。

我们可以手工安装调试信息包,如下:


我们也可以从源代码重新编译一份,如下:

以上是针对Debian安装包来进行的处理,然而对于luarocks安装的插件来说,默认luarocks是不能编译调试版本的,此时就需要我们手工编译了。我们以lua-zmq为例子,参考如下: