基于DSP/BIOS 的TI DSP 應(yīng)用程序框架設(shè)計

　　3.1 主從通信方式

　　我們在DSP 的存儲空間中定義了兩個寄存器：DSP 運行控制寄存器（DSP_CNTL）和DSP 運行狀態(tài)寄存器（DSP_STAT）。在DSP_CNTL 中可以定義一系列控制字段用來表示外部主機對DSP 的各種控制操作，而在DSP_STAT 中可以定義一些與DSP_CNTL 相對應(yīng)的描述DSP 當(dāng)前運行狀態(tài)的字段信息。GPP 通過合理地設(shè)置DSP_CNTL 以命令DSP 執(zhí)行相應(yīng)的操作，而DSP 在響應(yīng)了CPU 的命令后會設(shè)置好DSP_STAT 以告知CPU 目前DSP 的運行情況。

　　另外，為了便于 DSP 與主機進行數(shù)據(jù)交換，ERF5 在DSP 的存儲空間中開辟了兩塊專用于在DSP 與GPP 之間進行數(shù)據(jù)交換的緩沖區(qū)，并在DSP 運行狀態(tài)寄存器DSP_STAT 中定義一個緩沖區(qū)標(biāo)志位PPFLG 以告知主機當(dāng)前它所能訪問的乒乓緩沖區(qū)是“乒”或是“乓”，使得主機和DSP 之間的數(shù)據(jù)交互能夠彼此相對獨立地進行。

　　3.2 任務(wù)實現(xiàn)模型

　　在明確了主機與DSP 的通信方式以后，下面需要解決的就是如何在應(yīng)用程序框架中給出合理的任務(wù)實現(xiàn)模型使它既能支持主機對DSP 的有效控制又能盡可能地減小DSP/BIOS的任務(wù)調(diào)度開銷。這里以我們的實際項目為例來闡述任務(wù)的實現(xiàn)模型。在我們的H.264 混合編解碼系統(tǒng)中，DM642 需要運行三個相互獨立的任務(wù)：視頻編碼任務(wù)、視頻解碼任務(wù)和視頻直通任務(wù)，在任意時刻，這三個任務(wù)線程的核心處理過程運行與否完全受GPP 控制。首先，出于對系統(tǒng)性能的考慮，我們都以靜態(tài)配置的方式在DSP/BIOS 中定義這3 個任務(wù)，這樣在系統(tǒng)運行時不需要花費由于任務(wù)動態(tài)創(chuàng)建所帶來的不可避免的性能開銷。顯然這3 個任務(wù)應(yīng)該具有同等優(yōu)先級，否則，由于DSP/BIOS 實時內(nèi)核的搶占性特征將使得某些高優(yōu)先級的任務(wù)始終搶占那些低優(yōu)先級任務(wù)的執(zhí)行權(quán)即使GPP 在某些時刻并沒有啟動那些高優(yōu)先級的任務(wù)。此外，由于DSP/BIOS 周期性地調(diào)度系統(tǒng)中所有處于就緒狀態(tài)下的任務(wù)，所以必須使每個任務(wù)中判斷其主體處理過程是否執(zhí)行的邏輯和任務(wù)切換邏輯盡可能短小，因為這段代碼在系統(tǒng)執(zhí)行時將被頻繁地調(diào)用。另外需要注意的是應(yīng)該使用TSK_sleep(…)函數(shù)來實現(xiàn)任務(wù)切換邏輯以使當(dāng)前沒有被GPP 命令執(zhí)行的任務(wù)被阻塞一段時間（該時間間隔應(yīng)該至少是系統(tǒng)中各個周期性任務(wù)的最大執(zhí)行周期），否則DSP/BIOS 任務(wù)調(diào)度器會頻繁調(diào)度該任務(wù)以至于影響到其它任務(wù)的正常執(zhí)行。下面以視頻直通任務(wù)為例給出其任務(wù)執(zhí)行流程圖如圖3所示。

　　圖3 視頻直通任務(wù)的執(zhí)行流程圖