許多嵌入式系統(tǒng)部署在操作人員難以或無法接近的地方。物聯(lián)網(wǎng)（IoT）應(yīng)用尤其如此，這些應(yīng)用通常大量部署并且電池壽命有限。實例包括監(jiān)控人員或機(jī)器健康狀況的嵌入式系統(tǒng)。這些挑戰(zhàn)加上快速迭代的軟件生命周期，導(dǎo)致許多系統(tǒng)需要支持無線（OTA）更新。OTA更新用新軟件替換嵌入式系統(tǒng)的微控制器或微處理器上的軟件。雖然很多人非常熟悉移動設(shè)備上的OTA更新，但在資源受限的系統(tǒng)上設(shè)計和實施會帶來許多不同的挑戰(zhàn)。本文將介紹針對OTA更新的若干不同軟件設(shè)計，并討論其優(yōu)缺點。我們將了解OTA更新軟件如何利用兩款超低功耗微控制器的硬件特性。

構(gòu)建模塊

服務(wù)器和客戶端

OTA更新用新軟件替換器件上的當(dāng)前軟件，新軟件以無線方式下載。在嵌入式系統(tǒng)中，運(yùn)行此軟件的器件通常是微控制器。微控制器是一種小型計算器件，其存儲器、速度和功耗均很有限。微控制器通常包含微處理器（核心）和用于執(zhí)行特定操作的數(shù)字硬件模塊（外設(shè)）。工作模式下典型功耗為30μA/MHz至40μA/MHz的超低功耗微控制器是此類應(yīng)用的理想選擇。使用這些微控制器上的特定硬件外設(shè)并將其置于低功耗模式，是OTA更新軟件設(shè)計的重要組成部分。圖1顯示了一個可能需要OTA更新的嵌入式系統(tǒng)實例。可以看到，一個微控制器與無線電和傳感器相連，這可用在物聯(lián)網(wǎng)應(yīng)用中，利用傳感器收集有關(guān)環(huán)境的數(shù)據(jù)，并利用無線電定期報告數(shù)據(jù)。系統(tǒng)的這一部分稱為邊緣節(jié)點或客戶端，是OTA更新的目標(biāo)。系統(tǒng)的另一部分稱為云或服務(wù)器，是新軟件的提供者。服務(wù)器和客戶端利用收發(fā)器（無線電）通過無線連接進(jìn)行通信。

何為軟件應(yīng)用程序？

OTA更新過程的大部分操作是將新軟件從服務(wù)器傳輸?shù)娇蛻舳?。軟件從源格式轉(zhuǎn)換為二進(jìn)制格式之后，作為一個字節(jié)序列進(jìn)行傳輸。轉(zhuǎn)換過程會編譯源代碼文件（例如c、cpp），將其鏈接成一個可執(zhí)行文件（例如exe、elf），然后將可執(zhí)行文件轉(zhuǎn)換為可移植的二進(jìn)制文件格式（例如bin、hex）。概言之，這些文件格式包含一個字節(jié)序列，此字節(jié)序列屬于微控制器中存儲器的特定地址。通常，我們將通過無線鏈路發(fā)送的信息概念化為數(shù)據(jù)，例如更改系統(tǒng)狀態(tài)的命令或系統(tǒng)收集的傳感器數(shù)據(jù)。就OTA更新而言，數(shù)據(jù)就是二進(jìn)制格式的新軟件。在很多情況下，二進(jìn)制文件非常大，無法通過單次傳輸從服務(wù)器發(fā)送到客戶端，這意味著需要將二進(jìn)制文件放入多個不同的數(shù)據(jù)包中，此過程稱為“分包”。為了更好地說明此過程，圖2演示了軟件的不同版本如何生成不同的二進(jìn)制文件，從而在OTA更新期間發(fā)送不同的數(shù)據(jù)包。在這個簡單例子中，每個數(shù)據(jù)包包含8字節(jié)數(shù)據(jù)，前4個字節(jié)表示客戶端存儲器中用來存儲后4個字節(jié)的地址。

主要挑戰(zhàn)

