當前的Android手機設(shè)計中通常將應用子系統(tǒng)(AP)和通信子系統(tǒng)(CP)分離。比較典型的情況是應用子系統(tǒng)運行Android操作系統(tǒng)，通信子系統(tǒng)運行Nucleus操作系統(tǒng)，兩者相對獨立，通過一定的接口進行通信[1]。

    在手機運行過程中，通信子系統(tǒng)(即基帶子系統(tǒng)(CP))會產(chǎn)生一些需要動態(tài)更新的數(shù)據(jù)，譬如手機系統(tǒng)數(shù)據(jù)、TD參數(shù)、GSM參數(shù)、音頻校準數(shù)據(jù)等[2-3]。每臺手機的這些數(shù)據(jù)都不盡相同。一般這些數(shù)據(jù)通過非失憶性介質(zhì)(即NV(NonVolatile)模塊)來進行保存和管理。因此，需要設(shè)計一種機制將CP側(cè)的NV數(shù)據(jù)保存下來，以供基帶子系統(tǒng)啟動或運行時使用。
    本文設(shè)計了一種雙硬件處理器環(huán)境下將基帶NV數(shù)據(jù)保存到手機文件系統(tǒng)（Flash）中的方案。其中，基帶系統(tǒng)運行在ARM9核心的單核CP芯片上，應用系統(tǒng)運行在Cortex A9核心的四核AP芯片上。兩者通過IIC機制進行通信和數(shù)據(jù)共享。本文的設(shè)計主要包括AP側(cè)軟件模塊設(shè)計、CP側(cè)NV數(shù)據(jù)發(fā)送流程設(shè)計以及IIC通信機制設(shè)計。
    在實際的手機產(chǎn)品中應用本文的設(shè)計，進行大數(shù)據(jù)量、長時間基帶NV數(shù)據(jù)保存測試，并進行可靠性分析，得到了良好的實驗結(jié)果，證明了本設(shè)計的可靠性和可行性。
1 系統(tǒng)方案設(shè)計
1.1 系統(tǒng)總體框架設(shè)計
    基帶NV數(shù)據(jù)保存方案包括AP側(cè)軟件模塊、CP側(cè)數(shù)據(jù)發(fā)送流程以及IIC通信機制三個方面，如圖1所示。

    其中，CP側(cè)主要由NV數(shù)據(jù)產(chǎn)生模塊(NVM Process)和CP側(cè)IIC驅(qū)動組成；AP側(cè)主要由數(shù)據(jù)接收模塊(NVM Driver)、NV數(shù)據(jù)守護進程(NVM Daemon)和AP側(cè)IIC驅(qū)動組成。
    在CP側(cè)，Nucleus操作系統(tǒng)的NV數(shù)據(jù)進程(NVM Process)負責產(chǎn)生基帶的NV數(shù)據(jù)，經(jīng)過設(shè)備抽象層(DAI)轉(zhuǎn)發(fā)后，基帶NV數(shù)據(jù)被CP側(cè)IIC驅(qū)動寫入IIC緩存Buffer中。
    在AP側(cè)，對應的IIC驅(qū)動將從IIC緩存Buffer中讀取到的NV數(shù)據(jù)上報給AP側(cè)數(shù)據(jù)接收進程(NVM Driver)。最后，AP側(cè)NVM守護進程收到數(shù)據(jù)接收進程上報的數(shù)據(jù)，進行數(shù)據(jù)包的解析，并將其保存在Flash設(shè)備中。
    IIC通信機制包括物理上的IIC連接(IIC TX、RX、CTS、RTS)和公共的函數(shù)接口(API)，AP側(cè)和CP側(cè)IIC驅(qū)動通過調(diào)用這些API即可完成相互通信和數(shù)據(jù)傳輸，從而達到兩個系統(tǒng)命令和數(shù)據(jù)交互的目的。
1.2 AP側(cè)軟件模塊設(shè)計
1.2.1 AP側(cè)數(shù)據(jù)接收流程
    NV數(shù)據(jù)采用包的形式，數(shù)據(jù)包的解析由守護進程NVM Daemon來完成。因此底層的驅(qū)動程序NVM Driver和IIC Driver不關(guān)心數(shù)據(jù)的具體格式，只關(guān)注數(shù)據(jù)的接收和傳送過程[4]。如圖2所示，AP側(cè)數(shù)據(jù)接收流程如下：

    (1)NVM Daemon程序啟動成功之后，首先打開NVM驅(qū)動設(shè)備，若打開成功，則返回設(shè)備號，否則打印錯誤信息并退出。
    (2)NVM Daemon通過read系統(tǒng)調(diào)用從NVM Driver獲取更新后的NV數(shù)據(jù)。NVM Driver從IIC通道讀取基帶更新數(shù)據(jù)時，會首先判斷通道中是否有可讀數(shù)據(jù)，如果沒有，則進程進入睡眠，等待喚醒條件到來，喚醒條件為通道中有可讀數(shù)據(jù)；如通道中有可讀數(shù)據(jù)，則直接讀取，并將數(shù)據(jù)送往NVM Daemon。CP側(cè)不定時更新數(shù)據(jù)，并將數(shù)據(jù)送往IIC通道。
    (3)從內(nèi)核空間得到的基帶數(shù)據(jù)是以包的形式封裝的，所以接下來NVM Daemon要做的工作就是解析包頭，從包中取出有效數(shù)據(jù)，并且進行NV數(shù)據(jù)的保存工作，這一步很重要，將在下節(jié)詳細介紹。
    (4)NVM Daemon將NV數(shù)據(jù)完整地保存到文件系統(tǒng)后，發(fā)送應答ACK包通知CP側(cè)數(shù)據(jù)保存完成。如果在收包過程中出現(xiàn)異常，則發(fā)送ACK包通知CP側(cè)重傳。
