本發(fā)明涉及通信技術(shù)領(lǐng)域，特別涉及一種藍(lán)牙芯片OTA升級的方法和藍(lán)牙芯片。

背景技術(shù)：

IOT(Internet of Things，物聯(lián)網(wǎng))是當(dāng)前行業(yè)應(yīng)用熱點，同時也是設(shè)備互聯(lián)互通的技術(shù)發(fā)展方向。作為IOT技術(shù)的重要載體：低功耗藍(lán)牙SoC芯片，因其低成本，高效互聯(lián)技術(shù)特征，應(yīng)用的越來越廣泛。

OTA全稱over the air，也稱為在線升級，增量升級。OTA升級是Android系統(tǒng)提供的標(biāo)準(zhǔn)軟件升級方式。其升級模式有全量升級模式和增量升級模式。并且，OTA可以通過SD卡升級，也可以通過網(wǎng)絡(luò)升級。通常所說的OTA升級，一般是指增量升級，最常見的就是先通過網(wǎng)絡(luò)下載升級包，然后再進(jìn)入升級界面，等升級完成就自動重啟，完成升級。

實現(xiàn)藍(lán)牙芯片的OTA升級，一方面可以修復(fù)產(chǎn)品缺陷，豐富產(chǎn)品功能，以及增加用戶的粘性；另一方面，利于迭代的產(chǎn)品升級，有助于快速切入市場，降低整體開發(fā)成本，因此具有重要的意義。藍(lán)牙芯片的OTA升級，一般都是通過智能電視、智能手機(jī)、平板電腦等嵌入式產(chǎn)品來完成。智能電視、智能手機(jī)、平板電腦等產(chǎn)品借助移動網(wǎng)絡(luò)或者Wifi網(wǎng)絡(luò)，首先將OTA升級包(一般為壓縮包)從服務(wù)器下載到本地，在對升級包進(jìn)行解壓后通過藍(lán)牙通道將解壓后的升級包發(fā)送給藍(lán)牙設(shè)備，最后藍(lán)牙設(shè)備完成固件升級。

在低功耗藍(lán)牙SoC芯片的推廣過程中，隨著用戶應(yīng)用的多元化，低功耗藍(lán)牙SoC芯片的OTA升級功能需求突顯。

上述提到的藍(lán)牙芯片OTA升級過程需要依靠智能電視、智能手機(jī)、平板電腦等嵌入式產(chǎn)品來對升級包進(jìn)行解壓，但是對于一些非智能設(shè)備，如遙控器等，其內(nèi)部CPU芯片很弱，無法完成解壓升級包(此時的升級包一般為tar、zip等壓縮文件格式)的過程。因此通常需要直接將原始的升級包發(fā)送給藍(lán)牙SoC芯片。通常來說，如果直接通過原始的升級包進(jìn)行升級，將占用大量的Flash資源(原始升級文件一般較大)，這對于SRAM以及FLASH容量都有限(基于成本的考慮)的SoC藍(lán)牙芯片而言，無疑增加了OTA升級的難度。

為了解決上述問題，現(xiàn)有技術(shù)中有兩種解決方案。其一，通過增大SoC藍(lán)牙芯片的Flash容量和增多Flash分區(qū)來完成藍(lán)牙設(shè)備固件升級。其二，在SoC藍(lán)牙芯片外接入額外的Flash來完成藍(lán)牙設(shè)備固件升級。

申請人在實現(xiàn)本發(fā)明的過程中發(fā)現(xiàn)現(xiàn)有技術(shù)至少存在以下問題：

其一，增大Flash容量和分區(qū)的方法無疑增加了系統(tǒng)的成本。

其二，通過外接Flash來實現(xiàn)OTA升級的方法，一方面不僅增加了系統(tǒng)成本，而且也引入了Flash間數(shù)據(jù)傳輸?shù)腻e誤碼問題，嚴(yán)重時會導(dǎo)致升級錯誤碼，使整個低功耗藍(lán)牙SoC芯片系統(tǒng)Boot失敗。

因此，如何降低藍(lán)牙SoC芯片的OTA升級的成本以及保證升級過程中系統(tǒng)的穩(wěn)定性成為藍(lán)牙SoC芯片生產(chǎn)廠家亟待解決的問題。

技術(shù)實現(xiàn)要素：

本發(fā)明提供一種藍(lán)牙芯片OTA升級的方法，通過該方法可以減少藍(lán)牙芯片OTA升級過程中的內(nèi)存占用。所述藍(lán)牙SoC芯片內(nèi)的Flash儲存器內(nèi)有程序啟動分區(qū)和儲存分區(qū)，該方法包括：

通過藍(lán)牙通道接收智能設(shè)備發(fā)送的壓縮升級包并且將所述壓縮升級包儲存到所述儲存分區(qū)，所述壓縮升級包是由原始升級文件經(jīng)過數(shù)據(jù)壓縮并且保持格式不變后得到的，所述壓縮升級包為可執(zhí)行文件；

對所述壓縮升級包進(jìn)行解壓并將解壓后的數(shù)據(jù)寫入所述程序啟動分區(qū)；

