BLE-NRF51822教程3-sdk程序框架剖析

阳光穿透心脏的1/2处 2022-07-13 09:20 15阅读 0赞

http://blog.chinaunix.net/uid-28852942-id-5335038.html

本讲为框架介绍，不会牵涉到太多代码细节。

51822的官方SDK其实是没有框架依耐性的。什么叫框架，比如TI的BLE SDK中就有一个操作系统抽象层(OSAL)他是一个轮训的调度。你需要按照他的方式去创建任务等等。

而51822的SDK本质上只是提供了各种调用接口，比如开启初始化协议栈，初始化一些硬件功能模块，开始广播，发起链接等等。这些接口怎么用完全取决于自己。不过一般固件开发都是一些类似的流程各种资源的初始化，51822也不例外。所以sdk中的作为从机的例子main函数都是类似如下的步骤：

以官方的串口BLE 为例：

int main(void)

leds\_init();                           //非必须，只是该例子中用到了

timers\_init();                      //非必须，只是该例子中用到了

buttons\_init();                    //非必须，只是该例子中用到了

uart\_init();                          //非必须，只是该例子中用到了串口

**    ble\_stack\_init();               //必须**

**    gap\_params\_init();                   //必须**

**    services\_init();                  //跟自己创建的服务相关，不同的服务细节不同但大体建立                                                           
                                                //过程基本一致，通常在直接使用官    方的例子修改一些参数即可**

**    advertising\_init();            //广播数据初始化，必须**

conn\_params\_init();         //是情况而定，如果连接后不需要连接参数的协商，该初始化也                                                //可不要

sec\_params\_init();           //安全参数初始化,如果没用到配对绑定相关这个也可以不初始化

**    advertising\_start();                  //开启广播，必须**

// Enter main loop

for (;;)

power\_manage();             //进入睡眠

可以看到其实核心必要的只有这5个函数而已。你可以将其他代码全都去掉，只要留下这5个函数设备一样可以运行，手机也能搜到设备并与设备通信。

这种初始化的方式可以说是与我们一般的单片机开发没有区别。

那么初始化之后呢。以前的裸板单片机开发我们就是进入一个while循环执行一些周而复始的事，后面为了降低功耗开始在while(1)循环中加个睡眠代码让没有工作时芯片处于睡眠状态，并依靠中断来唤醒从而处理到来的事物。

而上面的51822的main函数最后也是一个for\{\}循环，power\_manage();       内部代码其实就是一个睡眠指令。Main函数到这里就已经没了，最后其实就是一个循环睡眠。这里看不到任何任务(task)，只有睡眠。那么可想而知，51822的协议栈实现应该是基于”事件唤醒”的，也就是没事的时候睡眠，有事的时候唤醒工作而后继续睡眠。那么那些处理事件的代码都是在哪里的？

**那协议栈到底是怎么运作的？**

**我希望创建一个服务在哪里添加？**

**手机发送来的数据在哪里？**

**我怎么发送数据给手机？**

下面一一解释这些问题：

**协议栈如何运作？**

要明白协议栈怎么运作，首先就要理解51822的协议栈是基于100%的事件驱动的。就是说协议栈向app发送的任何数据都是基于事件的。

比如设备收到手机发来的链接请求，或是手机发过来的数据等等。协议栈首先收到这些数据后做一些处理，然后将这些数据(比如链接请求，或是普通数据等)打包成一个结构体，并附上事件ID，比如BLE\_GAP\_EVT\_CONNECTED或BLE\_GATTS\_EVT\_WRITE来分别告诉上层app这个事件结构体代表的事件。

比如BLE\_GAP\_EVT\_CONNECTED代表链接事件，那么这个事件结构体中包含的数据就是连接参数等数据。

而BLE\_GATTS\_EVT\_WRITE代表写事件，那么结构体中的数据就是对端设备(比如手机)写给板子的数据。  
  
![28852942_1446428311ZUaQ.png][]

比如uart的demo中dispatch派发函数

static void ble\_evt\_dispatch(ble\_evt\_t \* p\_ble\_evt)

ble\_conn\_params\_on\_ble\_evt(p\_ble\_evt);

ble\_nus\_on\_ble\_evt(&m\_nus, p\_ble\_evt);

on\_ble\_evt(p\_ble\_evt);

在任何与BLE相关的事件被协议栈上抛上来给app时，ble\_evt\_dispatch就会被调用。从而将事件抛给各个服务函数或处理模块,这里是将事件抛给了

连接参数管理处理函数ble\_conn\_params\_on\_ble\_evt

Uart服务的事件处理函数ble\_nus\_on\_ble\_evt    (nus为Nordicuart server)

通用的事件处理函数on\_ble\_evt

不同的事件在事件结构体ble\_evt\_t中通过id来区别。不同是事件处理函数通常也只是处理自己感情去的事件，我们来看看ble\_nus\_on\_ble\_evt事件处理函数的内部

voidble\_nus\_on\_ble\_evt(ble\_nus\_t \* p\_nus, ble\_evt\_t \* p\_ble\_evt)