基于對OTA更新過程的這種高層次描述，OTA更新解決方案必須應(yīng)對三大挑戰(zhàn)。第一個挑戰(zhàn)與存儲器有關(guān)。軟件解決方案必須將新軟件應(yīng)用程序組織到客戶端器件的易失性或非易失性存儲器中，以便在更新過程完成時可以執(zhí)行它。解決方案必須確保將前一版本的軟件保留為后備應(yīng)用程序，以防新軟件出現(xiàn)問題。此外，當(dāng)復(fù)位和斷電重啟時，我們必須讓客戶端器件的狀態(tài)--例如當(dāng)前運(yùn)行的軟件版本以及它在存儲器中的位置--保持不變。第二大挑戰(zhàn)是通信。新軟件必須以離散數(shù)據(jù)包的形式從服務(wù)器發(fā)送到客戶端，每個數(shù)據(jù)包都要放在客戶端存儲器中的特定地址。分包方案、數(shù)據(jù)包結(jié)構(gòu)和數(shù)據(jù)傳輸協(xié)議必須在軟件設(shè)計中考慮周全。最后一個主要挑戰(zhàn)是安全性。當(dāng)新軟件以無線方式從服務(wù)器發(fā)送到客戶端時，我們必須確保服務(wù)器是可信任方。這種安全挑戰(zhàn)稱為身份驗證。我們還必須對新軟件進(jìn)行模糊處理以防觀察者偷窺，因為其中可能包含敏感信息。這種安全挑戰(zhàn)稱為保密。安全性的最后一個要素是完整性，即確保新軟件在通過無線方式發(fā)送時不會損壞。

第二階段引導(dǎo)加載程序（SSBL）

了解引導(dǎo)序列

主引導(dǎo)加載程序是一種軟件應(yīng)用程序，永久駐留在微控制器的只讀存儲器中。主引導(dǎo)加載程序所在的存儲區(qū)域稱為信息空間，有時用戶無法訪問。每次復(fù)位都會執(zhí)行該應(yīng)用程序，一般完成一些必要的硬件初始化，并且可能將用戶軟件加載到存儲器中。但是，如果微控制器包含片內(nèi)非易失性存儲器（如閃存），則引導(dǎo)加載程序不需要進(jìn)行任何加載，只需將控制權(quán)轉(zhuǎn)移到閃存中的程序即可。如果主引導(dǎo)加載程序不支持OTA更新，則必須有第二階段引導(dǎo)加載程序。與主引導(dǎo)加載程序一樣，SSBL會在每次復(fù)位時運(yùn)行，但將實施OTA更新過程的一部分。此引導(dǎo)序列如圖3所示。本節(jié)將說明為什么需要第二階段引導(dǎo)加載程序，并解釋如何指定此應(yīng)用程序的作用是一個重要設(shè)計權(quán)衡。

經(jīng)驗教訓(xùn)：務(wù)必有一個SSBL

從概念上講，省略SSBL并將所有OTA更新功能放入用戶應(yīng)用程序似乎更簡單，因為這樣的話，OTA過程可以無縫利用現(xiàn)有的軟件框架、操作系統(tǒng)和設(shè)備驅(qū)動程序。圖4顯示了一個選擇此方法的系統(tǒng)的存儲器映射和引導(dǎo)序列。

應(yīng)用程序A是部署在現(xiàn)場微控制器上的原始應(yīng)用程序。此應(yīng)用程序包含OTA更新相關(guān)軟件，當(dāng)服務(wù)器請求時，利用該軟件可下載應(yīng)用程序B。下載完成且應(yīng)用程序B經(jīng)過驗證之后，應(yīng)用程序A將對應(yīng)用程序B的復(fù)位處理程序執(zhí)行分支指令，以將控制權(quán)轉(zhuǎn)移給應(yīng)用程序B。復(fù)位處理程序是一小段代碼，用作軟件應(yīng)用程序的入口點，并在復(fù)位時運(yùn)行。在這種情況下，復(fù)位是通過執(zhí)行一個分支來模擬，這相當(dāng)于函數(shù)調(diào)用。這種方法有兩大問題：

許多嵌入式軟件應(yīng)用程序采用實時操作系統(tǒng)（RTOS），其允許將軟件拆分為多個并發(fā)任務(wù)，每個任務(wù)在系統(tǒng)中具有不同的職責(zé)。例如，圖1所示的應(yīng)用程序可能有用于讀取傳感器的RTOS任務(wù)，對傳感器數(shù)據(jù)運(yùn)行某種算法的RTOS任務(wù)，以及與無線電接口的RTOS任務(wù)。RTOS本身始終處于活動狀態(tài)，負(fù)責(zé)根據(jù)異步事件或特定的基于時間的延遲切換這些任務(wù)。因此，從RTOS任務(wù)分支到新程序是不安全的，因為其他任務(wù)會在后臺繼續(xù)運(yùn)行。對于實時操作系統(tǒng)，終止某個程序的唯一安全方法是通過復(fù)位。