重新啟動所述藍(lán)牙芯片進(jìn)行升級。

優(yōu)選的，所述壓縮升級包的生成過程如下：

接收初始壓縮升級包；

判斷所述初始壓縮升級包的格式是否與所述原始升級文件的格式相同；

若相同，則確認(rèn)所述初始壓縮升級包為所述壓縮升級包；

若不相同，則將所述初始壓縮升級包解壓為所述原始升級文件，在保持文件格式不變的基礎(chǔ)上對所述原始升級文件進(jìn)行數(shù)據(jù)壓縮，并將經(jīng)過數(shù)據(jù)壓縮后的所述原始升級文件確認(rèn)為所述壓縮升級包。

優(yōu)選的，所述對所述原始升級文件進(jìn)行數(shù)據(jù)壓縮，具體為：

在所述原始升級文件中讀取長度為預(yù)設(shè)長度的數(shù)據(jù)；

對所述數(shù)據(jù)進(jìn)行數(shù)據(jù)壓縮后得到壓縮數(shù)據(jù)段；

在所述壓縮數(shù)據(jù)段的前面添加指示標(biāo)記；所述指示標(biāo)記用于指出所述壓縮數(shù)據(jù)段的長度值；

判斷是否完成對原始升級文件的壓縮；

若已經(jīng)完成對原始升級文件的壓縮，則結(jié)束壓縮過程；

若未完成對原始升級文件的壓縮，則在原始升級文件中繼續(xù)讀取長度為預(yù)設(shè)長度的數(shù)據(jù)。

優(yōu)選的，所述對所述壓縮升級包進(jìn)行解壓具體為：

讀取所述指示標(biāo)記；

根據(jù)所述指示標(biāo)記獲取所述壓縮數(shù)據(jù)段的長度值；

根據(jù)所述長度值在所述壓縮升級包讀取所述壓縮數(shù)據(jù)段；

對讀取到的所述壓縮數(shù)據(jù)段進(jìn)行解壓處理；

判斷是否已經(jīng)完成對所述壓縮升級包的解壓；

若已經(jīng)完成對所述壓縮升級包的解壓，則結(jié)束解壓過程；

若未完成對所述壓縮升級包的解壓，則繼續(xù)讀取所述指示標(biāo)記。

優(yōu)選的，在所述對所述壓縮升級包進(jìn)行解壓之前，所述方法還包括；

對所述壓縮升級包進(jìn)行校驗，并且在校驗失敗時重新接收所述壓縮升級包。

相應(yīng)的，本申請?zhí)岢鲆环N藍(lán)牙芯片，其特征在于，所述藍(lán)牙芯片內(nèi)的Flash儲存器內(nèi)有程序啟動分區(qū)和儲存分區(qū)，所述藍(lán)牙芯片還包括：

接收模塊，通過藍(lán)牙通道接收智能設(shè)備發(fā)送的壓縮升級包并且將所述壓縮升級包儲存到所述儲存分區(qū)，所述壓縮升級包是由原始升級文件經(jīng)過數(shù)據(jù)壓縮并且保持格式不變后得到的，所述壓縮升級包為可執(zhí)行文件；

解壓模塊，對所述壓縮升級包進(jìn)行解壓并將解壓后的數(shù)據(jù)寫入所述程序啟動分區(qū)；

運(yùn)行模塊，重新啟動所述藍(lán)牙芯片進(jìn)行升級。

優(yōu)選的，所述壓縮升級包的生成過程如下：

接收初始壓縮升級包；

判斷所述初始壓縮升級包的格式是否與所述原始升級文件的格式相同；

若相同，則確認(rèn)所述初始壓縮升級包為所述壓縮升級包；若不相同，則將所述初始壓縮升級包解壓為所述原始升級文件，在保持文件格式不變的基礎(chǔ)上對所述原始升級文件進(jìn)行數(shù)據(jù)壓縮，并將經(jīng)過數(shù)據(jù)壓縮后的所述原始升級文件確認(rèn)為所述壓縮升級包。

優(yōu)選的，所述對所述原始升級文件進(jìn)行數(shù)據(jù)壓縮，具體為：

在所述原始升級文件中讀取長度為預(yù)設(shè)長度的數(shù)據(jù)；

對所述數(shù)據(jù)進(jìn)行數(shù)據(jù)壓縮后得到壓縮數(shù)據(jù)段；

在所述壓縮數(shù)據(jù)段的前面添加指示標(biāo)記；所述指示標(biāo)記用于指出所述壓縮數(shù)據(jù)段的長度值；

判斷是否完成對原始升級文件的壓縮；

若已經(jīng)完成對原始升級文件的壓縮，則結(jié)束壓縮過程；

若未完成對原始升級文件的壓縮，則在原始升級文件中繼續(xù)讀取長度為預(yù)設(shè)長度的數(shù)據(jù)。

優(yōu)選的，所述解壓模塊具體用于：

讀取所述指示標(biāo)記；

根據(jù)所述指示標(biāo)記獲取所述壓縮數(shù)據(jù)段的長度值；