\{     
     if ((p\_nus == NULL) || (p\_ble\_evt == NULL))

return;

switch (p\_ble\_evt->header.evt\_id)

case**BLE\_GAP\_EVT\_CONNECTED**:

on\_connect(p\_nus, p\_ble\_evt);

break；

case**BLE\_GAP\_EVT\_DISCONNECTED**:

on\_disconnect(p\_nus, p\_ble\_evt);

break;

case**BLE\_GATTS\_EVT\_WRITE**:

on\_write(p\_nus, p\_ble\_evt);

break;

default:

// No implementation needed.

break;

可以看到，uart服务事件处理函数只关心三个事件，链接事件，断开链接事件以及写事件(对端设备发数据过来)，不同的事件再针对做不同的，这个就由开发人员自己来实现了。比如对于连接事件通常应该记录下事件结构体中的连接句柄，因为后续的BLE操作基本都要基于连接句柄(可以看做是两个设备通信的信道ID，实际为链路层中的数据接入地址概念)。

PS: 事件是交给dispatch来派发给各个服务以及模块的，对于更底层的事件又是如何交给dispatch函数的过程请参考群公告中的  51822教程-协议栈概述教程。

解决了所谓的事件驱动再来解决：**如果希望创建一个服务在哪里添加？**

在main函数的初始化过程中有一个services\_init();这个函数的内部就是添加服务，添加特征值等代码。

函数内部其实就是注册了一会回调函数nus\_data\_handler(该函数会在手机发数据给板子时将数据从电脑串口打印出来) 然后再执行真正的初始化函数ble\_nus\_init。

该函数的内部又会调用sd\_ble\_gatts\_service\_add这个协议栈的api接口来添加服务。

后面也会调用sd\_ble\_gatts\_characteristic\_add这个协议栈的api接口来添加特征值。

层次关系如下：  
![28852942_1446649610NA7D.png][]

也就是说完成一个完整的服务建立函数其实只要**sd\_ble\_gatts\_service\_add()和sd\_ble\_gatts\_characteristic\_add ()**这两个核心函数。

通常建立服务并不需要自己去从头写过。而是直接赋值官方的这个services\_init()函数，然后做一些小改动就可以。比如修改一下uuid, 修改一下读/写属性，多添加一个特征值等。要修改的其实很少。

** **

**下面解决最后两个问题：手机发送来的数据在哪里？我怎么发送数据给手机？**

要搞清楚这两个问题，先来看一下群里常问的几个与上面相关的问题：

问：

手机发给51822设备的数据在哪个函数里出来的呀，   
答：  
    没有函数  
    协议栈会抛上来一个事件结构体  
    收到的数据在结构体中

问：

蓝牙上传函数，与下发函数都是一样的吗？都是服务API函数？  
答：  
    只有上传函数 是服务器用来将数据传给客户端的。  
    下发数据  是蓝牙芯片收到数据后，协议栈会拋上来一个有数据的事件结 构体。具体参看示例代码中的 dispatch派发程序中各个事件处理函数对各   种事件的数据。

问：

sd\_ble\_gatts\_hvx（）这个函数是 蓝牙的发送函数，有知道蓝牙的接收函数 ？  
答：  
       蓝牙没有接收函数，蓝牙的数据接收在底层，接收完后会返回事件给上层的 ble\_evt\_dispatch 分发函数，它将事件分发给各个服务或者事件处理函数。  服     务或处理函数会捕获是否存在写事件case BLE\_GATTS\_EVT\_WRITE:  存在就做    相应的处理。收到的数据都在返回的事件结构体里

其实看完这三个问题基本上上面的问题其实已经解决差不多了。作为从设备，BLE的发送数据给手机是有API接口的，就是上面问到的sd\_ble\_gatts\_hvx（），可以通过参数来设置是以通知方式发送还是指示方式发送(通知不需要回复确认，指示需要)。但是手机发过来数据却是没有接收函数，为什么？因为协议栈是基于事件驱动的！所以收到数据后协议栈会给上层app一个写事件(指示对端设备写数据过来了)，而写过来的数据时在这个事件结构体中。我们只要提取出来就行了。所以没有接收函数API。

从另一方面也可以解释为什么没有接收数据函数。因为发送数据时”同步的”，是主动调用的，在往想发送数据的时候。但是接收数据时”异步的”，数据可能随时到来，总不来一直调用一个函数然后原地等待数据到来吧，如果数据不来岂不是什么事都干不了了。所以接收是基于事件驱动的。有数据来再转过去处理。

用个图来解释下：

![28852942_1446649718oYAD.png][]

如果还是觉得有点抽象，回到前面看看协议栈运作讲解部分。应该更能体会所谓的事件驱动

[28852942_1446428311ZUaQ.png]: http://blog.chinaunix.net/attachment/201511/2/28852942_1446428311ZUaQ.png
[28852942_1446649610NA7D.png]: http://blog.chinaunix.net/attachment/201511/4/28852942_1446649610NA7D.png
[28852942_1446649718oYAD.png]: http://blog.chinaunix.net/attachment/201511/4/28852942_1446649718oYAD.png