一、nrf51822芯片和協(xié)議棧特性

51822芯片特色：

各個(gè)模塊的功能引腳可以隨意選擇，并不像傳統(tǒng)的單片機(jī)通過IO復(fù)用實(shí)現(xiàn)，固定好了某個(gè)功能只能選用哪個(gè)IO口。傳統(tǒng)單片機(jī)的IO功能復(fù)用通過寄存器使能其第二功能，而51822每個(gè)模塊都能通過模塊的寄存器選用各個(gè)引腳。

PPI系統(tǒng)。相比中斷更能降低處理器的占用，降低功耗。

協(xié)議棧特性：

協(xié)議堆棧和應(yīng)用程序代碼分離，沒有鏈接時(shí)間依存性，分開編譯和更新。沒有專用的應(yīng)用程序框架或RTOS依存性，TI的就有個(gè)輪詢框架。

堆棧為百分百的異步并由事件驅(qū)動(dòng)，并向應(yīng)用程序?qū)犹峁┚€程安全管理程序調(diào)用SVC的應(yīng)用程序接口。
協(xié)議棧向APP發(fā)送信息是通過事件發(fā)動(dòng)的！
APP向協(xié)議棧發(fā)送信息是通過API接口，而API接口通過SVC機(jī)制實(shí)現(xiàn)的。

協(xié)議棧如何發(fā)送數(shù)據(jù)給應(yīng)用程序：

????????當(dāng)有事件來臨，比如連接請(qǐng)求或者對(duì)端設(shè)備發(fā)來了數(shù)據(jù)，協(xié)議棧內(nèi)部會(huì)進(jìn)行處理，處理完就會(huì)置位SWI2中斷，中斷內(nèi)部就會(huì)調(diào)用事件分發(fā)，發(fā)送一個(gè)事件，給了事件分發(fā)任務(wù)（dispatch）,這個(gè)任務(wù)會(huì)發(fā)給每個(gè)服務(wù)，每個(gè)服務(wù)會(huì)判斷這個(gè)事件是什么，如果是自己感興趣的就進(jìn)行處理，比如連接請(qǐng)求是每個(gè)服務(wù)都感興趣，服務(wù)可能就會(huì)保存連接句柄，因?yàn)檫B接句柄是后續(xù)處理都要用的。

????????（if部分一般是不通的，沒有使能調(diào)度部分。）

????????這個(gè)中斷的觸發(fā)在協(xié)議棧內(nèi)部，我們看不到，比如協(xié)議棧收到發(fā)給自己的數(shù)據(jù)要進(jìn)行處理，就會(huì)包裝一個(gè)事件，然后觸發(fā)這個(gè)SWI2中斷函數(shù)！

????????intern_softdevice_events_execute函數(shù)中就會(huì)間接調(diào)用ble_evt_dispatch函數(shù)，把這個(gè)事件交給后者處理 ，后者就把事件發(fā)給各個(gè)服務(wù)。

????????（最開始的ble_stack_init協(xié)議棧初始化函數(shù)中通過函數(shù)softdevice_ble_evt_handler_set(ble_evt_dispatch)，賦值給全局變量m_ble_evt_handler = ble_evt_dispatch;）

static void ble_evt_dispatch(ble_evt_t * p_ble_evt) {dm_ble_evt_handler(p_ble_evt);ble_conn_params_on_ble_evt(p_ble_evt);bsp_btn_ble_on_ble_evt(p_ble_evt);on_ble_evt(p_ble_evt);ble_advertising_on_ble_evt(p_ble_evt);/*YOUR_JOB add calls to _on_ble_evt functions from each service your application is usingble_xxs_on_ble_evt(&m_xxs, p_ble_evt);ble_yys_on_ble_evt(&m_yys, p_ble_evt);*/ }

應(yīng)用程序如何發(fā)數(shù)據(jù)給協(xié)議棧：
在服務(wù)中通過調(diào)用API即可。

比如調(diào)用數(shù)據(jù)發(fā)送函數(shù)，然后就是協(xié)議棧的事情了，我們也看不到代碼實(shí)現(xiàn)了。大致過程如下：

?????????number就相當(dāng)于ID號(hào)一樣。加入我們調(diào)用的數(shù)據(jù)發(fā)送功能函數(shù)的ID是3，就相當(dāng)于調(diào)用了_SVC(3),然后就會(huì)“陷入”協(xié)議棧中的SVC中斷函數(shù)。