根據(jù)所述長度值在所述壓縮升級包讀取所述壓縮數(shù)據(jù)段；

對讀取到的所述壓縮數(shù)據(jù)段進(jìn)行解壓處理；

判斷是否已經(jīng)完成對所述壓縮升級包的解壓；

若已經(jīng)完成對所述壓縮升級包的解壓，則結(jié)束解壓過程；

若未完成對所述壓縮升級包的解壓，則繼續(xù)讀取所述指示標(biāo)記。

優(yōu)選的，還包括：

校驗?zāi)K，對所述壓縮升級包進(jìn)行校驗，并且在校驗失敗時重新接收所述壓縮升級包。

通過本申請的技術(shù)方案，藍(lán)牙芯片首先接收壓縮升級包并且將所述壓縮升級包儲存到所述儲存分區(qū)。壓縮升級包由原始升級文件經(jīng)過數(shù)據(jù)壓縮并且保持格式不變后得到的，并且為可執(zhí)行文件，因此藍(lán)牙芯片能夠直接對其進(jìn)行讀取。之后藍(lán)牙芯片對壓縮升級包進(jìn)行解壓，并將解壓出來的數(shù)據(jù)寫入所述程序啟動分區(qū)。在完成對壓縮升級包的解壓時，重新啟動藍(lán)牙芯片以完成OTA升級的過程。在本申請方案中，在對原始壓縮文件進(jìn)行數(shù)據(jù)壓縮的過程不會引起任何的數(shù)據(jù)失真，因此保證了升級過程中系統(tǒng)的穩(wěn)定性。并且，由于對原始升級文件進(jìn)行了壓縮，因此可以極大的減小儲存升級包所用的Flash空間。綜上，通過本申請的方案在小Flash容量下實現(xiàn)藍(lán)牙芯片OTA升級功能的同時，降低了藍(lán)牙芯片的成本。進(jìn)一步的，本申請的方案還能夠保證升級過程中系統(tǒng)的穩(wěn)定性。

附圖說明

圖1為本申請?zhí)岢龅囊环N藍(lán)牙SoC芯片OTA升級的方法的流程示意圖；

圖2為本申請具體實施例提出在執(zhí)行本申請方案時升級壓縮包狀態(tài)變化示意圖；

圖3為本申請具體實施例提出的應(yīng)用本申請方法各設(shè)備間的交互示意圖；

圖4為本申請具體實施例中實際應(yīng)用場景中藍(lán)牙SoC芯片OTA升級的流程示意圖；

圖5為本申請具體實施例中升級包壓縮過程的流程示意圖；

圖6為本申請具體實施例中升級包解壓過程的流程示意圖；

圖7為本申請?zhí)岢龅囊环N藍(lán)牙芯片的結(jié)構(gòu)示意圖。

具體實施方式

如背景技術(shù)所述，由于藍(lán)牙SoC芯片無法讀取如tar、zip等格式的壓縮文件。因此，為了完成藍(lán)牙SoC芯片的OTA升級過程，需要將原始格式的升級包直接發(fā)送給芯片。對于Flash容量有限的藍(lán)牙SoC芯片(基于成本考慮)，如果直接通過原始升級文件進(jìn)行升級，將占用大量的Flash資源，這增加芯片OTA升級的難度。為了解決上述問題，現(xiàn)有的技術(shù)方案采用的方法為增大芯片的Flash容量或者外接外接新的Flash的方法。但是，上述方法無疑增加了芯片的制作成本，同時外接Flash還會存在引入了Flash間數(shù)據(jù)傳輸?shù)腻e誤碼的問題，嚴(yán)重影響了芯片OTA升級過程中系統(tǒng)的穩(wěn)定性。

因此，針對現(xiàn)有藍(lán)牙SoC芯片升級過程中存在的問題，本申請?zhí)岢隽艘环N藍(lán)牙芯片OTA升級的方法，采用無損數(shù)據(jù)壓縮的方法對原始升級文件進(jìn)行多分段壓縮，可以在減小升級包的同時保證確保數(shù)據(jù)的準(zhǔn)確性；同時在對升級包進(jìn)行解壓時，相應(yīng)的采用分段解壓的方法，降低了對芯片內(nèi)存資源的占用。因此，可以在不增大芯片F(xiàn)lash內(nèi)存的前提下，完成藍(lán)牙芯片的OTA升級，同時保證了系統(tǒng)在升級過程中的穩(wěn)定性。

上述提到的無損數(shù)據(jù)壓縮是指利用數(shù)據(jù)的統(tǒng)計冗余進(jìn)行壓縮，然后對壓縮后的數(shù)據(jù)進(jìn)行重構(gòu)(或解壓縮)，重構(gòu)可完全恢復(fù)原始數(shù)據(jù)而不引起任何失真。因此，在本申請中，在對原始升級文件進(jìn)行無損數(shù)據(jù)壓縮之后，一方面可以減小升級包的大小，另一方面還能確保數(shù)據(jù)的準(zhǔn)確性。

