IAP的價值與意義

作者最早開始結實IAP這個概念還是在大學進行飛思卡爾智慧汽車比賽期間，瞭解的小夥伴應該知道我們大部分時間都是在"燒車"-(也就是車子不行的在賽道上進行測試)，特別是除錯PID或者是發現識別演算法的Bug以後，要麼就是去拿車過來燒錄，要麼就是拿著筆記本過去進行燒錄，這樣有時候還真是體力活，後來無意間看來一篇技術報告談到了遠端無線升級，當時自己調引數也是用藍芽除錯，便開始研究這個功能，折騰一段時間，因為需要對晶片的啟動過程等等進一步的熟悉，不過後面確實挺方便的，基本上換了電池以後我就只需要坐著寫程式碼升級即可。

至於到了現在的實際工作過程中，這種升級功能的需求成了軟體設計的必備專案，那有小夥伴可能就會問了:我覺得用燒錄器燒錄挺快的呀，每次想要升級直接用燒錄盒燒錄不就行了嗎？好，那比如說現在你在深圳，客戶在北京，你還得每次還要跑到客戶現場去升級嗎?到了客戶現場難道你還要拆客戶的機器插上燒錄器嗎？實在是太麻煩了，還是選擇遠端升級吧，同時IAP還會有更加嚴格的測試要求，比如燒錄過程中的斷電，斷網路等等系統的動作和後續修護問題都是要進行考慮和設計的。

MCU軟體升級的設計"進化論"

對於我們的MCU現在大部分的都是使用Flash來儲存程式，同時程式內部也會有讀寫Flash的介面函式，中斷也可以方便的重定位，這樣就非常適合IAP程式的開發。

1)IAP升級V1.0

作者這裡畫了一張現在目前比較普遍的升級軟體設計圖:

解析一下:我們把MCU的Flash分割槽分為如上圖所示的三個部分，Bootloader就是我們所要編寫的啟動程式，App程式為專案的實際應用程式，Param區域是用於儲存相應的版本App的版本資訊以及完整性校驗標誌序列等傳遞資料區域。

工作方式1:當MCU啟動以後執行Bootloader程式，檢測到Param引數區域是否存在App記錄，如果存在App直接執行App程式即可，如果不存在，則向PC機請求App檔案。

工作方式2:當MCU執行App過程中，接收到PC機的升級請求，更新Param引數區域，並跳轉到BootLoader進行App程式的接受和升級，升級完成以後處理Param引數區域並執行對應的新App程式。

V1.0算是比較常規的應用案例，我們都知道對MCU內部Flash進行程式設計一般會有解鎖、擦除、寫入和驗證幾個階段，當我們擦除原來MCU儲存的App程式以後如果手頭上沒有相關的韌體，基本上就不能恢復了，這樣如果我們想退回到之前的版本不可能了！於是升級方案還需要在改善一下。

2)IAP升級V2.0

為了解決V1.0提出的問題我們App分成了兩部分如下圖所示:

解析一下:上面兩張圖的原理是一樣的，都是把接收到的新App儲存起來(如果你用於備份老的App也是可以的)，圖1是通過把MCU內部Flash進行劃分，一部分用於儲存新App，另外一部分是原來執行的App區域，這樣的話，當我們通過bootloader接收完完整的新App進行校驗、解密處理以後便可以寫入到平時執行的App區域，從而防止了V1.0在升級過程中掉電、通訊異常導致擦除了App的問題。

同時，我們也可以把上一版本App備份到我們預留的內部Flash或者外部儲存裝置中，如果想還原系統即可直接通過PC傳送相應命令進行恢復即可。

好了，又有小夥伴提出問題，大家都知道我們自己編寫的BootLoader是非常靈活的，可以支援多種通訊協議的升級模式，不過在前期我們可能沒有考慮完善，後續想進一步完善相應功能就需要我們對Bootloader進行升級，那麼我們可以通過App對Bootloader進行升級操作，一般這種方式就可以滿足需求，不過如果在升級BootLoader過程中發生故障，那Bootloader全部被擦除導致整個MCU變成了個磚頭。好吧，是時候上V3.0版本的IAP程式了。

3)IAP升級V3.0

為了解決V2.0問題，作者設計了第三種升級方式:

解析一下:在V2.0的基礎上我們增加了Bootloader2，對於Bootloader1相當於固化在MCU中自定義的一種升級方式，而Bootloader2是可以根據我們啟動升級需求進行升級的區域，這樣即使在升級過程中擦除，我們也可以通過BootLoader1或者App2來進行恢復Bootloader2。

不過具體的實現過程會設計到較多的邏輯處理，大家在實現該方案的同時需要前期進行軟體上的設計和梳理。

4、最後小結

對於IAP軟體方案作者就分享到這裡，大家在選擇線上升級方案的同時需要結合自身專案的需求來考量，對於具體的實現過程還是有很多技術細節需要注意的，比如程式碼的地址連結、中斷的重定位方案、軟體的加密等等，後續有時間再針對具體的技術細節進行分享。