??????? 上圖中，下半部是協(xié)議棧的代碼，上半部是我們自己寫的程序代碼，分別有一個(gè)中斷向量表。但是實(shí)際上硬件只認(rèn)一個(gè)，所以應(yīng)用程序要緊挨著協(xié)議棧存儲(chǔ)，協(xié)議棧即可找到應(yīng)用程序中設(shè)定的“中斷向量表”，需要的時(shí)候跳轉(zhuǎn)就可。（協(xié)議棧中會(huì)有一個(gè)指針指向燒寫協(xié)議棧后的最末端的地址。）

????????實(shí)際上，當(dāng)真正的外部一切中斷到來時(shí)，都是到達(dá)協(xié)議棧內(nèi)部的中斷向量表中，找到對(duì)應(yīng)的中斷處理函數(shù)，此函數(shù)會(huì)找到APP中斷向量表的偏移，最終定位到用戶寫的handler中斷處理函數(shù)。

二、nrf51 sdk框架

必備的部分如下：

int main(void) {ble_stack_init();gap_params_init();advertising_init();services_init();//跟自己創(chuàng)建的服務(wù)相關(guān)，不同的服務(wù)細(xì)節(jié)不同但大致建立過程一致，通常在官方的例子上修改一些參數(shù)即可。ble_advertising_start(BLE_ADV_MODE_FAST);// Enter main loop.for (;;){power_manage();//進(jìn)入睡眠。 /*內(nèi)部?jī)H僅調(diào)用了sd_app_evt_wait()，內(nèi)部其實(shí)就是調(diào)用一個(gè)arm m0的睡眠指令。*/} }

????????由上可知，初始化之后就進(jìn)入睡眠。那是怎么通訊的呢，可以推測(cè)，肯定是通過中斷、事件這種機(jī)制。有事件產(chǎn)生時(shí)就在事件處理函數(shù)中處理的。

2.1 協(xié)議棧如何運(yùn)作？

????????“100%基于事件”！協(xié)議棧向app發(fā)送的任何數(shù)據(jù)都是基于事件。
????????開機(jī)運(yùn)行初始化完后就進(jìn)入低功耗睡眠了，直到底層有事件發(fā)生，都是協(xié)議棧內(nèi)部先捕獲事件并處理的！！

????????比如設(shè)備收到手機(jī)發(fā)來的鏈接請(qǐng)求，或是手機(jī)發(fā)過來的數(shù)據(jù)等等。協(xié)議棧首先收到這些數(shù)據(jù) 后做一些處理，然后將這些數(shù)據(jù)(比如鏈接請(qǐng)求，或是普通數(shù)據(jù)等)打包成一個(gè)結(jié)構(gòu)體，并附 上事件 ID，比如 BLE_GAP_EVT_CONNECTED 或 BLE_GATTS_EVT_WRITE 來分別告訴上層 app這個(gè)事件結(jié)構(gòu)體代表的事件。 ????????比如 BLE_GAP_EVT_CONNECTED 代表鏈接事件，那么這個(gè)事件結(jié)構(gòu)體中包含的數(shù)據(jù)就是連接參數(shù)等數(shù)據(jù)。
???????? 而 BLE_GATTS_EVT_WRITE 代表寫事件，那么結(jié)構(gòu)體中的數(shù)據(jù)就是對(duì)端設(shè)備(比如手機(jī))寫給板子的數(shù)據(jù)。

ble_evt_dispatch函數(shù)是初始化過程中“自己”注冊(cè)的。其代碼是我們可以修改的。

協(xié)議棧內(nèi)部處理完數(shù)據(jù)打包好就會(huì)交給ble_evt_dispatch函數(shù)。

比如 uart 的 demo 中 dispatch 派發(fā)函數(shù) ： static void ble_evt_dispatch(ble_evt_t * p_ble_evt) { ble_conn_params_on_ble_evt(p_ble_evt);//連接管理相關(guān)的處理函數(shù) ble_nus_on_ble_evt(&m_nus, p_ble_evt);//服務(wù)相關(guān)的，對(duì)手機(jī)讀寫數(shù)據(jù)感興趣 on_ble_evt(p_ble_evt); }

????????在任何與 BLE 相關(guān)的事件被協(xié)議棧上拋上來給 app 時(shí)，該函數(shù)就會(huì)被調(diào)用。從而將事件拋給 各個(gè)服務(wù)函數(shù)或處理模塊,這里是將事件拋給了連接參數(shù)管理處理函數(shù) ble_conn_params_on_ble_evt；Uart 服務(wù)的事件處理函數(shù) ble_nus_on_ble_evt (nus 為 Nordicuart server) ；通用的事件處理函數(shù) on_ble_evt 。

????????這個(gè)函數(shù)把事件交給各個(gè)模塊（實(shí)際就是各個(gè)事件處理函數(shù)，內(nèi)部就是各種case事件）后，處理完后，最終還是會(huì)到這個(gè)函數(shù)這里，再次進(jìn)入睡眠。形成一個(gè)循環(huán)的流程。

2.2 哪里添加服務(wù)？

????????在 main 函數(shù)的初始化過程中有一個(gè) services_init();這個(gè)函數(shù)的內(nèi)部就是添加服務(wù)，添加特征 值等代碼。 ??????? 以串口實(shí)驗(yàn)的demo為例，函數(shù)內(nèi)部其實(shí)就是注冊(cè)了一回調(diào)函數(shù) nus_data_handler(該函數(shù)會(huì)在手機(jī)發(fā)數(shù)據(jù)給板子時(shí)將數(shù)據(jù)從電腦串口打印出來) 然后再執(zhí)行真正的初始化函數(shù) ble_nus_init。（這些都不是固定的，都是自己隨便寫的。參考template的demo，結(jié)構(gòu)體什么的都是自己這個(gè)應(yīng)用想怎么寫就怎么寫。51822sdk要求的是下面這兩個(gè)函數(shù)。） ????????該函數(shù)的內(nèi)部又會(huì)調(diào)用 sd_ble_gatts_service_add 這個(gè)協(xié)議棧的 api 接口來添加服務(wù)。 后面也會(huì)調(diào)用 sd_ble_gatts_characteristic_add 這個(gè)協(xié)議棧的 api 接口來添加特征值。 層次關(guān)系如下：

????????也 就 是 說 完 成 一 個(gè) 完 整 的 服 務(wù) 建 立 函 數(shù) 其 實(shí) 只 要 sd_ble_gatts_service_add() 和sd_ble_gatts_characteristic_add ()這兩個(gè)核心函數(shù)。 ????????通常建立服務(wù)并不需要自己去從頭寫過。而是直接賦值官方的這個(gè) services_init()函數(shù)，然后 做一些小改動(dòng)就可以。比如修改一下 uuid, 修改一下讀/寫屬性，多添加一個(gè)特征值等。要修改的其實(shí)很少。 ????????難點(diǎn)在于自己改sd_ble_gatts_characteristic_add ()函數(shù)時(shí)里面有很多參數(shù)需要自己設(shè)置。（其實(shí)很多綁定安全連接等參數(shù)我們初學(xué)使用中不改也行，需要的時(shí)候?qū)φ帐謨?cè)改）。