1.2.2 AP側(cè)數(shù)據(jù)保存機制
    NV數(shù)據(jù)以包的形式發(fā)送，不同NV數(shù)據(jù)的數(shù)據(jù)包可能交錯發(fā)送，NVM Daemon應能夠正確組包，正確地將NV數(shù)據(jù)保存到文件系統(tǒng)中。NV數(shù)據(jù)包格式結(jié)構(gòu)體的定義為：
    typedef struct _pkginfo{
        u8 head;        //包頭首部
        u8 type；   
//當前包的NV數(shù)據(jù)類型
        u8 cur_id;   
//當前傳輸?shù)臄?shù)據(jù)包id
        u8 total_id；  //總數(shù)據(jù)包個數(shù)id
        u32 data_len；//當前包傳輸?shù)挠行?shù)據(jù)字節(jié)長度
    }pkginfo;
    同時，為了響應AP和CP間的數(shù)據(jù)收發(fā)動作，需要發(fā)送ACK包，ACK包格式結(jié)構(gòu)體定義為：
    typedef struct _ackinfo{
        u8 head;  //包頭首部字段
        u8 type； //數(shù)據(jù)類型
        u8 result；//當前包傳輸結(jié)果
        u8 tail； //包尾字段
    }ackinfo;
    ackinfo結(jié)構(gòu)體成員result表示當前包傳輸結(jié)果，返回0表示接收正確，返回1表示接收錯誤，要求CP側(cè)重傳。
    NVM Daemon對NV數(shù)據(jù)的保存過程如圖3所示，以動態(tài)NV數(shù)據(jù)(nv_dynamic)為例，簡述如下：
    (1)Daemon程序啟動后首先初始化全局變量n，用來統(tǒng)計本次接收過程中總共接收了多少個nv_dynamic類型的NV數(shù)據(jù)包。

    (2)進入read系統(tǒng)調(diào)用，收到數(shù)據(jù)后，首先解析包頭數(shù)據(jù)，獲取數(shù)據(jù)類型、總包數(shù)、當前包數(shù)、有效數(shù)據(jù)長度等，并將這些信息保存到包格式pkginfo結(jié)構(gòu)體中。
    (3)打開nv_dynamic.bin文件，將變量n的值加1；判斷是否n>pkginfo->total_id，若大于，則表明接收到的包數(shù)已經(jīng)超過了本次傳輸?shù)目偘鼣?shù)，為異常情況，打印相關(guān)的異常信息并且退出，重新調(diào)用read讀取數(shù)據(jù)包，否則繼續(xù)。
    (4)判斷是否n=pkginfo->cur_id，如果不等，則說明此時得到的NV數(shù)據(jù)不是按正常順序發(fā)送到AP端的，此時發(fā)送ACK包給CP，要求重傳。
    (5)若n=pkginfo->cur_id，接著判斷是否n=pkginfo->total_id，如果不等，則直接將NV數(shù)據(jù)保存到nv_dynamic.bin中，然后進行下一個數(shù)據(jù)包的接收。
    (6)如果n=pkginfo->total_id，則說明此次接收的是整個傳輸?shù)淖詈笠粋€包，將NV數(shù)據(jù)保存到nv_dynamic.bin文件。然后發(fā)送ACK包通知CP整個數(shù)據(jù)接收完成。將n清0，關(guān)閉nv_dynamic.bin文件后退出。
    通過上述流程，可以有效解決NV數(shù)據(jù)發(fā)送過程中的包序錯亂、發(fā)包重復等問題，保證NV數(shù)據(jù)的有效保存。
1.3 CP側(cè)NV數(shù)據(jù)發(fā)送流程
    CP側(cè)負責NV數(shù)據(jù)的產(chǎn)生和發(fā)送工作。CP側(cè)NV數(shù)據(jù)發(fā)送具體流程如下：
      (1)內(nèi)部定時器每20 ms判斷基帶NV數(shù)據(jù)是否有更新。
      (2)若NV數(shù)據(jù)有更新，且長度滿足發(fā)送條件，則進行包頭封裝，完成組包工作，不滿足則退出。
      (3)NV數(shù)據(jù)組包完成后，平臺無關(guān)化接口函數(shù)DAI_NV_SEND()調(diào)用CP側(cè)IIC驅(qū)動發(fā)送長度為L的NV數(shù)據(jù)。
      (4)DAI_NV_SEND()函數(shù)調(diào)用完成后返回數(shù)據(jù)發(fā)送結(jié)果retVal。
      (5)判斷retVal是否等于應發(fā)送長度L，若是則更新緩存Buffer數(shù)據(jù)索引后結(jié)束，不是則直接結(jié)束。