如圖1所示，為本申請?zhí)岢龅囊环N藍(lán)牙芯片OTA升級的方法，需要說明的是在本申請中涉及的藍(lán)牙芯片一般是指非智能設(shè)備(如智能遙控器)的藍(lán)牙芯片。該類設(shè)備的特點是內(nèi)部的CPU芯片較弱，無法完成對于tar、zip等壓縮格式文件的解壓過程。因此，芯片需要接收原始格式的升級包，來完成OTA升級過程。同時該類型芯片的Flash儲存器內(nèi)分為儲存分區(qū)和程序正常啟動分區(qū)，其中儲存分區(qū)是用來儲存升級包的，程序正常啟動分區(qū)是用來燒寫解壓后的升級包的。

具體的，該方法包括以下步驟：

S101，通過藍(lán)牙通道接收智能設(shè)備發(fā)送的壓縮升級包并且將壓縮升級包儲存到儲存分區(qū)。

在本申請的實施例中，壓縮升級包是由原始升級文件經(jīng)過數(shù)據(jù)壓縮并且保持格式不變后得到的。原始升級文件為可執(zhí)行文件，可執(zhí)行文件為二進(jìn)制文件，因此，即使是在CPU較弱的藍(lán)牙芯片也可以直接加載運(yùn)行。并且由于經(jīng)壓縮后原始升級文件的格式未變，壓縮升級包同樣也為可執(zhí)行文件。

上述提到的數(shù)據(jù)壓縮可以無損數(shù)據(jù)壓縮，在基于本申請思想的基礎(chǔ)上，本領(lǐng)域技術(shù)人員也可以采用其他的壓縮方法，這并不影響本申請的保護(hù)范圍。

在本申請的優(yōu)選實施例中，壓縮升級包是由智能設(shè)備(如智能手機(jī)、平板電腦、智能電視等)生成并發(fā)送的，壓縮升級包的生成過程如下：

(1)接收初始壓縮升級包。

智能設(shè)備可以從PC端或者是云端服務(wù)器中獲取初始壓縮升級包。

(2)判斷初始壓縮升級包的格式是否與原始升級文件的格式相同。

由于，智能設(shè)備獲取的初始壓縮升級包的格式可能和原始升級文件的格式不同，而藍(lán)牙芯片只能夠讀取與原始升級文件格式相同的文件，因此智能設(shè)備在將升級包發(fā)送給藍(lán)牙芯片之前，必須得先判斷該升級包的格式是否與原始升級文件的格式相同。

(3)若相同，則確認(rèn)初始壓縮升級包為壓縮升級包。

如果格式相同，則說明芯片能夠?qū)ζ溥M(jìn)行讀取，因此可將其直接發(fā)送給藍(lán)牙芯片。

(4)若不相同，則將初始壓縮升級包解壓為原始升級文件，在保持文件格式不變的基礎(chǔ)上對原始升級文件進(jìn)行數(shù)據(jù)壓縮，并將經(jīng)過數(shù)據(jù)壓縮后的原始升級文件確認(rèn)為壓縮升級包。

如果格式不相同，則說明芯片不能夠?qū)ζ溥M(jìn)行讀取，因此智能設(shè)備必須要先將其解壓為原始升級文件，并重新將原始升級文件壓縮為芯片能夠讀取的壓縮升級包。

在本申請的優(yōu)選實施例中，壓縮升級包由多個壓縮數(shù)據(jù)段組成，并且每個壓縮數(shù)據(jù)段均是采用無損數(shù)據(jù)壓縮的方法壓縮得到的。采用多個壓縮數(shù)據(jù)段是因為考慮到芯片的內(nèi)存有限，不能一次性的將整個壓縮包讀取，因此將壓縮升級包分為多個壓縮數(shù)據(jù)段，并且芯片在解壓時每次只讀取一段，從而降低了解壓過程中的內(nèi)存占用。相應(yīng)的，智能設(shè)備對原始升級文件的壓縮過程如下：

(1)在原始升級文件中讀取長度為預(yù)設(shè)長度的數(shù)據(jù)。

預(yù)設(shè)長度的大小可以根據(jù)芯片的內(nèi)存大小來確定，確定的原則是必須的保證芯片內(nèi)存能夠完成對該預(yù)設(shè)長度數(shù)據(jù)的讀取，進(jìn)而保證芯片能夠完成解壓的過程。

(2)對讀取出來的數(shù)據(jù)進(jìn)行數(shù)據(jù)壓縮得到壓縮數(shù)據(jù)段。

對讀取出來的數(shù)據(jù)進(jìn)行無損數(shù)據(jù)壓縮，一方面降低了數(shù)據(jù)內(nèi)存的占用，另一方面保證了數(shù)據(jù)的格式不發(fā)生改變，從而芯片能夠?qū)ζ溥M(jìn)行讀取。

(3)在壓縮數(shù)據(jù)段的前面添加指示標(biāo)記。

芯片在對壓縮數(shù)據(jù)段進(jìn)行讀取之前，首先得獲取壓縮數(shù)據(jù)段的長度，因此，在本申請的優(yōu)選實施例中，在壓縮數(shù)據(jù)段的前面添加指示標(biāo)記，上述指示標(biāo)記用于指出所述壓縮數(shù)據(jù)段的長度值。在解壓的過程中，芯片首先讀取指示標(biāo)記，以獲取壓縮數(shù)據(jù)段的數(shù)據(jù)長度，之后根據(jù)數(shù)據(jù)長度相應(yīng)的讀取壓縮數(shù)據(jù)段，并對其進(jìn)行解壓操作。

