嵌入式多節(jié)點(diǎn)的無線批量程序更新系統(tǒng)設(shè)計(jì)(二)

　　緩沖區(qū)Deluge_buf

　　Deluge_buf是一個環(huán)形緩沖區(qū)，用于緩存原始的網(wǎng)絡(luò)層數(shù)據(jù)。緩沖區(qū)實(shí)際上是由一個環(huán)形鏈表、兩個指針和一個整數(shù)組成。鏈表的每個節(jié)點(diǎn)用于存儲實(shí)際數(shù)據(jù)，節(jié)點(diǎn)數(shù)目根據(jù)需要而定;一個tail指針和一個head指針，分別指鏈表的讀出點(diǎn)和寫入點(diǎn)，執(zhí)行一次讀出或?qū)懭氩僮骱螅瑃ail或head指針都向前移動一次，整數(shù)的作用是統(tǒng)計(jì)當(dāng)前鏈表上可用節(jié)點(diǎn)的數(shù)目。Deluge_buf結(jié)構(gòu)體定義如下：

　　struct Deluge_buf {

　　struct data_entry queue_data[QUEUE_LENGTH]; // The data of current queue

　　uint8 recv_num;

　　uint8 queue_head;

　　uint8 queue_tail;

　　};

　　值得注意的是結(jié)構(gòu)體data_entry中Payload項(xiàng)的組成在不同類型的幀中是不同的，比如數(shù)據(jù)幀中Payload包括頁號p、幀號id和數(shù)據(jù)data以及數(shù)據(jù)長度data_len，而廣告幀中只包含p和id，因此解析方法要根據(jù)type值來區(qū)分。

　　幀結(jié)構(gòu)DelugeData

　　如圖五所示，DelugeData定義了幀類型(type)等六個數(shù)據(jù)項(xiàng)，設(shè)計(jì)中根據(jù)不同的幀類型規(guī)定了各個數(shù)據(jù)項(xiàng)的含義，具體定義如表4.1所示，“—”表示該數(shù)據(jù)項(xiàng)在幀中沒有定義。

表4.1 DelugeData中數(shù)據(jù)項(xiàng)含義的定義

　　3、緩沖區(qū)Flash_buf

　　因?yàn)閷慺lash操作比網(wǎng)絡(luò)傳輸慢得多，為了避免寫flash拖慢整個數(shù)據(jù)分發(fā)速度，建立緩沖區(qū)Flash_buf用于緩存準(zhǔn)備好的數(shù)據(jù)。Flash_buf也是一個環(huán)形緩沖區(qū)，原理和Deluge_buf相同。緩沖區(qū)的節(jié)點(diǎn)包含p、id、data三個數(shù)據(jù)項(xiàng)和指針域next，其中data是要寫入flash的數(shù)據(jù)，p和id用于計(jì)算待寫入的flash地址。

　　3.3.3 可靠數(shù)據(jù)分發(fā)協(xié)議的軟件架構(gòu)設(shè)計(jì)

　　可靠數(shù)據(jù)分發(fā)協(xié)議的軟件構(gòu)架設(shè)計(jì)包括發(fā)送端和接收端兩塊內(nèi)容。發(fā)送端軟件運(yùn)行在數(shù)據(jù)基站上，分為兩個階段，第一階段通知節(jié)點(diǎn)連續(xù)地發(fā)送整個文件，第二階段運(yùn)行狀態(tài)機(jī)參與到節(jié)點(diǎn)的交流中去;接收端軟件運(yùn)行在待燒錄節(jié)點(diǎn)上，第一個階段盡可能多的接收基站發(fā)送來的數(shù)據(jù)，第二階參與節(jié)點(diǎn)間討論。因?yàn)榘l(fā)送端第一階段軟件比較簡單，第二階段和接收端相同，所以這里只重點(diǎn)介紹接收端的軟件構(gòu)架設(shè)計(jì)。

　　第一階段：

　　程序完成初始化后進(jìn)入準(zhǔn)備接收狀態(tài)，當(dāng)數(shù)據(jù)幀到來時(shí)將數(shù)據(jù)提取出來寫到flash相應(yīng)的地址(地址由頁號p和幀號id計(jì)算得到)，并將該幀標(biāo)記為“完成幀”;若接收到結(jié)束幀，則記錄結(jié)束幀的頁號pmax和幀號idmax并進(jìn)入第二階段;若接收到其他類型幀則直接進(jìn)入第二階段。第一階段的軟件流程圖如圖4.6所示。