2 擴展的IIC通信機制設(shè)計
      IIC通信機制建立在普通IIC通信機制之上，除了一般的IIC數(shù)據(jù)收發(fā)功能外，還擴展了通道注冊、通道對象管理、通道中斷處理等功能。
      IIC通信機制為AP與CP間的NV數(shù)據(jù)驅(qū)動提供通信和數(shù)據(jù)傳送功能，起到了一個橋梁的作用。其結(jié)構(gòu)設(shè)計如圖4所示。

    硬件連接與通用IIC通信協(xié)議相同，在AP和CP側(cè)有對等的IIC驅(qū)動模塊。二者有相同的數(shù)據(jù)結(jié)構(gòu)和循環(huán)數(shù)據(jù)緩沖區(qū)管理接口。
    對于外部接口、內(nèi)部接口，通道對象管理和中斷ISR服務等，AP和CP側(cè)需要分別實現(xiàn)。AP和CP外部API接口相同，但具體實現(xiàn)不同。
    IIC通信機制提供給AP和CP的外部API包括：創(chuàng)建數(shù)據(jù)通道(iic_create_ch)、讀通道數(shù)據(jù)(iic_read_ch)、寫通道數(shù)據(jù)(iic_write_ch)、注冊通道中斷(iic_register_inthandle)、通道使能(iic_enable_inthandle)等。
3 系統(tǒng)功能測試與結(jié)果分析
    系統(tǒng)功能的測試主要包括兩個測試點：(1)數(shù)據(jù)通路是否暢通；(2)NVM Daemon保存的NV數(shù)據(jù)是否完整有效。
    針對測試點(1)可以在各個數(shù)據(jù)通路之間采取假數(shù)據(jù)發(fā)送的方式進行測試，例如，在AP側(cè)IIC Driver中用假數(shù)代替從基帶獲取的NV數(shù)據(jù)送往NVM Driver中，測試兩者間通路是否暢通。
    針對測試點(2)將假數(shù)據(jù)以包的形式發(fā)送，分多種類型，分開不按順序發(fā)送，測試NVM Daemon的組包能力。
    在進行數(shù)據(jù)通路測試的同時，使用一定壓力的基帶業(yè)務，以測試系統(tǒng)的抗壓能力[5]。具體測試場景設(shè)計如表1所示。

    重復以上測試場景多次后，將AP側(cè)保存的NV數(shù)據(jù)導出到PC上觀察可知，保存的NV數(shù)據(jù)正確，也沒有出現(xiàn)數(shù)據(jù)包丟失和錯亂的情況，符合系統(tǒng)設(shè)計的目標，如圖5所示。

    本文提出的基帶NV數(shù)據(jù)保存功能模塊已經(jīng)在基于Linux 2.6.32內(nèi)核的Android 4.1定制版本上實現(xiàn)。
    在AP和CP側(cè)通信機制設(shè)計中采用了擴展功能的IIC機制，使AP與CP兩個獨立系統(tǒng)的通信和數(shù)據(jù)交換十分方便。同時，在AP側(cè)的NV驅(qū)動中使用了中斷喚醒的技術(shù)，在沒有數(shù)據(jù)傳送時，整個數(shù)據(jù)通道處于睡眠狀態(tài)，有效地節(jié)省了系統(tǒng)資源開銷。最后，AP側(cè)的NVM Daemon在組包過程中考慮到了數(shù)據(jù)包錯亂、重復等異常情況，并設(shè)計了相應的容錯機制。既可保證數(shù)據(jù)的完整有效性，也能滿足實際項目的需求。
    本方案已經(jīng)被應用于國家重大專項“TD-SCDMA增強型多媒體手機終端的研發(fā)和產(chǎn)業(yè)化”中。
參考文獻
[1] 王海霞.TD/GSM雙模手機軟件架構(gòu)的研究與實現(xiàn)[D]. 南京：南京郵電大學，2010.
[2] 朱亞洲.GSM手機軟件開發(fā)[D].武漢：武漢科技大學，2007.
[3] 周非，亓英杰，劉永康，等.TD-SCDMA終端探測設(shè)的DSP設(shè)計與實現(xiàn)[J].電子技術(shù)應用，2012，38(4)：16-19.
[4] 孟小華，黃宗軒.Android系統(tǒng)非標準設(shè)備驅(qū)動程序設(shè)計[J].微型機與應用，2011，30(14)：7-9.
[5] 李志丹.嵌入式軟件調(diào)試方法研究[J].計算機與數(shù)字工程，2012(7)：157-159.