嵌入式多節點的無線批量程序更新系統設計(二)

　　緩沖區Deluge_buf

　　Deluge_buf是一個環形緩沖區，用于緩存原始的網絡層數據。緩沖區實際上是由一個環形鏈表、兩個指針和一個整數組成。鏈表的每個節點用于存儲實際數據，節點數目根據需要而定;一個tail指針和一個head指針，分別指鏈表的讀出點和寫入點，執行一次讀出或寫入操作后，tail或head指針都向前移動一次，整數的作用是統計當前鏈表上可用節點的數目。Deluge_buf結構體定義如下：

　　struct Deluge_buf {

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

　　uint8 recv_num;

　　uint8 queue_head;

　　uint8 queue_tail;

　　};

　　值得注意的是結構體data_entry中Payload項的組成在不同類型的幀中是不同的，比如數據幀中Payload包括頁號p、幀號id和數據data以及數據長度data_len，而廣告幀中只包含p和id，因此解析方法要根據type值來區分。

　　幀結構DelugeData

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

表4.1 DelugeData中數據項含義的定義

　　3、緩沖區Flash_buf

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

　　3.3.3 可靠數據分發協議的軟件架構設計

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

　　第一階段：

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

　　第二階段：

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

　　四 系統測試

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

　　Led.bin實現簡單的跑馬燈;

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

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

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

　　當前在節點上已經運行了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多個字節。添加的著1000多個字節是占patch.bin的主要內容。可見發送patch.bin比較適合于修改部分變量或者函數的時候。如果是單純的增加功能，比較適合于發送完整的鏡像文件。

　　五 總結

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

　　系統在Linux環境下進行了開發和應用，沒有開發Windows版本。項目組準備在下一階段把系統移植到Windows平臺上。

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