(4)判斷是否完成對原始升級文件的壓縮。

在每完成一段數(shù)據(jù)的壓縮后，都需要判斷是否完成對原始升級文件的壓縮，以便繼續(xù)下面的過程。

(5)若已經(jīng)完成對原始升級文件的壓縮，則結(jié)束壓縮過程。

如果完成了對原始升級文件的壓縮，則表示該段數(shù)據(jù)是最后一段數(shù)據(jù)，因此結(jié)束壓縮的過程。

(6)若未完成對原始升級文件的壓縮，則在原始升級文件中繼續(xù)讀取長度為預(yù)設(shè)長度的數(shù)據(jù)。

如果未完成對原始升級文件的壓縮，則表示還有數(shù)據(jù)需要壓縮，因此需要繼續(xù)讀取原始升級文件中為壓縮的數(shù)據(jù)，并對其進(jìn)行壓縮。

通過上述的流程能夠在減小升級包大小的同時，保證藍(lán)牙芯片能夠?qū)ι壈M(jìn)行讀取以及解壓。

在本申請的優(yōu)選實施例中，藍(lán)牙芯片內(nèi)的Flash儲存器內(nèi)有程序啟動分區(qū)和儲存分區(qū)。因為芯片在升級的過程中需要將程序啟動分區(qū)清空，因此必須要將升級包與儲存在儲存分區(qū)，以便完成OTA升級過程。

當(dāng)藍(lán)牙芯片需要升級時，需要接收升級壓縮包，并且將其儲存到Flash儲存器的儲存分區(qū)中。

S102，對壓縮升級包進(jìn)行解壓并將解壓后的數(shù)據(jù)寫入程序啟動分區(qū)。

在本申請的優(yōu)選實施例中，在接收了壓縮升級包之后需要對壓縮升級包進(jìn)行校驗。校驗的目的是為了驗證壓縮升級包的完整性，以保證能夠完成芯片的OTA升級過程，常用的校驗方法有CRC校驗等。

在校驗完畢，確認(rèn)壓縮升級包沒有問題之后，對壓縮升級包進(jìn)行解壓，并將解壓得到的數(shù)據(jù)燒寫到Flash儲存器的程序啟動分區(qū)。

由于藍(lán)牙SoC芯片的內(nèi)存有限，因此為了能夠降低藍(lán)牙芯片在解壓時候的負(fù)載，在本申請的優(yōu)選實施例中，對壓縮升級包采用分段解壓的方法。

在本申請的優(yōu)選實施例中，藍(lán)牙芯片逐一的對每一個壓縮數(shù)據(jù)段進(jìn)行解壓，并且將解壓出來的數(shù)據(jù)存入Flash儲存器的程序啟動分區(qū)。

上述解壓過程可以通過以下步驟實現(xiàn)：

(1)讀取壓縮數(shù)據(jù)段前面的指示標(biāo)記。

在解壓之前，藍(lán)牙芯片并不知道每一個壓縮數(shù)據(jù)段的數(shù)據(jù)長度，因此在對壓縮數(shù)據(jù)段進(jìn)行讀取之前，首先讀取壓縮數(shù)據(jù)段之前的指示標(biāo)記，以獲取壓縮數(shù)據(jù)段的數(shù)據(jù)長度值。

(2)根據(jù)所述指示標(biāo)記獲取將要解壓的壓縮數(shù)據(jù)段的數(shù)據(jù)長度值。

芯片通過解析指示標(biāo)記的內(nèi)容，獲取將要讀取的壓縮數(shù)據(jù)段的數(shù)據(jù)長度值。

(3)根據(jù)獲取的數(shù)據(jù)長度值在所述壓縮升級包讀取壓縮數(shù)據(jù)段；

在獲取了壓縮數(shù)據(jù)段的數(shù)據(jù)長度值之后，芯片在原始升級文件讀取相應(yīng)長度的壓縮數(shù)據(jù)段。采用在每個壓縮數(shù)據(jù)段前面添加指示標(biāo)記的方法，可以使芯片能夠準(zhǔn)確的對壓縮數(shù)據(jù)段進(jìn)行讀取。

(4)對讀取到的所述壓縮數(shù)據(jù)段進(jìn)行解壓處理。

芯片在讀取了壓縮數(shù)據(jù)段之后，對其進(jìn)行解壓的處理，并且相應(yīng)的將解壓出來的數(shù)據(jù)寫入Flash儲存器的程序運(yùn)行分區(qū)。

需要說明的是，上述對壓縮數(shù)據(jù)段解壓的過程是持續(xù)重復(fù)進(jìn)行的，直到對整個壓縮升級包解壓完成后才停止。

(5)判斷是否已經(jīng)完成對所述壓縮升級包的解壓；

