一 總體設計和平臺簡介

項目旨在實現多ARM節點通過無線通信完成對批量節點的程序燒錄，如圖2.1所示。系統分為上位機、發射接收模塊和待燒錄節點三個部分，上位機通過ID號選擇待燒錄節點并通過無線模塊向下廣播燒錄數據，各被選擇節點通過無線模塊接收燒錄數據檢查無誤后存儲。上位機軟件設定待燒錄節點的ID、燒錄文件目錄、發送數據包大小、發送速率等參數后將數據打包傳送到基站，基站通過無線發射模塊廣播數據。

圖2.1 多節點無線批量燒錄示意

整體思想是利用已有的代碼和目標代碼進行比較。將兩者的差異通過無線網絡(802.15.4)廣播出去。在每個接受節點根據收到的差異文件(也就是補丁文件patch)，對原有代碼進行修改(patching的過程)以達到更新程序的目的。

總體上來說本項目有兩大難點，涉及到巧妙的算法設計。

1、如何用盡可能少的字節數，來表示不同代碼之間的差異？

2、如何確保可靠性傳輸？

關于問題1，我們知道要待傳輸的字節數越少，對通信的要求越低。更新程序的效率也會更高。而且少的字節數也意味著丟更少的包。關于問題2，由于我們是要對代碼進行修正，所以一個字節的錯誤可能就會造成整個程序的崩潰。這對嵌入式程序，特別是運行在成千上萬個節點上的程序是不可接受的，必須保證100%的正確接受。除此兩大難點（也是關鍵點）之外，還有一些別的附加要求。如果滿足了能夠提高系統的持久性。分別是：

1、使用盡可能小的RAM。因為嵌入式芯片的RAM普遍珍貴。

2、消耗盡可能少的能量。

3、更新速度盡可能的快。

項目使用的硬件平臺是我們自制的智能小車eMouse 。平臺采用 TI公司32位Stellaris ?LM3S1968微處理器，工作頻率為50MHz，內含256 KB單周期Flash和64 KB單周期SRAM，flash支持可由用戶管理的塊保護和數據編程；板上Zigbee模塊通過串口與CPU通信，模塊僅提供MAC層服務，CPU與模塊間以MAC幀的形式通過串口傳遞數據。eMouse外觀如圖2.2所示。

圖2.2 硬件平臺eMouse

項目開發系統環境為Ubuntu9.04，程序編譯和下載工具分別為開源的sourcery G++和Openocd，用戶界面采用java語言編寫。

以下章節將對系統設計作詳盡的論述。

二 程序更新設計與實現

一些傳統的更新方法注重代碼本身的特點。比如以函數為基本的更新單位。在每個節點上運行一個動態鏈接器，將新的函數重新鏈接到原程序。其實代碼本身可以將其視為一串二進制的文本文件。代碼的更新即是從一串舊的文本更新為一串新的文本。

為此我們定義了一系列基本的更新操作命令，以及兩個輔助的索引指針：in_index以及out_index。in_index代表輸入文件當前的索引值，而out_index代表輸出文件當前的索引值。

基本的命令如下：

Copy:將in_index所指的字節復制到out_index處，并且in_index和out_index分別加1。

Replace A:將當前out_index所指的字節用A來替換，并且in_index和out_index分別加1。

Delete:in_index加1,out_index不變。實際為刪除in_index所指的字節

Insert A:在當前out_index處插入A，in_index不變,out_index加1。

Kill:表示刪除in_index后所有的原程序代碼。

其中包含了如下的子問題：

2.1 命令的表示

通過上面所說的基本命令的組合，我們可以表示出從一個舊文件到一個新文件的過程。隨之帶來了一個問題。這些命令應該如何表示才能盡可能的降低補丁文件(命令的組合)的大??？

有幾個需要注意的地方：

如果有連續的Copy命令，我們可以將其合并成一條命令，只要在Copy后加上表示長度的Length參數即可。

同理，如果有連續的Delete命令，也可以將其合并成一條命令，只要在Delete后加上表示長度的Length參數即可。

如果可以利用Replace命令，就不要用Delete和Insert命令的組合。這其實是另一重要的子問題:如何根據這些命令產生盡可能少補丁文件？

有五條基本命令，這樣為了區別這五條命令，至少需要3個比特。

由于大多數情況下，更新的大多數是程序的參數。也就是說Copy命令的數目遠遠大于其他命令。我們定義這5條命令如下表所示：