NORDIC藍(lán)牙BLE4.0方案SDK例子ANCS代碼分析

1、NORDIC藍(lán)牙BLE4.0方案SDK例子ANCS代碼分析參考：SDK11.0.0nRF5_SDK_11.0.0_89a8197examplesble_peripheralble_app_ancs_c1. 主函數(shù)下面結(jié)合上面的函數(shù)慢慢展開講解。2. 宏定義3. 定時(shí)器timers_init如下圖3.1. APP_TIMER_APPSH_INT宏Nordic的定時(shí)器是通過(guò)RTC1模擬出了一個(gè)定時(shí)器時(shí)鐘隊(duì)列，所以在初始化時(shí)需要傳入的參數(shù)有兩個(gè)：APP_TIMER_PRESCALER：時(shí)鐘分頻APP_TIMER_OP_QUEUE_SIZE：timer的隊(duì)列第3個(gè)參數(shù)是是否啟動(dòng)調(diào)度，這里true表示啟

2、用任務(wù)調(diào)度。也就是說(shuō)會(huì)調(diào)用app_timer_evt_schedule函數(shù)進(jìn)行時(shí)間任務(wù)調(diào)度，后面會(huì)講解。上面的初始化時(shí)使用的宏，那么真正的初始化函數(shù)是：上面又是一個(gè)宏進(jìn)行封裝的，實(shí)體如下：不繼續(xù)向下分析了，到這定時(shí)器就初始化完畢了。截取SDK說(shuō)明文檔中的說(shuō)明吧！3.2. 定時(shí)器創(chuàng)建app_timer_create定時(shí)器創(chuàng)建函數(shù)如下：這里定時(shí)器句柄是通過(guò)宏進(jìn)行定義的：這個(gè)宏的函數(shù)原型是：上面的“#” 表示連接前后的字符，也就是上面的宏表示static app_timer_t m_sec_req_timer_id_data= 0 ; static constapp_timer_id_t timer

3、_id = &m_sec_req_timer_id_data;實(shí)際上這個(gè)宏就是定義個(gè)兩個(gè)變量。3.3. 回調(diào)函數(shù)sec_req_timeout_handler回 調(diào)函數(shù)的作用，從名字上看的話，這個(gè)回調(diào)函數(shù)應(yīng)該與安全管理有關(guān)，那么到底什么關(guān)系呢？我們知道ANCS服務(wù)必須是在配對(duì)綁定啟動(dòng)加密之后才能進(jìn)行服務(wù) 的，也就是必須進(jìn)行配對(duì)綁定，然而配對(duì)就必須通過(guò)安全管理進(jìn)行，所以這個(gè)回調(diào)函數(shù)是從機(jī)啟動(dòng)加密請(qǐng)求，然而為啥又通過(guò)定時(shí)器進(jìn)行控制呢？這里只有當(dāng)連接建 立之后進(jìn)行一次調(diào)用，所以在創(chuàng)建定時(shí)器時(shí)使用的APP_TIMER_MODE_SINGLE_SHOT參數(shù)，為什么需要用定時(shí)器，因?yàn)閯倓偨⑦B接時(shí)需要 給

4、雙方一定的緩沖時(shí)間，在后面啟動(dòng)定時(shí)器時(shí)會(huì)傳入定時(shí)時(shí)間的?？纯催@個(gè)函數(shù)吧：這個(gè)回調(diào)函數(shù)有個(gè)入口參數(shù)，void * p_context。這個(gè)參數(shù)是在啟動(dòng)定時(shí)器時(shí)傳進(jìn)來(lái)的，當(dāng)然看有沒有用了，如果沒有用，就傳入NULL。在ANCS應(yīng)用中是在設(shè)備進(jìn)行連接之后進(jìn)行發(fā)起的，因?yàn)樾枰壎ǎ孕枰玫絥ordic的SDK中的設(shè)備管理文件，所以這個(gè)啟動(dòng)定時(shí)器是在設(shè)備管理事件回調(diào)函數(shù)中調(diào)用。4. 協(xié)議棧初始化ble_stack_init()協(xié)議棧初始化ble_stack_init()函數(shù)原型如下：第710函數(shù)設(shè)置低頻時(shí)鐘源，并初始化協(xié)議棧，第2個(gè)參數(shù)是在使用調(diào)度或者RTOS時(shí)傳入的回調(diào)函數(shù)句柄，例如如果帶有fre