基于圖4，上述問題的解決辦法是讓主引導(dǎo)加載程序分支到應(yīng)用程序B而不是應(yīng)用程序A。但在某些微控制器上，主引導(dǎo)加載程序總是運(yùn)行具有中斷向量表（IVT）的程序；IVT是應(yīng)用程序的一個關(guān)鍵部分，描述中斷處理函數(shù)，位于地址0。這意味著必須以某種形式重定位IVT，使其復(fù)位映射到應(yīng)用程序B。如果在IVT重定位期間發(fā)生斷電重啟，則系統(tǒng)可能會處于永久破損狀態(tài)。

將SSBL固定在地址0可以解決這些問題，如圖3所示。SSBL不是RTOS程序，因此可以安全地分支到新應(yīng)用程序。地址0處的SSBL的IVT永遠(yuǎn)不會重新定位，所以不必?fù)?dān)心斷電重啟會將系統(tǒng)置于災(zāi)難性狀態(tài)。

設(shè)計權(quán)衡：SSBL的作用

我們花了很多時間討論SSBL及其與應(yīng)用軟件的關(guān)系，但SSBL程序有何作用？至少，該程序必須確定當(dāng)前應(yīng)用程序是什么（其開始位置），然后分支到該地址。微控制器存儲器中各種應(yīng)用的位置一般保存在目錄（ToC）中，如圖3所示。這是持久內(nèi)存中的一個共享區(qū)域，SSBL和應(yīng)用軟件均利用它來相互通信。當(dāng)OTA更新過程完成時，新的應(yīng)用程序信息會更新ToC。OTA更新功能的某些部分也可以被推送到SSBL。開發(fā)OTA更新軟件時，確定推送哪些部分是重要的設(shè)計決策。上述最小SSBL將非常簡單，易于驗證，并且在應(yīng)用程序的生命周期中很可能不需要修改。但是，這意味著每個應(yīng)用程序都要負(fù)責(zé)下載和驗證下一個應(yīng)用程序。這可能導(dǎo)致無線電堆棧、設(shè)備固件和OTA更新軟件的代碼重復(fù)。另一方面，我們可以選擇將整個OTA更新過程推送到SSBL。在這種情況下，應(yīng)用程序只需在ToC中設(shè)置一個標(biāo)志以請求更新，然后執(zhí)行復(fù)位。SSBL隨后執(zhí)行下載序列和驗證過程。這將最大限度地減少代碼重復(fù)并簡化應(yīng)用專用軟件。然而，這會引入一個新的挑戰(zhàn)，那就是可能需要更新SSBL本身（即更新更新代碼）。最終，決定SSBL中放置哪些功能將取決于客戶端器件的存儲器限制、下載的應(yīng)用程序之間的相似性以及OTA更新軟件的可移植性。

設(shè)計權(quán)衡：緩存和壓縮

OTA更新軟件中的另一個關(guān)鍵設(shè)計決策是在OTA更新過程中如何組織存儲器中傳入的應(yīng)用程序。微控制器上通常有兩類存儲器：非易失性存儲器（例如閃存）和易失性存儲器（例如SRAM）。閃存用于存儲應(yīng)用程序的程序代碼和只讀數(shù)據(jù)，以及其他系統(tǒng)級數(shù)據(jù)，例如ToC和事件日志。SRAM用于存儲軟件應(yīng)用程序的可修改部分，例如非常數(shù)全局變量和堆棧。圖2所示的軟件應(yīng)用程序二進(jìn)制文件僅包含非易失性存儲器中存在的程序的某些部分。在啟動例程期間，應(yīng)用程序?qū)⒊跏蓟瘜儆谝资源鎯ζ鞯牟糠帧?/p>

在OTA更新過程中，每次客戶端器件從服務(wù)器收到一個包含該二進(jìn)制文件一部分的數(shù)據(jù)包時，便會將其存儲到SRAM中。該數(shù)據(jù)包可以是壓縮的，也可以是未壓縮的。壓縮應(yīng)用程序二進(jìn)制文件的好處是文件會變小，從而要發(fā)送的數(shù)據(jù)包會減少，下載過程中存儲數(shù)據(jù)包所需的SRAM空間相應(yīng)地減小。這種方法的缺點是壓縮和解壓縮會增加更新過程的處理時間，并且必須在OTA更新軟件中捆綁壓縮相關(guān)代碼。

