Android手機中基帶跟蹤數據的導出功能設計＊

黃一峰，黃俊偉，吳戀

（重慶郵電大學 新一代寬帶移動通信終端研究所，重慶400065）

引 言

在目前流行的Android手機設計方案中，應用處理器（AP）和通信處理器（CP）因為對任務實時性的要求不同而相對獨立。典型地，AP和CP子系統分別運行手機系統的應用操作系統（Android）和基帶操作系統（Nucleus）［1］。

在手機開發過程中，大部分的功能調試通過AP側來完成。因此，將CP側的基帶跟蹤數據導出到AP側進行保存和分析，對于手機開發過程中的功能調試和Bug修復都具有非常重要的意義［2－3］。

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

在實際的手機產品中應用本文的設計，進行大數據量、長時間基帶跟蹤數據導出實驗和可靠性分析，得到了良好的實驗結果，驗證了本文設計的可行性和可靠性。

1 系統框架設計

1.1 系統總體框架設計

圖1為基帶跟蹤數據導出方案的整體框架。整個方案包括CP、AP以及串口機制三個方面。其中，CP側主要由跟 蹤 數 據 產 生 模 塊 （ARMLOG TRACE、DSPLOG TRACE）和CP側串口驅動組成；AP側主要由數據接收模塊（ARMLOG Driver、DSPLOG Driver），USB傳輸模塊（USB Gadget Driver）和 AP側串口驅動組成。

在CP側，Nucleus操作系統的跟蹤數據進程（ARM－log trace和DSPlog trace）負責產生基帶的跟蹤數據，經過設備抽象層（DAI）轉發后，基帶跟蹤數據被CP側串口驅動存入串口緩存Buffer中。

圖1 方案整體框架圖

同時在AP側，對應的串口驅動將從串口緩存buffer中讀取到的跟蹤數據上報給AP側數據接收進程（ARM－LOG Driver和 DSPLOG Driver）。最后，AP側數據接收進程調用 USB傳輸驅動（USB Gadget Driver），將跟蹤數據發送到PC端軟件進行顯示或保存。

串口機制包括物理上的數據緩存（Buffer）和公共的函數接口（API），AP側和CP側串口驅動通過調用這些公共的函數接口，即可完成相互通信和數據傳輸，從而達到兩個系統交互的目的。

1.2 AP側軟件交互流程

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

① 系統啟動以后，AP側ARMLOG DSPLOG Driver連接USB為向 ARM DSP Gadget Driver發送數據作準備。首先進行相關的初始化工作，包括緩存的申請、一些全局變量的初始化、設備的注冊等工作。

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

③ 啟動工作隊列函數trace＿read＿serial＿work（），準備向USB數據緩沖區（usb＿fifo）發送跟蹤數據。

④ 在工作隊列函數trace＿read＿serial＿work（）中調用串口通道讀函數serial＿read＿avail（），獲取串口通道中CP側發來的跟蹤數據長度r，r表示串口通道中可讀數據長度。

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

圖2 AP側和CP側軟件交互圖

⑥trace＿read＿serial＿work（）工作隊列調用時機說明：trace＿read＿serial＿work（）首次調用放在 USB連接tra－ceusb＿connect（）函數中，當系統檢測到有USB插入時，traceusb＿connect（）函數即被調用，當一次跟蹤數據通過USB完全送出后，跟蹤數據發送完成函數trace＿write＿complete（）會被執行，在該函數中再次調用，準備第二次數據的發送。

1.3 CP側跟蹤數據發送流程

CP側負責跟蹤數據的記錄和發送工作。CP側跟蹤數據發送具體流程如下：

① 定時器每10ms判斷發送DSP或ARM的跟蹤數據。

② 若跟蹤數據長度滿足發送長度條件，則進行混合幀頭封裝，不滿足則退出。

③ 通過平臺無關化調用DAI＿TRA＿SEND（）函數發送L長度的跟蹤數據。

④ 函數調用完成后返回處理結果retVal。

⑤判斷retVal是否等于發送長度L，若是則更新buffer數據索引然后結束，否則直接結束。

2 串口機制設計

串口機制為AP和CP間的trace驅動提供通信和數據傳送功能，起到了一個橋梁的作用。其軟件結構設計如圖3所示。

圖3 串口機制軟件結構圖

在AP和CP上有對等的串口驅動模塊。二者有公共的數據結構和循環數據緩沖區管理接口。

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

對外部接口的實現、內部接口的實現、通道對象管理和中斷ISR的實現等，AP和CP需要分別實現。AP和CP外部API接口相同，但具體實現不同。

在調試中首先采用的是普通串口方式，我們發現在數據通信過程中會頻繁產生中斷，占用系統資源過大；同時在大數據量的跟蹤數據導出時會產生延遲。因此，在AP側和CP側同時采用串口的DMA傳輸方式，可有效地降低資源占用，同時傳輸效率得以保證。

3 方案驗證分析與測試結果

系統功能的測試主要包括兩個測試點：

① 數據通路是否暢通。包括 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之間的通路。

② 導出的跟蹤數據是否完整有效。針對第一個測試點，可以在各個數據通路之間采取假數據上報的方式進行測試，譬如，在AP側Serial Driver中用假數代替從基帶獲取的跟蹤數據送往 AP ARMLOG／DSPLOG Driver中，測試兩者間通路是否暢通。

針對第二個測試點，需要在完整的系統平臺上，連續測試24小時以上，期間包括基帶數據業務的使用，以驗證整體模塊功能的可行性和可靠性［5］。

具體測試場景設計如表1所列。

表1 測試場景列表

多次測試后，通過PC端的Trace導出軟件觀察，保存出來的跟蹤數據既沒有重復顯示歷史跟蹤數據，也沒有出現跟蹤數據丟失和錯亂的情況，有序、準確無誤地輸出預想的跟蹤數據，如圖4所示。

圖4 導出的基帶數據截圖

結 語

本文所提出的基帶Trace導出功能模塊，已經在基于 Linux 2.6.29內核的 Android 4.0定制版本上實現。在模塊設計中，采用了串口通信機制，使AP與CP兩個獨立系統的通信和數據交換十分方便。同時在AP側的ARMLOG／DSPLOG驅動中，使用工作隊列和中斷喚醒的技術，在沒有數據傳送時，整個數據通道處于睡眠狀態，有效地節省了系統資源開銷。既保證數據的完整有效性，也能滿足實際項目的需求。

［1］王海霞.TD／GSM雙模手機軟件架構的研究與實現 ［D］.南京：南京郵電大學，2010.

［2］李志丹.嵌入式軟件調試方法研究［J］.計算機與數字工程，2012（7）：157－159.

［3］朱亞洲.GSM 手機軟件開發［D］.武漢：武漢科技大學，2007.

［4］陶少玉.高效基帶芯片調試方法的研究及其在MTK手機開發中的應用 ［D］.上海：上海交通大學，2009.