5、ertos時(shí)，會(huì)傳入一個(gè)回調(diào)函數(shù)，這個(gè)回調(diào)函數(shù)會(huì)發(fā)出一個(gè)二值信號(hào)量，這個(gè)信號(hào)量發(fā)給協(xié)議棧。第713行其實(shí)就是初始化結(jié)構(gòu)體ble_enable_params，這個(gè)結(jié)構(gòu)體如下：第721行是根據(jù)程序所需的內(nèi)存大小來(lái)動(dòng)態(tài)的進(jìn)行設(shè)置起始地址和ram大小。在mdk中有一個(gè)可以設(shè)置RAM大小的地方：但是程序并不是一定是從這個(gè)地方開始，所以這個(gè)函數(shù)進(jìn)行重新調(diào)整，具體怎么調(diào)整可以自己看源碼，如果需要調(diào)整會(huì)打?。?.1. 協(xié)議棧事件有哪些第728和第732行是向協(xié)議棧和系統(tǒng)注冊(cè)事件對(duì)應(yīng)的處理函數(shù)。52832的整個(gè)協(xié)議都是通過(guò)事件進(jìn)行驅(qū)動(dòng)的，協(xié)議棧和事件可以向應(yīng)用層發(fā)送許多的事件，應(yīng)用層更具得到的事件在進(jìn)行相應(yīng)的處

6、理，例如那么這些怎么知道協(xié)議棧和系統(tǒng)到底能發(fā)送那些事件給應(yīng)用層呢？可以查看一下注冊(cè)函數(shù)傳入的參數(shù)是什么：也就只有知道ble_evt_t這個(gè)結(jié)構(gòu)體中有哪些事件即可：從上面可以了解到evt_id都是以BLE_EVT定義的枚舉，然而有哪些模塊可以上傳事件呢？在上圖的191行的聯(lián)合體中定義了5個(gè)模塊可以向應(yīng)用發(fā)送事件。在ble_ranges.h的頭文件中有如下宏：這個(gè)宏就是各個(gè)事件枚舉的起始值和結(jié)束值，根據(jù)這些宏可查找到這5個(gè)事件的所有枚舉。分別為：l公共事件lGAP事件lL2CAP事件lGATT客戶端事件lGATT服務(wù)器事件4.2. 系統(tǒng)事件有哪些先看看系統(tǒng)分發(fā)事件函數(shù)中到底分發(fā)了哪些東西：追溯到函

7、數(shù)里面去的話可以發(fā)現(xiàn)，上面兩個(gè)函數(shù)用到的事件ID只用到兩個(gè)：NRF_EVT_FLASH_OPERATION_SUCCESS /flash操作成功NRF_EVT_FLASH_OPERATION_ERROR /flash操作失敗ble_advertising_on_sys_evt這個(gè)函數(shù)是當(dāng)flash失敗時(shí)開始廣播。5. 設(shè)備管理5.1. 設(shè)備管理初始化在52832的SDK11中加了device_manager_init函數(shù)，包含了之前版本的安全參數(shù)初始化的內(nèi)容。device_manager_init這個(gè)函數(shù)傳入的參數(shù)為bool類型，為true時(shí)擦除flash中存儲(chǔ)的所有設(shè)備信息，為false時(shí)就

8、不擦除綁定的設(shè)備信息，這些信息用于廣播白名單列表以及秘鑰的一些保存。第469行調(diào)用pstorage_init()函數(shù)將flash進(jìn)行初始化。第465行將傳入的參數(shù)賦值個(gè)一個(gè)結(jié)構(gòu)體，這個(gè)結(jié)構(gòu)體作為參數(shù)傳入dm_init()函數(shù)，其實(shí)就是進(jìn)行flash進(jìn)行擦除的函數(shù)。register_param.sec_param結(jié)構(gòu)體變量將開始的定義的安全管理的宏傳入結(jié)構(gòu)體，這個(gè)安全管理參數(shù)只進(jìn)行綁定，臨時(shí)秘鑰TK為6個(gè)0。第490行為設(shè)備管理注冊(cè)，第一個(gè)參數(shù)m_app_handle為這個(gè)函數(shù)的返回值，也就是設(shè)備管理返回的一個(gè)應(yīng)用層用的句柄。52832最多可以保存8個(gè)設(shè)備的信息，多了就要去擦除。5.2. 設(shè)備管