新應(yīng)用軟件屬于閃存，但在更新過程中到達(dá)SRAM，因此OTA更新軟件需要在更新過程中的某個時刻執(zhí)行對閃存的寫操作。暫時將新應(yīng)用程序存儲在SRAM中的操作稱為緩存。概言之，OTA更新軟件可以采取三種不同的緩存方法。

不緩存：每次包含新應(yīng)用程序一部分的數(shù)據(jù)包到達(dá)時，便將其寫入閃存中的目標(biāo)位置。這種方案非常簡單，可以最大限度地減少OTA更新軟件中的邏輯數(shù)量，但要求完全擦除新應(yīng)用程序?qū)?yīng)的閃存區(qū)域。此方法會消磨閃存并增加開銷。

部分緩存：保留一個SRAM區(qū)域用于緩存，當(dāng)新數(shù)據(jù)包到達(dá)時，將其存儲在該區(qū)域中。當(dāng)該區(qū)域填滿時，將數(shù)據(jù)寫入閃存以清空該區(qū)域。如果數(shù)據(jù)包無序到達(dá)或新應(yīng)用程序二進(jìn)制文件中存在間隙，這種方案可能會變得很復(fù)雜，因為需要一種方法來將SRAM地址映射到閃存地址。一種策略是讓緩存充當(dāng)閃存一部分的鏡像。閃存被劃分為若干稱為頁面的小區(qū)域，這是可供擦除的最小區(qū)域。得益于這種自然劃分，一個好辦法是在SRAM中緩存閃存的一頁，當(dāng)其填滿或下一數(shù)據(jù)包屬于其他頁面時，便將該頁寫入閃存以清空緩存。

完全緩存：在OTA更新過程中將整個新應(yīng)用程序存儲在SRAM中，只有從服務(wù)器完全下載好新應(yīng)用程序之后才將其寫入閃存。這種方法克服了前述方法的缺點，寫入閃存的次數(shù)最少，OTA更新軟件無需復(fù)雜的緩存邏輯。但是，這會限制所下載新應(yīng)用程序的大小，因為系統(tǒng)的可用SRAM量通常遠(yuǎn)小于可用閃存量。

解決身份驗證這一最終挑戰(zhàn)的常見技術(shù)是使用非對稱加密。對于此操作，服務(wù)器會生成一個公鑰-私鑰對。私鑰只有服務(wù)器知道，客戶端知道公鑰。服務(wù)器使用私鑰可以生成給定數(shù)據(jù)塊的簽名，例如要無線發(fā)送的數(shù)據(jù)包的摘要。簽名被發(fā)送給客戶端，后者可以使用公鑰驗證簽名。這樣，客戶端就能確認(rèn)消息是從服務(wù)器而不是惡意第三方發(fā)送的。此序列如圖7所示，實線箭頭表示函數(shù)輸入/輸出，虛線箭頭表示無線發(fā)送的信息。

多數(shù)微控制器沒有用于執(zhí)行這些非對稱加密操作的硬件加速器，但可以使用Micro-ECC等專門針對資源受限器件的軟件庫來實現(xiàn)。該庫需要一個用戶定義的隨機(jī)數(shù)生成功能，這可以利用微控制器上的真隨機(jī)數(shù)發(fā)生器硬件外設(shè)來實現(xiàn)。雖然這些非對稱加密操作解決了OTA更新期間的信任挑戰(zhàn)，但是會消耗大量處理時間，并且需要將簽名與數(shù)據(jù)一同發(fā)送，這會增加數(shù)據(jù)包大小。我們可以在下載結(jié)束時使用最后數(shù)據(jù)包的摘要或整個新軟件應(yīng)用程序的摘要執(zhí)行一次此檢查，但如此的話，第三方將能把不受信任的軟件下載到客戶端，這不太理想。理想情況下，我們希望驗證所收到的每個數(shù)據(jù)包都來自我們信任的服務(wù)器，而且沒有每次都需要簽名的開銷。這可以利用哈希鏈來實現(xiàn)。