　　第二階段：

　　完成第一輪接收后，程序運(yùn)行ADV-REQ-DATA狀態(tài)機(jī)，和其他節(jié)點(diǎn)交流，完善或幫助其他節(jié)點(diǎn)完善數(shù)據(jù)文件。狀態(tài)機(jī)分為MAINTAIN(維護(hù))、RX(請求)和TX(發(fā)送)三個狀態(tài)，程序首先進(jìn)入MAINTAIN狀態(tài)。MAINTAIN狀態(tài)下，程序監(jiān)聽廣告幀和請求幀并在適當(dāng)時(shí)機(jī)發(fā)送廣告，根據(jù)協(xié)議規(guī)定，程序可能跳轉(zhuǎn)到RX狀態(tài)或TX狀態(tài)進(jìn)行數(shù)據(jù)幀請求和發(fā)送操作，操作完成后返回MAINTAIN狀態(tài)。程序中定義一個最長時(shí)間tmax，如果MAINTAIN狀態(tài)持續(xù)時(shí)間超過tmax，則認(rèn)為整個數(shù)據(jù)分發(fā)過程結(jié)束，程序檢查自己接收到的數(shù)據(jù)是否完備后退出。第二階段的軟件流程圖如圖4.7所示。

　　四 系統(tǒng)測試

　　本測試將用三個程序作為用例，以測試系統(tǒng)的可用性。三個程序分別為：

　　Led.bin實(shí)現(xiàn)簡單的跑馬燈;

　　GoAhead.bin 三輛小車將一直向前方走，即使碰到障礙物也不停止;

　　RandomWalk.bin 三輛小車將進(jìn)行隨機(jī)行走，并且碰到障礙物后會進(jìn)行壁障，轉(zhuǎn)彎。

　　首先我們將批量更新跑馬燈的程序，然后我們來看GoAhead.bin，如圖5.1所示。完整的程序鏡像大小為3340Bytes

　　當(dāng)前在節(jié)點(diǎn)上已經(jīng)運(yùn)行了Led.bin,我們將使用Led.bin和GoAhead.bin進(jìn)行比較，生成patch.bin文件，即補(bǔ)丁文件。

　　我們看到，生成的patch.bin文件僅僅是原程序GoAhead.bin的1/3大小!圖5.3是patch.bin代表的命令(截取一部分)。

　　下面從GoAhead.bin 生成 RandomWalk.bin，RandomWalk.bin的大小如圖5.4所示：

　　圖5.5從生成的patch.bin文件的大小可以看到，其為RandomWalk的大約1/3。但有個值得注意的地方是，RandomWalk.bin比GoAhead.bin大了1000多個字節(jié)。添加的著1000多個字節(jié)是占patch.bin的主要內(nèi)容。可見發(fā)送patch.bin比較適合于修改部分變量或者函數(shù)的時(shí)候。如果是單純的增加功能，比較適合于發(fā)送完整的鏡像文件。

　　五 總結(jié)

　　測試結(jié)果表明，本設(shè)計(jì)實(shí)現(xiàn)了可靠性無線批量嵌入式節(jié)點(diǎn)程序更新，燒錄出錯率低;更新效率高;不依賴操作系統(tǒng)，具有很好的可移植性，項(xiàng)目總體上實(shí)現(xiàn)了設(shè)計(jì)的目標(biāo)。另一方面由于時(shí)間限制，系統(tǒng)仍然存在一些不足。以下是設(shè)計(jì)中幾點(diǎn)需要優(yōu)化的地方和相應(yīng)的改進(jìn)意見。

　　系統(tǒng)在Linux環(huán)境下進(jìn)行了開發(fā)和應(yīng)用，沒有開發(fā)Windows版本。項(xiàng)目組準(zhǔn)備在下一階段把系統(tǒng)移植到Windows平臺上。

　　尚未實(shí)現(xiàn)程序的動態(tài)更新，即每次更新前都要將正在運(yùn)行的程序關(guān)掉，強(qiáng)制節(jié)點(diǎn)進(jìn)入準(zhǔn)備狀態(tài)?？梢苑峙湟粋€專用線程用于程序更新，同時(shí)為了避免更新對正在運(yùn)行的程序造成影響，需要在更新過程中引入動態(tài)鏈接技術(shù)