2.3 主機(jī)發(fā)送來的數(shù)據(jù)在哪里？如何發(fā)送數(shù)據(jù)給手機(jī)？

問：手機(jī)發(fā)給 51822 設(shè)備的數(shù)據(jù)，用哪個(gè)API函數(shù)取出來？（這體現(xiàn)了另一種協(xié)議棧設(shè)計(jì)方式） 答：沒有函數(shù)。協(xié)議棧會(huì)拋上來一個(gè)事件結(jié)構(gòu)體，收到的數(shù)據(jù)在事件結(jié)構(gòu)體中。 依舊以SDK中自帶的ble_app_uart這個(gè)demo為例： ble_evt_dispatch(ble_evt_t * p_ble_evt)中有?ble_nus_on_ble_evt(&m_nus, p_ble_evt); 后者內(nèi)部“捕獲”三個(gè)事件：switch (p_ble_evt->header.evt_id) case BLE_GAP_EVT_CONNECTED 、BLE_GAP_EVT_DISCONNECTED、BLE_GATTS_EVT_WRITE（寫事件！）。

typedef struct {ble_evt_hdr_t header; /**< Event header. */union{ble_common_evt_t common_evt; /**< Common Event, evt_id in BLE_EVT_* series. */ble_gap_evt_t gap_evt; /**< GAP originated event, evt_id in BLE_GAP_EVT_* series. */ble_l2cap_evt_t l2cap_evt; /**< L2CAP originated event, evt_id in BLE_L2CAP_EVT* series. */ble_gattc_evt_t gattc_evt; /**< GATT client originated event, evt_id in BLE_GATTC_EVT* series. */ble_gatts_evt_t gatts_evt; /**< GATT server originated event, evt_id in BLE_GATTS_EVT* series. */} evt; } ble_evt_t;typedef struct {uint16_t conn_handle; /**< Connection Handle on which the event occurred. */union{ble_gatts_evt_write_t write; /**主機(jī)寫數(shù)據(jù)過來的結(jié)構(gòu)體！！*/ble_gatts_evt_rw_authorize_request_t authorize_request; /**< Read or Write Authorize Request Parameters. */ble_gatts_evt_sys_attr_missing_t sys_attr_missing; /**< System attributes missing. */ble_gatts_evt_hvc_t hvc; /**< Handle Value Confirmation Event Parameters. */ble_gatts_evt_timeout_t timeout; /**< Timeout Event. */} params; /**< Event Parameters. */ } ble_gatts_evt_t;typedef struct {uint16_t handle; /**< Attribute Handle.句柄！！ */ble_uuid_t uuid; /**< Attribute UUID. */uint8_t op; /**< Type of write operation, see @ref BLE_GATTS_OPS. */uint8_t auth_required; /**< Writing operation deferred due to authorization requirement. Application may use @ref sd_ble_gatts_value_set to finalise the writing operation. */uint16_t offset; /**< Offset for the write operation. */uint16_t len; /**< Length of the received data. */uint8_t data[1]; /**< 數(shù)據(jù)！！Received data. @note This is a variable length array. The size of 1 indicated is only a placeholder for compilation.See @ref sd_ble_evt_get for more information on how to use event structures with variable length array members. */ } ble_gatts_evt_write_t;

