全球最低功耗蓝牙单芯片(DA14580)系统架构和应用开发框架分析

最后更新于:2022-04-01 06:58:20

DA14580是Dialog公司研制的蓝牙单芯片,号称全球功耗最低,是TI CC2541的四分之一,是运动手环等穿戴类电子产品的常用芯片。但是DA14580的开发门槛不低,适合有蓝牙开发经验的团队来开发,不适合学习爱好者,在网络上搜索DA14580相关的开发文章,基本上都是对官方仅有的几篇文档进行简单翻译,还不如直接阅读英文原文。笔者将对DA14580的系统架构和应用开发框架进行分析,之后再讲解如何进行应用开发。        对于蓝牙单芯片应用开发来说,我们要关注的问题是:蓝牙协议栈方面如何新增一个GATT profile(服务和特征值定义及操作)、SOC内核方面如何驱动外围设备、系统应用框架上如何使用定时器和任务间消息通信等等。DA14580单芯片发布时并不是一颗裸片,而是带有开发平台和SDK包,还有常用的应用例程(如防丢proximity),我们要做的就是通过SDK和相关的文档去理解它整个系统架构和应用框架,在这个基础上才能去完成以上三个方面的开发。 >一、DA14580系统架构 DA14580是基于Cortex M0架构,内置ROM、OTP和RAM。其中ROM固化了大部分协议栈和操作系统(单任务)的代码实现,而OTP一次性编程则是为了降低成本,实现用户的差异化应用需求。当用户通过SPI NORFLASH引导或者直接通过JLINK下载代码到RAM进行调试后,就可以通过SmartSnippets工具下载代码到OTP。量产产品即从OTP开始引导执行。 DA14580集成的是第三方公司RW的蓝牙协议栈IP,范围包括GAT和GAP层及以下。因此我们可以在代码框架目录上看到RW开头命名的目录和头文件,官方文档涉及到蓝牙协议栈方面大部分都是RW公司出品。 ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-01-12_5694d4a460a68.jpg) >二、DA14580 开发例程目录和SDK目录结构 DA14580的SDK开发平台使用keil,我们先来看看开发例程的目录结构,再来看SDK目录结构。前者简单一些,后者因为涉及到第三方IP、ROM等原因,目录实在是太多太细了,初接手真的会歇菜。 防丢(proximity,英文是接近的意思)的开发目录结构如下: ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-01-12_5694d4a4734f0.jpg) 这里需要注意的是,ROM里面的固话代码,包括协议栈和单任务操作系统的相关管理代码也是整个工程应用的一部分,只不过没有列到开发目录里面。 SDK目录架构如下: ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-01-12_5694d4a48d947.jpg) >三、蓝牙profile和应用的角色和分工 从工程的代码目录结构来看,每个profile都有一个以profile(如proxr)命名的.c文件,也有一个以profile_task(如proxr_task)命名的.c文件;相应地,每个应用子任务也有一个app_profile(如app_proxr)的.C文件,和app_profile_task(如app_proxr_task)的.c文件。一般地: 在操作系统ke内核看来,Profile和profile_task共同完成一个task任务,其中app_proxr_task的task ID标识是TASK_PROXR。但app_profile和app_profile_task并不是一个具体的task任务,在代码目录的app目录,所有的task,包括app_proxr_task和app_batt_task(电池)、app_sec_task(安全)共同组成一个task,在app.c中完成任务创建,task的ID标识是TASK_APP。各个app_profile_task只不过完成应用的一个子场景功能,如防丢、电池告警等。 app是主动发送消息给profile,以执行相应的蓝牙GATT服务和操作,并接受回调。即app是profile的上层。 Profile任务执行GATT服务/属性的具体创建create、开启服务enable和属性特征的读写等操作,其调用ATT和GAP等底层接口来实现具体功能。Profile作为接口供给app层调用,app是通过消息通信来完成接口调用的。 app_profile的代码一般包括主动调用的接口实现,而app_profile_task则是接受消息回调的接口实现。两者的分工是非常清晰的。 >四、应用开发框架 DA14580的应用开发框架的核心是基于状态机和消息回调。以下分析以防丢proxr为例。 **1.状态机** 每个任务都必须明确自己的状态表,例如proxr的状态表是: ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-01-12_5694d4a4a315f.jpg) 状态的初始化和转换是由用户主动切换的。在某个确定的状态时,内核会在对应的状态响应接口集中遍历所有发给该任务的消息。 每个任务都会在初始化时被创建,例如proxr任务的创建是: ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-01-12_5694d4a4b1107.jpg) 这时,假设有个其他的任务发一个消息给TASK_PROXR,则会在proxr_disabled中查找相应的消息回调接口,并执行回调。 **2.消息回调** 接下来看看各个状态的响应接口集,例如PROXR_CONNECTED连接状态时的状态响应接口集如下。可见,其会对两个消息进行回调,一个是底层ATT收到对特征值的写操作时执行回调,另一个应用层主动改写另一个特征值。在笔者的防丢和计步应用中,前者是实现防丢告警功能,后者是上报计步数据。 ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-01-12_5694d4a4c64c3.jpg) **3.任务间通信** 消息发出之后,系统即会执行proxr_jibu_update_req_handler回调。  ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-01-12_5694d4a4d58a4.jpg) 另外,笔者会根据文章的阅读量考虑进一步对DA14580的SDK进行分析,如系统启动过程、服务建立过程以及上面说的,如何进行应用开发,即蓝牙协议栈方面如何新增一个GATT profile(服务和特征值定义及操作)、SOC内核方面如何驱动外围设备、系统应用框架上如何使用定时器和任务间消息通信等等。 更多原创请关注微信公众号:嵌入式企鹅圈 ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-01-12_5694d4a4e7662.jpg)
';