OMAPL138雙核系統的調試方案設計

欒小飛

（電子科技大學 自動化工程學院，成都 611731）

1 雙核調試困難

雙核芯片的推出為兼顧強大的數據處理能力和良好的用戶體驗提供了解決方案，將雙CPU集成在一個芯片上也簡化了硬件電路設計的難度。但是，雙核開發增加了軟件設計的難度。以往的ARM工程師與DSP算法工程師的明確分工已經不能適用于雙核芯片的開發，需要在雙核芯片的同步運行上提供一些解決方案。開發工程師在進行雙核開發中會遇到調試方面的困難，以往的CCS和仿真器的調試方式已經不適用于雙核環境下對DSP程序的調試。DSP端的程序運行，無法直觀地提供調試信息給開發者，相當于一個“黑匣子”，以至于開發者無法獲取DSP端寄存器和變量的變化情況。本文通過推出基于DSPLink軟件模塊的消息隊列組件，使DSP調試信息通過ARM端應用程序打印。

2 雙核通信理論

TI公司推出的OMAP體系結構與其推出的達芬奇結構有相似之處，OMAP體系開發套件與達芬奇套件有很大的相似性，而達芬奇處理器最具革命性的意義在于它的全平臺開放。TI提供了全套開發套件，給工程師們在開發上提供了便利性和規范。開發套件中，基于雙核通信的底層為DSPLink模塊，為核心模塊。

2.1 DSPLink雙核通信構架

在OMAP體系中，芯片設計時，在片內分配一塊RAM內存區域，是ARM和DSP都可以直接使用的共享內存區域。在小數據量的簡單的控制信息通信時，可以直接使用片內的共享內存，通信速率也是最快的。同時還有將共享內存分配在片外的DDR，以便進行大數據量的傳輸。

DSPLink為TI針對雙核通信的底層模塊，在ARM端和DSP端具有相似的作用，在ARM端Linux嵌入式操作系統中作為Linux的內核模塊存在，扮演著設備驅動的角色，通過驅動提供的眾多上層API接口直接操作共享內存。在DSP端其連接的是TI推出的主要用于DSP的一款實時操作系統DSP／BIOS，同樣作為驅動存在。采用DSPLink軟件方法將物理層抽象出來，為硬件提供了十分優秀的擬合，使ARM和DSP在通信上實現無縫的鏈接。DSPLink的軟件構架如圖1所示。

圖1 DSPLink的軟件構架

（1）在GPP端

GPP OS：在GPP端多采用操作系統，比較常用的是嵌入式操作系統Linux和 WinCE，TI的DVSDK中有相關的支持。

OS抽象層：OS抽象層包含了DSPLink需要的一些通用的OS服務部件，通過此層使DSPLink可以不依賴特定的操作系統，從而可以利用接口特性更多地針對不同的操作系統使用，使開發者方便地移植到不同操作系統中。

Link Driver：GPP端的驅動層，該層提供了共享內存的GPP端的驅動。

Processor Manager：該層維護一個針對所有模塊的Book－Keeping信息，通過API給用戶提供通過Link Driver的控制操作。

DSP／BIOS Link：通過API可以脫離對底層的了解，直接操作共享內存，以實現通信。

（2）在DSP端

DSP Link Driver：Link Driver是DSP／BIOS中驅動的一部分，該部分驅動只負責基于物理連接之上與GPP之間的交互。

DSP／BIOS：DSP端的實時操作系統。

2.2 MSGQ通信搭建方法

雙核通信的基本模式即是一方將所需要傳輸的數據放到共享內存中，通過中斷的方式告知另一方。作為DSPLink中不同的通信模塊，存在的不同只是對共享內存的組織方式不同。下面以MSGQ傳輸方式為例分析建立雙核通信構架。

MSGQ表述消息隊列方式，主要針對ARM和DSP端可變長度的短消息的交互，是基于DSP／BIOS的MSGQ模塊實現的。消息的發送／接收都要以隊列的方式進行。消息的發送者將消息發送入隊列中，隨后接收者從隊列中將消息取出。每個消息隊列只能有一個接收者，但是可以同時有多個發送者。在一個任務中，可以進行多個消息隊列的讀寫。使用MSGQ進行數據傳輸還需要用到另外兩個組件：

