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

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

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

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

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

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

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

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