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

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

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

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

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

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

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

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