DSP/BIOS環(huán)境下的數據通信

對于數字信號處理應用來(lái)說(shuō)，數據的通信很關(guān)鍵。在TI公司的DSP/BIOS環(huán)境下有3種通信方式，即基于管道（PIP，pipe）的通信、基于流（SIO，stream I/O）通道的通信以及基于主機（HST，host）通道的通信。每一種通信方式都是通過(guò)調度其相應的內核對象來(lái)完成的。DSP/BIOS提供了管理每一種通信方式的模塊及相應地API調用，通過(guò)這些模塊及調用，可以完成DSP環(huán)境下的輸入/輸出 （I/O）。本文在對各種通信方式進(jìn)行簡(jiǎn)要介紹的基礎上,對各種通信方式進(jìn)行比較，并給出利用PIP對象進(jìn)行數據通信的1個(gè)例子。

1 通信方式簡(jiǎn)介

（1）主機通信

主機通信方式下，由HST對象完成主機與目標機之間的通信。HST對象靜態(tài)配置為輸入/輸出，每一個(gè)HST對象內部是用數據管道對象來(lái)實(shí)現的。

開(kāi)發(fā)DSP應用時(shí)，可以應用HST對象來(lái)模仿數據流和測試程序算法對數據的處理。在程序開(kāi)發(fā)的早期，特別是在測試信號處理算法時(shí)，程序使用輸入通道對象訪(fǎng)問(wèn)來(lái)自主機文件中的數據，以及使用輸出通道對象把算法處理過(guò)的結果反饋回主機一側，以供查驗或比較。在程序開(kāi)發(fā)的后期，當算法開(kāi)發(fā)

（2）管道通信

管道（PIP）對象用于管理塊I/O（也稱(chēng)為基于流的I/O或者異步I/O）。每一個(gè)PIP對象維護著(zhù)一個(gè)分為固定數量和固定大小的緩沖區（稱(chēng)為幀）。所有的I/O操作在每一刻只處理1幀。盡管每一幀長(cháng)度是固定的，但是應用程序可以在每一幀中放置可變數量的數據（但不能超過(guò)最大值）。管道有兩端，一端為寫(xiě)線(xiàn)程，一端為讀線(xiàn)程。寫(xiě)線(xiàn)程一端用于向管道中添加數據，讀線(xiàn)程一端用于從管道中讀取數據。管道能夠用于在程序內的任意2個(gè)線(xiàn)程之間傳遞數據。經(jīng)常地，管道的一端由ISR控制，另一端由軟件中斷函數控制。數據通知函數（也稱(chēng)為回調函數）用于同步數據的傳輸，包括通知讀函數和通知寫(xiě)函數。當讀或寫(xiě)1幀數據時(shí)，這些函數被觸發(fā)，以通知程序有空閑幀或者有數據可以利用。

（3）流通信

流是一個(gè)通道，通過(guò)它，數據在應用程序與 I/O設備之間傳輸。流通道可以是只讀的（用于輸入）或者只寫(xiě)的（用于輸出）。它對所有I/O設備提供了一個(gè)簡(jiǎn)單通用接口，允許應用程序完全不用考慮每個(gè)設備操作的細節。流I/O的一個(gè)重要方面是它的異步特性。當應用程序正在處理當前緩沖區時(shí)，一個(gè)新的輸入緩沖區正在被添充和以前的緩沖區正在被輸出。流交換的是指針而不是數據，這就大大減少了開(kāi)銷(xiāo)，使得程序更能滿(mǎn)足實(shí)時(shí)約束的要求。流模塊（SIO）通過(guò)驅動(dòng)程序來(lái)與不同類(lèi)型的設備打交道。驅動(dòng)程序由DEV（Device）模塊管理。

設備驅動(dòng)程序是管理一類(lèi)設備的軟件模塊。這些模塊遵從通用接口（由DEV提供），因此，流函數能夠發(fā)出普通請求。圖 1 給出了流與設備之間的交互示意圖。

（4）各種通信方式比較

DSP/BIOS支持兩種不同的數據傳輸模型，一種是管道模型，由PIP與HST模塊使用；另一種是流模型，由SIO與DEV模塊使用。2個(gè)模型都要求1個(gè)管道或者流具有1個(gè)讀線(xiàn)程和1個(gè)寫(xiě)線(xiàn)程。2個(gè)模型都通過(guò)拷貝指針而不是數據來(lái)完成數據的拷貝。一般來(lái)說(shuō)，管道模型支持低級通信，而流模型支持高級的、與設備無(wú)關(guān)的I/O。具體情況如表1所列。

