NRF52832DK协议栈高级实验
1 实验简介
| 工程编号 | 实验名称 | 工程简介 |
|---|---|---|
| 3.0_ble_peripheral_profile_led | LED控制实验 | 实现了LED服务，可以通过手机控制LED灯的点亮和熄灭 |
| 3.1_ble_peripheral_profile_btn | 按键控制实验 | 实现了按键服务，可以将按键按下的状态发送给手机 |
| 3.2_ble_peripheral_beacon | 基站（信标）实验 | BEACON格式广播 |
| 3.3_ble_peripheral_nus | 从机NUS实验（串口透传） | 实现了NUS服务，可以实现主从机的串口透传 |
| 3.4_ble_central_nus | 主机NUS实验（串口透传） | 实现了NUS服务，可以实现主从机的串口透传 |
| 3.5_ble_peripheral_multi | 一从多主实验 | 一个从机支持被多个主机连接 |
| 3.6_ble_central_multi | 一主多从实验 | 一个主机支持连接多个从机 |
| 3.7_ble_central_peripheral | 主从一体实验 | 异常 |
2 LED控制实验
2.1 实验简介
我们的蓝牙实战实验将从蓝牙控制IO输出高低电平，以此来控制开发板上LED点亮和熄灭开始。
在这个实验中，我们主要会展示一下，有关特征值的write以及read属性，其中由于read属性相对而言使用的较少。我们主要会给大家介绍write属性，也就是主机给从机发送数据的属性。
2.2 硬件说明
nRF52DK开发板采用与Nordic官方开发板相同的指示灯电路，原则协议栈例程可以直接控制指示灯，无需修改代码。
指示灯与芯片引脚对应关系如下表格。
| 网络标号 | 芯片引脚号 | 连接方式 |
|---|---|---|
| LED1 | P0.17 | 直连，低电平亮灯 |
| LED2 | P0.18 | 直连，低电平亮灯 |
| LED3 | P0.19 | 直连，低电平亮灯 |
| LED4 | P0.20 | 直连，低电平亮灯 |
2.3 实验现象
手机端通过nordic的app"nrf master control panel"，发起对设备的扫描和连接，连接成功之后，我们通过UUID FFF1给开发板发送数据。
例如发送0x00,0x00,0x00,0x00给开发板，此时开发板的4个LED灯均被点亮；同样的我们给将某位数据改成0x01，对应的LED就会熄灭。
2.4 源码讲解
2.4.1 gy_profile_led.c\.h
我们首先查看一下他的服务文件，也就是gy_profile_led，我们我们就是通过这个服务来接收手机端发送的LED控制数据的。
可以看到这个服务初始化ble_led_init函数中对于服务以及他的特征值属性的初始化过程，首先我们先初始化一个回调（p_led->led_write_handler = p_led_init->led_write_handler;），这个回调是用来将gy_profile_led这一层的数据，上传给mian文件去处理。
接下来是服务的添加，首先是调用sd_ble_uuid_vs_add去添加服务，然后给这个ble_uuid的服务的参数赋值，最后调用sd_ble_gatts_service_add函数去注册这个服务，这边我们注册的服务句柄是p_led->service_handle。
注册完服务之后，我们就要开始添加我们的特征值characteristic，特征值的添加也是一样的，首先配置特征值的参数，这些参数中我们主要关注一下ble_gatt_char_props_t，这个参数是用来定义特征值的属性的，可以看到我们的属性有如下几种：
/**@brief GATT Characteristic Properties. */
typedef struct
{
/* Standard properties */
uint8_t broadcast :1; /**< 广播 */
uint8_t read :1; /**< 读 */
uint8_t write_wo_resp :1; /**< 写指令 */
uint8_t write :1; /**< 写*/
uint8_t notify :1; /**< 通知*/
uint8_t indicate :1; /**< 暗示 */
uint8_t auth_signed_wr :1; /**< 签名写指令 */
} ble_gatt_char_props_t;
因为我们的led的服务，是手机写数据给开发板控制LED，所以我们要定义特征值写使能（add_char_params.char_props.write = 1;），另外当我们需要知道上次是发送的什么控制数据给开发板时，我们需要读一下数据，所以这边我们同样定义一下读使能（add_char_params.char_props.read = 1;），当我们配置完特征值的属性之后，我们调用characteristic_add函数，去向刚刚注册的p_led->service_handle服务中添加我们的特征值。
53 //******************************************************************************
54 // fn :ble_led_init
55 //
56 // brief : 初始化LED服务
57 //
58 // param : p_led -> led服务结构体
59 // p_led_init -> led服务初始化结构体
60 //
61 // return : uint32_t -> 成功返回SUCCESS，其他返回ERR NO.
62 uint32_t ble_led_init(ble_led_t * p_led, const ble_led_init_t * p_led_init)
63 {
64 uint32_t err_code;
65 ble_uuid_t ble_uuid;
66 ble_add_char_params_t add_char_params;
67
68 // 初始化服务结构体
69 p_led->led_write_handler = p_led_init->led_write_handler;
70
71 // 添加服务（128bit UUID）
72 ble_uuid128_t base_uuid = {LED_UUID_BASE};
73 err_code = sd_ble_uuid_vs_add(&base_uuid, &p_led->uuid_type);
74 VERIFY_SUCCESS(err_code);
75
76 ble_uuid.type = p_led->uuid_type;
77 ble_uuid.uuid = LED_UUID_SERVICE;
78
79 err_code = sd_ble_gatts_service_add(BLE_GATTS_SRVC_TYPE_PRIMARY, &ble_uuid, &p_led->service_handle);
80 VERIFY_SUCCESS(err_code);
81
82 // 添加LED特征值（属性是Write和Read、长度是4）
83 memset(&add_char_params, 0, sizeof(add_char_params));
84 add_char_params.uuid = LED_UUID_CHAR;
85 add_char_params.uuid_type = p_led->uuid_type;
86 add_char_params.init_len = LED_UUID_CHAR_LEN;
87 add_char_params.max_len = LED_UUID_CHAR_LEN;
88 add_char_params.char_props.read = 1;
89 add_char_params.char_props.write = 1;
90
91 add_char_params.read_access = SEC_OPEN;
92 add_char_params.write_access = SEC_OPEN;
93
94 return characteristic_add(p_led->service_handle, &add_char_params, &p_led->led_char_handles);
95 }
看完服务的初始化，我们来看下我们的服务注册之后是怎么来进行工作的，首先我们看下ble_led_on_ble_evt这个函数，这个函数在我们mian函数中注册BLE_LED_DEF(m_led);实例的时候被引用。
15 //******************************************************************************
16 // fn :BLE_LED_DEF
17 //
18 // brief : 初始化LED服务实例
19 //
20 // param : _name -> 实例的名称
21 //
22 // return : none
23 #define BLE_LED_DEF(_name) \
24 static ble_led_t _name; \
25 NRF_SDH_BLE_OBSERVER(_name ## _obs, \
26 BLE_LED_BLE_OBSERVER_PRIO, \
27 ble_led_on_ble_evt, &_name)
这个m_led实例注册，涉及到NRF_SDH_BLE_OBSERVER的使用，简单的理解就是利用这个注册了实例之后，当底层有GAP或者GATT消息返回的时候，就会触发ble_led_on_ble_evt函数。 因为我们LED服务这里需要接收手机端write的LED控制数据，所以我们在事件判断中，判断是否出现GATT Write事件，一旦出现了，我们调用on_write函数去处理这个事件。
28 //******************************************************************************
29 // fn :ble_led_on_ble_evt
30 //
31 // brief : BLE事件处理函数
32 //
33 // param : p_ble_evt -> ble事件
34 // p_context -> ble事件处理程序的参数（暂时理解应该是不同的功能，注册时所携带的结构体参数）
35 //
36 // return : none
37 void ble_led_on_ble_evt(ble_evt_t const * p_ble_evt, void * p_context)
38 {
39 ble_led_t * p_led = (ble_led_t *)p_context;
40
41 switch (p_ble_evt->header.evt_id)
42 {
43 // GATT Client Write事件
44 case BLE_GATTS_EVT_WRITE:
45 on_write(p_led, p_ble_evt);
46 break;
47
48 default:
49 break;
50 }
51 }
on_write函数用于处理接收的write数据，我们判断一下接收的数据是否符合我们的要求，如果符合，那么我们通过初始化函数中的回调函数，将接收到的值上传到main函数中去处理。
7 //******************************************************************************
8 // fn :on_write
9 //
10 // brief : 处理Write事件的函数。
11 //
12 // param : p_led -> led服务结构体
13 // p_ble_evt -> ble事件
14 //
15 // return : none
16 static void on_write(ble_led_t * p_led, ble_evt_t const * p_ble_evt)
17 {
18 ble_gatts_evt_write_t const * p_evt_write = &p_ble_evt->evt.gatts_evt.params.write;
19
20 if ( (p_evt_write->handle == p_led->led_char_handles.value_handle)
21 && (p_evt_write->len <= LED_UUID_CHAR_LEN)
22 && (p_led->led_write_handler != NULL))
23 {
24 p_led->led_write_handler((uint8_t*)p_evt_write->data);
25 }
26 }
2.4.2 gy_serial_led.c\.h
有关外设处理，请大家查看基础实验部分
2.4.3 main.c
main文件中也不给大家全部介绍了，这个和蓝牙协议实验部分是重合的，我们只关注实验改动的部分。
我们看下服务初始化的部分，可以看到调用了我们gy_profile_led中的ble_led_init函数初始化注册了我们的LED服务，并且通用注册了一个回调函数。
在这个回调函数led_write_handler中，我们可以获取到gy_profile_led中上传上来的接收到的wirte数据，并且利用这个数据进行LED的控制。
195 //******************************************************************
196 // fn : nus_data_handler
197 //
198 // brief : 用于处理来自Nordic UART服务的数据的功能
199 // details : 该功能将处理从Nordic UART BLE服务接收的数据并将其发送到UART模块
200 //
201 // param : ble_nus_evt_t -> nus事件
202 //
203 // return : none
204 static void led_write_handler(uint8_t * new_state)
205 {
206 NRF_LOG_INFO("Recive State:%02X,%02X,%02X,%02X",new_state[0],new_state[1],new_state[2],new_state[3]);
207 LED_Control(BSP_LED_0, new_state[0]);
208 LED_Control(BSP_LED_1, new_state[1]);
209 LED_Control(BSP_LED_2, new_state[2]);
210 LED_Control(BSP_LED_3, new_state[3]);
211 }
212
213 //******************************************************************
214 // fn : services_init
215 //
216 // brief : 初始化复位（本例程展示NUS：Nordic Uart Service）
217 //
218 // param : none
219 //
220 // return : none
221 static void services_init(void)
222 {
223 uint32_t err_code;
224 ble_led_init_t led_init;
225
226 // Initialize NUS.
227 memset(&led_init, 0, sizeof(led_init));
228
229 led_init.led_write_handler = led_write_handler;
230
231 err_code = ble_led_init(&m_led, &led_init);
232 APP_ERROR_CHECK(err_code);
233 }
3 按键控制实验
3.1 实验简介
按键控制实验，就是开发板上的按键按下，然后我们将通过蓝牙上报手机是哪一个按键被按下。
在上一个LED控制实验中，我们主要讲了Write属性，也就是主机给从机发送数据。在这个实验中，我们将会给大家展示从机如何给主机发送数据，也就是notify属性的使用。
3.2 硬件说明
nRF52DK开发板采用与Nordic官方开发板相同的按键电路，原则协议栈例程可以直接使用按键，无需修改代码。
按键与芯片引脚对应关系如下表格。
| 网络标号 | 芯片引脚号 | 连接方式 |
|---|---|---|
| BTN1 | P0.13 | 直连，下降沿（低电平）触发 |
| BTN2 | P0.14 | 直连，下降沿（低电平）触发 |
| BTN3 | P0.15 | 直连，下降沿（低电平）触发 |
| BTN4 | P0.16 | 直连，下降沿（低电平）触发 |
3.3 实验现象
首先还是使用nordic的app "nrf master control panel"去连接我们的开发板，连接成功之后，我们点击UUID FFE1特征值的使用notify的按钮（三个向下箭头的图标）。
使能了notify之后，我们分别按下开发板上的按键S1-S4，可以看到手机上显示对应的上报状态数据。
3.4 源码讲解
3.4.1 gy_profile_btn.c\.h
首先我们还是先看一下服务配置文件，首先还是注册一下服务，注册的服务句柄是p_btn->service_handle。服务注册完成之后，我们注册按键的特征值，可以看到我们分别使能了按键的notify通知属性（add_char_params.char_props.notify = 1;），并且同样使能了read属性（add_char_params.char_props.read = 1;）。
这里我们需要注意的是下面的cccd_write_access参数被使能，上一实验大家都好理解需要使能write_access和read_access，因为我们需要使用读写，那么为什么这个例程要使能cccd_write_access呢，这边给大家简单说明一下CCCD。
 |
