緩沖區(qū)Deluge_buf

　　Deluge_buf是一個環(huán)形緩沖區(qū)，用于緩存原始的網(wǎng)絡層數(shù)據(jù)。緩沖區(qū)實際上是由一個環(huán)形鏈表、兩個指針和一個整數(shù)組成。鏈表的每個節(jié)點用于存儲實際數(shù)據(jù)，節(jié)點數(shù)目根據(jù)需要而定;一個tail指針和一個head指針，分別指鏈表的讀出點和寫入點，執(zhí)行一次讀出或?qū)懭氩僮骱?，tail或head指針都向前移動一次，整數(shù)的作用是統(tǒng)計當前鏈表上可用節(jié)點的數(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項的組成在不同類型的幀中是不同的，比如數(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ù)項，設計中根據(jù)不同的幀類型規(guī)定了各個數(shù)據(jù)項的含義，具體定義如表4.1所示，“—”表示該數(shù)據(jù)項在幀中沒有定義。

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

　　3、緩沖區(qū)Flash_buf

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

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

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

　　第一階段：

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

　　第二階段：

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

　　四 系統(tǒng)測試

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

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

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

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

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

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

　　我們看到，生成的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ù)的時候。如果是單純的增加功能，比較適合于發(fā)送完整的鏡像文件。

　　五 總結(jié)

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

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

　　尚未實現(xiàn)程序的動態(tài)更新，即每次更新前都要將正在運行的程序關(guān)掉，強制節(jié)點進入準備狀態(tài)。可以分配一個專用線程用于程序更新，同時為了避免更新對正在運行的程序造成影響，需要在更新過程中引入動態(tài)鏈接技術(shù)