①PROC，在GPP應用中模擬DSP角色，控制DSP程序的載入、運行、停止。

②POOL，用于分配存儲器緩沖區，將內存合理分塊，使分配所需內存適合傳輸數據的尺寸。

利用這兩個組件，將完成DSP程序的載入啟動和內存池的分配。

MSGQ通信流程如圖2所示。

圖2 MSGQ通信流程

GPP端按如下順序開通消息隊列：

①PROC＿setup（）。采用ARM端應用程序載入DSP程序到DSP中運行的方法啟動DSP，由于PROC組件被用于模擬DSP，首先要針對PROC進行創建和初始化。

② PROC＿attach（processorId，NULL）。在 DSP端運行之前，需要建立與GPP端通信的DSP的關聯，其中指定的processorId為與之通信的DSP的編號，防止ARM與多DSP通信時造成連接混亂。

③ POOL＿open（POOL＿makePoolId（processorId，POOL＿ID），＆SamplePoolAttrs）。打開共享內存池，內存緩沖區同樣需要一個ID來進行不同的分工。Sample－PoolAttrs用來指定緩沖區大小、buffer個數等屬性。

④ MSGQ＿open（SampleGppMsgqName，＆Sample－GppMsgq，NULL）。在進行MSGQ通信之前的一個前提是處理器雙方都需要各自打開一個消息隊列，每個消息隊列擁有各自的name，只有當連接方提出的name與消息隊列的name相吻合的時候，消息隊列才得到建立。利用該API打開消息隊列，SampleGppMsgqName指代的是GPP端消息隊列的name。

⑤ PROC＿load（processorId，（Char8＊）＆imageInfo，numArgs，args）。將編譯好的DSP程序載入DSP中，相關參數為DSP的編號、DSP可運行程序名字、參數的個數和運行參數。

⑥PROC＿start（processorId）。開始運行編號為processorId的DSP。

⑦ MSGQ＿locate（dspMsgqName，＆SampleDspMsgq，＆syncLocateAttrs）。等待需要建立的消息隊列打開。由于通信時需要將一條消息隊列的兩個端口都關聯到指定的處理器，只有name為dspMsgqName的消息隊列一邊已經打開后，才能連接指定要連接的消息隊列，該消息隊列才真正建立起來，并進行通信。該接口函數與MSGQ＿open相呼應。syncLocateAttrs為指定等待的相關屬性，例如指定該屬性為syncLocateAttrs.timeout＝ WAIT＿FOREVER時，程序一旦運行到此函數處，如果另一方處理器還沒有MSGQ＿open的name為dspMsgqName的消息隊列，便會阻塞在此處，直到打開為止。至此GPP端的消息隊列已經完成設置，等待DSP端消息隊列的建立。

DSP端按如下順序開通隊列：

①建立TASK任務。由于DSPLink是基于處理器兩端操作系統進行的連接，因此，在DSP端同樣必須采用操作系統作為通信的媒介，采用DSP／BIOS操作系統，以任務的形式運行程序。

②創建和初始化MSGQ傳輸屬性。在進行MSGQ的創建打開之前，要先指定MSGQ的相關屬性。

③ MSGQ＿open（（String）dspMsgQName，＆info－﹥localMsgq，＆msgqAttrs）創建DSP端消息隊列，原理如同GPP端。

④ MSGQ＿locate（GPP＿MSGQNAME，＆info－﹥locatedMsgq，＆syncLocateAttrs）等待連接GPP端打開的消息隊列，原理如同GPP端。

⑤當GPP和DSP端消息隊列都建立完畢，并且關聯，通信即建立，可以采用 MSGQ＿put和 MSGQ＿get發送和接收數據。

3 基于MSGQ雙核調試方案

MSGQ組件在實際的應用中因其數據長度的可變性，對DSP端應用程序的調試提供了強大的解決方案。通過MSGQ的分析可以發現，采用ARM和DSP端聯合，通過log打印的方式可以方便地對DSP端的運行情況進行一定的了解。