Client Characteristic Configuration Descriptor（CCCD）是客户端特征配置描述符。当主机向CCCD中写入0x0001，此时使能notify；当写入0x0000时，此时禁止notify。
在nordic的协议栈当中，他的这个notify使能是交给用户自己处理的，也是说即便主机没有向cccd中写入0x0001去使能notify，我们同样可以直接利用notify去发送数据，只能这样不符合规范。 |
50 //******************************************************************************
51 // fn :ble_btn_init
52 //
53 // brief : 初始化BTN服务
54 //
55 // param : p_btn -> btn服务结构体
56 //
57 // return : uint32_t -> 成功返回SUCCESS，其他返回ERR NO.
58 uint32_t ble_btn_init(ble_btn_t * p_btn)
59 {
60 uint32_t err_code;
61 ble_uuid_t ble_uuid;
62 ble_add_char_params_t add_char_params;
63
64 // 添加服务（128bit UUID）
65 ble_uuid128_t base_uuid = {BTN_UUID_BASE};
66 err_code = sd_ble_uuid_vs_add(&base_uuid, &p_btn->uuid_type);
67 VERIFY_SUCCESS(err_code);
68
69 ble_uuid.type = p_btn->uuid_type;
70 ble_uuid.uuid = BTN_UUID_SERVICE;
71
72 err_code = sd_ble_gatts_service_add(BLE_GATTS_SRVC_TYPE_PRIMARY, &ble_uuid, &p_btn->service_handle);
73 VERIFY_SUCCESS(err_code);
74
75 // 添加BTN特征值（属性是Write和Read、长度是4）
76 memset(&add_char_params, 0, sizeof(add_char_params));
77 add_char_params.uuid = BTN_UUID_CHAR;
78 add_char_params.uuid_type = p_btn->uuid_type;
79 add_char_params.init_len = BTN_UUID_CHAR_LEN;
80 add_char_params.max_len = BTN_UUID_CHAR_LEN;
81 add_char_params.char_props.read = 1;
82 add_char_params.char_props.notify = 1;
83
84 add_char_params.read_access = SEC_OPEN;
85 add_char_params.cccd_write_access = SEC_OPEN;
86
87 return characteristic_add(p_btn->service_handle, &add_char_params, &p_btn->btn_char_handles);
88 }
服务部分剩下的处理流程和上一实验是类型的，只不过上一个实验是处理的wirte属性，而这个实验是处理notify属性。 首先在BLE事件处理的函数中，本来我们应该要处理CCCD_Write的数据的，但是这边我们偷懒了，不去做处理，验证一下主机不发送数据使能notify，我们也可以通过notify发送数据出去。
31 //******************************************************************************
32 // fn :ble_led_on_ble_evt
33 //
34 // brief : BLE事件处理函数
35 //
36 // param : p_ble_evt -> ble事件
37 // p_context -> ble事件处理程序的参数（暂时理解应该是不同的功能，注册时所携带的结构体参数）
38 //
39 // return : none
40 void ble_led_on_ble_evt(ble_evt_t const * p_ble_evt, void * p_context)
41 {
42 switch (p_ble_evt->header.evt_id)
43 {
44
45 default:
46 break;
47 }
48 }
下面这个函数，就是我们notify发送数据的函数，他的参数我们只需要配置4个。
type配置为BLE_GATT_HVX_NOTIFICATION，代表是notify属性的数据；
handle我们需要配置为我们按键特征值的value.handle，代表的是按键特征值的Value这个列表的句柄；
剩下的p_data和p_len就是我们需要发送的数据以及数据的长度。
7 //******************************************************************************
8 // fn :ble_lbs_on_button_change
9 //
10 // brief : 处理按键按下，状态更新的事件
11 //
12 // param : conn_handle -> 连接的句柄
13 // p_btn -> btn结构体
14 // button_state -> 按键状态
15 //
16 // return : none
17 uint32_t ble_lbs_on_button_change(uint16_t conn_handle, ble_btn_t * p_btn, uint8_t *button_state)
18 {
19 ble_gatts_hvx_params_t params;
20 uint16_t len = BTN_UUID_CHAR_LEN;
21
22 memset(¶ms, 0, sizeof(params));
23 params.type = BLE_GATT_HVX_NOTIFICATION;
24 params.handle = p_btn->btn_char_handles.value_handle;
25 params.p_data = button_state;
26 params.p_len = &len;
27
28 return sd_ble_gatts_hvx(conn_handle, ¶ms);
29 }
3.4.2 gy_serial_btn.c\.h
按键的外设处理驱动文件，这个详细的说明也是请大家查看基础实验部分的，这里我们只关注一下按键被触发，然后通过notify函数，去向手机发送通知。
41 //******************************************************************
42 // fn : btn_timeout_handler
43 //
44 // brief : 按键定时器超时任务
45 //
46 // param : p_event -> 指向数据库发现事件的指针
47 //
48 // return : none
49 static void btn_timeout_handler(void * p_context)
50 {
51 uint8_t btnStateBuf[BTN_UUID_CHAR_LEN] = {0};
52
53 if(nrf_drv_gpiote_in_is_set(BUTTON_1) == 0)
54 {
55 NRF_LOG_INFO("BTN1");
56 btnStateBuf[0] = 0x01;
57 btnState = 1;
58 }
59
60 if(nrf_drv_gpiote_in_is_set(BUTTON_2) == 0)
61 {
62 NRF_LOG_INFO("BTN2");
63 btnStateBuf[1] = 0x01;
64 btnState = 1;
65 }
66
67 if(nrf_drv_gpiote_in_is_set(BUTTON_3) == 0)
68 {
69 NRF_LOG_INFO("BTN3");
70 btnStateBuf[2] = 0x01;
71 btnState = 1;
72 }
73
74 if(nrf_drv_gpiote_in_is_set(BUTTON_4) == 0)
75 {
76 NRF_LOG_INFO("BTN4");
77 btnStateBuf[3] = 0x01;
78 btnState = 1;
79 }
80
81 if(btnState)
82 {
83 ble_lbs_on_button_change(0x0000, &m_btn, btnStateBuf);
84 }
85 btnState = 0;
86 }
3.5 main.c
由于这个例程的按键通知我们是放到了按键驱动文件中处理，所以在main函数当中我们只需要去初始化一下这个服务就可以了。
194 //******************************************************************
195 // fn : services_init
196 //
197 // brief : 初始化复位（本例程展示NUS：Nordic Uart Service）
198 //
199 // param : none
200 //
201 // return : none
202 static void services_init(void)
203 {
204 uint32_t err_code;
205
206 err_code = ble_btn_init(&m_btn);
207 APP_ERROR_CHECK(err_code);
208 }
4 基站（信标）实验
4.1 实验简介
无线技术中的信标是广播小块信息的概念。 信息可以是任何东西，范围从环境数据（温度，气压，湿度等）到微位置数据（资产跟踪，零售等）或方向数据（加速，旋转等）。
传输的数据通常是静态的，但也可以是动态的并随时间变化。 通过使用蓝牙低功耗，可以将信标设计为在单个纽扣电池上运行多年。 本应用报告介绍了信标的概念以及如何开始实施信标解决方案。 本文档中的命名约定可以概括为使用蓝牙低能耗技术广告来广播信息的信标，该技术可被称为蓝牙低功耗。
4.2 实验现象
4.3 源码讲解
首先我们先定义beacon相关的数据，其中我们用户需要关注的主要有3个参数，UUID、Major以及Minor，其他的参数大家可以理解为固定的格式（格式固定，但数据内容不固定，可能有不同的厂商信息）。另外还有一个值得我们关注的数据，那就是APP_COMPANY_IDENTIFIER，如果我们定义此参数为0x004C（也就是Apple id），那么我们的基站设备就被成为iBeacon。
54 // BEACON数据
55 #define APP_BEACON_INFO_LENGTH 0x17 // BEACON数据总长度
56 #define APP_ADV_DATA_LENGTH 0x15 // BEACON特殊字节的长度
57 #define APP_DEVICE_TYPE 0x02 // 字节0x02代表这个设备是BEACON
58 #define APP_MEASURED_RSSI 0xC3 // BEACON在1米距离处的信号强度
59 #define APP_COMPANY_IDENTIFIER 0x004C // 004C代表的是Apple id（只有这个ID，设备才会叫iBeacon）
60 #define APP_MAJOR_VALUE 0x27, 0x12 // major
61 #define APP_MINOR_VALUE 0x0B, 0x86 // minor
62 #define APP_BEACON_UUID 0xFD,0xA5,0x06,0x93, \
63 0xA4,0xE2,0x4F,0xB1, \
64 0xAF,0xCF,0xC6,0xEB, \
65 0x07,0x64,0x78,0x25 // UUID
66
67 // BEACON数据数组，用于初始化广播数据内容
68 static uint8_t m_beacon_info[APP_BEACON_INFO_LENGTH] =
69 {
70 APP_DEVICE_TYPE,
71 APP_ADV_DATA_LENGTH,
72 APP_BEACON_UUID,
73 APP_MAJOR_VALUE,
74 APP_MINOR_VALUE,
75 APP_MEASURED_RSSI
76 };
定义好基站的数据之后，我们需要把它添加到广播数据中，那么这边唯一的疑问的就是我们应该把基站数据作为什么type来添加。 从下面的代码中，我们不难看出，基站的数据是作为p_manuf_specific_data（也就是用户自定义）数据来添加的，在Beacon数据添加的时候，大家可以看到只有company_identifier是被独立出来配置的，这里我们将其配置为apple id，所以最终我们的设备类型会是iBeacon。
110 //******************************************************************
111 // fn : advertising_init
112 //
113 // brief : 用于初始化广播
114 //
115 // param : none
116 //
117 // return : none
118 static void advertising_init(void)
119 {
120 uint32_t err_code;
121 ble_advertising_init_t init;
122 ble_advdata_manuf_data_t manuf_specific_data;
123
124 memset(&init, 0, sizeof(init));
125
126 // 扫描回调数据包含短设备名称（方便大家看app显示BEACON标志）
127 init.srdata.name_type = BLE_ADVDATA_SHORT_NAME;
128 init.srdata.short_name_len = 9;
129
130 // 配置广播数据的flag，设置为beacon，配置为BLE_GAP_ADV_FLAG_BR_EDR_NOT_SUPPORTED
131 init.advdata.flags = BLE_GAP_ADV_FLAG_LE_GENERAL_DISC_MODE|BLE_GAP_ADV_FLAG_BR_EDR_NOT_SUPPORTED;
132
133 // 配置广播数据中的BEACON数据
134 manuf_specific_data.company_identifier = APP_COMPANY_IDENTIFIER;
135 manuf_specific_data.data.p_data = (uint8_t *) m_beacon_info;
136 manuf_specific_data.data.size = APP_BEACON_INFO_LENGTH;
137 init.advdata.p_manuf_specific_data = &manuf_specific_data;
138
139 // 配置广播周期，40ms快速广播，超时参数配置为0代表一直广播
140 init.config.ble_adv_fast_enabled = true;
141 init.config.ble_adv_fast_interval = 64; // 64*0.625 = 40ms
142 init.config.ble_adv_fast_timeout = 0; // 1800*10ms = 18s
143
144 err_code = ble_advertising_init(&m_advertising, &init);
145 APP_ERROR_CHECK(err_code);
146
147 ble_advertising_conn_cfg_tag_set(&m_advertising, APP_BLE_CONN_CFG_TAG);
148 }
5 从机NUS实验
5.1 实验简介
NUS（Nordic Uart Service）实验，他本质上是和开始的LED与按键的实验是一样的，都是新建一个服务文件，注册好我们需要使用的特征值功能，然后传输数据。不过是要比他们稍微复杂一点，因为我们串口的数据是涉及到收发两个部分（也就是既有write也有notify），所以我们在注册特征值的时候，是要注册两个，一个负责write，一个负责notify。
剩下的就是串口外设的处理，我们这边对于串口驱动不做介绍，大家可以去看基础实验部分的说明。我们在这个实验中仅给大家讲解串口RX收到的数据如何通知（notify）给手机，手机下发（write）的数据如何通过串口TX打印显示出来。
5.2 硬件说明
串口一向是所有开发板必需的功能之一，nRF52DK开发板采用CH340C芯片，将芯片的UART信号转换为USB接口信号，方便电脑使用USB来虚拟一个串口调试。
CH340C外围电路简单，且不需要外部晶振，nRF52DK开发板采用与Nordic官方开发板相同的串口收发引脚，如下表格所示。
| 网络标号 | 芯片引脚号 | 连接方式 |
|---|---|---|
| CH340_TX | P0.08（nRF_RX信号） | 通过SW1拨动开关，选择连接 |
| CH340_RX | P0.06（nRF_TX信号） | 通过SW1拨动开关，选择连接 |
图中P5引出了CH340C的流控制引脚，但是没有连接任何线路，所需要使用流控制，可自行连接测试。
5.3 实验现象
5.4 源码讲解
5.4.1 ble_nus.c\.h
先看下nus服务的初始化函数，首先我们还是先初始化了一个回调p_nus_init->data_handler，这个回调用于将nus层的数据传递给mian文件使用。
接下来我们初始化nus服务，还是和以前一样的，经过给参数的赋值，最终我们调用sd_ble_gatts_service_add函数注册了一个句柄为p_nus->service_handle的服务。
最后我们来注册我们需要使用的特征值characteristic，这边我们需要注册两个，一个是TX（发送），一个是RX（接收）。
首先我们看一下RX特征值的添加，我们配置他的属性是write，因为手机（主机）发送数据是通过write的方式；接下来我们看下TX特征值，我们做为从机设备，发送数据给手机（主机）使用的是notify方式，我们依次将这两个特征值添加到服务当中。
248 uint32_t ble_nus_init(ble_nus_t * p_nus, ble_nus_init_t const * p_nus_init)
249 {
250 ret_code_t err_code;
251 ble_uuid_t ble_uuid;
252 ble_uuid128_t nus_base_uuid = NUS_BASE_UUID;
253 ble_add_char_params_t add_char_params;
254
255 VERIFY_PARAM_NOT_NULL(p_nus);
256 VERIFY_PARAM_NOT_NULL(p_nus_init);
257
258 // Initialize the service structure.
259 p_nus->data_handler = p_nus_init->data_handler;
260
261 /**@snippet [Adding proprietary Service to the SoftDevice] */
262 // Add a custom base UUID.
263 err_code = sd_ble_uuid_vs_add(&nus_base_uuid, &p_nus->uuid_type);
264 VERIFY_SUCCESS(err_code);
265
266 ble_uuid.type = p_nus->uuid_type;
267 ble_uuid.uuid = BLE_UUID_NUS_SERVICE;
268
269 // Add the service.
270 err_code = sd_ble_gatts_service_add(BLE_GATTS_SRVC_TYPE_PRIMARY,
271 &ble_uuid,
272 &p_nus->service_handle);
273 /**@snippet [Adding proprietary Service to the SoftDevice] */
274 VERIFY_SUCCESS(err_code);
275
276 // Add the RX Characteristic.
277 memset(&add_char_params, 0, sizeof(add_char_params));
278 add_char_params.uuid = BLE_UUID_NUS_RX_CHARACTERISTIC;
279 add_char_params.uuid_type = p_nus->uuid_type;
280 add_char_params.max_len = BLE_NUS_MAX_RX_CHAR_LEN;
281 add_char_params.init_len = sizeof(uint8_t);
282 add_char_params.is_var_len = true;
283 add_char_params.char_props.write = 1;
284 add_char_params.char_props.write_wo_resp = 1;
285
286 add_char_params.read_access = SEC_OPEN;
287 add_char_params.write_access = SEC_OPEN;
288
289 err_code = characteristic_add(p_nus->service_handle, &add_char_params, &p_nus->rx_handles);
290 if (err_code != NRF_SUCCESS)
291 {
292 return err_code;
293 }
294
295 // Add the TX Characteristic.
296 /**@snippet [Adding proprietary characteristic to the SoftDevice] */
297 memset(&add_char_params, 0, sizeof(add_char_params));
298 add_char_params.uuid = BLE_UUID_NUS_TX_CHARACTERISTIC;
299 add_char_params.uuid_type = p_nus->uuid_type;
300 add_char_params.max_len = BLE_NUS_MAX_TX_CHAR_LEN;
301 add_char_params.init_len = sizeof(uint8_t);
302 add_char_params.is_var_len = true;
303 add_char_params.char_props.notify = 1;
304
305 add_char_params.read_access = SEC_OPEN;
306 add_char_params.write_access = SEC_OPEN;
307 add_char_params.cccd_write_access = SEC_OPEN;
308
309 return characteristic_add(p_nus->service_handle, &add_char_params, &p_nus->tx_handles);
310 /**@snippet [Adding proprietary characteristic to the SoftDevice] */
311 }
看完nus服务初始化之后，我们需要来看下ble_nus_on_ble_evt函数，这个函数在LED实验中有过说明，它的注册是在main文件中，我们注册nus实例的时候注册好的，功能是用来接收底层返回的GAP与GATT事件。 从代码中可以看到，我们这个实验需要接收的底层返回有3个，分别是：连接成功的GAP事件（BLE_GAP_EVT_CONNECTED）、write属性的GATT事件（BLE_GATTS_EVT_WRITE）以及notify通知传输完成的事件（BLE_GATTS_EVT_HVN_TX_COMPLETE）。
218 void ble_nus_on_ble_evt(ble_evt_t const * p_ble_evt, void * p_context)
219 {
220 if ((p_context == NULL) || (p_ble_evt == NULL))
221 {
222 return;
223 }
224
225 ble_nus_t * p_nus = (ble_nus_t *)p_context;
226
227 switch (p_ble_evt->header.evt_id)
228 {
229 case BLE_GAP_EVT_CONNECTED:
230 on_connect(p_nus, p_ble_evt);
231 break;
232
233 case BLE_GATTS_EVT_WRITE:
234 on_write(p_nus, p_ble_evt);
235 break;
236
237 case BLE_GATTS_EVT_HVN_TX_COMPLETE:
238 on_hvx_tx_complete(p_nus, p_ble_evt);
239 break;
240
241 default:
242 // No implementation needed.
243 break;
244 }
245 }
首先我们看下GAP连接成功事件，我们处理了哪些消息，在连接成功指令，我们首先是调用blcm_link_ctx_get函数去获取蓝牙连接的相关信息（这个暂时没有明白它的具体意义，因为获取到的p_client并没有被任何地方使用）。 然后我们调用sd_ble_gatts_value_get函数去获取CCCD中的gatts_val数据，然后我们调用ble_srv_is_notification_enabled对这个数据进行判断，如果得到的gatts_val数据是0x0001，那么代表了主机已经使能了我们从机的notify功能，那么我们通过p_nus->data_handler向mian文件传递BLE_NUS_EVT_COMM_STARTED事件。
72 static void on_connect(ble_nus_t * p_nus, ble_evt_t const * p_ble_evt)
73 {
74 ret_code_t err_code;
75 ble_nus_evt_t evt;
76 ble_gatts_value_t gatts_val;
77 uint8_t cccd_value[2];
78 ble_nus_client_context_t * p_client = NULL;
79
80 err_code = blcm_link_ctx_get(p_nus->p_link_ctx_storage,
81 p_ble_evt->evt.gap_evt.conn_handle,
82 (void *) &p_client);
83 if (err_code != NRF_SUCCESS)
84 {
85 NRF_LOG_ERROR("Link context for 0x%02X connection handle could not be fetched.",
86 p_ble_evt->evt.gap_evt.conn_handle);
87 }
88
89 /* Check the hosts CCCD value to inform of readiness to send data using the RX characteristic */
90 memset(&gatts_val, 0, sizeof(ble_gatts_value_t));
91 gatts_val.p_value = cccd_value;
92 gatts_val.len = sizeof(cccd_value);
93 gatts_val.offset = 0;
94
95 err_code = sd_ble_gatts_value_get(p_ble_evt->evt.gap_evt.conn_handle,
96 p_nus->rx_handles.cccd_handle,
97 &gatts_val);
98
99 if ((err_code == NRF_SUCCESS) &&
100 (p_nus->data_handler != NULL) &&
101 ble_srv_is_notification_enabled(gatts_val.p_value))
102 {
103 if (p_client != NULL)
104 {
105 p_client->is_notification_enabled = true;
106 }
107
108 memset(&evt, 0, sizeof(ble_nus_evt_t));
109 evt.type = BLE_NUS_EVT_COMM_STARTED;
110 evt.p_nus = p_nus;
111 evt.conn_handle = p_ble_evt->evt.gap_evt.conn_handle;
112 evt.p_link_ctx = p_client;
113
114 p_nus->data_handler(&evt);
115 }
116 }
接下来我们查看一下接收到的主机数据的处理，对于接收到的主机数据，我们分两个部分判断，一个是CCCD写的数据（p_nus->tx_handles.cccd_handle），一个是特征值RX的数据（p_nus->rx_handles.value_handle）。
CCCD的数据，我们接收到之后，去判断一下是使能notify还是禁能notify（也就是数据是0x0000还是0x0001）。如果是使能，则向main文件返回BLE_NUS_EVT_COMM_STARTED事件，如果是禁能，则向mian文件返回BLE_NUS_EVT_COMM_STOPPED事件。
RX特征值，是用于接收主机wirte的数据（也就是我们用户通信的数据），我们将接收的数据赋值给回调任务（evt.params.rx_data.p_data = p_evt_write->data; evt.params.rx_data.length = p_evt_write->len;），然后向mian文件返回BLE_NUS_EVT_RX_DATA事件。
124 static void on_write(ble_nus_t * p_nus, ble_evt_t const * p_ble_evt)
125 {
126 ret_code_t err_code;
127 ble_nus_evt_t evt;
128 ble_nus_client_context_t * p_client;
129 ble_gatts_evt_write_t const * p_evt_write = &p_ble_evt->evt.gatts_evt.params.write;
130
131 err_code = blcm_link_ctx_get(p_nus->p_link_ctx_storage,
132 p_ble_evt->evt.gatts_evt.conn_handle,
133 (void *) &p_client);
134 if (err_code != NRF_SUCCESS)
135 {
136 NRF_LOG_ERROR("Link context for 0x%02X connection handle could not be fetched.",
137 p_ble_evt->evt.gatts_evt.conn_handle);
138 }
139
140 memset(&evt, 0, sizeof(ble_nus_evt_t));
141 evt.p_nus = p_nus;
142 evt.conn_handle = p_ble_evt->evt.gatts_evt.conn_handle;
143 evt.p_link_ctx = p_client;
144
145 if ((p_evt_write->handle == p_nus->tx_handles.cccd_handle) &&
146 (p_evt_write->len == 2))
147 {
148 if (p_client != NULL)
149 {
150 if (ble_srv_is_notification_enabled(p_evt_write->data))
151 {
152 p_client->is_notification_enabled = true;
153 evt.type = BLE_NUS_EVT_COMM_STARTED;
154 }
155 else
156 {
157 p_client->is_notification_enabled = false;
158 evt.type = BLE_NUS_EVT_COMM_STOPPED;
159 }
160
161 if (p_nus->data_handler != NULL)
162 {
163 p_nus->data_handler(&evt);
164 }
165
166 }
167 }
168 else if ((p_evt_write->handle == p_nus->rx_handles.value_handle) &&
169 (p_nus->data_handler != NULL))
170 {
171 evt.type = BLE_NUS_EVT_RX_DATA;
172 evt.params.rx_data.p_data = p_evt_write->data;
173 evt.params.rx_data.length = p_evt_write->len;
174
175 p_nus->data_handler(&evt);
176 }
177 else
178 {
179 // Do Nothing. This event is not relevant for this service.
180 }
181 }
最后一个，也就是我们的BLE_GATTS_EVT_HVN_TX_COMPLETE事件的任务处理，这个事件代表的是我们notify数据向主机通知完成。所以这里我们也没有什么需要处理的，只需要向mian文件返回一个BLE_NUS_EVT_TX_RDY事件，代表我们发送完成了（notify方式发送）。
189 static void on_hvx_tx_complete(ble_nus_t * p_nus, ble_evt_t const * p_ble_evt)
190 {
191 ret_code_t err_code;
192 ble_nus_evt_t evt;
193 ble_nus_client_context_t * p_client;
194
195 err_code = blcm_link_ctx_get(p_nus->p_link_ctx_storage,
196 p_ble_evt->evt.gatts_evt.conn_handle,
197 (void *) &p_client);
198 if (err_code != NRF_SUCCESS)
199 {
200 NRF_LOG_ERROR("Link context for 0x%02X connection handle could not be fetched.",
201 p_ble_evt->evt.gatts_evt.conn_handle);
202 return;
203 }
204
205 if (p_client->is_notification_enabled)
206 {
207 memset(&evt, 0, sizeof(ble_nus_evt_t));
208 evt.type = BLE_NUS_EVT_TX_RDY;
209 evt.p_nus = p_nus;
210 evt.conn_handle = p_ble_evt->evt.gatts_evt.conn_handle;
211 evt.p_link_ctx = p_client;
212
213 p_nus->data_handler(&evt);
214 }
215 }
上面的部分介绍完之后，整个ble_nus.c文件就只剩下一个函数还没有介绍，也就是ble_nus_data_send函数，这个函数是预留给大家在mian文件中调用，去notify数据的。 在发送数据之前，我们首先先分别判断了一下设备是否连接了，notify属性是否被使能，发送的数据长度是否符合要求。以上都通过之后，我们将会给ble_gatts_hvx_params_t的参数赋值，最后调用sd_ble_gatts_hvx函数发送。
314 uint32_t ble_nus_data_send(ble_nus_t * p_nus,
315 uint8_t * p_data,
316 uint16_t * p_length,
317 uint16_t conn_handle)
318 {
319 ret_code_t err_code;
320 ble_gatts_hvx_params_t hvx_params;
321 ble_nus_client_context_t * p_client;
322
323 VERIFY_PARAM_NOT_NULL(p_nus);
324
325 err_code = blcm_link_ctx_get(p_nus->p_link_ctx_storage, conn_handle, (void *) &p_client);
326 VERIFY_SUCCESS(err_code);
327
328 if ((conn_handle == BLE_CONN_HANDLE_INVALID) || (p_client == NULL))
329 {
330 return NRF_ERROR_NOT_FOUND;
331 }
332
333 if (!p_client->is_notification_enabled)
334 {
335 return NRF_ERROR_INVALID_STATE;
336 }
337
338 if (*p_length > BLE_NUS_MAX_DATA_LEN)
339 {
340 return NRF_ERROR_INVALID_PARAM;
341 }
342
343 memset(&hvx_params, 0, sizeof(hvx_params));
344
345 hvx_params.handle = p_nus->tx_handles.value_handle;
346 hvx_params.p_data = p_data;
347 hvx_params.p_len = p_length;
348 hvx_params.type = BLE_GATT_HVX_NOTIFICATION;
349
350 return sd_ble_gatts_hvx(conn_handle, &hvx_params);
351 }
5.4.2 mian.c
mian文件中的内容，很多都是和之前重复的，这边我们只说明两个部分。一个是nus服务的回调函数，也就是刚刚ble_nus.c中向main文件回调的一些事件的处理；另一部分就是接收到串口的数据，调用刚刚最后说明的notify发送函数去向主机传输数据的部分。
首先看下nus服务的回调函数，其中处理了4个事件，正是刚刚我们从ble_nus.c文件中回调上来的。
BLE_NUS_EVT_RX_DATA事件中，我们将接收的主机write数据，通过串口打印显示。
其他的三个事件中，分别提示了各自代表的意义。
212 //******************************************************************
213 // fn : nus_data_handler
214 //
215 // brief : 用于处理来自Nordic UART服务的数据的功能
216 // details : 该功能将处理从Nordic UART BLE服务接收的数据并将其发送到UART模块
217 //
218 // param : ble_nus_evt_t -> nus事件
219 //
220 // return : none
221 static void nus_data_handler(ble_nus_evt_t * p_evt)
222 {
223 if (p_evt->type == BLE_NUS_EVT_RX_DATA)
224 {
225 UART_Write((uint8_t*)p_evt->params.rx_data.p_data, p_evt->params.rx_data.length);
226 NRF_LOG_DEBUG("Received data from BLE NUS. Writing data on UART.");
227 NRF_LOG_HEXDUMP_DEBUG(p_evt->params.rx_data.p_data, p_evt->params.rx_data.length);
228 }
229 else if (p_evt->type == BLE_NUS_EVT_TX_RDY)
230 {
231 NRF_LOG_DEBUG(" Service is ready to accept new data to be transmitted..");
232 }
233 else if(p_evt->type == BLE_NUS_EVT_COMM_STARTED)
234 {
235 NRF_LOG_DEBUG("NUS Notification Enable.");
236 //app_timer_start(m_timer_nus, APP_TIMER_TICKS(10), NULL);
237 }
238 else if (p_evt->type == BLE_NUS_EVT_COMM_STOPPED)
239 {
240 NRF_LOG_DEBUG("NUS Notification Disable.");
241 }
242 }
接下来我们看下串口回调函数，与前面的nus服务的回调类似，不过这个回调是处理串口上传的数据。 我们接收到串口的数据，并且调用ble_nus_data_send函数去将接收的数据，传输给主机。
434 // 串口回调函数
435 void APP_UartEvtHandle(uart_evt_t* pEvt)
436 {
437 uint16_t len = 0;
438 switch(pEvt->evt_type)
439 {
440 case UART_EVT_RX_TIMEOUT:
441 case UART_EVT_RX_OVERFLOW:
442 len = UART_Read(Buf,pEvt->status);
443 ble_nus_data_send(&m_nus, Buf, &len, m_conn_handle); //从串口发出
444 break;
445 }
446 }
6 主机NUS实验
6.1 实验简介
NUS_C（Nordic Uart Service Client）实验，这个实验就是针对NUS进行处理的。
这点是nordic的特色，之前我们做ti的CC25和CC26开发，从机的服务文件是一样需要大家根据自己需求实现，而主机部分的客户端处理，则是在一个大的事件回调中处理，开发者只要知道从机服务的UUID即可。而在nordic的工程中，我们可以看到，所有的服务都有其对应的客户端服务处理的文件，这样的好处在于一对一处理，我们对于细节上的处理能够做的更好，缺点在于如果大家自己新增服务，那么还需要编辑一个对应的客户端文件，这样增加了大家的开发难度。
剩下的就是串口外设的处理，我们这边对于串口驱动不做介绍，大家可以去看基础实验部分的说明。我们在这个实验中仅给大家讲解串口RX收到的数据如何写（Write）给从机，从机通知（notify）的数据，主机如何接收并通过串口TX打印出来显示。
6.2 硬件说明
串口一向是所有开发板必需的功能之一，nRF52DK开发板采用CH340C芯片，将芯片的UART信号转换为USB接口信号，方便电脑使用USB来虚拟一个串口调试。
CH340C外围电路简单，且不需要外部晶振，nRF52DK开发板采用与Nordic官方开发板相同的串口收发引脚，如下表格所示。
| 网络标号 | 芯片引脚号 | 连接方式 |
|---|---|---|
| CH340_TX | P0.08（nRF_RX信号） | 通过SW1拨动开关，选择连接 |
| CH340_RX | P0.06（nRF_TX信号） | 通过SW1拨动开关，选择连接 |
图中P5引出了CH340C的流控制引脚，但是没有连接任何线路，所需要使用流控制，可自行连接测试。
6.3 实验现象
6.4 源码讲解
6.4.1 ble_nus.c\.h
NUS_C客户端相对于NUS服务，功能部分要多一些，因为除了客户端初始化以及通信等回调事件的处理，多了一个部分，也就是发起服务扫描的回调函数处理。
首先是第一部分，也就是客户端初始化，以及底层回调的GAP和GATT事件的处理。
NUS客户端初始化函数，我们首先同样是先调用sd_ble_uuid_vs_add函数，根据我们的NUS_BASE_UUID，去确定一下客户端的UUID Type（p_ble_nus_c->uuid_type）。
然后我们分别初始化了p_ble_nus_c的连接句柄（conn_handle）、NUS服务的TX和RX的句柄，以及配置了一个回调函数p_ble_nus_c->evt_handler。
121 uint32_t ble_nus_c_init(ble_nus_c_t * p_ble_nus_c, ble_nus_c_init_t * p_ble_nus_c_init)
122 {
123 uint32_t err_code;
124 ble_uuid_t uart_uuid;
125 ble_uuid128_t nus_base_uuid = NUS_BASE_UUID;
126
127 VERIFY_PARAM_NOT_NULL(p_ble_nus_c);
128 VERIFY_PARAM_NOT_NULL(p_ble_nus_c_init);
129
130 err_code = sd_ble_uuid_vs_add(&nus_base_uuid, &p_ble_nus_c->uuid_type);
131 VERIFY_SUCCESS(err_code);
132
133 uart_uuid.type = p_ble_nus_c->uuid_type;
134 uart_uuid.uuid = BLE_UUID_NUS_SERVICE;
135
136 p_ble_nus_c->conn_handle = BLE_CONN_HANDLE_INVALID;
137 p_ble_nus_c->evt_handler = p_ble_nus_c_init->evt_handler;
138 p_ble_nus_c->handles.nus_tx_handle = BLE_GATT_HANDLE_INVALID;
139 p_ble_nus_c->handles.nus_rx_handle = BLE_GATT_HANDLE_INVALID;
140
141 return ble_db_discovery_evt_register(&uart_uuid);
142 }
看完初始化函数，接下来我们还是一样的来看下ble_nus_c_on_ble_evt函数，这个是nus服务的部分是一样的，都是mian文件中注册nus_c实例的时候就初始化好的，用于接收底层返回的GAP和GATT消息事件。 这里面我们初始化了两个事件，一个是BLE_GATTC_EVT_HVX，用于接收notify数据的事件，另一个处理的是BLE_GAP_EVT_DISCONNECTED，这个事件处理的是，如果断开连接，我们需要将nus_c的状态改成断开状态。
144 void ble_nus_c_on_ble_evt(ble_evt_t const * p_ble_evt, void * p_context)
145 {
146 ble_nus_c_t * p_ble_nus_c = (ble_nus_c_t *)p_context;
147
148 if ((p_ble_nus_c == NULL) || (p_ble_evt == NULL))
149 {
150 return;
151 }
152
153 if ( (p_ble_nus_c->conn_handle != BLE_CONN_HANDLE_INVALID)
154 &&(p_ble_nus_c->conn_handle != p_ble_evt->evt.gap_evt.conn_handle)
155 )
156 {
157 return;
158 }
159
160 switch (p_ble_evt->header.evt_id)
161 {
162 case BLE_GATTC_EVT_HVX:
163 on_hvx(p_ble_nus_c, p_ble_evt);
164 break;
165
166 case BLE_GAP_EVT_DISCONNECTED:
167 if (p_ble_evt->evt.gap_evt.conn_handle == p_ble_nus_c->conn_handle
168 && p_ble_nus_c->evt_handler != NULL)
169 {
170 ble_nus_c_evt_t nus_c_evt;
171
172 nus_c_evt.evt_type = BLE_NUS_C_EVT_DISCONNECTED;
173
174 p_ble_nus_c->conn_handle = BLE_CONN_HANDLE_INVALID;
175 p_ble_nus_c->evt_handler(p_ble_nus_c, &nus_c_evt);
176 }
177 break;
178
179 default:
180 // No implementation needed.
181 break;
182 }
183 }
接下来我们顺带的看一下on_hvx函数，我们接收到底层的BLE_GATTC_EVT_HVX事件之后，调用这个函数进行处理。首先是获取p_ble_evt携带的数据内容和长度，并且将ble_nus_c_evt.evt_type的任务ID改成是BLE_NUS_C_EVT_NUS_TX_EVT，这样我们会向main文件回调我们的事件和数据。
103 static void on_hvx(ble_nus_c_t * p_ble_nus_c, ble_evt_t const * p_ble_evt)
104 {
105 // HVX can only occur from client sending.
106 if ( (p_ble_nus_c->handles.nus_tx_handle != BLE_GATT_HANDLE_INVALID)
107 && (p_ble_evt->evt.gattc_evt.params.hvx.handle == p_ble_nus_c->handles.nus_tx_handle)
108 && (p_ble_nus_c->evt_handler != NULL))
109 {
110 ble_nus_c_evt_t ble_nus_c_evt;
111
112 ble_nus_c_evt.evt_type = BLE_NUS_C_EVT_NUS_TX_EVT;
113 ble_nus_c_evt.p_data = (uint8_t *)p_ble_evt->evt.gattc_evt.params.hvx.data;
114 ble_nus_c_evt.data_len = p_ble_evt->evt.gattc_evt.params.hvx.len;
115
116 p_ble_nus_c->evt_handler(p_ble_nus_c, &ble_nus_c_evt);
117 NRF_LOG_DEBUG("Client sending data.");
118 }
119 }
接下来的三个函数我们就放到一起说明了，功能比较好理解。
cccd_configure和ble_nus_c_tx_notif_enable函数，从名称上就不难看出，他们俩是用来配置我们的CCCD的，也就是使能NUS的notify功能。
ble_nus_c_string_send函数，这个是主机的write功能函数，就是调用这个函数向从机写数据。
185 /**@brief Function for creating a message for writing to the CCCD. */
186 static uint32_t cccd_configure(uint16_t conn_handle, uint16_t cccd_handle, bool enable)
187 {
188 uint8_t buf[BLE_CCCD_VALUE_LEN];
189
190 buf[0] = enable ? BLE_GATT_HVX_NOTIFICATION : 0;
191 buf[1] = 0;
192
193 ble_gattc_write_params_t const write_params =
194 {
195 .write_op = BLE_GATT_OP_WRITE_REQ,
196 .flags = BLE_GATT_EXEC_WRITE_FLAG_PREPARED_WRITE,
197 .handle = cccd_handle,
198 .offset = 0,
199 .len = sizeof(buf),
200 .p_value = buf
201 };
202
203 return sd_ble_gattc_write(conn_handle, &write_params);
204 }
205
206
207 uint32_t ble_nus_c_tx_notif_enable(ble_nus_c_t * p_ble_nus_c)
208 {
209 VERIFY_PARAM_NOT_NULL(p_ble_nus_c);
210
211 if ( (p_ble_nus_c->conn_handle == BLE_CONN_HANDLE_INVALID)
212 ||(p_ble_nus_c->handles.nus_tx_cccd_handle == BLE_GATT_HANDLE_INVALID)
213 )
214 {
215 return NRF_ERROR_INVALID_STATE;
216 }
217 return cccd_configure(p_ble_nus_c->conn_handle,p_ble_nus_c->handles.nus_tx_cccd_handle, true);
218 }
219
220
221 uint32_t ble_nus_c_string_send(ble_nus_c_t * p_ble_nus_c, uint8_t * p_string, uint16_t length)
222 {
223 VERIFY_PARAM_NOT_NULL(p_ble_nus_c);
224
225 if (length > BLE_NUS_MAX_DATA_LEN)
226 {
227 NRF_LOG_WARNING("Content too long.");
228 return NRF_ERROR_INVALID_PARAM;
229 }
230 if (p_ble_nus_c->conn_handle == BLE_CONN_HANDLE_INVALID)
231 {
232 NRF_LOG_WARNING("Connection handle invalid.");
233 return NRF_ERROR_INVALID_STATE;
234 }
235
236 ble_gattc_write_params_t const write_params =
237 {
238 .write_op = BLE_GATT_OP_WRITE_CMD,
239 .flags = BLE_GATT_EXEC_WRITE_FLAG_PREPARED_WRITE,
240 .handle = p_ble_nus_c->handles.nus_rx_handle,
241 .offset = 0,
242 .len = length,
243 .p_value = p_string
244 };
245
246 return sd_ble_gattc_write(p_ble_nus_c->conn_handle, &write_params);
247 }
了解完第一部分，我们来看下第二部分的内容，也就是发现服务的部分。
当我们在main文件中完成一系列获取服务的流程之后，最终会进入下面这个函数处理服务，可以看到我们分别根据TX和RX这两个特征值的UUID，获取了对应的handle。
并且会向main文件中返回一个BLE_NUS_C_EVT_DISCOVERY_COMPLETE事件，代表的是服务获取完成。
55 void ble_nus_c_on_db_disc_evt(ble_nus_c_t * p_ble_nus_c, ble_db_discovery_evt_t * p_evt)
56 {
57 ble_nus_c_evt_t nus_c_evt;
58 memset(&nus_c_evt,0,sizeof(ble_nus_c_evt_t));
59
60 ble_gatt_db_char_t * p_chars = p_evt->params.discovered_db.charateristics;
61
62 // Check if the NUS was discovered.
63 if ( (p_evt->evt_type == BLE_DB_DISCOVERY_COMPLETE)
64 && (p_evt->params.discovered_db.srv_uuid.uuid == BLE_UUID_NUS_SERVICE)
65 && (p_evt->params.discovered_db.srv_uuid.type == p_ble_nus_c->uuid_type))
66 {
67 for (uint32_t i = 0; i < p_evt->params.discovered_db.char_count; i++)
68 {
69 switch (p_chars[i].characteristic.uuid.uuid)
70 {
71 case BLE_UUID_NUS_RX_CHARACTERISTIC:
72 nus_c_evt.handles.nus_rx_handle = p_chars[i].characteristic.handle_value;
73 break;
74
75 case BLE_UUID_NUS_TX_CHARACTERISTIC:
76 nus_c_evt.handles.nus_tx_handle = p_chars[i].characteristic.handle_value;
77 nus_c_evt.handles.nus_tx_cccd_handle = p_chars[i].cccd_handle;
78 break;
79
80 default:
81 break;
82 }
83 }
84 if (p_ble_nus_c->evt_handler != NULL)
85 {
86 nus_c_evt.conn_handle = p_evt->conn_handle;
87 nus_c_evt.evt_type = BLE_NUS_C_EVT_DISCOVERY_COMPLETE;
88 p_ble_nus_c->evt_handler(p_ble_nus_c, &nus_c_evt);
89 }
90 }
91 }
最后我们看下ble_nus_c_handles_assign函数，这个函数是用于给nus_c来分配句柄的。 他是在上面返回给mian函数的BLE_NUS_C_EVT_DISCOVERY_COMPLETE事件中进行处理，这个时候底层的handle句柄已经获取完成，这边是给我们定义的句柄结构体中的参数赋值。
250 uint32_t ble_nus_c_handles_assign(ble_nus_c_t * p_ble_nus,
251 uint16_t conn_handle,
252 ble_nus_c_handles_t const * p_peer_handles)
253 {
254 VERIFY_PARAM_NOT_NULL(p_ble_nus);
255
256 p_ble_nus->conn_handle = conn_handle;
257 if (p_peer_handles != NULL)
258 {
259 p_ble_nus->handles.nus_tx_cccd_handle = p_peer_handles->nus_tx_cccd_handle;
260 p_ble_nus->handles.nus_tx_handle = p_peer_handles->nus_tx_handle;
261 p_ble_nus->handles.nus_rx_handle = p_peer_handles->nus_rx_handle;
262 }
263 return NRF_SUCCESS;
264 }
6.4.2 main.c
mian文件中，主要也是有两个部分，一个是注册NUS_C的，一个是用于NUS服务发现的。我们从main函数开始看起。
mian函数中，我们分别初始化了数据库发现（db_discovery_init）以及nus_c（nus_c_init）。
542 //******************************************************************
543 // fn : main
544 //
545 // brief : 主函数
546 //
547 // param : none
548 //
549 // return : none
550 int main(void)
551 {
552 // 初始化
553 log_init(); // 初始化LOG打印，由RTT工作
554 timer_init(); // 初始化定时器
555 db_discovery_init(); // 初始化数据库发现
556 power_management_init();// 初始化电源控制
557 ble_stack_init(); // 初始化BLE栈堆
558 gatt_init(); // 初始化GATT
559 nus_c_init(); // 初始化NUS
560 scan_init(); // 初始化扫描
561
562 // 打印例程名称
563 //NRF_LOG_INFO("demo0: simple central");
564
565 // 初始化外设
566 UART_Init(APP_UartEvtHandle); //初始化串口
567 UART_Write("3.4_ble_central_nus", sizeof("3.4_ble_central_nus"));
568
569
570 scan_start(); // 开始扫描
571
572 // 进入主循环
573 for (;;)
574 {
575 idle_state_handle(); // 空闲状态处理
576 }
577 }
我们看一下NUS_C的初始化函数，以及NUS_C的回调函数，可以看到都是调用的我们刚刚说的ble_nus_c.c中的函数去处理的，这里也没有太多的东西需要重复描述，我们主要看一下回调函数中的两个事件处理的内容。
BLE_NUS_C_EVT_DISCOVERY_COMPLETE，这个是我们服务发现完成之后返回的事件，所以我们可以在这个事件中调用ble_nus_c_handles_assign去获取特征值的句柄，并且可以调用ble_nus_c_tx_notif_enable使能从机的notify属性。
BLE_NUS_C_EVT_NUS_TX_EVT事件中，我们接收从机notify的数据，并通过串口打印出来。
250 //******************************************************************
251 // fn : ble_nus_c_evt_handler
252 //
253 // brief : NUS事件
254 //
255 // param : none
256 //
257 // return : none
258 static void ble_nus_c_evt_handler(ble_nus_c_t * p_ble_nus_c, ble_nus_c_evt_t const * p_ble_nus_evt)
259 {
260 ret_code_t err_code;
261
262 switch (p_ble_nus_evt->evt_type)
263 {
264 case BLE_NUS_C_EVT_DISCOVERY_COMPLETE:
265 NRF_LOG_INFO("Discovery complete.");
266 err_code = ble_nus_c_handles_assign(p_ble_nus_c, p_ble_nus_evt->conn_handle, &p_ble_nus_evt->handles);
267 APP_ERROR_CHECK(err_code);
268
269 err_code = ble_nus_c_tx_notif_enable(p_ble_nus_c);
270 APP_ERROR_CHECK(err_code);
271 NRF_LOG_INFO("Connected to device with Nordic UART Service.");
272
273 app_timer_start(m_timer_nus, APP_TIMER_TICKS(1000), NULL);
274 break;
275
276 case BLE_NUS_C_EVT_NUS_TX_EVT:
277 UART_Write((uint8_t*)p_ble_nus_evt->p_data, p_ble_nus_evt->data_len);
278 NRF_LOG_DEBUG("Receiving data.");
279 NRF_LOG_HEXDUMP_DEBUG(p_ble_nus_evt->p_data, p_ble_nus_evt->data_len);
280 break;
281
282 case BLE_NUS_C_EVT_DISCONNECTED:
283 NRF_LOG_INFO("Disconnected.");
284 break;
285 default:
286 break;
287 }
288 }
289
290 //******************************************************************
291 // fn : nus_c_init
292 //
293 // brief : 初始化NUS客户端（Nordic UART Service client）
294 //
295 // param : none
296 //
297 // return : none
298 static void nus_c_init(void)
299 {
300 ret_code_t err_code;
301 ble_nus_c_init_t init;
302
303 init.evt_handler = ble_nus_c_evt_handler;
304
305 err_code = ble_nus_c_init(&m_ble_nus_c, &init);
306 APP_ERROR_CHECK(err_code);
307 }
接下来我们看一下初始化以及发起服务获取部分，首先是初始化函数，我们调用ble_db_discovery_init函数初始化了服务发现的功能，并且注册了一个回调函数db_disc_handler。这个回调函数中我们将对发现的服务进行功能判断，以及相应的参数赋值或者其他处理，处理调用的函数也是ble_nus_c.c中的ble_nus_c_on_db_disc_evt。
309 //******************************************************************
310 // fn : db_disc_handler
311 //
312 // brief : 用于处理数据库发现事件的函数
313 // details : 此函数是一个回调函数，用于处理来自数据库发现模块的事件。
314 // 根据发现的UUID，此功能将事件转发到各自的服务。
315 //
316 // param : p_event -> 指向数据库发现事件的指针
317 //
318 // return : none
319 static void db_disc_handler(ble_db_discovery_evt_t * p_evt)
320 {
321 ble_nus_c_on_db_disc_evt(&m_ble_nus_c, p_evt);
322 }
323
324 //******************************************************************
325 // fn : db_discovery_init
326 //
327 // brief : 用于初始化数据库发现模块的函数
328 //
329 // param : none
330 //
331 // return : none
332 static void db_discovery_init(void)
333 {
334 ret_code_t err_code = ble_db_discovery_init(db_disc_handler);
335 APP_ERROR_CHECK(err_code);
336 }
上面的发现服务初始化找到了，最终返回的消息事件也知道怎么处理了，那么我们是在哪边去开始服务发现这个过程的呢。 我们可以看到在ble协议栈任务回调事件中，当我们连接成功之后（BLE_GAP_EVT_CONNECTED事件返回），我们调用了ble_db_discovery_start函数去发现服务。
338 //******************************************************************
339 // fn : ble_evt_handler
340 //
341 // brief : BLE事件回调
342 // details : 包含以下几种事件类型：COMMON、GAP、GATT Client、GATT Server、L2CAP
343 //
344 // param : ble_evt_t 事件类型
345 // p_context 未使用
346 //
347 // return : none
348 static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
349 {
350 ret_code_t err_code;
351 ble_gap_evt_t const * p_gap_evt = &p_ble_evt->evt.gap_evt;
352 ble_gap_evt_connected_t const * p_connected_evt = &p_gap_evt->params.connected;
353
354 switch (p_ble_evt->header.evt_id)
355 {
356 // 连接
357 case BLE_GAP_EVT_CONNECTED:
358 UART_Write("Connected", sizeof("Connected"));
359
360 NRF_LOG_INFO("Connected. conn_DevAddr: %s\nConnected. conn_handle: 0x%04x\nConnected. conn_Param: %d,%d,%d,%d",
361 Util_convertBdAddr2Str((uint8_t*)p_connected_evt->peer_addr.addr),
362 p_gap_evt->conn_handle,
363 p_connected_evt->conn_params.min_conn_interval,
364 p_connected_evt->conn_params.max_conn_interval,
365 p_connected_evt->conn_params.slave_latency,
366 p_connected_evt->conn_params.conn_sup_timeout
367 );
368 m_conn_handle = p_gap_evt->conn_handle;
369
370 // 开始发现服务，NUS客户端等待发现结果
371 err_code = ble_db_discovery_start(&m_db_disc, p_ble_evt->evt.gap_evt.conn_handle);
372 APP_ERROR_CHECK(err_code);
373
374 break;
375
376 // 断开连接
377 case BLE_GAP_EVT_DISCONNECTED:
378 UART_Write("Disconnected", sizeof("Disconnected"));
379
380 NRF_LOG_INFO("Disconnected. conn_handle: 0x%x, reason: 0x%04x",
381 p_gap_evt->conn_handle,
382 p_gap_evt->params.disconnected.reason);
383 m_conn_handle = BLE_CONN_HANDLE_INVALID;
384
385 // 如果需要异常断开重连，可以打开下面的注释
386 // scan_start(); // 重新开始扫描
387 break;
388
389 // 连接参数更新请求
390 case BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST:
391 NRF_LOG_INFO("conn_Param Update REQUEST: %d,%d,%d,%d",
392 p_ble_evt->evt.gap_evt.params.conn_param_update_request.conn_params.min_conn_interval,
393 p_ble_evt->evt.gap_evt.params.conn_param_update_request.conn_params.max_conn_interval,
394 p_ble_evt->evt.gap_evt.params.conn_param_update_request.conn_params.slave_latency,
395 p_ble_evt->evt.gap_evt.params.conn_param_update_request.conn_params.conn_sup_timeout
396 );
397 break;
398
399 case BLE_GAP_EVT_CONN_PARAM_UPDATE:
400 {
401 NRF_LOG_INFO("conn_Param Update Success: %d,%d,%d,%d",
402 p_ble_evt->evt.gap_evt.params.conn_param_update_request.conn_params.min_conn_interval,
403 p_ble_evt->evt.gap_evt.params.conn_param_update_request.conn_params.max_conn_interval,
404 p_ble_evt->evt.gap_evt.params.conn_param_update_request.conn_params.slave_latency,
405 p_ble_evt->evt.gap_evt.params.conn_param_update_request.conn_params.conn_sup_timeout
406 );
407 }break;
408
409 default:
410 break;
411 }
412 }
7 一从多主实验
7.1 实验简介
一主多从以及一从多主，这个在大家的实际场景使用中，经常会要用到，所以我们将会在接下来的两个例程依次给大家做介绍。
首先是给大家带来的我们本实验的一从多主，顾名思义就是一个从机设备支持被多个主机设备同时连接。那么我们建立这样一对多的连接方式，代码的处理过程会变得非常麻烦吗，实际上并不是这样，对于我们开发者而言，如果大家对于连接句柄（conn_handle）的理解已经比较透彻，那么增加的难度真的很低。
7.2 硬件说明
串口一向是所有开发板必需的功能之一，nRF52DK开发板采用CH340C芯片，将芯片的UART信号转换为USB接口信号，方便电脑使用USB来虚拟一个串口调试。
CH340C外围电路简单，且不需要外部晶振，nRF52DK开发板采用与Nordic官方开发板相同的串口收发引脚，如下表格所示。
| 网络标号 | 芯片引脚号 | 连接方式 |
|---|---|---|
| CH340_TX | P0.08（nRF_RX信号） | 通过SW1拨动开关，选择连接 |
| CH340_RX | P0.06（nRF_TX信号） | 通过SW1拨动开关，选择连接 |
图中P5引出了CH340C的流控制引脚，但是没有连接任何线路，所需要使用流控制，可自行连接测试。
7.3 实验现象
7.4 源码讲解
7.4.1 mian.c
mian文件中，我们首先看一下mian函数，可以看到并没有因为要建立多个链接而新增什么功能的初始化，这就说明我们只需要在原有的功能基础上去修改一些东西。那么接下来我们带大家一起看下我们修改了哪些地方。
第一点，ble协议栈初始化，咋一看好像没有什么改动，实际上在我们的nrf_sdh_ble_default_cfg_set初始化函数中，我们已经配置了本从机最大支持被4个主机连接，这个配置是的sdk_conifg.h中去修改了宏定义。
11965 // <o> NRF_SDH_BLE_PERIPHERAL_LINK_COUNT - Maximum number of peripheral links.
11966 #ifndef NRF_SDH_BLE_PERIPHERAL_LINK_COUNT
11967 #define NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 4
11968 #endif
11969
11970 // <o> NRF_SDH_BLE_CENTRAL_LINK_COUNT - Maximum number of central links.
11971 #ifndef NRF_SDH_BLE_CENTRAL_LINK_COUNT
11972 #define NRF_SDH_BLE_CENTRAL_LINK_COUNT 0
11973 #endif
11974
11975 // <o> NRF_SDH_BLE_TOTAL_LINK_COUNT - Total link count.
11976 // <i> Maximum number of total concurrent connections using the default configuration.
11977
11978 #ifndef NRF_SDH_BLE_TOTAL_LINK_COUNT
11979 #define NRF_SDH_BLE_TOTAL_LINK_COUNT 4
11980 #endif
501 //******************************************************************
502 // fn : ble_stack_init
503 //
504 // brief : 用于初始化BLE协议栈
505 // details : 初始化SoftDevice、BLE事件中断
506 //
507 // param : none
508 //
509 // return : none
510 static void ble_stack_init(void)
511 {
512 ret_code_t err_code;
513
514 // SD使能请求，配置时钟，配置错误回调，中断（中断优先级栈堆默认设置）
515 err_code = nrf_sdh_enable_request();
516 APP_ERROR_CHECK(err_code);
517
518 // SD默认配置
519 uint32_t ram_start = 0;
520 err_code = nrf_sdh_ble_default_cfg_set(APP_BLE_CONN_CFG_TAG, &ram_start);
521 APP_ERROR_CHECK(err_code);
522
523 // 使能BLE栈堆
524 err_code = nrf_sdh_ble_enable(&ram_start);
525 APP_ERROR_CHECK(err_code);
526
527 // 注册BLE事件的处理程序，所有BLE的事件都将分派ble_evt_handler回调
528 NRF_SDH_BLE_OBSERVER(m_ble_observer, APP_BLE_OBSERVER_PRIO, ble_evt_handler, NULL);
529 }
初始化中我们已经定义好了最大支持被4个主机连接，接下来就轮到了GAP状态处理的部分，我们看一下BLE协议栈的回调函数，可以看到里面还是只处理了连接（BLE_GAP_EVT_CONNECTED）和断开（BLE_GAP_EVT_DISCONNECTED）这两个状态。
473 //******************************************************************
474 // fn : ble_evt_handler
475 //
476 // brief : BLE事件回调
477 // details : 包含以下几种事件类型：COMMON、GAP、GATT Client、GATT Server、L2CAP
478 //
479 // param : ble_evt_t 事件类型
480 // p_context 未使用
481 //
482 // return : none
483 static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
484 {
485 switch (p_ble_evt->header.evt_id)
486 {
487 case BLE_GAP_EVT_CONNECTED:
488 on_connected(&p_ble_evt->evt.gap_evt);
489 break;
490
491 case BLE_GAP_EVT_DISCONNECTED:
492 on_disconnected(&p_ble_evt->evt.gap_evt);
493 break;
494
495 default:
496 // No implementation needed.
497 break;
498 }
499 }
接下来我们分别来看一下连接成功的处理函数on_connected以及断开的处理函数on_disconnected.
首先看一下连接的处理函数，相对于以前只支持一个连接的例程，我们这边新增了一个nrf_ble_qwr_conn_handle_assign函数处理，这个函数的功能是用于将连接句柄分配给Queued Writes模块的给定实例。
并且我们需要对当前连接的总数量进行判断，如果以及连接的主机数量少于4个，则继续开启广播，等待其他主机继续发起连接；如果连接的主机数量达到4个，则不再开启广播。
407 //******************************************************************
408 // fn : on_connected
409 //
410 // brief : 用于处理Connected事件的函数。
411 //
412 // param : p_gap_evt -> 从BLE堆栈收到的GAP事件
413 //
414 // return : none
415 static void on_connected(const ble_gap_evt_t * const p_gap_evt)
416 {
417 ret_code_t err_code;
418 uint32_t periph_link_cnt = ble_conn_state_peripheral_conn_count(); // Number of peripheral links.
419
420 UART_Printf("Connection with link 0x%x established.\n", p_gap_evt->conn_handle);
421
422 // Assign connection handle to available instance of QWR module.
423 for (uint32_t i = 0; i < NRF_SDH_BLE_PERIPHERAL_LINK_COUNT; i++)
424 {
425 if (m_qwr[i].conn_handle == BLE_CONN_HANDLE_INVALID)
426 {
427 err_code = nrf_ble_qwr_conn_handle_assign(&m_qwr[i], p_gap_evt->conn_handle);
428 APP_ERROR_CHECK(err_code);
429 break;
430 }
431 }
432
433 if (periph_link_cnt == NRF_SDH_BLE_PERIPHERAL_LINK_COUNT)
434 {
435
436 }
437 else
438 {
439 // Continue advertising. More connections can be established because the maximum link count has not been reached.
440 advertising_start();
441 }
442 }
然后我们再看一下断开连接的处理函数，先判断下是否有设备连接（periph_link_cnt == 0），如果没有设备连接，则返回err。然后我们再判断一下，当前连接数是否是最大连接数量减1（periph_link_cnt == (NRF_SDH_BLE_PERIPHERAL_LINK_COUNT - 1)），也就是说刚刚从满数量连接少了一个，这个时候我要需要重新开启广播，等待连接。
444 //******************************************************************
445 // fn : on_disconnected
446 //
447 // brief : 用于处理Disconnected事件的函数。
448 //
449 // param : p_gap_evt -> 从BLE堆栈收到的GAP事件
450 //
451 // return : none
452 static void on_disconnected(ble_gap_evt_t const * const p_gap_evt)
453 {
454 ret_code_t err_code;
455 uint32_t periph_link_cnt = ble_conn_state_peripheral_conn_count(); // Number of peripheral links.
456
457 UART_Printf("Connection 0x%x has been disconnected. Reason: 0x%X\n",
458 p_gap_evt->conn_handle,
459 p_gap_evt->params.disconnected.reason);
460
461 if (periph_link_cnt == 0)
462 {
463 APP_ERROR_CHECK(err_code);
464 }
465
466 if (periph_link_cnt == (NRF_SDH_BLE_PERIPHERAL_LINK_COUNT - 1))
467 {
468 // Advertising is not running when all connections are taken, and must therefore be started.
469 advertising_start();
470 }
471 }
讲完了一从多主连接相关的改变，我们接下来来说明一下多主连接的情况下，服务的处理。 首先看下服务初始化函数，这里我们主要是Queue Write初始化时候，需要根据最大连接数量初始化多个m_qwr实例。NUS的初始化部分是不需要改变的。
314 //******************************************************************
315 // fn : services_init
316 //
317 // brief : 初始化复位（本例程展示NUS：Nordic Uart Service）
318 //
319 // param : none
320 //
321 // return : none
322 static void services_init(void)
323 {
324 ret_code_t err_code;
325 ble_nus_init_t nus_init;
326 nrf_ble_qwr_init_t qwr_init = {0};
327
328 // Initialize Queued Write Module instances.
329 qwr_init.error_handler = nrf_qwr_error_handler;
330
331 for (uint32_t i = 0; i < LINK_TOTAL; i++)
332 {
333 err_code = nrf_ble_qwr_init(&m_qwr[i], &qwr_init);
334 APP_ERROR_CHECK(err_code);
335 }
336
337 // Initialize NUS.
338 memset(&nus_init, 0, sizeof(nus_init));
339
340 nus_init.data_handler = nus_data_handler;
341
342 err_code = ble_nus_init(&m_nus, &nus_init);
343 APP_ERROR_CHECK(err_code);
344
345 ble_conn_state_init();
346 }
其他就只剩下数据收发部分，我们得考虑有多个连接的设备。从上面一路看下来，我们不难看出，所谓的多主连接，实际上只是对conn_handle的处理（我们宏定义需要修改最大连接数量）。
281 //******************************************************************
282 // fn : nus_data_handler
283 //
284 // brief : 用于处理来自Nordic UART服务的数据的功能
285 // details : 该功能将处理从Nordic UART BLE服务接收的数据并将其发送到UART模块
286 //
287 // param : ble_nus_evt_t -> nus事件
288 //
289 // return : none
290 static void nus_data_handler(ble_nus_evt_t * p_evt)
291 {
292 if (p_evt->type == BLE_NUS_EVT_RX_DATA)
293 {
294 UART_Printf("Recive on connection handle 0x%04x.\n", p_evt->conn_handle);
295 UART_Write((uint8_t*)p_evt->params.rx_data.p_data, p_evt->params.rx_data.length);
296
297 NRF_LOG_DEBUG("Received data from BLE NUS. Writing data on UART.");
298 NRF_LOG_HEXDUMP_DEBUG(p_evt->params.rx_data.p_data, p_evt->params.rx_data.length);
299 }
300 else if (p_evt->type == BLE_NUS_EVT_TX_RDY)
301 {
302 NRF_LOG_DEBUG(" Service is ready to accept new data to be transmitted..");
303 }
304 else if(p_evt->type == BLE_NUS_EVT_COMM_STARTED)
305 {
306 NRF_LOG_DEBUG("NUS Notification Enable.");
307 }
308 else if (p_evt->type == BLE_NUS_EVT_COMM_STOPPED)
309 {
310 NRF_LOG_DEBUG("NUS Notification Disable.");
311 }
312 }
580 // 串口回调函数
581 void APP_UartEvtHandle(uart_evt_t* pEvt)
582 {
583 uint16_t len = 0;
584 ble_conn_state_conn_handle_list_t conn_handles = ble_conn_state_periph_handles();
585
586 switch(pEvt->evt_type)
587 {
588 case UART_EVT_RX_TIMEOUT:
589 case UART_EVT_RX_OVERFLOW:
590 len = UART_Read(Buf,pEvt->status);
591 if(len > BLE_NUS_MAX_DATA_LEN) break;
592 for (uint8_t i = 0; i < conn_handles.len; i++)
593 {
594 UART_Printf("Sent on connection handle 0x%04x.\n", conn_handles.conn_handles[i]);
595 ble_nus_data_send(&m_nus, Buf, &len, conn_handles.conn_handles[i]);
596 }
597 break;
598 }
599 }
8 一主多从实验
8.1 实验简介
介绍完一从多主的实验，我们来看下一主多从的，从上一个实验的源码讲解中我们不难看出，所谓的多路连接，主要处理的就是连接的句柄。
而在我们的一主都从实验中，大家需要多注意下服务句柄的分配部分，因为涉及到多个从机的服务，所以我们对于句柄的分配，则相关内容要多一些。
8.2 硬件说明
串口一向是所有开发板必需的功能之一，nRF52DK开发板采用CH340C芯片，将芯片的UART信号转换为USB接口信号，方便电脑使用USB来虚拟一个串口调试。
CH340C外围电路简单，且不需要外部晶振，nRF52DK开发板采用与Nordic官方开发板相同的串口收发引脚，如下表格所示。
| 网络标号 | 芯片引脚号 | 连接方式 |
|---|---|---|
| CH340_TX | P0.08（nRF_RX信号） | 通过SW1拨动开关，选择连接 |
| CH340_RX | P0.06（nRF_TX信号） | 通过SW1拨动开关，选择连接 |
图中P5引出了CH340C的流控制引脚，但是没有连接任何线路，所需要使用流控制，可自行连接测试。
8.3 实验现象
8.4 源码讲解
8.4.1 mian.c
首先还是一样的，我们先看下ble协议栈初始化的部分，我们定义了可以连接的从机最大数量为8。
12065 // <o> NRF_SDH_BLE_PERIPHERAL_LINK_COUNT - Maximum number of peripheral links.
12066 #ifndef NRF_SDH_BLE_PERIPHERAL_LINK_COUNT
12067 #define NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 0
12068 #endif
12069
12070 // <o> NRF_SDH_BLE_CENTRAL_LINK_COUNT - Maximum number of central links.
12071 #ifndef NRF_SDH_BLE_CENTRAL_LINK_COUNT
12072 #define NRF_SDH_BLE_CENTRAL_LINK_COUNT 8
12073 #endif
12074
12075 // <o> NRF_SDH_BLE_TOTAL_LINK_COUNT - Total link count.
12076 // <i> Maximum number of total concurrent connections using the default configuration.
12077
12078 #ifndef NRF_SDH_BLE_TOTAL_LINK_COUNT
12079 #define NRF_SDH_BLE_TOTAL_LINK_COUNT 8
12080 #endif
314 //******************************************************************
315 // fn : ble_evt_handler
316 //
317 // brief : BLE事件回调
318 // details : 包含以下几种事件类型：COMMON、GAP、GATT Client、GATT Server、L2CAP
319 //
320 // param : ble_evt_t 事件类型
321 // p_context 未使用
322 //
323 // return : none
324 static void ble_stack_init(void)
325 {
326 ret_code_t err_code;
327
328 err_code = nrf_sdh_enable_request();
329 APP_ERROR_CHECK(err_code);
330
331 // Configure the BLE stack using the default settings.
332 // Fetch the start address of the application RAM.
333 uint32_t ram_start = 0;
334 err_code = nrf_sdh_ble_default_cfg_set(APP_BLE_CONN_CFG_TAG, &ram_start);
335 APP_ERROR_CHECK(err_code);
336
337 // Enable BLE stack.
338 err_code = nrf_sdh_ble_enable(&ram_start);
339 APP_ERROR_CHECK(err_code);
340
341 // Register a handler for BLE events.
342 NRF_SDH_BLE_OBSERVER(m_ble_observer, APP_BLE_OBSERVER_PRIO, ble_evt_handler, NULL);
343 }
接下来我们通用查看一下ble协议栈的回调函数，看下其中对于连接和断开等GAP状态的处理。
BLE_GAP_EVT_CONNECTED连接状态，我们首先调用ble_nus_c_handles_assign函数去分配句柄，但实际上由于第三个参数为NULL，这里我们等于是给nus服务句柄置0。接下来我们调用ble_db_discovery_start函数去发现服务（由于有多个连接，所以我们需要根据当前连接的设备句柄参数去发现服务），成功发现NUS服务之后，会给我们在ble_nus_c_evt_handler回调函数中返回BLE_NUS_C_EVT_DISCOVERY_COMPLETE事件。
BLE_GAP_EVT_DISCONNECTED断开状态，先判断了是否有设备连接，如果没有就直接返回err，并且在最后重新开启扫描。
207 //******************************************************************
208 // fn : db_disc_handler
209 //
210 // brief : 用于处理数据库发现事件的函数
211 // details : 此函数是一个回调函数，用于处理来自数据库发现模块的事件。
212 // 根据发现的UUID，此功能将事件转发到各自的服务。
213 //
214 // param : p_event -> 指向数据库发现事件的指针
215 //
216 // return : none
217 static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
218 {
219 ret_code_t err_code;
220
221 // For readability.
222 ble_gap_evt_t const * p_gap_evt = &p_ble_evt->evt.gap_evt;
223
224 switch (p_ble_evt->header.evt_id)
225 {
226 // Upon connection, check which peripheral is connected, initiate DB
227 // discovery, update LEDs status, and resume scanning, if necessary.
228 case BLE_GAP_EVT_CONNECTED:
229 {
230 UART_Printf("Connection 0x%x established, starting DB discovery.",
231 p_gap_evt->conn_handle);
232
233 APP_ERROR_CHECK_BOOL(p_gap_evt->conn_handle < NRF_SDH_BLE_CENTRAL_LINK_COUNT);
234
235 err_code = ble_nus_c_handles_assign(&m_ble_nus_c[p_gap_evt->conn_handle],
236 p_gap_evt->conn_handle,
237 NULL);
238 APP_ERROR_CHECK(err_code);
239
240 err_code = ble_db_discovery_start(&m_db_disc[p_gap_evt->conn_handle],
241 p_gap_evt->conn_handle);
242 if (err_code != NRF_ERROR_BUSY)
243 {
244 APP_ERROR_CHECK(err_code);
245 }
246
247 // Update LEDs status and check whether it is needed to look for more
248 // peripherals to connect to.
249 if (ble_conn_state_central_conn_count() == NRF_SDH_BLE_CENTRAL_LINK_COUNT)
250 {
251
252 }
253 else
254 {
255 // Resume scanning.
256 scan_start();
257 }
258 } break; // BLE_GAP_EVT_CONNECTED
259
260 // Upon disconnection, reset the connection handle of the peer that disconnected, update
261 // the LEDs status and start scanning again.
262 case BLE_GAP_EVT_DISCONNECTED:
263 {
264 UART_Printf("LBS central link 0x%x disconnected (reason: 0x%x)",
265 p_gap_evt->conn_handle,
266 p_gap_evt->params.disconnected.reason);
267
268 if (ble_conn_state_central_conn_count() == 0)
269 {
270 APP_ERROR_CHECK(err_code);
271 }
272
273 // Start scanning.
274 scan_start();
275 } break;
276
277 case BLE_GAP_EVT_TIMEOUT:
278 {
279 // Timeout for scanning is not specified, so only the connection requests can time out.
280 if (p_gap_evt->params.timeout.src == BLE_GAP_TIMEOUT_SRC_CONN)
281 {
282 NRF_LOG_DEBUG("Connection request timed out.");
283 }
284 } break;
285
286 default:
287 // No implementation needed.
288 break;
289 }
290 }
然后我们看下nus_c的初始化，不同于从机设备的多路连接（因为从机自己提供服务，服务是唯一的），主机连接的多个从机有可能存在服务的不同，所以我们需要初始化多个m_ble_nus_c的实例。 同样的在nus_c_init的初始化函数中，我们需要对这些m_ble_nus_c的实例都进行初始化操作。
51 BLE_NUS_C_ARRAY_DEF(m_ble_nus_c, NRF_SDH_BLE_CENTRAL_LINK_COUNT);
286 //******************************************************************
287 // fn : nus_c_init
288 //
289 // brief : 初始化NUS客户端（Nordic UART Service client）
290 //
291 // param : none
292 //
293 // return : none
294 static void nus_c_init(void)
295 {
296 ret_code_t err_code;
297 ble_nus_c_init_t init;
298
299 init.evt_handler = ble_nus_c_evt_handler;
300
301 for (uint32_t i = 0; i < NRF_SDH_BLE_CENTRAL_LINK_COUNT; i++)
302 {
303 err_code = ble_nus_c_init(&m_ble_nus_c[i], &init);
304 APP_ERROR_CHECK(err_code);
305 }
306 }
看完nus_c的初始化函数，我们来看下他的回调函数的事件处理。
BLE_NUS_C_EVT_DISCOVERY_COMPLETE事件是服务发现完成后返回，我们可以在这个事件中去调用ble_nus_c_handles_assign给对应的连接的从设备的服务分配句柄，并且去使能他的notify。
BLE_NUS_C_EVT_NUS_TX_EVT事件是接收到从机的notify数据时返回，我们可以从这里获取到从设备的数据，并且打印出来显示。
168 //******************************************************************
169 // fn : ble_nus_c_evt_handler
170 //
171 // brief : NUS事件
172 //
173 // param : none
174 //
175 // return : none
176 static void ble_nus_c_evt_handler(ble_nus_c_t * p_ble_nus_c, ble_nus_c_evt_t const * p_ble_nus_evt)
177 {
178 ret_code_t err_code;
179
180 switch (p_ble_nus_evt->evt_type)
181 {
182 case BLE_NUS_C_EVT_DISCOVERY_COMPLETE:
183 NRF_LOG_INFO("Discovery complete.");
184 err_code = ble_nus_c_handles_assign(p_ble_nus_c, p_ble_nus_evt->conn_handle, &p_ble_nus_evt->handles);
185 APP_ERROR_CHECK(err_code);
186
187 err_code = ble_nus_c_tx_notif_enable(p_ble_nus_c);
188 APP_ERROR_CHECK(err_code);
189 NRF_LOG_INFO("Connected to device with Nordic UART Service.");
190 break;
191
192 case BLE_NUS_C_EVT_NUS_TX_EVT:
193 UART_Write((uint8_t*)p_ble_nus_evt->p_data, p_ble_nus_evt->data_len);
194 NRF_LOG_DEBUG("Receiving data.");
195 NRF_LOG_HEXDUMP_DEBUG(p_ble_nus_evt->p_data, p_ble_nus_evt->data_len);
196 break;
197
198 case BLE_NUS_C_EVT_DISCONNECTED:
199 NRF_LOG_INFO("Disconnected.");
200 break;
201 default:
202 break;
203 }
204 }
最后是串口回调函数，我们需要在这边处理接收到的串口数据，利用ble_nus_c_string_send函数发送给与我们主机连接的从机设备，由于是多路连接，所以我们需要一个循环来向多个m_ble_nus_c发送数据（就是像多个从机设备发送）。
447 // 串口回调函数
448 void APP_UartEvtHandle(uart_evt_t* pEvt)
449 {
450 uint16_t len = 0;
451
452 switch(pEvt->evt_type)
453 {
454 case UART_EVT_RX_TIMEOUT:
455 case UART_EVT_RX_OVERFLOW:
456 len = UART_Read(Buf,pEvt->status);
457 for (uint8_t i = 0; i < NRF_SDH_BLE_CENTRAL_LINK_COUNT; i++)
458 {
459 //UART_Printf("Sent on connection handle 0x%04x.\n",0);
460 ble_nus_c_string_send(&m_ble_nus_c[i], Buf, len);
461 }
462 break;
463 }
464 }