从零开始的nrf52832蓝牙开发——蓝牙串口实现
共 3641字,需浏览 8分钟
·
2022-04-18 00:05
来源:https://blog.csdn.net/qwe5959798/article/details/120152350
蓝牙串口是一个很实用的例子,里面涉及到数据发送和接收,这是应该是作为蓝牙设备很基础的功能。如果你没有看上一篇,建议从上一篇看起,因为这一篇会省去上一篇的重复内容。
打开工程:
nRF5_SDK_15.3.0_59ac345\examples\ble_peripheral\experimental\bluetoothds_template\pca10040\s132\ses
实验现象:
下载代码后打开串口可以接收到手机发送的数据:
手机也可以接收到串口发送的数据,需要启用接收功能:
至于按键和LED和上一篇模板差不多不再赘述。
代码差异分析:
首先和上一章模板有区别的地方:
main函数里少了配对管理初始化,多了串口初始化:
串口初始化很简单,关键是传入了一个事件回调:
在蓝牙协议栈初始化中,创建的观察者的回调函数中新增了对两个事件的处理:
在gatt初始化时,传入了GATT事件处理回调函数并设置最大传输单元,注意这个值是从机建议主机的值,至于主机采不采用完全由主机说了算:
在回调函数里处理了交换MTU的事件,设置串口最长传输数据 = MTU - OPCODE - HANDLE,这个m_ble_nus_max_data_len值才是实际通信过程中发送的最大数据长度:
在服务初始化中初始化蓝牙串口服务:
细节展开放在后面详细讲。然后是广播初始化中,广播模式为有限可发现模式:
两种模式有什么区别可以自行查找相关资料。
串口服务分析
串口服务对象实例化
由上面可以看出,其实相比上一章的蓝牙模板来说,改动并不大,主要是新增了蓝牙串口服务。
按照Nordic的SDK编程风格,首先对于一个新的服务对象,需要有一个服务实例,所以第一步是创建对象,然后实例化,在main.c里有:
这个宏就是Nordic写的实例化蓝牙串口这个对象的宏,初始化后,m_nus就是我们后面要操作的蓝牙串口服务对象,NRF_SDH_BLE_TOTAL_LINK_COUNT 代表连接数最大为1,宏原型:
初步展开:
最后展开:
可以看到,这个宏首先定义了一个连接上下文存储的结构体变量,这个结构体里面保存了所有连接占用的内存池、最大支持多少个连接、单个连接内存这三个参数,在这里单个连接占用多少内存如下图:
可以看到单个连接占用内存为 ble_nus_client_context_t 结构体的大小:
也就是一个bool类型的变量,具体多大,由编译器决定,不同编译器可能最终结果不同。
然后实例化m_nus,并把上面那个结构体变量存入m_nus 这个实例中。
最后是把 ble_nus_on_ble_evt 这个回调函数注册为观察者,然后当调用这个函数时,传入的上下文参数为 m_nus 这个实例的指针。
然后看一下这个蓝牙串口服务结构体:
它包含:
1.服务的uuid,相当于这个服务的唯一编号
2.服务句柄,服务创建成功后,协议栈自动分配给我们的操作标识
3.特征句柄,特征创建成功后,协议栈自动分配给我们的操作标识
4.连接上下文内存池指针,指向用来保存连接上下文的内存池,该内存池需要我们根据自己的需求去自己创建(其实就是全局数组),在实例化时初始化
5.数据处理回调函数指针,可有可无,主要作为函数指针,在数据到来时执行。
串口服务初始化
比上一篇模板就多了一个蓝牙串口初始化函数,这个函数两个参数分别为服务对象和初始化参数:
添加蓝牙服务:
1.添加UUID
2.添加服务
3.添加特征
首先因为UUID是一个128bit的特征码,为了方便使用,我们先把它添加进协议栈里,然后协议栈返回一个type(类型),其实就是一个索引,我们操作这个索引即相当于操作这个UUID的服务。因为在蓝牙协议里,不同的服务和特征,使用UUID的第12、13位来区别的,所以我们把完整的128bit(16bytes)的UUID存进协议栈里,然后只修改它的第12和第13byte就可以了,而修改它是通过索引来修改的:
sd_ble_uuid_vs_add 函数原型:
sd_ble_gatts_service_add 函数原型:
其中服务类型分为三种:
服务句柄由协议栈分配(其实也相当于一个索引),我们保存在之前介绍的m_nus实例里。
如果在你的工程里需要添加多个不同的基础UUID,记得修改sdk_config.h里的NRF_SDH_BLE_VS_UUID_COUNT,它表示添加了几个UUID:
添加完成后,还需要修改用户代码RAM的起始地址(后移0x10)和大小(减小0x10),修改方法查看上一篇。
其实添加到这里如果下载代码,已经可以看到蓝牙多了一个服务了,只不过服务下面什么也没有。
特征要添加在服务下面:
而其中最主要的特征参数设置为:
uuid:特征的UUID(完整的16bytes下的第12、13byte)
uuid_type:完整UUID的索引,如果为0,则使用SIG的UUID
max_len:特征值的最大长度
init_len:特征值的初始长度
p_init_value:特征值的初始值
is_var_len:特征值长度是否可变
char_props:特征属性,其中又包括:
broadcast:是否允许广播
read:是否允许读取特征值
write_wo_resp:是否允许通过命令(cmd)写特征值
write:是否允许通过请求(request)写特征值
notify:是否允许通知
indicate:是否允许指示
auth_signed_wr:是否允许带符号的写入命令
char_ext_props:特性的拓展属性,其中又包括:
reliable_wr:写数据时是否允许使用队列方式
wr_aux :是否允许写入用户特征描述符
is_defered_read:是否支持延迟读取操作
is_defered_write:是否支持延迟写入操作
read_access:读取特征值的安全要求
write_access:写入特征值的安全要求
cccd_write_access:写入特征CCCD的安全要求
is_value_user:特征值是保存在用户代码的RAM里还是保存在协议栈的RAM里
p_user_descr:需要时,指向用户描述符
p_presentation_format:需要时,指向特征格式
蓝牙串口数据处理
对数据的处理都集中在蓝牙事件回调函数里,这个函数两个参数,第一个参数包含事件类型等,第二个参数在我们初始化时,我们把它设置为了蓝牙串口实例的指针:
连接事件:
可以看到连接时主要判断了是否使能通知,然后把连接事件传给nus_data_handler ,但其实函数中并没有处理这一事件。
接收数据分为两个,一个是接收到是否启用通知,另一个是接收到串口数据,这两种数据是由特征句柄来区分的:
而在回调函数里,只处理了这一种回调类型,处理方式是使用for循环把数据通过串口发送出去:
发送事件基本没有什么作用,因为在回调里没有对该类型处理:
发送函数在串口事件处理回调函数里:
具体的发送很简单:
‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ END ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧
关注我的微信公众号,回复“加群”按规则加入技术交流群。
点击“阅读原文”查看更多分享,欢迎点分享、收藏、点赞、在看。