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公司出品。  >二、DA14580 開發例程目錄和SDK目錄結構 DA14580的SDK開發平臺使用keil，我們先來看看開發例程的目錄結構，再來看SDK目錄結構。前者簡單一些，后者因為涉及到第三方IP、ROM等原因，目錄實在是太多太細了，初接手真的會歇菜。 防丟（proximity，英文是接近的意思）的開發目錄結構如下：  這里需要注意的是，ROM里面的固話代碼，包括協議棧和單任務操作系統的相關管理代碼也是整個工程應用的一部分，只不過沒有列到開發目錄里面。 SDK目錄架構如下：  >三、藍牙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的狀態表是：  狀態的初始化和轉換是由用戶主動切換的。在某個確定的狀態時，內核會在對應的狀態響應接口集中遍歷所有發給該任務的消息。 每個任務都會在初始化時被創建，例如proxr任務的創建是：  這時，假設有個其他的任務發一個消息給TASK_PROXR，則會在proxr_disabled中查找相應的消息回調接口，并執行回調。 **2.消息回調** 接下來看看各個狀態的響應接口集，例如PROXR_CONNECTED連接狀態時的狀態響應接口集如下。可見，其會對兩個消息進行回調，一個是底層ATT收到對特征值的寫操作時執行回調，另一個應用層主動改寫另一個特征值。在筆者的防丟和計步應用中，前者是實現防丟告警功能，后者是上報計步數據。  **3.任務間通信** 消息發出之后，系統即會執行proxr_jibu_update_req_handler回調。 ? 另外，筆者會根據文章的閱讀量考慮進一步對DA14580的SDK進行分析，如系統啟動過程、服務建立過程以及上面說的，如何進行應用開發，即藍牙協議棧方面如何新增一個GATT profile（服務和特征值定義及操作）、SOC內核方面如何驅動外圍設備、系統應用框架上如何使用定時器和任務間消息通信等等。 更多原創請關注微信公眾號：嵌入式企鵝圈