本文將介紹Nordic nRF5 SDK軟件架構(gòu)以及softdevice工作原理，以加深大家對Nordic產(chǎn)品開發(fā)的理解，這樣開發(fā)過程中碰到問題時，大家也知道如何去調(diào)試。

如果你剛開始接觸nRF5 SDK，建議先看一下這篇文章“Nordic nRF5 SDK和softdevice介紹”，以建立Nordic nRF5 SDK的一些基本知識。

首先說明一下，Nordic nRF5系列產(chǎn)品都是使用Flash存儲器的，確切說，是嵌入式可執(zhí)行代碼的Flash存儲器，也就是說，代碼是可以直接在上面運行的，這個跟很多其他BLE廠商是不一樣的（他們使用的是nand Flash，代碼是不能直接在nand Flash中運行的，必須先裝載到RAM中才能跑，所以你會發(fā)現(xiàn)這些廠商的RAM都非常大）。Nordic Flash是帶cache機制的，以保證大部分代碼執(zhí)行速度可以達到64MHz，在cache失敗的時候，等待周期也只有1個cycle，可以說Flash的執(zhí)行速度和效率都是非常不錯的。另外，Nordic芯片是純Flash產(chǎn)品，里面沒有其他NVM，所有非易失性數(shù)據(jù)都放在Flash中，包括藍牙協(xié)議棧，這也是為什么Nordic藍牙協(xié)議棧也可以O(shè)TA的根本原因所在。

Nordic nRF5 SDK將芯片的存儲器劃分成如下格局：

Flash結(jié)構(gòu)圖 RAM結(jié)構(gòu)圖

從上圖可知，F(xiàn)lash存儲器最下面放的是softdevice（softdevice就是藍牙協(xié)議棧，圖中的MBR也屬于softdevice的一部分），中間是application，最上面是bootloader（可選，只有需要OTA的時候，才需要下載bootloader）。這里需要特別指出的是，softdevice是以二進制形式提供給大家的，它占據(jù)了Flash的一塊固定空間，起始地址為0，結(jié)束地址為APP_CODE_BASE。softdevice同時占用了RAM的一塊固定空間，起始地址為0x20000000，結(jié)束地址為APP_RAM_BASE。Softdevice占用的Flash空間是固定不變的，運行時不可調(diào)節(jié)，也就是說APP_CODE_BASE是一個固定值，而softdevice占用的RAM空間是動態(tài)可調(diào)的，跟softdevice配置和藍牙服務(wù)的多少有直接關(guān)聯(lián)，所以APP_RAM_BASE一定要根據(jù)應(yīng)用的實際情況進行調(diào)整。

這里說明一下， Softdevice不是以庫的形式提供給大家，而是以二進制文件（hex文件）的形式提供給大家，這種方式可以帶來很多好處。首先二進制形式可以保證藍牙BQB認證的版本和發(fā)布給客戶的版本一模一樣（因為庫形式的版本每次編譯都會產(chǎn)生少許差異！）。其次softdevice不需要跟你的應(yīng)用一起編譯或者鏈接，大大節(jié)省調(diào)試時間，更主要的是，Softdevice運行在固定的Flash空間中，使用固定的RAM空間，從而與你的應(yīng)用完全隔離開，實現(xiàn)了真正的模塊分離，從而出現(xiàn)問題時，可以迅速定位是協(xié)議棧的問題還是應(yīng)用的問題。再次二進制形式的 Softdevice開啟了保護機制，應(yīng)用代碼是不能對其進行訪問的，以保證Softdevice的安全性，防止應(yīng)用代碼誤訪問或者誤擦除某些softdevice區(qū)域。最后這種多bin形式使得OTA變得非常靈活，你可以只OTA應(yīng)用，也可以O(shè)TA協(xié)議棧和bootloader，或者三者同時OTA。

上面是站在芯片存儲器角度來看nRF5 SDK的結(jié)構(gòu)劃分。如果站在軟件架構(gòu)角度，nRF5 SDK可以劃分成如下結(jié)構(gòu)圖：

由上圖可知，最下面是芯片本身，然后是ARM公司的CMSIS庫，再往上就是協(xié)議棧softdevice和設(shè)備驅(qū)動，最后就是application和標準的藍牙service了。softdevice是以二進制文件形式提供給大家的，除此之外，其他所有的SDK代碼都是開源的，以方便大家開發(fā)。應(yīng)用程序，包括SDK代碼，都是通過softdevice API來與softdevice進行交互的，所有softdevice API都是以sd_打頭的，比如：

