基于DSP/BIOS 的TI DSP 應用程序框架設計

　　3.1 主從通信方式

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

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

　　3.2 任務實現模型

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

　　圖3 視頻直通任務的執行流程圖