在每次解壓完一段壓縮數(shù)據(jù)段之后，需要判斷是否已經(jīng)完成了對壓縮升級包的解壓過程。

(6)若已經(jīng)完成對所述壓縮升級包的解壓，則結(jié)束解壓過程；

(7)若未完成對所述壓縮升級包的解壓，則繼續(xù)讀取所述指示標(biāo)記。

如果未完成，則需要繼續(xù)解壓。

通過上述分段對壓縮升級包解壓的方法，可以有效的降低壓縮升級包在解壓過程中的內(nèi)存消耗，減少了壓縮升級包的解壓負(fù)載。

S103,重新啟動藍(lán)牙芯片進(jìn)行升級。

在本申請的優(yōu)選實施例中，藍(lán)牙芯片對壓縮升級包的解壓過程是以壓縮數(shù)據(jù)段為單位逐一進(jìn)行的。在完成對所有的壓縮數(shù)據(jù)段解壓后，需要重新啟動藍(lán)牙芯片，以完成藍(lán)牙芯片的OTA升級過程。

為了更好的對本申請優(yōu)選實施例中提到的對升級包的壓縮與解壓過程，如圖2所示為本申請藍(lán)牙芯片在OTA升級過程中升級包的變化示意圖。由圖可見，原始升級文件在未經(jīng)壓縮之前是由很多的原始數(shù)據(jù)段組成的；之后，對原始升級文件中的每一個原始數(shù)據(jù)段進(jìn)行無損壓縮之后，得到相應(yīng)的壓縮數(shù)據(jù)段，并在每個壓縮數(shù)據(jù)段前面添加指示標(biāo)記；在解壓時，逐一的對各壓縮數(shù)據(jù)段進(jìn)行解壓后得到解壓后的原始升級文件。由于采用無損數(shù)據(jù)壓縮的方法不會給壓縮數(shù)據(jù)帶來任何的失真，因此解壓后的升級包是和原始升級文件是完全一樣的，這保證了升級包數(shù)據(jù)的完整性，從而保證了藍(lán)牙芯片在OTA升級過程中系統(tǒng)的穩(wěn)定性。

通過以上步驟的描述可知，通過本申請的技術(shù)方案，藍(lán)牙芯片首先接收壓縮升級包并且將所述壓縮升級包儲存到所述儲存分區(qū)。壓縮升級包由原始升級文件經(jīng)過數(shù)據(jù)壓縮并且保持格式不變后得到的，并且為可執(zhí)行文件，因此藍(lán)牙芯片能夠直接對其進(jìn)行讀取。之后藍(lán)牙芯片對壓縮升級包進(jìn)行解壓，并將解壓出來的數(shù)據(jù)寫入所述程序啟動分區(qū)。在完成對壓縮升級包的解壓時，重新啟動藍(lán)牙芯片以完成OTA升級的過程。在本申請方案中，在對原始壓縮文件進(jìn)行數(shù)據(jù)壓縮的過程不會引起任何的數(shù)據(jù)失真，因此保證了升級過程中系統(tǒng)的穩(wěn)定性。并且，由于對原始升級文件進(jìn)行了壓縮，因此可以極大的減小儲存升級包所用的Flash空間。綜上，通過本申請的方案在小Flash容量下實現(xiàn)藍(lán)牙芯片OTA升級功能的同時，降低了藍(lán)牙芯片的成本。進(jìn)一步的，本申請的方案還能夠保證升級過程中系統(tǒng)的穩(wěn)定性。

為了進(jìn)一步闡述本發(fā)明的技術(shù)思想，現(xiàn)結(jié)合具體的應(yīng)用場景，對本發(fā)明的技術(shù)方案進(jìn)行說明。

如圖3所示為本申請在具體應(yīng)用場景中各設(shè)備的交互示意圖，由圖可知本申請應(yīng)用于包括PC平臺，云服務(wù)器、智能設(shè)備、藍(lán)牙設(shè)備的系統(tǒng)中。各設(shè)備的作用如下：

PC平臺，負(fù)責(zé)對OTA升級包進(jìn)行無損壓縮；

云服務(wù)器，負(fù)責(zé)儲存PC平臺上傳的OTA升級包；

智能設(shè)備，負(fù)責(zé)從云服務(wù)器下載OTA升級包，以及將OTA升級包發(fā)送給藍(lán)牙設(shè)備；

藍(lán)牙設(shè)備，接收OTA升級包，并完成OTA升級過程。

如圖4所示，為本申請在具體的應(yīng)用場景中的流程示意圖。

該具體流程包括以下步驟：

S401，對OTA升級包進(jìn)行無損壓縮。

S402，將壓縮后的OTA升級包發(fā)布至服務(wù)器。

S403，智能電視、智能手機(jī)、平板電腦對OTA升級包進(jìn)行檢測是否需要更新，若是,則轉(zhuǎn)到S404，否則，轉(zhuǎn)到S405；

S404，將OTA升級包下載到本地設(shè)備上；

S405，不進(jìn)行下載；

S406，智能電視、手機(jī)或平板電腦與藍(lán)牙設(shè)備建立連接；

