基于GIO/FVID的DSP視頻驅動(dòng)程序設計
加入技術(shù)交流群
隨著(zhù)時(shí)代的發(fā)展，DSP技術(shù)在遠程監控、可視電話(huà)、工業(yè)檢測等視頻處理領(lǐng)域得到了廣泛的應用，對于不同的視頻處理系統，會(huì )使用不同的視頻設備，所以有必要為視頻沒(méi)備設計驅動(dòng)程序，為高層應用程序提供統一的接口來(lái)操作底層硬件。只要是遵循此驅動(dòng)程序接口標準開(kāi)發(fā)的高層應用程序，都可以在具有相同接口的不同硬件平臺上運行，具有很好的通用性和可移植性。同時(shí)高層應用程序設計人員只要會(huì )使用設備驅動(dòng)程序提供的API接口，就不必了解底層硬件的具體實(shí)現，可以大大提高整個(gè)視頻系統的開(kāi)發(fā)效率。
對于視頻設備，TI公司也提出了對應的視頻設備驅動(dòng)程序模型，但這些模型主要是針對6000系列高端DSP，甚至是DM64X這樣的視頻處理專(zhuān)用DSP設計的。而TMS320F2812(簡(jiǎn)稱(chēng)F2812)DSP這樣的低端處理器，內部存儲空間較小，且沒(méi)有DM64X那樣專(zhuān)用的視頻接口。本文針對這類(lèi)問(wèn)題，提出了對TI視頻驅動(dòng)模型進(jìn)行簡(jiǎn)化和改造的方法，使視頻設備驅動(dòng)程序占用盡量少的系統資源，來(lái)完成對視頻硬件設備的操作。這種視頻驅動(dòng)模型的裁減方法，對于使用低端處理器的視頻處理系統具有借可鑒性。
1、基于DSP／BIOS的外設驅動(dòng)開(kāi)發(fā)模型
TI公司為開(kāi)發(fā)DsP的外設驅動(dòng)程序，推出了DSP／BIOS Device Driver kit，定義了標準的設備驅動(dòng)模型，并提供了一系列的API接口。如圖1所示，外設驅動(dòng)程序分為兩層：
①類(lèi)驅動(dòng)(class driver)。類(lèi)驅動(dòng)程序用來(lái)為應用程序提供接口。這部分程序與設備無(wú)關(guān)，主要功能包括維護設備數據緩沖區，向上提供API接口供應用層程序調用，并協(xié)調應用程序對外設操作的同步和阻塞；向下提供適配層與迷你驅動(dòng)層相連，實(shí)現API接口函數到迷你驅動(dòng)層程序的映射。類(lèi)驅動(dòng)程序與硬件無(wú)關(guān)，只要外設驅動(dòng)模型選定了，類(lèi)驅動(dòng)程序就定下來(lái)了，不需要做多少修改。
②迷你驅動(dòng)(mini driver)。迷你驅動(dòng)程序與設備相關(guān)，所以設計迷你驅動(dòng)程序是外設驅動(dòng)開(kāi)發(fā)中的重點(diǎn)。迷你驅動(dòng)程序與類(lèi)驅動(dòng)層的接口格式是統一的，但迷你驅動(dòng)程序對底層硬件的操作是根據硬件平臺的不同而變化的。迷你驅動(dòng)接收類(lèi)驅動(dòng)層發(fā)出的IOM_Packet命令包，決定對底層硬件進(jìn)行什么樣的操作。
外設驅動(dòng)程序模型又可以分為以下3類(lèi)：
①PIP/PI0模型?；跀祿艿赖腎／O模型，每個(gè)管道都在維護自己的一個(gè)緩沖區。當數據寫(xiě)入緩沖區，或從緩沖區取出數據時(shí)，便會(huì )激發(fā)notifyReader和notifyWriter函數實(shí)現數據的同步。
②SIO／DIO模型?；跀祿鞯腎／O模型，一個(gè)數據流是單向的，要么是輸入，要么是輸出，而且SIO／DIO模瓔使用異步方式來(lái)操作I／0，對于數據的讀寫(xiě)、處理可以同時(shí)進(jìn)行。
③GI0模型。通用的I／O模型，靈活性很強，且沒(méi)有適配層，直接操作迷你驅動(dòng)程序，主要用來(lái)設計新型的設備驅動(dòng)模型。
2、視頻處理系統硬件平臺
硬件平臺如圖2所示。系統以TI公司的F2812 DSP作為中心處理器，以模擬攝像機進(jìn)行視頻信號采集，再使用SAA7111視頻解碼芯片將其轉換為BT601格式的數字視頻信號。DSP將數字視頻信號處理后，再寫(xiě)入輸出幀緩存AL422中，并控制視頻編碼芯片ADV7177，將其轉換為模擬電視信號輸出。整個(gè)系統以l片CPLD——IspMachLC4128來(lái)協(xié)調各個(gè)芯片之間的時(shí)序關(guān)系。
3、視頻設備驅動(dòng)程序開(kāi)發(fā)
3．1 設備驅動(dòng)程序模型的選擇
如上文介紹，常用的驅動(dòng)程序模型包括3類(lèi)：PIO、SIO和GIO。比較這3種模型可以知道：PIO支持更底層的通信，適合設計比較簡(jiǎn)單的外設驅動(dòng)程序。例如在TI公司的6X11DSK板上實(shí)現的音頻采集和回放，一般都是基于PIO模型的。而SIO模型具有很好的緩沖器分配回收機制，比較適合描述視頻設備，但是SIO的很多功能在本系統中使用不到，而且GIO模型設計的目的就是針對特殊硬件的新型設備，所以最終考慮使用GIO設備驅動(dòng)模型。
TI公司最初設計的GIO模型其實(shí)是有缺陷的，主要在數據緩沖區管理的問(wèn)題上，應用程序在取得緩沖區進(jìn)行數據處理之后，卻無(wú)法將緩沖區返回設備驅動(dòng)程序。于是TI公司在推出DM6北這一款主要用于視頻處理的DSP芯片的同時(shí)，對GIO模型進(jìn)行了改進(jìn)，提出了專(zhuān)門(mén)針對視頻設備的FVID模型。FVID模型是建立在GIO模型之上的，以FVID_alloc、FVID_exchangc、FVID_free函數對GIO模型中的GIO_submit函數進(jìn)行封裝，解決了GIO模型中驅動(dòng)程序不能回收緩沖區的問(wèn)題。
此外FVID模型還專(zhuān)門(mén)設計了FVID_frame結構。此結構中包含了常用的視頻信號的信息，如行數、列數、YUV結構、場(chǎng)頻等，很適合描述視頻數據幀。但FVID主要是針對DM64X系統設計的，DM64X的很多功能在F2812 DSP上都不具備。所以本設計針對F2812 DSP視頻處理系統，對FVID模型進(jìn)行了一定的簡(jiǎn)化，保留類(lèi)驅動(dòng)程序，而重寫(xiě)了迷你驅動(dòng)層程序。
3.2 視頻處理程序運行流程
在設計完成的視頻驅動(dòng)程序基礎上，開(kāi)發(fā)一個(gè)典型的視頻處理應用程序，其運行流程如圖3所示。首先使用FVID_create函數建立GIO_capture和GIO_play兩個(gè)視頻通道．再以GIO_capture通道的FVID_control函數發(fā)出cmd_start，采集到1幀視頻數據。應用程序以GIO_capture通道的FVID_alloc函數向驅動(dòng)程序申請采集到的數據幀，進(jìn)行處理后再以FVID_exchange函數將修改后的數據幀返回驅動(dòng)程序，最后再調用GI0_play通道的FVID_control函數發(fā)出cmd_display命令將數據幀輸出。由圖3可以看到，應用程序調用的這些FVID_XXX接口函數會(huì )自動(dòng)由類(lèi)驅動(dòng)程序層層向下映射，到達迷你驅動(dòng)層程序；而迷你層程序可以直接操縱底層硬件設備，來(lái)完成整個(gè)視頻的采集、處理和顯示的過(guò)程。
3.3 迷你驅動(dòng)程序的設計
迷你層驅動(dòng)程序足整個(gè)設計的重點(diǎn)所在，下面詳細介紹其實(shí)現方法。迷你層驅動(dòng)程序主要由表1所列的幾個(gè)函數組成。
對各個(gè)函數的具體實(shí)現如下：
①mdBindDev函數。在應用程序建立設備接口(如FVID_create函數)時(shí)被調用，完成對外部設備的初始化。而與其對應的是md_UBindDev函數，使用nadUBindDev函數會(huì )使設備處于無(wú)效狀態(tài)，不能再使用。
②mdCreateChan函數。使用此函數為應用程序和驅動(dòng)程序建立通信通道，同時(shí)為每個(gè)通道申請緩沖區。在TI公司發(fā)布的FVID模型中，為每個(gè)通道都分配了3個(gè)緩沖區，輪流與外部設備交換數據，每個(gè)緩沖區對應1幀視頻數據，這樣的設計在DM642這樣可以外擴大容量SDRAM的系統中是完全可行的。但是對于本系統，F2812DSP外部只擴展了512K×16位的SRAM，既要做視頻輸入的幀緩存，義要存放一部分程序，這樣存儲空間就不夠了。所以本設計中進(jìn)行了簡(jiǎn)化，對視頻輸入設備采用兩緩沖區輪轉的機制，如圖4(a)所示。而對于視頻輸出設備，以AL422 FIFO作為硬件幀緩存，而不在SRAM中再為其分配緩沖區。與mdCreateChan對應的是md-DeleteChan函數，用于刪除設備通道，釋放緩沖區資源。
③mdSubmitChan函數。負責管理緩沖區。分別接受應用程序發(fā)出的FVID_ALLOC、FVID_EXCHANGE、FVID_FREE三個(gè)命令并進(jìn)行處理。其中FVID_ALLOC命令對應圖4中(a)到(b)的過(guò)程，應用程序從兩個(gè)緩沖區中取出最新的一幀視顴數據，塒其中的數據做處理，而只剩下一個(gè)緩沖區用來(lái)接受外部設備輸入的數據。FVID_EXCHANGE對應圖4中(b)到(c)的過(guò)程，應用程序處理完1幀數據，將這1幀數據返回驅動(dòng)程序，準備用來(lái)顯示，同時(shí)再讀入新的l幀數據進(jìn)行處理。FVID_FREE對應圖4中(c)到(a)的過(guò)程，應用程序將處理完的數據幀返回驅動(dòng)程序，而不再向驅動(dòng)程序申請新的數據幀。以上3個(gè)命令足針對視頻輸入接口GIO_capture而言的，而對于輸出設備接口GIO_play，在SRAM中沒(méi)有分配緩沖區，所以其nldSubmitChan函數內部設為空函數。
④mdControlChan函數。用來(lái)操作外部視頻設備，完成對視頻數據的采集和輸出。對于GIO_capture和GIO_play這兩個(gè)設備接口的mdControlChan函數接受的命令是不同的：
視頻輸入GIO_capture接口的mdControlCham函數只接受cmd_start命令，完成1幀視頻數據的采集；而視頻輸出GIO_play接口的mdControlChan函數只接受cmd_display命令．完成視頻信號的輸出。
3.4 視頻驅動(dòng)模型裁剪的一般方法
TI公司設計的GIO／FVID視頻設備驅動(dòng)原型相對復雜，且占用較多的系統資源，要使其可以應用于更通用的低端處理器系統，就必須進(jìn)行改造和裁減。在改造中要注意以下幾個(gè)方面：
①阻塞的I／0操作。TI公司6000系列的DSP具有FDMA功能，傳輸數據不需要CPU的干預，而DM64X還具有專(zhuān)用的視頻接口，傳輸數據不會(huì )占用外部擴展總線(xiàn)，所以視頻數據的處理和輸入輸出是可以并行的。而低端處理器是不具備這樣功能的，視頻設備一般都是通過(guò)外部擴展總線(xiàn)連接的，所以對視頻設備的操作必須設計為阻塞型的I／O操作，視頻數據輸入/輸出的過(guò)程是由CPU來(lái)完成，且要保證對視頻設備的操作不會(huì )被其他操作中斷。
②對視頻數據緩沖區的管理。GIO／FVID視頻設備驅動(dòng)原型中使用的3緩沖區模型，雖然功能很完善，卻占用了太多的存儲空間，所以對于實(shí)際的視頻處理系統就要進(jìn)行調整，改為兩緩沖區甚至是單緩沖區模型。對于具有獨立硬件緩存的輸出設備，可以考慮不再為其分配動(dòng)態(tài)緩沖區。
③對視頻設備的操作。mdControlChan函數主要用來(lái)操作外部視頻設備，只要保留對實(shí)際系統有用的操作就足夠了，而GI0／FVID視頻設備驅動(dòng)原犁中定義的很多操作都可以省略。
4、小結
本文介紹了基于DSP／BIOS的外設驅動(dòng)程序模型，并針對基于F2812DSP的視頻處理系統這一具體的硬件平臺，重點(diǎn)介紹了開(kāi)發(fā)GIO／FVID設備驅動(dòng)的流程和針對低端處理器系統的視頻驅動(dòng)模型裁減方法。本視頻驅動(dòng)程序為開(kāi)發(fā)各種視頻處理應用程序(如JPEG圖像EPA控制網(wǎng)絡(luò )中ZigBee壓縮、MPEG視頻壓縮、視頻監控程序等)提供了有力的支持。本文介紹的設備驅動(dòng)程序的開(kāi)發(fā)方法，對于同類(lèi)視頻處理系統，特別是對于使用TI2000系州DSP這樣系統資源比較有限的視頻處理系統，具有很好的可借鑒性。
評論