Android手機(jī)中基帶跟蹤數(shù)據(jù)的導(dǎo)出功能設(shè)計(jì)＊

黃一峰，黃俊偉，吳戀

（重慶郵電大學(xué) 新一代寬帶移動(dòng)通信終端研究所，重慶400065）

引 言

在目前流行的Android手機(jī)設(shè)計(jì)方案中，應(yīng)用處理器（AP）和通信處理器（CP）因?yàn)閷θ蝿?wù)實(shí)時(shí)性的要求不同而相對獨(dú)立。典型地，AP和CP子系統(tǒng)分別運(yùn)行手機(jī)系統(tǒng)的應(yīng)用操作系統(tǒng)（Android）和基帶操作系統(tǒng)（Nucleus）［1］。

在手機(jī)開發(fā)過程中，大部分的功能調(diào)試通過AP側(cè)來完成。因此，將CP側(cè)的基帶跟蹤數(shù)據(jù)導(dǎo)出到AP側(cè)進(jìn)行保存和分析，對于手機(jī)開發(fā)過程中的功能調(diào)試和Bug修復(fù)都具有非常重要的意義［2－3］。

本文設(shè)計(jì)了一種雙硬件芯片環(huán)境下的基帶跟蹤數(shù)據(jù)的導(dǎo)出方案。其中，基帶系統(tǒng)運(yùn)行在重郵信科公司C6310雙模（TD－SCDMA＋GSM）CP芯片上，應(yīng)用系統(tǒng)運(yùn)行在三星Exynos 4412四核AP芯片上。兩者通過串口機(jī)制進(jìn)行通信和數(shù)據(jù)共享。本文的設(shè)計(jì)主要包括AP側(cè)軟件模塊設(shè)計(jì)、CP側(cè)軟件模塊設(shè)計(jì)，以及串口通信機(jī)制設(shè)計(jì)。

在實(shí)際的手機(jī)產(chǎn)品中應(yīng)用本文的設(shè)計(jì)，進(jìn)行大數(shù)據(jù)量、長時(shí)間基帶跟蹤數(shù)據(jù)導(dǎo)出實(shí)驗(yàn)和可靠性分析，得到了良好的實(shí)驗(yàn)結(jié)果，驗(yàn)證了本文設(shè)計(jì)的可行性和可靠性。

1 系統(tǒng)框架設(shè)計(jì)

1.1 系統(tǒng)總體框架設(shè)計(jì)

圖1為基帶跟蹤數(shù)據(jù)導(dǎo)出方案的整體框架。整個(gè)方案包括CP、AP以及串口機(jī)制三個(gè)方面。其中，CP側(cè)主要由跟 蹤 數(shù) 據(jù) 產(chǎn) 生 模 塊 （ARMLOG TRACE、DSPLOG TRACE）和CP側(cè)串口驅(qū)動(dòng)組成；AP側(cè)主要由數(shù)據(jù)接收模塊（ARMLOG Driver、DSPLOG Driver），USB傳輸模塊（USB Gadget Driver）和 AP側(cè)串口驅(qū)動(dòng)組成。

在CP側(cè)，Nucleus操作系統(tǒng)的跟蹤數(shù)據(jù)進(jìn)程（ARM－log trace和DSPlog trace）負(fù)責(zé)產(chǎn)生基帶的跟蹤數(shù)據(jù)，經(jīng)過設(shè)備抽象層（DAI）轉(zhuǎn)發(fā)后，基帶跟蹤數(shù)據(jù)被CP側(cè)串口驅(qū)動(dòng)存入串口緩存Buffer中。

圖1 方案整體框架圖

同時(shí)在AP側(cè)，對應(yīng)的串口驅(qū)動(dòng)將從串口緩存buffer中讀取到的跟蹤數(shù)據(jù)上報(bào)給AP側(cè)數(shù)據(jù)接收進(jìn)程（ARM－LOG Driver和 DSPLOG Driver）。最后，AP側(cè)數(shù)據(jù)接收進(jìn)程調(diào)用 USB傳輸驅(qū)動(dòng)（USB Gadget Driver），將跟蹤數(shù)據(jù)發(fā)送到PC端軟件進(jìn)行顯示或保存。

串口機(jī)制包括物理上的數(shù)據(jù)緩存（Buffer）和公共的函數(shù)接口（API），AP側(cè)和CP側(cè)串口驅(qū)動(dòng)通過調(diào)用這些公共的函數(shù)接口，即可完成相互通信和數(shù)據(jù)傳輸，從而達(dá)到兩個(gè)系統(tǒng)交互的目的。

1.2 AP側(cè)軟件交互流程

