嵌入式多節點(diǎn)的無(wú)線(xiàn)批量程序更新系統設計(二)

　　緩沖區Deluge_buf

　　Deluge_buf是一個(gè)環(huán)形緩沖區，用于緩存原始的網(wǎng)絡(luò )層數據。緩沖區實(shí)際上是由一個(gè)環(huán)形鏈表、兩個(gè)指針和一個(gè)整數組成。鏈表的每個(gè)節點(diǎn)用于存儲實(shí)際數據，節點(diǎn)數目根據需要而定;一個(gè)tail指針和一個(gè)head指針，分別指鏈表的讀出點(diǎn)和寫(xiě)入點(diǎn)，執行一次讀出或寫(xiě)入操作后，tail或head指針都向前移動(dòng)一次，整數的作用是統計當前鏈表上可用節點(diǎn)的數目。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項的組成在不同類(lèi)型的幀中是不同的，比如數據幀中Payload包括頁(yè)號p、幀號id和數據data以及數據長(cháng)度data_len，而廣告幀中只包含p和id，因此解析方法要根據type值來(lái)區分。

　　幀結構DelugeData

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

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

　　3、緩沖區Flash_buf

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

　　3.3.3 可靠數據分發(fā)協(xié)議的軟件架構設計

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

　　第一階段：

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

　　第二階段：

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

　　四 系統測試

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

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

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

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

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

　　當前在節點(diǎn)上已經(jīng)運行了Led.bin,我們將使用Led.bin和GoAhead.bin進(jìn)行比較，生成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。但有個(gè)值得注意的地方是，RandomWalk.bin比GoAhead.bin大了1000多個(gè)字節。添加的著(zhù)1000多個(gè)字節是占patch.bin的主要內容?？梢?jiàn)發(fā)送patch.bin比較適合于修改部分變量或者函數的時(shí)候。如果是單純的增加功能，比較適合于發(fā)送完整的鏡像文件。

　　五 總結

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

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

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