嵌入式多節(jié)點的無線批量程序更新系統(tǒng)設(shè)計
一 總體設(shè)計和平臺簡介
項目旨在實現(xiàn)多ARM節(jié)點通過無線通信完成對批量節(jié)點的程序燒錄,如圖2.1所示。系統(tǒng)分為上位機(jī)、發(fā)射接收模塊和待燒錄節(jié)點三個部分,上位機(jī)通過ID號選擇待燒錄節(jié)點并通過無線模塊向下廣播燒錄數(shù)據(jù),各被選擇節(jié)點通過無線模塊接收燒錄數(shù)據(jù)檢查無誤后存儲。上位機(jī)軟件設(shè)定待燒錄節(jié)點的ID、燒錄文件目錄、發(fā)送數(shù)據(jù)包大小、發(fā)送速率等參數(shù)后將數(shù)據(jù)打包傳送到基站,基站通過無線發(fā)射模塊廣播數(shù)據(jù)。
圖2.1 多節(jié)點無線批量燒錄示意
整體思想是利用已有的代碼和目標(biāo)代碼進(jìn)行比較。將兩者的差異通過無線網(wǎng)絡(luò)(802.15.4)廣播出去。在每個接受節(jié)點根據(jù)收到的差異文件(也就是補(bǔ)丁文件patch),對原有代碼進(jìn)行修改(patching的過程)以達(dá)到更新程序的目的。
總體上來說本項目有兩大難點,涉及到巧妙的算法設(shè)計。
1、如何用盡可能少的字節(jié)數(shù),來表示不同代碼之間的差異?
2、如何確??煽啃詡鬏??
關(guān)于問題1,我們知道要待傳輸?shù)淖止?jié)數(shù)越少,對通信的要求越低。更新程序的效率也會更高。而且少的字節(jié)數(shù)也意味著丟更少的包。關(guān)于問題2,由于我們是要對代碼進(jìn)行修正,所以一個字節(jié)的錯誤可能就會造成整個程序的崩潰。這對嵌入式程序,特別是運(yùn)行在成千上萬個節(jié)點上的程序是不可接受的,必須保證100%的正確接受。除此兩大難點(也是關(guān)鍵點)之外,還有一些別的附加要求。如果滿足了能夠提高系統(tǒng)的持久性。分別是:
1、使用盡可能小的RAM。因為嵌入式芯片的RAM普遍珍貴。
2、消耗盡可能少的能量。
3、更新速度盡可能的快。
項目使用的硬件平臺是我們自制的智能小車eMouse 。平臺采用 TI公司32位Stellaris LM3S1968微處理器,工作頻率為50MHz,內(nèi)含256 KB單周期Flash和64 KB單周期SRAM,flash支持可由用戶管理的塊保護(hù)和數(shù)據(jù)編程;板上Zigbee模塊通過串口與CPU通信,模塊僅提供MAC層服務(wù),CPU與模塊間以MAC幀的形式通過串口傳遞數(shù)據(jù)。eMouse外觀如圖2.2所示。
圖2.2 硬件平臺eMouse
項目開發(fā)系統(tǒng)環(huán)境為Ubuntu9.04,程序編譯和下載工具分別為開源的sourcery G++和Openocd,用戶界面采用java語言編寫。
以下章節(jié)將對系統(tǒng)設(shè)計作詳盡的論述。
二 程序更新設(shè)計與實現(xiàn)
一些傳統(tǒng)的更新方法注重代碼本身的特點。比如以函數(shù)為基本的更新單位。在每個節(jié)點上運(yùn)行一個動態(tài)鏈接器,將新的函數(shù)重新鏈接到原程序。其實代碼本身可以將其視為一串二進(jìn)制的文本文件。代碼的更新即是從一串舊的文本更新為一串新的文本。
為此我們定義了一系列基本的更新操作命令,以及兩個輔助的索引指針:in_index以及out_index。in_index代表輸入文件當(dāng)前的索引值,而out_index代表輸出文件當(dāng)前的索引值。
基本的命令如下:
Copy:將in_index所指的字節(jié)復(fù)制到out_index處,并且in_index和out_index分別加1。
Replace A:將當(dāng)前out_index所指的字節(jié)用A來替換,并且in_index和out_index分別加1。
Delete:in_index加1,out_index不變。實際為刪除in_index所指的字節(jié)
Insert A:在當(dāng)前out_index處插入A,in_index不變,out_index加1。
Kill:表示刪除in_index后所有的原程序代碼。
其中包含了如下的子問題:
2.1 命令的表示
通過上面所說的基本命令的組合,我們可以表示出從一個舊文件到一個新文件的過程。隨之帶來了一個問題。這些命令應(yīng)該如何表示才能盡可能的降低補(bǔ)丁文件(命令的組合)的大???
有幾個需要注意的地方:
如果有連續(xù)的Copy命令,我們可以將其合并成一條命令,只要在Copy后加上表示長度的Length參數(shù)即可。
同理,如果有連續(xù)的Delete命令,也可以將其合并成一條命令,只要在Delete后加上表示長度的Length參數(shù)即可。
如果可以利用Replace命令,就不要用Delete和Insert命令的組合。這其實是另一重要的子問題:如何根據(jù)這些命令產(chǎn)生盡可能少補(bǔ)丁文件?
有五條基本命令,這樣為了區(qū)別這五條命令,至少需要3個比特。
由于大多數(shù)情況下,更新的大多數(shù)是程序的參數(shù)。也就是說Copy命令的數(shù)目遠(yuǎn)遠(yuǎn)大于其他命令。我們定義這5條命令如下表所示:
表3.1
命令 | 操作碼(最左端開始) | 操作數(shù)的長度(緊跟操作碼) | 總長度(字節(jié)) |
Copy | 1 | 15 | 2 |
Delete | 000 | 13 | 2 |
Replace | 001XXXXX | 8 | 2 |
Insert | 010XXXXX | 8 | 2 |
Kill | 011XXXXX | 8 | 2 |
經(jīng)過大量實驗,我們發(fā)現(xiàn)連續(xù)出現(xiàn)Copy的情況最多,因此Copy命令操作碼只有1位,即只要是最左端比特為1,則此命令為Copy命令。這樣Copy的操作數(shù)為15個比特,一次能表示復(fù)制32768個字節(jié)。同理,Delete的格式同Copy時相同的,只不過其操作碼較長,操作數(shù)只有13位,最多能代表刪除8192個字節(jié)。實際上這也完全夠用了。
Replace和Insert操作碼的有效位為最左端三位,緊跟著5個比特是保留位,當(dāng)前還沒有用到。操作數(shù)的長度為一個字節(jié),表示當(dāng)前要替換的或者要插入的新值。
Kill命令操作碼為左端3個比特,剩下的15個比特都是保留位。操作數(shù)的長度為一個字節(jié),表示刪除的起始索引。
綜上可以看出,指令的格式都是定長的——2個字節(jié)。定長的代價是會浪費一定的比特。造成實際生成的補(bǔ)丁文件略大(由于Insert,Replace和Kill的保留位)。但正如MIPS處理器,定長的規(guī)定使得整個指令集簡潔有序。雖然產(chǎn)生的指令條數(shù)要比X86系列的CISC機(jī)要多,但簡潔的特性總是讓人喜歡的。
2.2 命令的產(chǎn)生
這是最有挑戰(zhàn)性的問題,如何根據(jù)前面定義的基本命令,產(chǎn)生盡可能小的操作指令集(補(bǔ)丁文件)?仔細(xì)觀察發(fā)現(xiàn),其實此問題包含了一個最優(yōu)子結(jié)構(gòu),也就是說,我們可以用動態(tài)規(guī)劃的算法來解決這個問題,保證產(chǎn)生的補(bǔ)丁文件是最小的。
假設(shè)原程序的長度為m個字節(jié),目標(biāo)程序的長度為n個字節(jié)。定義= x[1..i],Yj = y[1..j],其中x[1..i]表示源程序的第一個到第i個字節(jié),y[1..j]表示目標(biāo)程序的第一個到第j字節(jié)。用c[i,j]表示從Xi 到Y(jié)j所用的最小的代價。由于所有的命令長度均相同,故每條命令代價都為1,c[i,j]也就是代表從Xi 到Y(jié)j 所需的最小的命令數(shù),求得最小的命令數(shù),別且記錄下其操作,我們就能得到最小的補(bǔ)丁文件。這樣我們有以下幾種情況:
如果最后的操作為Copy,則一定有x[i] = y[j]。原問題包含將Xi-1 轉(zhuǎn)化到Y(jié)j-1的子問題。c[i,j] = c[i-1,j-1]+1
如果最后的操作為Replace,則一定有x[i] != y[j]。原問題包含將Xi-1 轉(zhuǎn)化到Y(jié)j-1的子問題。c[i,j] = c[i-1,j-1]+1
如果最后的操作為 Delete,則沒有什么必須滿足的條件。原問題包含將Xi-1 轉(zhuǎn)化到Y(jié)j的子問題。c[i,j] = c[i-1,j]+1
如果最后的操作為 Insert,也沒有什么必須滿足的條件。原問題包含將Xi 轉(zhuǎn)化到Y(jié)j-1的子問題。c[i,j] = c[i,j-1]+1
如果最后的操作為Kill。由于Kill表示刪除源程序所有剩余的字節(jié)。Kill只能出現(xiàn)在最后一個操作上。即完成Kill后就已經(jīng)使得Xm 轉(zhuǎn)化為了Yn。
c[m,n] = min(c[i,n]) + 1, 0= i= m
這樣所有的情況都已經(jīng)包含在內(nèi)。對于每一個i,j我們可以求得最c[i,j]
公式從上到下依次代表了Copy,Replace,Delete,Insert和Kill這五種情況。
整體的偽代碼如代碼3.1所示:注意,我們不僅求得每一個c[i,j]而且記錄下了與其相應(yīng)的操作.op[i,j]這個數(shù)組中的每個元素為一個結(jié)構(gòu)體,包含操作數(shù)以及操作碼。
代碼3.1得到c[i,j]以及op[i,j]
這樣,我們得到了c[m,n]以及操作表。下面就是要求得操作序列。根據(jù)之前生成的操作表,采用一個遞歸的方法得出最小代價的操作序列。偽代碼如代碼3.2所示:
代碼3.2生成最小代價的操作序列
這樣,我們得到在定長命令下,最小的補(bǔ)丁文件。以上都是在PC機(jī)上進(jìn)行的。即界面中的生成補(bǔ)丁按鈕。
圖3.3 界面-生成補(bǔ)丁功能
2.3在LM3S1968上的實現(xiàn)
在PC機(jī)上的部分比較容易實現(xiàn)(生成patch文件)。但在LM3S1968這個嵌入式芯片上進(jìn)行代碼的替換就不是很簡單了。首先我們要確定各個文件的位置。這里為了簡單起見,將flash的0x0000到0x3000處,設(shè)為更新服務(wù)程序區(qū),初始化必要的硬件(通信、flash等),等待基站發(fā)送的命令來更新程序或者直接將控制轉(zhuǎn)移給應(yīng)用程序程序,本部分的程序在啟動后首先運(yùn)行。如果檢測0x4000處為合法的應(yīng)用程序,則將控制權(quán)轉(zhuǎn)交給它,每個應(yīng)用程序在接受到了“等待接受”命令后,又將控制權(quán)轉(zhuǎn)移給更新服務(wù)程序,等待從基站發(fā)來的其他命令。需要注意的是在將控制權(quán)轉(zhuǎn)移到應(yīng)用程序時,中斷向量表的位置,棧指針,是兩個要小心設(shè)置的量。否則會造成整個系統(tǒng)的崩潰。而且本部分只能用匯編語言寫,具體可以參見bl_start_gcc.S。0x3000到0x7000處為應(yīng)用程序區(qū),存放待運(yùn)行的程序。0x7000以后存放這從主機(jī)發(fā)來的Patch文件。
整體的流程為:
圖3.4更新流程圖
三 可靠數(shù)據(jù)分發(fā)協(xié)議的設(shè)計與實現(xiàn)
3.1 Deluge協(xié)議簡介
Deluge協(xié)議是一個優(yōu)秀的可靠性數(shù)據(jù)分發(fā)協(xié)議,由加利福尼亞大學(xué)伯克利分校的David Culler等人在2004年提出的,首先在TinyOS1.1.8操作系統(tǒng)上實現(xiàn)。協(xié)議的設(shè)計初衷是用來進(jìn)行較大規(guī)模的數(shù)據(jù)分發(fā),比如大塊數(shù)據(jù)傳輸和遠(yuǎn)程系統(tǒng)升級等。
在Deluge協(xié)議中,采用了協(xié)商式交互策略(ADV-REQ-DATA)來實現(xiàn)受控泛洪。而整個網(wǎng)絡(luò)由狀態(tài)機(jī)來控制數(shù)據(jù)的分發(fā),網(wǎng)絡(luò)中每個節(jié)點都處在MAINTAIN、RX和TX三種狀態(tài)的其中一種,并且遵循該種狀態(tài)下的一系列動作規(guī)則。在Deluge協(xié)議中,把將要分發(fā)的目標(biāo)文件(Sobj)劃分為固定大小的程序包(Spkt),由N個程序包(Spkt)組成一個程序頁(Spage)。Deluge協(xié)議對整個目標(biāo)文件數(shù)據(jù)的劃分如圖4.1所示?;谶@種數(shù)據(jù)結(jié)構(gòu),Deluge協(xié)議支持空間多路技術(shù)以提高數(shù)據(jù)傳輸?shù)乃俣?,在協(xié)議中的具體實現(xiàn)是流水線傳輸(Pipelining)。
圖4.1 Deluge協(xié)議中分發(fā)數(shù)據(jù)的結(jié)構(gòu)
Deluge協(xié)議引入了復(fù)雜的控制信息,而目前很多無線傳感器網(wǎng)絡(luò)應(yīng)用中的節(jié)點都不能支持像TinyOS這樣的操作系統(tǒng),因此實現(xiàn)起來難度較高;同時,許多數(shù)據(jù)分發(fā)的應(yīng)用場景提供Deluge協(xié)議中的一些高級功能并不能明顯提升網(wǎng)絡(luò)性能,比如網(wǎng)絡(luò)節(jié)點較少則不需要流水線數(shù)據(jù)分發(fā),數(shù)據(jù)塊較少則不需要分頁機(jī)制等?;谝陨显颍驹O(shè)計在提出若干常見應(yīng)用場景假設(shè)的基礎(chǔ)上對Deluge協(xié)議做了簡化和補(bǔ)充。
3.2 可靠數(shù)據(jù)分發(fā)協(xié)議的設(shè)計
在闡述具體的設(shè)計思路之前,先提出以下應(yīng)用場景的假設(shè)。
假設(shè)一:網(wǎng)絡(luò)節(jié)點不支持高級的操作系統(tǒng)。可以理解為必須考慮節(jié)點處理和通信能力有限,而且通信協(xié)議要從底層(如MAC層)實現(xiàn)。
假設(shè)二:大部分待燒錄節(jié)點分布在數(shù)據(jù)基站的通訊范圍之內(nèi)??梢岳斫鉃橥ㄐ艆f(xié)議不需要實現(xiàn)復(fù)雜的多跳通信和流水線,可以充分利用數(shù)據(jù)基站第一次數(shù)據(jù)廣播,這一點下文會詳細(xì)闡述。
基于以上兩點假設(shè),可靠性數(shù)據(jù)分發(fā)協(xié)議的具體設(shè)計如下。
考慮到不同平臺的無線收發(fā)模塊提供的服務(wù)接口和通信質(zhì)量的差異以及程序更新對網(wǎng)絡(luò)可靠性的要求,通信協(xié)議選擇在網(wǎng)絡(luò)層實現(xiàn)可靠數(shù)據(jù)分發(fā)的機(jī)制,協(xié)議只需要硬件平臺在MAC層提供收發(fā)數(shù)據(jù)幀的應(yīng)用接口即可。協(xié)議中,數(shù)據(jù)分發(fā)分為兩個階段:第一輪發(fā)送階段和節(jié)點間交流階段。圖4.2為兩個階段通信方式示意圖。
圖4.2 數(shù)據(jù)分發(fā)兩階段通信方式示意圖
(實線代表發(fā)送完整數(shù)據(jù)文件,虛線表示發(fā)送數(shù)據(jù)頁)
1、第一輪發(fā)送階段。
數(shù)據(jù)基站(如PC)在接收節(jié)點準(zhǔn)備好后不間斷廣播數(shù)據(jù)幀,直至數(shù)據(jù)發(fā)送結(jié)束;接收節(jié)點盡力接收數(shù)據(jù),并記錄自己已有數(shù)據(jù)幀的id信息,期間不向源節(jié)點發(fā)送反饋信息。
在原始的Deluge協(xié)議中沒有這一階段,因為Deluge協(xié)議中可能無線傳感器網(wǎng)絡(luò)龐大,分布范圍也較廣,所以數(shù)據(jù)分發(fā)一旦啟動,所有接收到數(shù)據(jù)的節(jié)點都參與到數(shù)據(jù)發(fā)送中來;而本設(shè)計中,網(wǎng)絡(luò)充分利用了假設(shè)二中的節(jié)點分布條件,通常情況下,在第一輪發(fā)送結(jié)束后,相當(dāng)大比例的節(jié)點就已經(jīng)接收到了大部分的數(shù)據(jù),而這個過程中因為只有數(shù)據(jù)基站在發(fā)送廣播,網(wǎng)絡(luò)中數(shù)據(jù)傳輸?shù)男适亲罡叩?。?dāng)然,這種節(jié)點分布條件不滿足的情況也不會明顯降低數(shù)據(jù)分發(fā)效率。
節(jié)點間交流階段。
交流階段參考了trickle算法的“polite gossip”策略,所有節(jié)點(包括數(shù)據(jù)基站)都參與到交流中去。每個節(jié)點的交流的目的都是相同的,即將自己擁有的數(shù)據(jù)包發(fā)送給需要的節(jié)點和請求并接收自己需要的數(shù)據(jù)包。
第2階段是保證可靠性的關(guān)鍵,協(xié)議中讓源節(jié)點也參與到交流中來,這是為了防止網(wǎng)絡(luò)狀況極差以至在第一輪發(fā)送結(jié)束之后所有節(jié)點接收數(shù)據(jù)的總和都不構(gòu)成完整數(shù)據(jù)文件的極端情況。這一步中,節(jié)點長時間處于“維護(hù)”狀態(tài)標(biāo)志數(shù)據(jù)分發(fā)結(jié)束。
節(jié)點首先廣播廣告,每一個廣告包含一個摘要(φ),摘要(φ)由兩部分組成:(1)本節(jié)點的IP標(biāo)識v。(2)本節(jié)點的最大可用頁號p,即φ(v,p)。可用頁號p的定義:頁p所包含的包被節(jié)點全部接收,稱頁p完成。頁p被完成并且它之前的所有的頁(0,p)也被節(jié)點全部接收,稱頁p可用。節(jié)點通過廣告來了解對方擁有的數(shù)據(jù)信息,繼而向比自己數(shù)據(jù)更完備的節(jié)點發(fā)送數(shù)據(jù)頁請求。協(xié)議中將時間分成時間片(round),在每一個時間片中,節(jié)點來決定是否廣播一個廣告。假設(shè)時間片的長度由Tm,i來表示,它的上下界由Tl和Th來表示,則有取TlTm,iTh。在每一個時間片i中,節(jié)點維護(hù)—個隨機(jī)值ri,ri的值在Tm,i/2和Tm,i之間,ri值的范圍選取是為了解決短監(jiān)聽問題(short—listen problem)。
交流階段中,節(jié)點擁有“維護(hù)”、“請求”和“發(fā)送”中的人一個狀態(tài)。節(jié)點在“維護(hù)”狀態(tài)廣播廣告并聽取其他節(jié)點的廣播;在請求階段向其他節(jié)點發(fā)送數(shù)據(jù)頁請求,并接收對方發(fā)來的數(shù)據(jù);在發(fā)送狀態(tài)廣播被請求的數(shù)據(jù)頁。圖4.3為狀態(tài)轉(zhuǎn)換示意圖。主要的交流規(guī)則如下。
(1)“維護(hù)”狀態(tài)規(guī)則
M1: 假設(shè)時間片i的開始時間為ti,節(jié)點在ti+ri的時間段內(nèi),若接收不到廣告φ=φ,則廣播廣告φ;若收到與φ不一致的廣告(包括φ=φ、廣告幀和數(shù)據(jù)幀等),則調(diào)整時間片為Tl,并立即重新開始時間片;若接收到廣告φ=φ,則調(diào)整時間片為min(2*Tm,i ,Th )。
M2: 節(jié)點在收到廣告φ(v,p)中p大于自身的最大可用頁p時,轉(zhuǎn)向“請求”狀態(tài),向節(jié)點v發(fā)送數(shù)據(jù)頁請求;節(jié)點收到請求幀,則轉(zhuǎn)向“發(fā)送”狀態(tài),廣播被請求數(shù)據(jù)頁。
規(guī)則1能控制冗余廣告的發(fā)送,節(jié)約網(wǎng)絡(luò)資源,并且根據(jù)網(wǎng)絡(luò)狀況動態(tài)調(diào)整時間片長度,從而是網(wǎng)絡(luò)資源得到有效的利用。
規(guī)則2實現(xiàn)從“維護(hù)”狀態(tài)到“請求”和“發(fā)送”狀態(tài)的轉(zhuǎn)換。
(2)“請求”狀態(tài)規(guī)則:
M3:若節(jié)點在向源節(jié)點發(fā)出數(shù)據(jù)頁請求后節(jié)點在時間t(t為自定義時間長度,是經(jīng)驗值,根據(jù)網(wǎng)絡(luò)狀況而定)內(nèi)沒有收到數(shù)據(jù),則再次發(fā)送請求,若累計請求次數(shù)大于k(k為自定義次數(shù)),則認(rèn)為請求失敗,返回“維護(hù)”狀態(tài);若節(jié)點接收到數(shù)據(jù)頁,則在接收結(jié)束后返回“維護(hù)”狀態(tài)。
規(guī)則3中考慮到網(wǎng)絡(luò)的質(zhì)量因素,定義了等待時間t和最大請求次數(shù)k。
(3)“發(fā)送”狀態(tài)規(guī)則:
M4:節(jié)點進(jìn)入“發(fā)送”狀態(tài)立即廣播被請求的數(shù)據(jù)頁,廣播結(jié)束后返回“維護(hù)”狀態(tài)。
規(guī)則4中要注意的是,節(jié)點以廣播的方式發(fā)送數(shù)據(jù),這意味著處于“請求”狀態(tài)的節(jié)點可以接收任何節(jié)點(不一定是它請求的指定節(jié)點)發(fā)送的符合其需要的數(shù)據(jù)包,這也是協(xié)議中避免網(wǎng)絡(luò)冗余的一個體現(xiàn)。
圖4.3 可靠數(shù)據(jù)分發(fā)交流階段節(jié)點狀態(tài)轉(zhuǎn)換示意圖
以上是本設(shè)計中可靠數(shù)據(jù)分發(fā)協(xié)議的全部內(nèi)容,本文在下一節(jié)中將詳細(xì)論述協(xié)議的軟件設(shè)計實現(xiàn)。
3.3 可靠數(shù)據(jù)分發(fā)協(xié)議的軟件設(shè)計實現(xiàn)
協(xié)議的軟件設(shè)計在網(wǎng)絡(luò)層實現(xiàn),涉及到MAC層接口的調(diào)用。本節(jié)先簡單介紹本設(shè)計實驗平臺上網(wǎng)絡(luò)模塊提供的MAC層應(yīng)用接口,然后詳細(xì)論述軟件的設(shè)計和實現(xiàn)。
3.3.1 MAC層接口簡介
首先做兩點說明。
第一,設(shè)計中使用的MAC層接口不提供絕對可靠的網(wǎng)絡(luò)通信。一方面是因為設(shè)計使用實驗室自制的硬件平臺主要用于做群體實驗,而群體實驗不需要可靠的網(wǎng)絡(luò)通信,所以平臺的通信模塊也沒有能實現(xiàn)可靠通信的機(jī)制;另一方面要求MAC層提供可靠通信也不是必要的。
第二,網(wǎng)絡(luò)層只使用了MAC層提供的數(shù)據(jù)幀發(fā)送和數(shù)據(jù)幀接收兩個接口,網(wǎng)絡(luò)層的幀結(jié)構(gòu)包含在MAC數(shù)據(jù)幀的數(shù)據(jù)域中。
從第一點可以看到,協(xié)議在網(wǎng)絡(luò)層實現(xiàn)可靠數(shù)據(jù)傳輸?shù)臋C(jī)制,降低了對MAC層通信質(zhì)量的要求,而第二點說明協(xié)議僅僅需要MAC層提供兩個最基本的應(yīng)用接口。本設(shè)計中的可靠數(shù)據(jù)分發(fā)協(xié)議對底層通信的要求很低,具有較好的魯棒性和可移植性。
本設(shè)計實驗平臺上提供的MAC層數(shù)據(jù)幀發(fā)送命令結(jié)構(gòu)如圖4.4所示,其中區(qū)域3為數(shù)據(jù)域,包含網(wǎng)絡(luò)層的幀結(jié)構(gòu),另外節(jié)點在MAC層以廣播的方式通信,所以命令中不包含源節(jié)點和目的節(jié)點的地址信息。MAC層接收到數(shù)據(jù)幀后,將數(shù)據(jù)域分離出來存儲到接收緩存區(qū);發(fā)送數(shù)據(jù)時,將發(fā)送緩存區(qū)中的數(shù)據(jù)加上MAC層數(shù)據(jù)幀的頭部和尾部并發(fā)送出去,網(wǎng)絡(luò)層只關(guān)心發(fā)送和接收緩沖區(qū)中的數(shù)據(jù)。這里規(guī)定以下章節(jié)中提到的各種幀結(jié)構(gòu)均指網(wǎng)絡(luò)層幀結(jié)構(gòu)。
圖4.4 MAC層接口數(shù)據(jù)幀發(fā)送命令
3.3.2 可靠數(shù)據(jù)分發(fā)協(xié)議的數(shù)據(jù)結(jié)構(gòu)設(shè)計
網(wǎng)絡(luò)層數(shù)據(jù)要經(jīng)過緩存,解析再到存儲或者執(zhí)行三步操作,并且不同種類的幀要區(qū)別處理,因此一個好的數(shù)據(jù)結(jié)構(gòu)設(shè)計方案對簡化數(shù)據(jù)處理操作和提高數(shù)據(jù)處理效率是非常有必要的。圖4.5為網(wǎng)絡(luò)層數(shù)據(jù)流圖,數(shù)據(jù)幀的流向為:
從MAC層讀入后放入原始數(shù)據(jù)緩沖區(qū);
經(jīng)解析后得到幀結(jié)構(gòu);
將幀結(jié)構(gòu)作相關(guān)處理后僅提取頁號(p)、幀號(id)和數(shù)據(jù)(data)放到寫flash緩沖區(qū);
寫flash。
注意以上是數(shù)據(jù)幀的流向,除數(shù)據(jù)幀以外的其他類型幀(如請求幀,結(jié)束幀等)只執(zhí)行第(1)、(2)步操作。下面著重論述圖中每個階段涉及到的數(shù)據(jù)結(jié)構(gòu)。
圖4.5 網(wǎng)絡(luò)層數(shù)據(jù)流圖
緩沖區(qū)Deluge_buf
Deluge_buf是一個環(huán)形緩沖區(qū),用于緩存原始的網(wǎng)絡(luò)層數(shù)據(jù)。緩沖區(qū)實際上是由一個環(huán)形鏈表、兩個指針和一個整數(shù)組成。鏈表的每個節(jié)點用于存儲實際數(shù)據(jù),節(jié)點數(shù)目根據(jù)需要而定;一個tail指針和一個head指針,分別指鏈表的讀出點和寫入點,執(zhí)行一次讀出或?qū)懭氩僮骱螅瑃ail或head指針都向前移動一次,整數(shù)的作用是統(tǒng)計當(dā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ù)項,設(shè)計中根據(jù)不同的幀類型規(guī)定了各個數(shù)據(jù)項的含義,具體定義如表4.1所示,“—”表示該數(shù)據(jù)項在幀中沒有定義。
表4.1 DelugeData中數(shù)據(jù)項含義的定義
數(shù)據(jù)項 幀類型 | type | v | p | id | data | data_len |
數(shù)據(jù)幀 | DATA | 版本號 | 頁號 | 幀號 | 數(shù)據(jù) | 數(shù)據(jù)長度 |
結(jié)束幀 | END | 版本號 | 頁號 | 幀號 | — | — |
廣告幀 | ADV | 版本號 | 頁號 | 源節(jié)點標(biāo)識 | — | — |
請求幀 | REQ | 版本號 | 頁號 | 目標(biāo)節(jié)點標(biāo)識 | — | — |
命令幀 | CMD | 命令參數(shù) | — | — | — | — |
3、緩沖區(qū)Flash_buf
因為寫flash操作比網(wǎng)絡(luò)傳輸慢得多,為了避免寫flash拖慢整個數(shù)據(jù)分發(fā)速度,建立緩沖區(qū)Flash_buf用于緩存準(zhǔn)備好的數(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è)計
可靠數(shù)據(jù)分發(fā)協(xié)議的軟件構(gòu)架設(shè)計包括發(fā)送端和接收端兩塊內(nèi)容。發(fā)送端軟件運(yùn)行在數(shù)據(jù)基站上,分為兩個階段,第一階段通知節(jié)點連續(xù)地發(fā)送整個文件,第二階段運(yùn)行狀態(tài)機(jī)參與到節(jié)點的交流中去;接收端軟件運(yùn)行在待燒錄節(jié)點上,第一個階段盡可能多的接收基站發(fā)送來的數(shù)據(jù),第二階參與節(jié)點間討論。因為發(fā)送端第一階段軟件比較簡單,第二階段和接收端相同,所以這里只重點介紹接收端的軟件構(gòu)架設(shè)計。
第一階段:
程序完成初始化后進(jìn)入準(zhǔn)備接收狀態(tài),當(dāng)數(shù)據(jù)幀到來時將數(shù)據(jù)提取出來寫到flash相應(yīng)的地址(地址由頁號p和幀號id計算得到),并將該幀標(biāo)記為“完成幀”;若接收到結(jié)束幀,則記錄結(jié)束幀的頁號pmax和幀號idmax并進(jìn)入第二階段;若接收到其他類型幀則直接進(jìn)入第二階段。第一階段的軟件流程圖如圖4.6所示。
圖4.6 接收端軟件第一階段流程圖
第二階段:
完成第一輪接收后,程序運(yùn)行ADV-REQ-DATA狀態(tài)機(jī),和其他節(jié)點交流,完善或幫助其他節(jié)點完善數(shù)據(jù)文件。狀態(tài)機(jī)分為MAINTAIN(維護(hù))、RX(請求)和TX(發(fā)送)三個狀態(tài),程序首先進(jìn)入MAINTAIN狀態(tài)。MAINTAIN狀態(tài)下,程序監(jiān)聽廣告幀和請求幀并在適當(dāng)時機(jī)發(fā)送廣告,根據(jù)協(xié)議規(guī)定,程序可能跳轉(zhuǎn)到RX狀態(tài)或TX狀態(tài)進(jìn)行數(shù)據(jù)幀請求和發(fā)送操作,操作完成后返回MAINTAIN狀態(tài)。程序中定義一個最長時間tmax,如果MAINTAIN狀態(tài)持續(xù)時間超過tmax,則認(rèn)為整個數(shù)據(jù)分發(fā)過程結(jié)束,程序檢查自己接收到的數(shù)據(jù)是否完備后退出。第二階段的軟件流程圖如圖4.7所示。
圖4.7 接收端軟件第二階段流程圖
四 系統(tǒng)測試
本測試將用三個程序作為用例,以測試系統(tǒng)的可用性。三個程序分別為:
Led.bin實現(xiàn)簡單的跑馬燈;
GoAhead.bin 三輛小車將一直向前方走,即使碰到障礙物也不停止;
RandomWalk.bin 三輛小車將進(jìn)行隨機(jī)行走,并且碰到障礙物后會進(jìn)行壁障,轉(zhuǎn)彎。
首先我們將批量更新跑馬燈的程序,然后我們來看GoAhead.bin,如圖5.1所示。完整的程序鏡像大小為3340Bytes
圖5.1 GoAhead.bin的大小
當(dāng)前在節(jié)點上已經(jīng)運(yùn)行了Led.bin,我們將使用Led.bin和GoAhead.bin進(jìn)行比較,生成patch.bin文件,即補(bǔ)丁文件。
圖5.2生成的patch.bin文件
我們看到,生成的patch.bin文件僅僅是原程序GoAhead.bin的1/3大??!圖5.3是patch.bin代表的命令(截取一部分)。
圖5.3 patch.bin代表的命令
下面從GoAhead.bin 生成 RandomWalk.bin,RandomWalk.bin的大小如圖5.4所示:
圖5.4 Randomalk.bin
圖5.5從生成的patch.bin文件的大小可以看到,其為RandomWalk的大約1/3。但有個值得注意的地方是,RandomWalk.bin比GoAhead.bin大了1000多個字節(jié)。添加的著1000多個字節(jié)是占patch.bin的主要內(nèi)容。可見發(fā)送patch.bin比較適合于修改部分變量或者函數(shù)的時候。如果是單純的增加功能,比較適合于發(fā)送完整的鏡像文件。
圖5.5 patch.bin文件
五 總結(jié)
測試結(jié)果表明,本設(shè)計實現(xiàn)了可靠性無線批量嵌入式節(jié)點程序更新,燒錄出錯率低;更新效率高;不依賴操作系統(tǒng),具有很好的可移植性,項目總體上實現(xiàn)了設(shè)計的目標(biāo)。另一方面由于時間限制,系統(tǒng)仍然存在一些不足。以下是設(shè)計中幾點需要優(yōu)化的地方和相應(yīng)的改進(jìn)意見。
系統(tǒng)在Linux環(huán)境下進(jìn)行了開發(fā)和應(yīng)用,沒有開發(fā)Windows版本。項目組準(zhǔn)備在下一階段把系統(tǒng)移植到Windows平臺上。
尚未實現(xiàn)程序的動態(tài)更新,即每次更新前都要將正在運(yùn)行的程序關(guān)掉,強(qiáng)制節(jié)點進(jìn)入準(zhǔn)備狀態(tài)。可以分配一個專用線程用于程序更新,同時為了避免更新對正在運(yùn)行的程序造成影響,需要在更新過程中引入動態(tài)鏈接技術(shù)
評論