哈希鏈將本節(jié)討論的加密概念整合到一系列數(shù)據(jù)包中，以便在數(shù)學(xué)上將它們聯(lián)系在一起。如圖8所示，第一個數(shù)據(jù)包（編號0）包含下一個數(shù)據(jù)包的摘要。第一個數(shù)據(jù)包的有效載荷不是實際的軟件應(yīng)用程序數(shù)據(jù)，而是簽名。第二個數(shù)據(jù)包（編號1）的有效載荷包含二進(jìn)制文件的一部分和第三個數(shù)據(jù)包（編號2）的摘要?？蛻舳蓑炞C第一個數(shù)據(jù)包中的簽名并緩存摘要H0以供以后使用。當(dāng)?shù)诙€數(shù)據(jù)包到達(dá)時，客戶端對有效載荷進(jìn)行哈希處理并將其與H0進(jìn)行比較。如果它們匹配，客戶端便可確定該后續(xù)數(shù)據(jù)包來自可信服務(wù)器，而無需費(fèi)力進(jìn)行簽名檢查。生成此鏈的高開銷任務(wù)留給服務(wù)器完成，客戶端只需在每個數(shù)據(jù)包到達(dá)時進(jìn)行緩存和哈希處理，確保到達(dá)的數(shù)據(jù)包完整無損并驗明正身。

實驗設(shè)置

解決本文所述存儲器、通信和安全設(shè)計挑戰(zhàn)的超低功耗微控制器是ADuCM3029和ADuCM4050.這些微控制器包含本文討論的用于OTA更新的硬件外設(shè)，例如閃存、SRAM、加密加速器和真隨機(jī)數(shù)發(fā)生器。這些微控制器的器件系列包（DFP）為在這些器件上構(gòu)建OTA更新解決方案提供了軟件支持。DFP包含外設(shè)驅(qū)動，以便為使用硬件提供簡單靈活的接口。

硬件配置

為了驗證本文討論的概念，我們利用ADuCM4050創(chuàng)建了OTA更新軟件參考設(shè)計。對于客戶端，一個ADuCM4050 EZ-KIT使用收發(fā)器子板馬蹄形連接器連接到ADF7242?？蛻舳似骷鐖D9左側(cè)所示。對于服務(wù)器，我們開發(fā)了一個在Windows PC上運(yùn)行的Python應(yīng)用程序。Python應(yīng)用程序通過串行端口與另一個ADuCM4050 EZ-KIT通信，后者也以與客戶端相同的配置連接一個ADF7242。但是，圖9中右邊的EZ-KIT不執(zhí)行OTA更新邏輯，只是將從ADF7242接收到的數(shù)據(jù)包中繼給Python應(yīng)用程序。

軟件組件

軟件參考設(shè)計對客戶端器件的閃存進(jìn)行分區(qū)，如圖3所示。主要客戶端應(yīng)用程序具有非常好的移植性和可配置性，以便其他方案或其他硬件平臺也可以使用。圖10顯示了客戶端器件的軟件架構(gòu)。請注意，雖然我們有時將整個應(yīng)用程序稱為SSBL，但在圖10中，并且從現(xiàn)在開始，我們在邏輯上將真正的SSBL部分（藍(lán)色）與OTA更新部分（紅色）分開，因為后者不一定需要完全在上述應(yīng)用程序中實現(xiàn)。圖10所示的硬件抽象層使OTA客戶端軟件可移植并獨(dú)立于任何底層庫（以橙色顯示）。

軟件應(yīng)用程序?qū)崿F(xiàn)圖3中的引導(dǎo)序列（一個用于從服務(wù)器下載新應(yīng)用程序的簡單通信協(xié)議）和哈希鏈。通信協(xié)議中的每個數(shù)據(jù)包都有12字節(jié)的元數(shù)據(jù)頭、64字節(jié)的有效載荷和32字節(jié)的摘要。此外，它還有如下特性：

緩存：根據(jù)用戶配置，支持不緩存或緩存閃存的一頁。

目錄：ToC設(shè)計為僅容納兩個應(yīng)用程序，并且新應(yīng)用程序總是下載到最舊的位置，以保留一個備用應(yīng)用程序。這稱為A/B更新方案。

消息傳遞：支持ADF7242或UART進(jìn)行消息傳遞，具體取決于用戶配置。使用UART進(jìn)行消息傳遞可免除圖9左側(cè)的EZ-KIT，僅保留右側(cè)套件用于客戶端。這種有線更新方案對初始系統(tǒng)啟動和調(diào)試很有用。

結(jié)果