圖2為AP與CP側(cè)軟件交互示意圖。基帶跟蹤數(shù)據(jù)采用流數(shù)據(jù)的形式，數(shù)據(jù)的存儲和解析由PC端的Trace軟件完成。因此AP側(cè)不關(guān)心數(shù)據(jù)的具體格式，其關(guān)注點(diǎn)在于數(shù)據(jù)的接收和傳送過程。AP側(cè)軟件流程步驟如下：

① 系統(tǒng)啟動(dòng)以后，AP側(cè)ARMLOG DSPLOG Driver連接USB為向 ARM DSP Gadget Driver發(fā)送數(shù)據(jù)作準(zhǔn)備。首先進(jìn)行相關(guān)的初始化工作，包括緩存的申請、一些全局變量的初始化、設(shè)備的注冊等工作。

② 其后工作主要在ARMLOG DSPLOG Driver中完成。調(diào)用在初始化函數(shù)中調(diào)用的serial＿create＿ch（）函數(shù)，注冊基帶跟蹤功能專用的串口通道。

③ 啟動(dòng)工作隊(duì)列函數(shù)trace＿read＿serial＿work（），準(zhǔn)備向USB數(shù)據(jù)緩沖區(qū)（usb＿fifo）發(fā)送跟蹤數(shù)據(jù)。

④ 在工作隊(duì)列函數(shù)trace＿read＿serial＿work（）中調(diào)用串口通道讀函數(shù)serial＿read＿avail（），獲取串口通道中CP側(cè)發(fā)來的跟蹤數(shù)據(jù)長度r，r表示串口通道中可讀數(shù)據(jù)長度。

⑤ 如果r≠0，表示CP側(cè)發(fā)來數(shù)據(jù)，則繼續(xù)調(diào)用serial＿read（）函數(shù)將通道中的跟蹤數(shù)據(jù)讀取到USB數(shù)據(jù)緩沖區(qū)（usb＿buf）中，ARM／DSP Gadget Driver驅(qū)動(dòng)提供的接口trace＿write（）將緩沖區(qū)中保存的跟蹤數(shù)據(jù)通過USB發(fā)往PC，發(fā)送完成后再調(diào)用trace＿read＿serial＿work（），進(jìn)入下一次數(shù)據(jù)收發(fā)流程；如果r＝0，則說明串口通道中沒有可讀的跟蹤數(shù)據(jù)，此時(shí)調(diào)用休眠等待函數(shù)wait＿interrupt（），使跟蹤進(jìn)程進(jìn)入睡眠等待。進(jìn)程喚醒條件為跟蹤通道中有可讀數(shù)據(jù)，中斷到來后喚醒跟蹤進(jìn)程。

圖2 AP側(cè)和CP側(cè)軟件交互圖

⑥trace＿read＿serial＿work（）工作隊(duì)列調(diào)用時(shí)機(jī)說明：trace＿read＿serial＿work（）首次調(diào)用放在 USB連接tra－ceusb＿connect（）函數(shù)中，當(dāng)系統(tǒng)檢測到有USB插入時(shí)，traceusb＿connect（）函數(shù)即被調(diào)用，當(dāng)一次跟蹤數(shù)據(jù)通過USB完全送出后，跟蹤數(shù)據(jù)發(fā)送完成函數(shù)trace＿write＿complete（）會被執(zhí)行，在該函數(shù)中再次調(diào)用，準(zhǔn)備第二次數(shù)據(jù)的發(fā)送。

1.3 CP側(cè)跟蹤數(shù)據(jù)發(fā)送流程

CP側(cè)負(fù)責(zé)跟蹤數(shù)據(jù)的記錄和發(fā)送工作。CP側(cè)跟蹤數(shù)據(jù)發(fā)送具體流程如下：

① 定時(shí)器每10ms判斷發(fā)送DSP或ARM的跟蹤數(shù)據(jù)。

② 若跟蹤數(shù)據(jù)長度滿足發(fā)送長度條件，則進(jìn)行混合幀頭封裝，不滿足則退出。

③ 通過平臺無關(guān)化調(diào)用DAI＿TRA＿SEND（）函數(shù)發(fā)送L長度的跟蹤數(shù)據(jù)。

④ 函數(shù)調(diào)用完成后返回處理結(jié)果retVal。

⑤判斷retVal是否等于發(fā)送長度L，若是則更新buffer數(shù)據(jù)索引然后結(jié)束，否則直接結(jié)束。

2 串口機(jī)制設(shè)計(jì)

串口機(jī)制為AP和CP間的trace驅(qū)動(dòng)提供通信和數(shù)據(jù)傳送功能，起到了一個(gè)橋梁的作用。其軟件結(jié)構(gòu)設(shè)計(jì)如圖3所示。

圖3 串口機(jī)制軟件結(jié)構(gòu)圖

