各位看官好,上一篇文章我們聊了一下關(guān)于 OTA 升級(jí)過程中,新的軟件包是如何從開發(fā)者的電腦上,安全的下載到嵌入式設(shè)備中的。
這個(gè)流程似乎很簡單,不就是下載一個(gè)文件而已嘛,怎么還值得寫成一篇文章呢?
其實(shí)這不僅僅是下載文件這么簡單,這其中涉及到如何對(duì)眾多的終端設(shè)備進(jìn)行批量升級(jí)的策略問題。
如果你親自在 AWS 的平臺(tái)上操刀一次,就知道這其中有很多細(xì)節(jié)問題是需要考慮的。
一失足成千古恨哪!一旦設(shè)備升級(jí)策略忽略了一個(gè)小細(xì)節(jié),也許某一天就是我們的深淵!
包括產(chǎn)品的生產(chǎn)過程也是如此,那些踩過的坑,真是一把鼻涕一把淚,這個(gè)問題后面有時(shí)間專門寫一篇。
今天,我們繼續(xù) OTA 升級(jí)過程中后續(xù)的階段。
還記得我們之前的假設(shè)嗎?
設(shè)備中正在執(zhí)行的 V1 版本的程序,包括這 3 個(gè)文件,它們位于文件系統(tǒng)中的 /root/app 目錄下:
main: 主程序;
config.ini: 配置文件(包括一個(gè)配置項(xiàng):version=V1_0);
mylib.so: 實(shí)現(xiàn)了某個(gè)算法的動(dòng)態(tài)庫,被 main 程序調(diào)用;
現(xiàn)在,新的版本 V2 優(yōu)化了算法,壓縮包名稱是 app_V2.0.tgz,其中包括文件:
main: 沒有變化;
config.ini: 配置項(xiàng)修改了:version=V2_0;
mylib.so: 優(yōu)化了算法,主要就是想升級(jí)這個(gè)動(dòng)態(tài)庫;
upgrade.sh: 一個(gè)腳本程序,新增的文件;
升級(jí)包 app_V2.0.tgz 已經(jīng)被下載到設(shè)備本地的文件系統(tǒng)中了,假設(shè)解壓到目錄 /root/upgrade 中。
現(xiàn)在需要做的事情就是:新版本程序,去替代 /root/app 目錄中的舊版本程序。
upgrade.sh 升級(jí)腳本
我們首先要明白一個(gè)問題:執(zhí)行升級(jí)指令、下載壓縮包,都是此刻正在執(zhí)行的 main 程序來執(zhí)行的。
如果把復(fù)制替換的操作也讓 main 程序來執(zhí)行的話,肯定是會(huì)出問題的:它不可能去復(fù)制一個(gè)新的 main 文件,來把自己替換掉!
寫過單片機(jī)程序的小伙伴肯定都知道:當(dāng)新的固件下載到 flash 之后,一般都是重新啟動(dòng)設(shè)備,然后由 bootloader 來執(zhí)行具體的文件復(fù)制操作。
那么對(duì)于帶有文件系統(tǒng)的設(shè)備來說,也可以模仿類似的操作方式。
比如:當(dāng)設(shè)備重新啟動(dòng)后,當(dāng)執(zhí)行 /etc/rc.local 時(shí),此時(shí) main 應(yīng)用程序還沒有啟動(dòng)。
此時(shí)就可以在 rc.local 這個(gè)文件中去做升級(jí)操作。
但是這樣的方式,相當(dāng)于是輕微的侵入了操作系統(tǒng),總感覺這樣做不太好。
此刻, upgrade.sh 升級(jí)腳本開始登場了!
這個(gè)腳本文件的主要作用就是用來控制升級(jí)過程。
這里隱藏這一個(gè)很重要的思想:upgrade.sh 是放在升級(jí)包中的,它并沒有固化在終端設(shè)備中。
這樣的話,每次執(zhí)行升級(jí)任務(wù)時(shí),都可以根據(jù)本次的升級(jí)需要,來靈活的編寫升級(jí)腳本。
換句話說:只要能保證升級(jí)的通道沒有問題,那么升級(jí)的過程就完全由這個(gè)腳本文件來控制,你想怎么搞,就怎么搞!
完全升級(jí)
所謂的完全升級(jí),就是把舊版本的程序全部丟棄,把升級(jí)包中的新程序全部復(fù)制過去。
此時(shí),升級(jí)腳本文件 upgrade.sh 就完成下面這幾個(gè)主要工作:
停止(kill)當(dāng)前正在執(zhí)行的 V1.0 版本的程序;
刪除 /root/app 目錄下的所有舊文件;
把升級(jí)包中所有的新版本文件 /root/upgrade/* 復(fù)制到 /root/app 目錄下;
這樣的完全升級(jí)方式是最無腦、最粗魯?shù)摹?/p>
當(dāng)然,還有一些細(xì)節(jié)問題是需要考慮的。比如:如果復(fù)制文件過程中出現(xiàn)錯(cuò)誤怎么辦?
還有一點(diǎn),既然剛才提到了配置文件 config.ini,不知您是否會(huì)有這樣一個(gè)疑問:
如果配置信息被用戶修改了,那么升級(jí)之后,所有的配置信息又被恢復(fù)為默認(rèn)值了,用戶的私人配置信息全丟了怎么辦?
關(guān)于這個(gè)問題,我們就繼續(xù)來聊一下增量升級(jí)!
增量升級(jí)
所謂的增量升級(jí):就是升級(jí)時(shí)并不會(huì)把所有的文件全部進(jìn)行替換,而只是替換那些需要更新的文件。
對(duì)于我們假設(shè)的升級(jí)場景,只需要做 2 件事情:
替換 mylib.so 庫文件;
把配置文件 config.ini 中的版本字段修改為:version=V2_0;
同樣的,所有的升級(jí)過程仍然是寫在 upgrade.sh 這個(gè)升級(jí)腳本中:
停止(kill)當(dāng)前正在執(zhí)行的 V1.0 版本的程序;
把 /root/upgrade/mylib.so 文件復(fù)制到 /root/app 目錄下;
使用 sed 命令來修改 config.ini 文件中的 version 字段;
PS:此時(shí)升級(jí)包中,只需要包含必要的文件就可以了,不需要把其他用不到的文件也放進(jìn)去了。
從我描述的文字來看,似乎完全升級(jí)和增量升級(jí)差別不大。
這是因?yàn)檫@里的示例太簡單,如果是一個(gè)比較復(fù)雜的、有多個(gè)模塊相互配合的應(yīng)用程序,增量升級(jí)的優(yōu)勢(shì)就明顯了。
關(guān)于 OTA 升級(jí)過程,就先說這么多了,主要是以思想為主,畢竟每一個(gè)項(xiàng)目的需求場景是不一樣的,從大方向上明白 OTA 的升級(jí)過程就可以了。
One more thing
后臺(tái)提供一個(gè)很多年前項(xiàng)目中的升級(jí)腳本文件模板。
作者|道哥
轉(zhuǎn)自|IOT物聯(lián)網(wǎng)小鎮(zhèn)
編輯:jq
-
OTA
+關(guān)注
關(guān)注
7文章
566瀏覽量
35106 -
腳本
+關(guān)注
關(guān)注
1文章
387瀏覽量
14811 -
AWS
+關(guān)注
關(guān)注
0文章
427瀏覽量
24290
原文標(biāo)題:技術(shù)分享 | 物聯(lián)網(wǎng)設(shè)備OTA軟件升級(jí)之:完全升級(jí)和增量升級(jí)
文章出處:【微信號(hào):Ithingedu,微信公眾號(hào):安芯教育科技】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論