????? 補(bǔ)充：? sd_ble_gatts_hvx（）這個(gè)函數(shù)是藍(lán)牙的發(fā)送函數(shù)。可以通過參數(shù)來設(shè)置是以通知方式發(fā)送還是指示方式發(fā)送(通知不需要回復(fù)確認(rèn)，指示需要)。 ??????? 為啥又發(fā)送的函數(shù)，不弄個(gè)接受的函數(shù)呢？
??????? 因?yàn)榘l(fā)送是“同步的”，我們代碼知道什么時(shí)候發(fā)。可是不知道什么時(shí)候收數(shù)據(jù)，如果調(diào)用函數(shù)，豈不是一直等？這是異步的過程，底層實(shí)現(xiàn)只能通過異步事件通知的方式。

三、main函數(shù)中初始化詳解

https://blog.csdn.net/chen3522061/article/details/118265541

四、main函數(shù)進(jìn)入休眠之后呢？

????????整個(gè)初始化完成后，設(shè)備便進(jìn)入睡眠模式，每當(dāng)廣播間隔到期會(huì)發(fā)送一次廣播。即工作狀態(tài)為：睡眠+廣播。直到有設(shè)備發(fā)來連接請(qǐng)求，當(dāng)設(shè)備連接上手機(jī)后邊繼續(xù)處于睡眠狀態(tài)等待”事件”的發(fā)生。

老版本的串口透?jìng)鞯睦訛槔?/strong>

電腦串口->51822->手機(jī)