在AP和CP上有對等的串口驅(qū)動(dòng)模塊。二者有公共的數(shù)據(jù)結(jié)構(gòu)和循環(huán)數(shù)據(jù)緩沖區(qū)管理接口。

串口機(jī)制提供給AP和CP的外部API包括創(chuàng)建數(shù)據(jù)通道（serial＿create＿ch）、讀通道數(shù)據(jù)（serial＿read）、寫通道數(shù)據(jù)（serial＿write）、注冊通道中斷（serial＿register＿inthandle）、通道復(fù)位（serial＿reset）等。

對外部接口的實(shí)現(xiàn)、內(nèi)部接口的實(shí)現(xiàn)、通道對象管理和中斷ISR的實(shí)現(xiàn)等，AP和CP需要分別實(shí)現(xiàn)。AP和CP外部API接口相同，但具體實(shí)現(xiàn)不同。

在調(diào)試中首先采用的是普通串口方式，我們發(fā)現(xiàn)在數(shù)據(jù)通信過程中會頻繁產(chǎn)生中斷，占用系統(tǒng)資源過大；同時(shí)在大數(shù)據(jù)量的跟蹤數(shù)據(jù)導(dǎo)出時(shí)會產(chǎn)生延遲。因此，在AP側(cè)和CP側(cè)同時(shí)采用串口的DMA傳輸方式，可有效地降低資源占用，同時(shí)傳輸效率得以保證。

3 方案驗(yàn)證分析與測試結(jié)果

系統(tǒng)功能的測試主要包括兩個(gè)測試點(diǎn)：

① 數(shù)據(jù)通路是否暢通。包括 Trace USB Gadget Driver與 AP ARMLOG／DSPLOG Driver之間的通路，AP ARMLOG／DSPLOG Driver與 AP Serial Driver之間的通路，AP Serial Driver與 CP Serial Driver之間的通路，CP Serial Driver與CP Trace Module之間的通路。

② 導(dǎo)出的跟蹤數(shù)據(jù)是否完整有效。針對第一個(gè)測試點(diǎn)，可以在各個(gè)數(shù)據(jù)通路之間采取假數(shù)據(jù)上報(bào)的方式進(jìn)行測試，譬如，在AP側(cè)Serial Driver中用假數(shù)代替從基帶獲取的跟蹤數(shù)據(jù)送往 AP ARMLOG／DSPLOG Driver中，測試兩者間通路是否暢通。

針對第二個(gè)測試點(diǎn)，需要在完整的系統(tǒng)平臺上，連續(xù)測試24小時(shí)以上，期間包括基帶數(shù)據(jù)業(yè)務(wù)的使用，以驗(yàn)證整體模塊功能的可行性和可靠性［5］。

具體測試場景設(shè)計(jì)如表1所列。

表1 測試場景列表

多次測試后，通過PC端的Trace導(dǎo)出軟件觀察，保存出來的跟蹤數(shù)據(jù)既沒有重復(fù)顯示歷史跟蹤數(shù)據(jù)，也沒有出現(xiàn)跟蹤數(shù)據(jù)丟失和錯(cuò)亂的情況，有序、準(zhǔn)確無誤地輸出預(yù)想的跟蹤數(shù)據(jù)，如圖4所示。

圖4 導(dǎo)出的基帶數(shù)據(jù)截圖

結(jié) 語

本文所提出的基帶Trace導(dǎo)出功能模塊，已經(jīng)在基于 Linux 2.6.29內(nèi)核的 Android 4.0定制版本上實(shí)現(xiàn)。在模塊設(shè)計(jì)中，采用了串口通信機(jī)制，使AP與CP兩個(gè)獨(dú)立系統(tǒng)的通信和數(shù)據(jù)交換十分方便。同時(shí)在AP側(cè)的ARMLOG／DSPLOG驅(qū)動(dòng)中，使用工作隊(duì)列和中斷喚醒的技術(shù)，在沒有數(shù)據(jù)傳送時(shí)，整個(gè)數(shù)據(jù)通道處于睡眠狀態(tài)，有效地節(jié)省了系統(tǒng)資源開銷。既保證數(shù)據(jù)的完整有效性，也能滿足實(shí)際項(xiàng)目的需求。

［1］王海霞.TD／GSM雙模手機(jī)軟件架構(gòu)的研究與實(shí)現(xiàn) ［D］.南京：南京郵電大學(xué)，2010.

［2］李志丹.嵌入式軟件調(diào)試方法研究［J］.計(jì)算機(jī)與數(shù)字工程，2012（7）：157－159.

［3］朱亞洲.GSM 手機(jī)軟件開發(fā)［D］.武漢：武漢科技大學(xué)，2007.

［4］陶少玉.高效基帶芯片調(diào)試方法的研究及其在MTK手機(jī)開發(fā)中的應(yīng)用 ［D］.上海：上海交通大學(xué)，2009.