9、理事件回調(diào)函數(shù)在485行還傳入了一個(gè)函數(shù)device_manager_evt_handler，這個(gè)函數(shù)的函數(shù)定義如下：分別是：l連接完成事件l連接斷開事件l加密開始事件l加密完成事件l已經(jīng)處于加密通信連接l加密重新建立6. 對(duì)端設(shè)備服務(wù)發(fā)現(xiàn)對(duì)端設(shè)備有么有ANCS的服務(wù)，需要本地設(shè)備在連接之后去發(fā)現(xiàn)對(duì)端設(shè)備的服務(wù)，這里的初始化函數(shù)如下：上面的調(diào)用了一個(gè)函數(shù)，同時(shí)也傳入了一個(gè)函數(shù)。ble_db_discovery_init函數(shù)定義如下：db_disc_handler函數(shù)定義如下：7. 任務(wù)調(diào)度隊(duì)列Scheduler_init函數(shù)如下：如果不跑rtos，SDK11中是使用一個(gè)隊(duì)列來(lái)管理多個(gè)任務(wù)的，因

10、為中斷中不能處理太多和時(shí)間太長(zhǎng)的任務(wù)，所以在中斷中將相應(yīng)的事件標(biāo)志以及處理函數(shù)放入隊(duì)列，然后在主函數(shù)中，一直輪訓(xùn)這個(gè)隊(duì)列處理相應(yīng)的任務(wù)。從上面分析可以大概了解，應(yīng)該有3個(gè)函數(shù)需要調(diào)用：l列初始化函數(shù)APP_SCHED_INIT；l事件注入隊(duì)列的函數(shù)app_sched_event_put；l放在主循環(huán)中的一個(gè)函數(shù)來(lái)輪訓(xùn)隊(duì)列app_sched_execute。繼續(xù)往下走可以知道ble_ancs_c_on_db_disc_evt函數(shù)是對(duì)ANCS服務(wù)的具體發(fā)現(xiàn)，傳入的兩個(gè)參數(shù)，第一個(gè)參數(shù)是應(yīng)用層定義的關(guān)于ANCS的一個(gè)結(jié)構(gòu)體，第二個(gè)參數(shù)是設(shè)備發(fā)現(xiàn)時(shí)協(xié)議棧向應(yīng)用層上報(bào)的事件7.1. APP_SCHED_

11、INIT他其實(shí)是一個(gè)宏：這里注意傳入的兩個(gè)參數(shù)：lEVENT_SIZE這個(gè) size的大小就像定義一個(gè)聯(lián)合體，聯(lián)合體所占用的內(nèi)存是變量中占用內(nèi)存最大的那個(gè)，這里的size也是這樣的，假設(shè)有3個(gè)任務(wù)，這3任務(wù)產(chǎn)生的事件分別 為1、3、7個(gè)，假設(shè)每個(gè)事件所占用的內(nèi)存為1個(gè)字節(jié)。那么這里傳入的EVENT_SIZE應(yīng)該為7*1byte，即7個(gè)字節(jié)。lQUEUE_SIZE任 務(wù)調(diào)度室隊(duì)列的大小，這個(gè)隊(duì)列其實(shí)就像一個(gè)緩存，中斷函數(shù)是這個(gè)緩存的數(shù)據(jù)生成者，主循環(huán)是這個(gè)緩存的消耗者，假設(shè)中斷生產(chǎn)的數(shù)據(jù)比主循環(huán)消耗的數(shù)據(jù)要 快，那么是不是通過(guò)擴(kuò)大緩存來(lái)解決這個(gè)不平衡的問(wèn)題。通用這個(gè)QUEUE_SIZE也是根據(jù)中