除了滿足功能要求并通過各種測試之外，軟件的性能對于判斷項目成功與否也很重要。通常使用兩個指標(biāo)來衡量嵌入式軟件的性能：占用空間和周期數(shù)。占用空間是指軟件應(yīng)用程序在易失性（SRAM）和非易失性（閃存）存儲器中占用的空間大小。周期數(shù)是指軟件執(zhí)行特定任務(wù)所使用的微處理器時鐘周期數(shù)。它與軟件運(yùn)行時間相似，但在執(zhí)行OTA更新時，軟件可能進(jìn)入低功耗模式，此時微處理器處于非活動狀態(tài)，不消耗任何周期。雖然軟件參考設(shè)計沒有針對任何一個指標(biāo)進(jìn)行優(yōu)化，但它們對于程序基準(zhǔn)測試和比較設(shè)計權(quán)衡非常有用。

圖11和圖12顯示了在ADuCM4050上實現(xiàn)的OTA更新軟件參考設(shè)計的占用空間（不緩存）。這些圖根據(jù)圖10所示的組件進(jìn)行劃分。如圖11所示，整個應(yīng)用程序使用大約15 kB的閃存。鑒于ADuCM4050包含512 kB閃存，此占用空間非常小。真正的應(yīng)用軟件（為OTA更新過程開發(fā)的軟件）僅需1.5 kB左右，其余用于庫，例如DFP、Micro-ECC和ADF7242堆棧。這些結(jié)果有助于說明SSBL應(yīng)在系統(tǒng)中扮演什么角色的設(shè)計權(quán)衡。15 kB占用空間的大部分是用于更新過程。SSBL本身僅占用大約500字節(jié)的空間，另外還有1 kB到2 kB的DFP代碼，用于訪問閃存驅(qū)動器之類的器件。

了評估軟件的開銷，我們在每次接收數(shù)據(jù)包時計數(shù)周期，然后計算每個數(shù)據(jù)包平均消耗的周期數(shù)。每個數(shù)據(jù)包都需要AES-128解密、SHA-256哈希處理、閃存寫入和某種數(shù)據(jù)包元數(shù)據(jù)驗證。數(shù)據(jù)包有效載荷為64字節(jié)且不緩存時，處理單個數(shù)據(jù)包的開銷為7409個周期。使用26 MHz內(nèi)核時鐘時，大約需要285微秒的處理時間。該值是利用ADuCM4050 DFP中的周期計數(shù)驅(qū)動程序計算的（未調(diào)整周期數(shù)），并且是100 kB二進(jìn)制文件下載期間（約1500個數(shù)據(jù)包）的平均值。為使每個數(shù)據(jù)包的開銷最小，DFP中的驅(qū)動程序應(yīng)利用ADuCM4050上的直接存儲訪問（DMA）硬件外設(shè)來執(zhí)行總線事務(wù)，并且驅(qū)動程序在每次事務(wù)處理期間將處理器置于低功耗休眠狀態(tài)。每個事務(wù)中不存在一個萬能的狀態(tài)如果我們禁用DFP中的低功耗休眠并將總線事務(wù)更改為不使用DMA，則每個數(shù)據(jù)包的開銷將增加到17，297個周期。這說明了高效使用器件驅(qū)動程序?qū)η度胧杰浖?yīng)用程序是有影響的。雖然減少每個數(shù)據(jù)包的數(shù)據(jù)字節(jié)數(shù)也可以降低開銷，但每個數(shù)據(jù)包的數(shù)據(jù)字節(jié)數(shù)翻一倍達(dá)到128時，周期數(shù)僅有少量增加，相同實驗得到的周期數(shù)為8362。

周期數(shù)和占用空間也解釋了先前討論的權(quán)衡--緩存數(shù)據(jù)包數(shù)據(jù)而不是每次都寫入閃存。使能緩存一頁閃存后，每個數(shù)據(jù)包的開銷從7409減少到5904個周期。此20%減幅來自于更新過程跳過了大多數(shù)數(shù)據(jù)包的閃存寫入，僅在緩存已滿時才執(zhí)行閃存寫入。其代價是SRAM占用面積增加。不使用緩存時，HAL只需要336個字節(jié)的SRAM，如圖12所示。但是，當(dāng)使用緩存時，必須保留一個相當(dāng)于閃存一整頁的空間，故SRAM占用增加到2388字節(jié)。HAL使用的閃存也會少量增加，原因是需要額外代碼來判斷緩存何時必須清空。

這些結(jié)果證明，設(shè)計決策對軟件性能會有切實的影響。不存在一個萬能的解決方案，每個系統(tǒng)都有不同的要求和約束，OTA更新軟件需要視具體情況具體對待。希望本文闡明了在設(shè)計、實現(xiàn)和驗證OTA更新軟件解決方案時遇到的常見問題和權(quán)衡。