sd_softdevice_enable(…);

sd_ble_gap_adv_start(…);

sd_flash_write(…);

sd_ppi_channel_assign(…);

Softdevice API有兩種類型：

與BLE協(xié)議有關(guān)的API，比如sd_ble_gap_connect()，sd_ble_gatts_hvx()等。

外設(shè)操作API，比如sd_flash_write()，sd_power_gpregret_set()等。由于softdevice會使用到某些外設(shè)，應(yīng)用程序也需要訪問這些外設(shè)時，不能通過普通的外設(shè)驅(qū)動API去訪問，必須通過softdevice API去訪問。

如前所述，softdevice是以二進制文件形式提供給大家的，那么應(yīng)用是如何做到可以成功調(diào)用softdevice API的？其實，softdevice是通過SVC中斷和軟中斷來實現(xiàn)與應(yīng)用程序交互的。每一個softdevice API對應(yīng)一個SVC異常號（softdevice API是非阻塞的），也就是說，每當應(yīng)用程序調(diào)用softdevice API，其實是產(chǎn)生一個SVC異常，然后進入到softdevice協(xié)議棧，由softdevice的SVC handler進行相應(yīng)處理。示例代碼如下所示：

Softdevice API調(diào)用流程如下所示：

每當softdevice完成相關(guān)重要操作，都會以事件形式通知應(yīng)用程序的，比如與手機連接成功，softdevice就會把BLE_GAP_EVT_CONNECTED事件告知應(yīng)用程序，那softdevice是如何把相關(guān)事件告知給應(yīng)用程序的？這個是通過軟中斷來實現(xiàn)的。每當softdevice完成相關(guān)操作，就會把對應(yīng)的事件放入一個隊列中，然后觸發(fā)一個軟中斷，以重新回到應(yīng)用程序環(huán)境中，應(yīng)用程序在相關(guān)軟中斷handler中查詢該隊列，一旦發(fā)現(xiàn)有事件在里面，就回調(diào)相關(guān)函數(shù)，比如ble_evt_handler，從而達到通知應(yīng)用程序相關(guān)事件的目的。事件通知流程如下所示：

為了達到各個軟件模塊松耦合的目的，每個軟件模塊，比如廣播模塊，可以單獨注冊自己的BLE事件回調(diào)處理函數(shù)，然后在自己的事件回調(diào)處理函數(shù)里面只處理跟本模塊有關(guān)的事件，與本模塊無關(guān)的事件不進行處理而直接返回。這里需要注意兩點：一雖然每個BLE事件回調(diào)處理函數(shù)只處理跟本模塊有關(guān)的事件，但是它是可以捕獲所有BLE事件的，你可以讓整個應(yīng)用程序只有一個BLE事件回調(diào)處理函數(shù)，但這樣會讓各個模塊緊密地耦合在一起，因此Nordic SDK沒有這么做，尤其是SDK14以后，各個模塊都自己注冊自己的藍牙事件回調(diào)處理函數(shù)，完全跟用戶代碼切割開，同樣如果用戶代碼需要捕獲BLE事件的話，只需注冊自己的BLE事件回調(diào)處理函數(shù)即可。二BLE事件是異步的，所以有時BLE事件回調(diào)處理函數(shù)會同時收到多個BLE事件，也就是BLE事件回調(diào)處理函數(shù)有可能在很短的時間內(nèi)被調(diào)用多次（BLE事件回調(diào)處理函數(shù)每次只處理一個事件case，然后返回，所以短時間內(nèi)會被調(diào)用多次），這個在開發(fā)的時候需要注意一下。

從上面nRF5 SDK軟件架構(gòu)的講解過程中，我們可以看到，當我們開發(fā)Nordic平臺的BLE應(yīng)用時，主要需要做兩件事：

第1件事：初始化。為了簡化初始化工作，Nordic SDK所有模塊初始化時，只需要將相應(yīng)API輸入結(jié)構(gòu)體參數(shù)清0即可完成初始化工作，也就是說，只要你保證初始化參數(shù)為0，藍牙協(xié)議棧就可以工作起來，這對很多Nordic初學者來說，大大減輕了開發(fā)工作量。

第2件事：寫藍牙事件回調(diào)處理函數(shù)。一般來說，你的應(yīng)用邏輯都是放在藍牙事件回調(diào)處理函數(shù)中，所以寫好回調(diào)處理函數(shù)代碼，你的開發(fā)工作就完成了大半了。

審核編輯 黃宇