S407，讀取藍(lán)牙設(shè)備固件版本號，與本地OTA升級包版本號繼續(xù)對比，看是否需要升級；

S408，智能電視、手機(jī)、平板電腦與藍(lán)牙設(shè)備將本地存儲的OTA升級包發(fā)送給藍(lán)牙設(shè)備；

S409，藍(lán)牙設(shè)備對接受到的OTA升級包進(jìn)行CRC校驗，若校驗成功，則轉(zhuǎn)到S410，若校驗失敗，則轉(zhuǎn)到S408；

S410，藍(lán)牙設(shè)備對OTA升級包進(jìn)行解壓縮，恢復(fù)原始OTA升級包，燒寫至正常啟動區(qū)；

S411，通知智能電視、手機(jī)、平板電腦等設(shè)備，升級失??；

S412，重啟藍(lán)牙設(shè)備，完成升級；

為了進(jìn)一步的對本申請的發(fā)明進(jìn)行說明，如圖5所示為本申請?zhí)岢龅囊环N原始升級文件的壓縮過程。

該過程包括以下步驟：

S501，讀取固定長度原始OTA升級包數(shù)據(jù)；

S502，對讀取到的數(shù)據(jù)進(jìn)行無損壓縮；

S503，將壓縮后的數(shù)據(jù)添加長度為9bytes的head然后寫入文件；

在該具體的流程中，標(biāo)記文件為長度為9bytes的head。

S504，判斷是否壓縮完整個原始OTA升級包，若是，轉(zhuǎn)到S505；若否，轉(zhuǎn)到S501

S505，結(jié)束壓縮過程。

為了進(jìn)一步的對本申請的發(fā)明進(jìn)行說明，如圖6所示為本申請?zhí)岢龅囊环N原始數(shù)據(jù)壓縮包的解壓縮過程。

該過程包括以下步驟：

S601首先讀取長度為9bytes的head數(shù)據(jù)，通過head數(shù)據(jù)確定有所數(shù)據(jù)的長度；

在該具體的流程中，標(biāo)記文件為長度為9bytes的head。

S602，根據(jù)獲取的壓縮數(shù)據(jù)長度讀取相應(yīng)的壓縮數(shù)據(jù)；

S603，對讀取的壓縮數(shù)據(jù)進(jìn)行解壓處理，將解壓后的數(shù)據(jù)寫入flash；

S604，判斷是否解壓完整個OTA升級包，若是，轉(zhuǎn)到S605；否，轉(zhuǎn)到S601；

S605，結(jié)束解壓過程。

通過以上對具體應(yīng)用場景的描述可知，通過本申請的技術(shù)方案，藍(lán)牙芯片首先接收壓縮升級包并且將所述壓縮升級包儲存到所述儲存分區(qū)。壓縮升級包由原始升級文件經(jīng)過數(shù)據(jù)壓縮并且保持格式不變后得到的，并且為可執(zhí)行文件，因此藍(lán)牙芯片能夠直接對其進(jìn)行讀取。之后藍(lán)牙芯片對壓縮升級包進(jìn)行解壓，并將解壓出來的數(shù)據(jù)寫入所述程序啟動分區(qū)。在完成對壓縮升級包的解壓時，重新啟動藍(lán)牙芯片以完成OTA升級的過程。在本申請方案中，在對原始壓縮文件進(jìn)行數(shù)據(jù)壓縮的過程不會引起任何的數(shù)據(jù)失真，因此保證了升級過程中系統(tǒng)的穩(wěn)定性。并且，由于對原始升級文件進(jìn)行了壓縮，因此可以極大的減小儲存升級包所用的Flash空間。綜上，通過本申請的方案在小Flash容量下實現(xiàn)藍(lán)牙芯片OTA升級功能的同時，降低了藍(lán)牙芯片的成本。進(jìn)一步的，本申請的方案還能夠保證升級過程中系統(tǒng)的穩(wěn)定性。

為了達(dá)到以上技術(shù)目的，本申請還提出了一種藍(lán)牙芯片，藍(lán)牙芯片內(nèi)的Flash儲存器內(nèi)有程序啟動分區(qū)和儲存分區(qū)如圖6所示，所述藍(lán)牙芯片還包括：

接收模塊701，通過藍(lán)牙通道接收智能設(shè)備發(fā)送的壓縮升級包并且將所述壓縮升級包儲存到所述儲存分區(qū)，所述壓縮升級包是由原始升級文件經(jīng)過數(shù)據(jù)壓縮并且保持格式不變后得到的，所述壓縮升級包為可執(zhí)行文件；

解壓模塊702，對所述壓縮升級包進(jìn)行解壓并將解壓后的數(shù)據(jù)寫入所述程序啟動分區(qū)；

運(yùn)行模塊703，重新啟動所述藍(lán)牙芯片進(jìn)行升級。

在具體的應(yīng)用場景中，所述壓縮升級包的生成過程如下：

接收初始壓縮升級包；

判斷所述初始壓縮升級包的格式是否與所述原始升級文件的格式相同；