在GPP端和DSP端應用程序中建立獨立線程和任務。由于只需要將DSP信息傳輸到GPP端而不需要GPP端的反饋信息，因此只需要設計單向傳輸，創建一條消息隊列即可。當DSP端運行到需要打印的信息時，將消息暫存于指定的內存空間，當任務切換到調試任務時，將暫存的消息發送到GPP端，GPP端接收到消息后在終端打印。調試建立流程如圖3所示。

3.1 DSP端

（1）消息結構

（2）發送端初始化

（3）消息創建和發送

（4）釋放內存

釋放內存主要采用 MSGQ＿release（DebugMsgq），進行消息隊列的釋放。

3.2 GPP端

GPP端的消息結構與DSP端相同。

圖3 調試建立流程

（1）線程建立和隊列建立

（2）信息接收

（3）釋放內存

主要采用MSGQ＿Close（GppMsgq）；釋放建立的消息隊列。

根據圖3，在DSP端，首先需要建立調試打印任務并且為所需要傳輸的log長度分配內存空間，隨后在log發送端初始化中進行 MSGQ的定位 MSGQ＿locate（），通過定位將指定連接DSP與GPP端的消息傳輸隊列。消息就通過此隊列進行傳輸，采用 MSGQ＿put（）將DSP端的調試信息發送到GPP端。在多次傳輸調試信息后，占用過多的內存空間會導致內存泄露。為防止這種狀況的發生，要在傳輸完畢后進行空間的釋放，在下次傳輸時再重新創建。雖然這會影響到傳輸時間，但是為了內存空間更加便利安全的管理，在傳輸結束后應立即釋放。

在GPP端，為了使MSGQ調試程序與主程序的運行互不干擾，創建單獨線程進行調試使用。在接收內存空間分配好后，采用 MSGQ＿open（）打開已經創建的 MSGQ，使用MSGQ＿get（）消息接收。在接收完調試信息后，可以直接利用printf將調試信息通過串口打印在調試工具上。GPP端打印完成后，同樣需要對分配內存空間進行釋放。至此完成調試。

該調試方法同樣存在著缺陷：DSP端正在運行的任務無法直接顯示消息，需要將消息暫存，隨后進行任務切換傳輸，因此無法即時進行調試信息的顯示。但對于開發者來說，常常只是需要知道變量的數值或者程序運行的進度，所以此缺陷不會成為影響調試的大障礙，可以接受。

4 測試驗證

采用DVSDK中提供的example進行更改，更改上述調試模塊，對MSGQ的雙核調試信息進行測試，打印出通過與EMIFA相連接的LED的值，如圖4所示。

圖4 調試模塊測試

采用insmod dsplinkk.ko將編譯好的內核模塊加載進系統中，然后利用GPP端應用程序載入DSP端應用，在DSP端中，將string為“led test reg＝”作為msg－＞str參數，將控制LED的寄存器作為arg［］參數，傳入GPP端打印出來。

結 語

本文針對OMAP雙核體系分析了在TI雙核體系中雙核進行通信的方式，又分析了DVSDK中雙核通信底層模塊DSPLink在Linux操作系統中的搭建和以MSGQ通信時的過程。雙核體系硬件擬合性好，功耗低，有很好的應用前景。針對的雙核開發過程中調試難的特點設計了log打印的調試方式，在實際的應用中有較大的意義。

［1］Corbet Rubini，Kroah Hartman.Linux設備驅動程序［M］.3版.北京：中國電力出版社，2010：21－44.

［2］Texas Instruments.Install Guide Linux OMAPL138，2010.

［3］趙加祥.DSP系統設計和BIOS編程及應用實例［M］.北京：機械工業出版社，2008.

［4］Texas Instruments.Platform Guide OMAPL138，2010.

［5］Karim Yaghmour.構建嵌入式Linux系統［M］.北京：中國電力出版社，2008：178－198.

［6］Texas Instruments.Building DSPLink Applications version 1.65.00.02，2010.

［7］Texas Instruments.Programmer’s Guide，2010.