2 基于管道通信的一個(gè)例子

在基于以上分析的基礎上，給出利用管道進(jìn)行通信的1個(gè)例子。該例是音頻處理的一個(gè)例子。數據從數據源輸入到編碼器以后經(jīng)量化通過(guò)串行口輸入到目標機，目標機處理完畢后再經(jīng)串行口發(fā)送到編碼器，由編碼器經(jīng)揚聲器輸出。圖2給出數據的流程圖。

（1）管道設計

該例中，設計了DSS_rxPipe和DSS_txPipe兩個(gè)管道，其中DSS_rxPipe用于數據的接收，DSS_txPipe用于數據的發(fā)送。

（2）線(xiàn)程設計

由于每個(gè)管道分別對應1個(gè)讀寫(xiě)線(xiàn)程，因此，發(fā)送管道與接收管道總共需要4個(gè)讀寫(xiě)線(xiàn)程。本例中為了簡(jiǎn)化設計，只設計了2個(gè)線(xiàn)程。其中，音頻處理函數（設計為軟件中斷SWI）既作為接收管道的讀線(xiàn)程又作為發(fā)送管道的寫(xiě)線(xiàn)程；串行口接收中斷處理服務(wù)例程ISR既作為接收管道的寫(xiě)線(xiàn)程又作為發(fā)送管道的讀線(xiàn)程。

每次中斷發(fā)生時(shí)，串行口中斷服務(wù)例程（ISR）把數據接收寄存器（DRR）中的數據字（32位）拷貝到數據接收管道的一空閑幀中。當1幀被填滿(mǎn)時(shí)，ISR把該滿(mǎn)幀寫(xiě)到數據接收管道中（通過(guò)調用PIP_put），供該管道的讀線(xiàn)程（即音頻處理函數）讀取。音頻處理函數執行時(shí)，它讀取接收管道中的一滿(mǎn)幀，處理完畢后再把它寫(xiě)到發(fā)送管道的一空閑幀中，供該管道的讀線(xiàn)程（即ISR）發(fā)送。每次ISR觸發(fā)時(shí)，它從發(fā)送管道中讀取一滿(mǎn)幀（若有的話(huà)），并每次32位字地發(fā)向串行口發(fā)送寄存器（DXR）直到1幀中的所有數據發(fā)送完畢。然后，該空閑幀被回收到發(fā)送管道，供音頻處理函數（即該管道的寫(xiě)線(xiàn)程使用）。需要注意的是，由于例子當中發(fā)送速率與接收速率一樣，因此，中斷處理函數不但負責數據的接收也負責數據的發(fā)送，并且每次中斷執行時(shí)只發(fā)送1個(gè)32位字。

（3）需注意的問(wèn)題

PIP_alloc和PIP_put由PIP對象的寫(xiě)線(xiàn)程調用，PIP_get和PIP_free由PIP對象的讀線(xiàn)程調用，這種調用順序是非常重要的。若打亂這種調用順序，將會(huì )產(chǎn)生不可預測的后果。因此，每一次對PIP_alloc的調用都要跟著(zhù)對PIP_put的調用才能繼續調用PIP_alloc；對于PIP_get，情況也是如此。

另外，為了避免PIP調用過(guò)程中產(chǎn)生遞歸，作為通知讀/寫(xiě)函數的一部分，應該避免調用PIP API函數。如果為了效率起見(jiàn)必須要這樣做，那么對諸如此類(lèi)的調用應該加以保護，以阻止同一管道對象的重入以及錯誤的PIP API調用順序。例如，在發(fā)送管道的通知讀函數以及接收管道的通知寫(xiě)函數的開(kāi)始部分，我們添加了如下語(yǔ)句，以避免遞歸調用：

　　static

　　…

　　if (nested){/*防止由于調用PIP_get函數而產(chǎn)生的遞歸調用*/

　　return；

　　}

　　nested =1；

　　…

3 總 結

在DSP/BIOS提供的3種通信方式中，由于PIP對象的效率很高，因此使得它在基于DSP應用系統的輸入輸出中得到了廣泛的應用。但是，我們在利用其所提供的便利的同時(shí)，一定要妥善處理好通知讀/寫(xiě)函數的編寫(xiě)工作，以免發(fā)生遞歸調用，產(chǎn)生災難性的后果。