若相同，則確認(rèn)所述初始壓縮升級包為所述壓縮升級包；若不相同，則將所述初始壓縮升級包解壓為所述原始升級文件，在保持文件格式不變的基礎(chǔ)上對所述原始升級文件進(jìn)行數(shù)據(jù)壓縮，并將經(jīng)過數(shù)據(jù)壓縮后的所述原始升級文件確認(rèn)為所述壓縮升級包。

在具體的應(yīng)用場景中，所述對所述原始升級文件進(jìn)行數(shù)據(jù)壓縮，具體為：

在所述原始升級文件中讀取長度為預(yù)設(shè)長度的數(shù)據(jù)；

對所述數(shù)據(jù)進(jìn)行數(shù)據(jù)壓縮后得到壓縮數(shù)據(jù)段；

在所述壓縮數(shù)據(jù)段的前面添加指示標(biāo)記；所述指示標(biāo)記用于指出所述壓縮數(shù)據(jù)段的長度值；

判斷是否完成對原始升級文件的壓縮；

若已經(jīng)完成對原始升級文件的壓縮，則結(jié)束壓縮過程；

若未完成對原始升級文件的壓縮，則在原始升級文件中繼續(xù)讀取長度為預(yù)設(shè)長度的數(shù)據(jù)。

在具體的應(yīng)用場景中，所述解壓模塊具體用于：

讀取所述指示標(biāo)記；

根據(jù)所述指示標(biāo)記獲取所述壓縮數(shù)據(jù)段的長度值；

根據(jù)所述長度值在所述壓縮升級包讀取所述壓縮數(shù)據(jù)段；

對讀取到的所述壓縮數(shù)據(jù)段進(jìn)行解壓處理；

判斷是否已經(jīng)完成對所述壓縮升級包的解壓；

若已經(jīng)完成對所述壓縮升級包的解壓，則結(jié)束解壓過程；

若未完成對所述壓縮升級包的解壓，則繼續(xù)讀取所述指示標(biāo)記。

在具體的應(yīng)用場景中，還包括：

校驗?zāi)K，對所述壓縮升級包進(jìn)行校驗，并且在校驗失敗時重新接收所述壓縮升級包。

通過以上描述可以知道，通過本申請的技術(shù)方案，藍(lán)牙芯片首先接收壓縮升級包并且將所述壓縮升級包儲存到所述儲存分區(qū)。壓縮升級包由原始升級文件經(jīng)過數(shù)據(jù)壓縮并且保持格式不變后得到的，并且為可執(zhí)行文件，因此藍(lán)牙芯片能夠直接對其進(jìn)行讀取。之后藍(lán)牙芯片對壓縮升級包進(jìn)行解壓，并將解壓出來的數(shù)據(jù)寫入所述程序啟動分區(qū)。在完成對壓縮升級包的解壓時，重新啟動藍(lán)牙芯片以完成OTA升級的過程。在本申請方案中，在對原始壓縮文件進(jìn)行數(shù)據(jù)壓縮的過程不會引起任何的數(shù)據(jù)失真，因此保證了升級過程中系統(tǒng)的穩(wěn)定性。并且，由于對原始升級文件進(jìn)行了壓縮，因此可以極大的減小儲存升級包所用的Flash空間。綜上，通過本申請的方案在小Flash容量下實現(xiàn)藍(lán)牙芯片OTA升級功能的同時，降低了藍(lán)牙芯片的成本。進(jìn)一步的，本申請的方案還能夠保證升級過程中系統(tǒng)的穩(wěn)定性。

通過以上的實施方式的描述，本領(lǐng)域的技術(shù)人員可以清楚地了解到本發(fā)明可以通過硬件實現(xiàn)，也可以借助軟件加必要的通用硬件平臺的方式來實現(xiàn)?；谶@樣的理解，本發(fā)明的技術(shù)方案可以以軟件產(chǎn)品的形式體現(xiàn)出來，該軟件產(chǎn)品可以存儲在一個非易失性存儲介質(zhì)(可以是CD-ROM，U盤，移動硬盤等)中，包括若干指令用以使得一臺計算機(jī)設(shè)備(可以是個人計算機(jī)，服務(wù)器，或者網(wǎng)絡(luò)設(shè)備等)執(zhí)行本發(fā)明各個實施場景所述的方法。

本領(lǐng)域技術(shù)人員可以理解附圖只是一個優(yōu)選實施場景的示意圖，附圖中的模塊或流程并不一定是實施本發(fā)明所必須的。

本領(lǐng)域技術(shù)人員可以理解實施場景中的裝置中的模塊可以按照實施場景描述進(jìn)行分布于實施場景的裝置中，也可以進(jìn)行相應(yīng)變化位于不同于本實施場景的一個或多個裝置中。上述實施場景的模塊可以合并為一個模塊，也可以進(jìn)一步拆分成多個子模塊。

上述本發(fā)明序號僅僅為了描述，不代表實施場景的優(yōu)劣。

以上公開的僅為本發(fā)明的幾個具體實施場景，但是，本發(fā)明并非局限于此，任何本領(lǐng)域的技術(shù)人員能思之的變化都應(yīng)落入本發(fā)明的保護(hù)范圍。