http://blog.chinaunix.net/uid-28852942-id-5748595.html
解决第三个问题:如何使能从机上的特征值的 notify功能,使其能通过notify方式发送数据
使能从机的notify功能是通过写0x0001到从机的那个具有notify功能的特征值的CCCD描述符中来实现的。 既然要写那就需要先有服务发现过程,服务发现就是找到从机里我们需要的服务以及服务下面的 特征值,描述符等。 关于服务发现过程的具体讲解 参见 服务发现过程解析 教程。
因为服务发现过程sdk已经做好了,我们不需要去处理。我们要做的就是注册自己需要找的那个服务。 对于sdk中的这个主从例子来说。因为实现的就是从机按键然后发数据给主机,主机对应亮/灭 led灯, 功能很简单,所以从机就定义了一个服务,该服务只包含一个 具有notify功能的特征值,以用来发送数据给主机。可以在从机的services_init函数中看到,如下图:
![](http://blog.chinaunix.net/attachment/201607/26/28852942_1469534876Bpkh.png)
![](http://blog.chinaunix.net/attachment/201607/26/28852942_1469534880ITit.png)
服务和其下的特征值的UUID定义如上图。这里是128位的uuid,所以还有个自定义的基准uuid
所以对于主机端来说,主机端只要 找到这个我们需要的服务以及它下面的那个具有notify功能的特征值和CCCD就可以了。然后直接写0x0001到CCCD,就使能从机的notify功能了。
前面说道主机工程中sdk已经做好了服务发现的相关流程,也就是主机连接上从机后会自动开始查找从机里面我们需要的服务,特征值等信息。所以我们需要做的就是直接指明自己想要找的那个服务就行了。 SDK提供的机制就是注册机制,也就是SDK在执行完 服务发现过程前会有个初始化,在这个初始化中注册自己想要找的服务,以及对应的回调处理函数。之后会自动进行服务查找,并且查找完成后会调用之前一同注册的回调函数
综上 要做的其实就是注册 上面说过的 从机中创建的那个服务和对应处理函数,在main函数中的client_handling_init就做了如上处理
![](http://blog.chinaunix.net/attachment/201607/26/28852942_1469534881E3hu.png)
该函数首先设置了和从机一样的 基准UUID和服务UUID,然后调用
ble_db_discovery_evt_register函数注册改服务和回调函数db_discovery_evt_handler。如下图所示。
![](http://blog.chinaunix.net/attachment/201607/26/28852942_1469534882sStT.png)
所以最终当主从机连接完成后,主机执行服务发现过程,开始查找我们调用ble_db_discovery_evt_register函数注册过的要找的服务。 找到了从机上的服务之后,然后便调用一同注册的回调函数db_discovery_evt_handler。
再来看下这个回调函数的实现
回调函数的目的就是找到从机上那个服务下面的具有notify特性的特征值,并且记录下是第几个,然后调用写函数 写改特征值的 附属描述符CCCD来实现使能notify功能。(demo中虽然这个服务下面只有一个特征值,但是代码中实际还是有一个查找过程,因为一般情况下可能会存在多个特征值)如下图所示
![](http://blog.chinaunix.net/attachment/201607/26/28852942_1469534883qPir.png)
再看下notify_enable的实现,就是写0x0001到该特征值的附属描述符CCCD中以实现使能从机上改特征值的notify功能
![](http://blog.chinaunix.net/attachment/201607/26/28852942_1469534884pVo3.png)
正常情况下,上面执行后,从机的中服务下面的那个唯一的特征值的notify功能就已经被使能了,后续从机应该就可以使用notify方式来发送数据给主机了。但是demo中到这里其实并未使能从机的notify功能,原因在于从机中对 其特征值的附属描述符CCCD做了安全要求,要求写该描述符时是需要链路被加密过的。如下图
在从机的services_init函数中有下面这段设置。
因为主从连接上后,链路并不是加密的,所以当之前的 为了使能notify而写CCCD的操作发送给从机后,从机就会返回 安全不足错误。
因为上面的notify_enable中是通过BLE_GATT_OP_WRITE_REQ 即需要回复的写操作,主机于是在收道BLE_GATTC_EVT_WRITE_RSP事件后判断是不是有安全不足错误,是就启动建立加密链路。如下图
![](http://blog.chinaunix.net/attachment/201607/26/28852942_1469534885hF7m.png)
后续就是安全链路的建立。实际就是配对绑定的过程。Sdk中已经做好了这些过程。这部分内容比较多,这里不便展开。前面也有一些关于配对绑定的一些教程,感兴趣的可以自己花时间看下。
上面的dm_security_setup_req调用后,主机就启动配对绑定过程来加密链路了。当链路加密完成后,协议栈会产生 BLE_GAP_EVT_CONN_SEC_UPDATE事件给派发函数
![](http://blog.chinaunix.net/attachment/201607/26/28852942_1469534886nQQo.png)
在dm_ble_evt_handler处理函数中处理了该事件
![](http://blog.chinaunix.net/attachment/201607/26/28852942_1469534887GKvV.png)
处理过程就是 设置了一个内部事件id(dm 这个设备管理模块内部自定义的事件),然后再转交给device_manager_event_handler 函数处理(这个过程前面有描述),这个函数最后又会调用client_handling_dm_event_handler函数,再最后这个函数内部会判断是不是链路加密完成事件,如果是就再次 通过notif_enable 函数来使能从机上特征值的notify功能
如图所示
![](http://blog.chinaunix.net/attachment/201607/26/28852942_14695348889rZv.png)
到这里,主机如何使能从机上的特征值的notify功能也解决了。
最后一个问题:如何通信,即从机如何在按键后将信息发给主机
在从机main初始化中对 按键模块做了初始化,并注册了一个按键事件回调函数
![](http://blog.chinaunix.net/attachment/201607/26/28852942_1469534888146t.png)
![](http://blog.chinaunix.net/attachment/201607/26/28852942_1469534889sjG3.png)
sdk9中的程序都是根据官方PCA10028板子来编写的,这个板子上有四个按键button1-4分别对应引脚pin0.17-pin0.20,当初始化函数buttons_leds_init被调用后,就默认配置这四个按键被按下时对应产生BSP_EVENT_KEY_0- BSP_EVENT_KEY_3事件。
Sdk中主从demo做的是,从机按下button1主机就会对应亮/灭某个led灯(具体第几个有从机是第几个连接上的决定),所以从机中对button1按键做了处理,因为button1按键会产生BSP_EVENT_KEY_0事件,所以按键事件处理函数中就对该事件做了处理,具体就是 使用notify发送一个值给主机,如下图
![](http://blog.chinaunix.net/attachment/201607/26/28852942_1469534890U7bk.png)
主机端收到从机的notify后协议栈产生BLE_GATTC_EVT_HVX事件,并由派发函数递交给client_handling_ble_evt_handler处理函数
![](http://blog.chinaunix.net/attachment/201607/26/28852942_1469534890o08s.png)
client_handling_ble_evt_handler函数中首先找到是第几个连接的从机发来的数据,然后将index作为参数 传递给on_evt_hvx函数最终处理
![](http://blog.chinaunix.net/attachment/201607/26/28852942_14695348918QM9.png)
on_evt_hvx 函数最终就是根据index亮灭LED,因为板子上LED只有4个,所以index<4,主机上的led灯才会对应亮/灭。
![](http://blog.chinaunix.net/attachment/201607/26/28852942_14695348928sXp.png)