12、斷產(chǎn)生事件的速度來(lái)覺得這個(gè)隊(duì)列的大小的，假設(shè)有2個(gè)地方用 到了app_sched_event_put，那么這個(gè)隊(duì)列的最小設(shè)置為2。如果調(diào)用app_sched_event_put的頻率非常高，那就就要嘗試 這擴(kuò)大這個(gè)大小了。7.2. app_sched_event_put他的函數(shù)定義如下：傳入的參數(shù)有3個(gè)，先看第3個(gè)app_sched_event_handler_t，這是一個(gè)函數(shù)指針。定義如下：可以知道，前兩個(gè)參數(shù)其實(shí)就在這個(gè)回調(diào)函數(shù)的參數(shù)。7.2.1. app_timer_evt_schedule在講定時(shí)器章節(jié)中的APP_TIMER_APPSH_INT宏中，有傳入一個(gè)定時(shí)器的回調(diào)函數(shù)：進(jìn)入看看

13、：app_timer_evt_get函數(shù)就是任務(wù)的處理函數(shù)7.2.2. ANCS實(shí)例中的任務(wù)調(diào)度時(shí)最終調(diào)用的定時(shí)器回調(diào)函數(shù)而這里實(shí)際的處理函數(shù)是在創(chuàng)建定時(shí)器時(shí)傳入的回調(diào)函數(shù)：8. 連接參數(shù)連接參數(shù)有哪些需要設(shè)置？4個(gè)供主機(jī)參考的參數(shù)，最小連接間隔、最大連接間隔、從機(jī)潛伏期和連接超時(shí)時(shí)間。具體函數(shù)如下：第350行設(shè)置的是安全模式，在ble4.0中有如下幾種安全模式：安全模式1等級(jí)1：連接無(wú)需安全管理安全模式1等級(jí)2：需要加密但無(wú)中間人保護(hù)/加密的未認(rèn)證配對(duì)安全模式1等級(jí)3：有加密且有中間人保護(hù)/加密的認(rèn)證配對(duì)安全模式2等級(jí)1：簽名但無(wú)中間人保護(hù)/數(shù)據(jù)簽名的未認(rèn)證配對(duì)安全模式2等級(jí)2：中間人簽名保

14、護(hù)/帶數(shù)據(jù)簽名的認(rèn)證配對(duì)這里設(shè)置的是安全模式1等級(jí)1，即沒有安全需求，這里是不是有疑問(wèn)，ANCS不是必須進(jìn)行綁定嗎？為啥設(shè)置怎么低的安全等級(jí)，因?yàn)檫@個(gè)里程中安全請(qǐng)求是有本地發(fā)起的。第352行將設(shè)備名字傳入?yún)f(xié)議棧。第364行設(shè)置的就是基本的連接參數(shù)。9. 廣播初始化廣播初始化主要是設(shè)置一些廣播間隔時(shí)間、超時(shí)時(shí)間以及廣播模式等等參數(shù)。也會(huì)設(shè)置廣播內(nèi)容，例如廣播自己有哪些服務(wù)UUID，也可以廣播自己想要得到哪些服務(wù)的UUID，也可以設(shè)置掃描應(yīng)答的數(shù)據(jù)。本例具體函數(shù)如下：這里需要注意的是，廣播初始化一定要放到服務(wù)初始化函數(shù)的后面，因?yàn)閺V播初始化中有些參數(shù)是由服務(wù)初始化時(shí)傳遞上來(lái)的，例如：第804行的UUID類型就是服務(wù)初始化時(shí)協(xié)議棧傳出來(lái)的。第814和815行設(shè)置的是自己希望對(duì)端設(shè)備擁有的服務(wù)的UUID，即ANCS服務(wù)。第826行就是廣播的初始化函數(shù)了，在這個(gè)函數(shù)中傳入了一個(gè)事件回調(diào)函數(shù)on_adv_evt，在協(xié)議棧初始化時(shí)向協(xié)議棧以及系統(tǒng)注冊(cè)的事件分發(fā)函數(shù)是連接之后的回調(diào)，這里只是一個(gè)廣播事件回調(diào)函數(shù)，那就看看廣播事件到底有哪些事件可以產(chǎn)生：可見廣播事件也不多??！上面的最后兩個(gè)事件如果白名單沒有使能或者沒有啟用定向廣播，這兩個(gè)事件是可