Nordic nRF5x SoC在开发BLE应用时,需要使用蓝牙协议栈。SoC的软件框架如下图所示,其中蓝牙协议栈以二进制文件(hex文件)形式提供给用户。协议栈软件架构本身是不带OS的,应用层的开发用户可以选择是否使用OS,SDK提供的绝大部分例程都是不带OS的(仅带几个FreeRTOS的例程)。软件部分本文以SDK15.3为基础做简要介绍。

应用层与协议栈的互动依靠SVC中断和SW中断实现。

应用层通过调用API访问协议栈,协议栈在SVC中断里获得应用层的访问数据并进行处理;当协议栈需要发送事件或者数据的时候,会通过SW中断传送给应用层,用户会在应用层收到对应的事件与数据。协议栈API有两种,一种操作BLE,一种操作SoC外设如PPI、Flash等等。它们命名方式为 sd_xxx_xxxx(),函数名都以sd打头,例如下图中例举的分别是获取本设备MAC地址的API和操作PPI的API。注意调用API时注意检查返回值,返回值的含义在API的什么处都有介绍,获得非正常的返回值后需要根据应用场景处理,具体处理方式根据用户应用而异。

由于有些外设协议栈会使用,所以用户在操作这些外设的时候,需要先向协议栈申请。例如S132 v6.1 协议栈中对外设的开放权限如下图列举,删除了部分Open的外设,图完整表格及注释说明请翻看协议栈说明文档。红框中圈出了被协议栈使用的硬件,这些硬件应用层禁止访问(必须访问的情况下可以使用timeslot方式申请);Restricted标注的外设不能直接操作寄存器,需要用SDK中的API申请访问;Open标注的外设,用户可以自由访问寄存器,但也推荐使用SDK中的驱动。

除了占用一部分外设,协议栈还会占用Flash和RAM资源,各个版本的协议功能不尽相同,所以它们栈消耗的Flash和RAM大小也不同。下图是整理的协议栈功能与消耗资源的参考表格。需要说明的是,各个版本协议栈对nRF52芯片的适配性数据参考于Nordic infocenter。

从上图可以知道,S112,S113是专门给BLE从机使用的协议栈,消耗资源比较少,因此非常适合用于nRF52810和nRF52811等资源较少的SoC上。广播拓展、2Mbps(高速率)、长距离 这3项都是BLE5.0的新增功能;而MTU拓展和DLE是BLE4.2的功能,它们可以有效提高BLE的传输速度。

下图是以nRF52832-QFAA 和S132 v6.1.1为例的Flash资源分配情况。

 

下图是以nRF52832-QFAA 和S132 v6.1.1为例的RAM资源分配情况。其中APP_RAM_BASE是应用层的RAM起始地址,一般在编译器中设置,它的具体大小根据协议栈功能设定而变化。协议栈使用的call stack空间并未计算到协议栈的RAM范围中,协议栈消耗的call stack一般需要1536字节(FPU disable),通常SDK中S132工程默认call stack为8KB,无特殊情况可以保持默认。另外协议栈不会用到heap。

APP_RAM_BASE的大小取决于ATT tables ize,BLE角色,安全等级,私有UUID个数等等参数。APP_RAM_BASE的值计算起来比较复杂,通常根据应用需求在sdk_config.h中配置,再编译下载应用程序,通过log或者仿真的方式查看协议栈初始化时反馈的RAM需求。下图是sdk_config.h的界面截图,协议栈的配置在nRF_SoftDevice栏目下。红色框中的是协议栈基本功能的配置,他们会影响APP_RAM_BASE的值。

黄色框中是协议栈低频时钟源的配置(根据上面的内容可以知道协议栈占用了外设RTC0),SDK中例程默认使用外部低频晶体,用户可以根据需要将其切换为内部低频RC,nRF52832内部低频RC的精度为+-250ppm(不同型号有差异,具体参考数据手册),并增加1uA左右功耗。若使用内部低频RC,可以参考上图方式切换。

APP_RAM_BASE值的获取:在运行完nrf_sdh_ble_enable()之后,变量ram_start的值就是。同时,nrf_sdh_ble_enable中会将APP_RAM_BASE的建议值通过log(waring等级)打印出来。

获得APP_RAM_BASE的值后,在编译器中填入即可。KEIL用户参考下图将APP_RAM_BASE的值填入IRAM1 的Start项,将(RAM SIZE-APP_RAM_BASE)的值填入Size项。Embedded studio用户参考NORDIC BLE SOC开发环境 – 编译器中的操作修改。

修改完成之后,重新编译下载,协议栈配置部分就完成了,协议栈初始化就能正常运行了。

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注