????????main 函數(shù)的串口初始化程序 uart_init 的最后打開了串口的接收中斷。那么這個(gè)方向的數(shù)據(jù)流的起點(diǎn)就是在串口中斷中收到電腦上發(fā)來的數(shù)據(jù)為起點(diǎn)，通過無線發(fā)給手機(jī)。 （重點(diǎn)是API：sd_ble_gatts_hvx函數(shù)） void UART0_IRQHandler(void)//就在主文件的main函數(shù)的上面 {static uint8_t data_array[BLE_NUS_MAX_DATA_LEN];static uint8_t index = 0;uint32_t err_code; uint8_t temp; //取得電腦串口發(fā)過來的數(shù)據(jù)data_array[index] = simple_uart_get();index++; //判斷串口發(fā)送給來的數(shù)據(jù)是否達(dá)到 20 的字節(jié)，或者是不是發(fā)送了字母’q’。如果滿足 //調(diào)用發(fā)送函數(shù)將收到的串口數(shù)據(jù)發(fā)送給手機(jī)。否則不發(fā)送等待知道滿足條件。// (這里通常新手說手機(jī)收不到數(shù)據(jù)的原因，因?yàn)闆]輸入達(dá)到 20 個(gè)字節(jié))if ((data_array[index - 1] == 'q') || (index >= (BLE_NUS_MAX_DATA_LEN - 1))){err_code = ble_nus_send_string(&m_nus, data_array, index + 1); //這個(gè)模樣像API？然而是這個(gè)項(xiàng)目自己寫的，封裝了一下，其實(shí)內(nèi)部起作用的是sd_ble_gatts_hvx！！//發(fā)送了數(shù)據(jù)后清零數(shù)組下標(biāo)。以繼續(xù)緩存后續(xù)的串口數(shù)據(jù)。index = 0;} }uint32_t ble_nus_send_string(ble_nus_t * p_nus, uint8_t * string, uint16_t length) {ble_gatts_hvx_params_t hvx_params;//這里是檢測(cè)參數(shù)是否正確。是否是已經(jīng)連接上了手機(jī) (只有連接后，conn_handle 才會(huì)// 被賦值為有效值),檢查手機(jī)是否使能了開發(fā)板的通知，因?yàn)殚_發(fā)板作為服務(wù)端向手機(jī) //發(fā)送數(shù)據(jù)時(shí)通過通知或指示兩種方式，這兩種方式都需要手機(jī)先使能開發(fā)板。if((p_nus->conn_handle==BLE_CONN_HANDLE_INVALID)||(!p_nus->is_notification_enabled)){return NRF_ERROR_INVALID_STATE;} //一次發(fā)送的長(zhǎng)度不能超過限定值，通常為 20if (length > BLE_NUS_MAX_DATA_LEN){return NRF_ERROR_INVALID_PARAM;}memset(&hvx_params, 0, sizeof(hvx_params)); //以為是通過 Rx 這個(gè)參數(shù)來發(fā)送數(shù)據(jù)給手機(jī)的，所以句柄要填 rx 的句柄 //這個(gè)句柄是在上面的服務(wù)初始化函數(shù)中的添加特征值函數(shù)調(diào)用完畢后或得的(最后一 // 個(gè)參數(shù)為返回的句柄) //然后就是賦值要發(fā)送的數(shù)據(jù)，并且設(shè)置為 notify 方式hvx_params.handle = p_nus->rx_handles.value_handle;hvx_params.p_data = string;hvx_params.p_len = &length;hvx_params.type = BLE_GATT_HVX_NOTIFICATION; //發(fā)送函數(shù)return sd_ble_gatts_hvx(p_nus->conn_handle, &hvx_params); } ????????調(diào)用 sd_ble_gatts_hvx(p_nus->conn_handle, &hvx_params);發(fā)送數(shù)據(jù)給手機(jī)的時(shí)候，第二 個(gè)參數(shù)是上面賦值的，那第一個(gè)參數(shù)這個(gè)連接句柄是怎么回事？在哪里設(shè)置過他？ ????????連接句柄你可以看做是信道標(biāo)志一樣(實(shí)際數(shù)據(jù)接入地址)，每?jī)蓚€(gè)連接的設(shè)備都會(huì)具有這個(gè) 連接句柄。他們后續(xù)的通信都是通過這個(gè)連接句柄來進(jìn)行(可以理解是信道標(biāo)志，兩個(gè)設(shè) 的通信標(biāo)志必須一樣，這代表他們是在同樣的信道上通信才能正確進(jìn)行通信) ????????上面說過，板子整個(gè)初始化流程走完后就是睡眠和廣播等待手機(jī)連接。那么這個(gè)conn_handle 就一定是手機(jī)發(fā)來連接，板子中協(xié)議棧處理完后上拋給 app 的連接事件中賦值的。從而記錄下后續(xù)板子和手機(jī)通信的”信道”。 在 程序框架剖析 那一講中介紹過，協(xié)議棧拋上來的事件結(jié)構(gòu)體最終是由 dispatch 這個(gè)派發(fā)程序發(fā)給再發(fā)給各個(gè)服務(wù)的事件處理函數(shù)和模塊的事件處理函數(shù)的。 static void ble_evt_dispatch(ble_evt_t * p_ble_evt) { //將事件交給連接管理模塊的事件處理函數(shù) ble_conn_params_on_ble_evt(p_ble_evt); //將事件交給 uart 服務(wù)的事件處理函數(shù) ble_nus_on_ble_evt(&m_nus, p_ble_evt); //處理一些一般的事件on_ble_evt(p_ble_evt); }

再進(jìn)入 uart 服務(wù)的事件處理函數(shù)中看下發(fā)生連接時(shí)是如何記下 后續(xù)通信所用的連接句柄 的：

疑問：那注冊(cè)服務(wù)時(shí)的&p_nus->service_handle是什么呢？？？？？？？？？？？？？

手機(jī)->51822手機(jī)電腦串口->51822->

sdk11版本的串口透?jìng)鞯睦訛槔?/strong>

總結(jié)

以上是生活随笔為你收集整理的nrf51822杂乱笔记的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。