一 總體設計和平臺簡介
　　項目旨在實現多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個比特。