|
0 引言 隨著人們生活水平的提高，消費(fèi)結(jié)構(gòu)發(fā)生了巨大變化，消費(fèi)者用于娛樂方面的支出在總支出中所占的比例正在不斷擴(kuò)大。掌上多媒體系統(tǒng)可以滿足人們對(duì)于試聽以及便攜的需求，另外還可以實(shí)現(xiàn)一些其他功能，如圖片瀏覽、網(wǎng)絡(luò)下載、以及影音錄制等。目前市場上的掌上多媒體系統(tǒng)多是Windows CE、Symbian、Palm OS等商用操作系統(tǒng)，其開放的程序不夠高，而且價(jià)格偏高，不適于第三方應(yīng)用軟件的移植。ARM體系作為專用嵌入式系統(tǒng)設(shè)計(jì)的通用處理器內(nèi)核，具備高性能、低功耗、易擴(kuò)展的特點(diǎn)。本系統(tǒng)基于ARM9、嵌入式Linux操作系統(tǒng)設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)更為開放的嵌入式平臺(tái)，來實(shí)現(xiàn)掌上多媒體系統(tǒng)的諸多功能。 1 多功能掌上媒體播放器系統(tǒng)的硬件設(shè)計(jì) 多功能掌上媒體播放器系統(tǒng)的硬件設(shè)計(jì)如圖1所示。LCD采用的是Sharp的TFT屏，3．52in，分辨率240×320；音頻控制器是IIS接口的音頻控制器，解碼芯片是UDA1314TS；另外擴(kuò)展了用于視頻錄制的Philips的視頻解碼芯片SAA7113和ADI的JPEG壓縮芯片。視頻錄制的框圖如圖2所示。 2 多功能掌上媒體播放器系統(tǒng)的軟件設(shè)計(jì) 系統(tǒng)設(shè)計(jì)和軟件設(shè)計(jì)是本系統(tǒng)的難點(diǎn)。系統(tǒng)軟件設(shè)計(jì)的總體框架如圖3所示。 2．1 嵌入式Linux操作系統(tǒng) Linux最初由Linux Torvalds編寫，后來在網(wǎng)絡(luò)上被眾多的Linux愛好者加以修改和維護(hù)，具有內(nèi)核高效穩(wěn)定、開源、可移植性強(qiáng)、內(nèi)核可定制可裁剪、多線程多任務(wù)等特點(diǎn)，因此選擇其作為本媒體播放器系統(tǒng)的操作系統(tǒng)。 首先定制裁剪并移植了Linux2．6的內(nèi)核，然后為使各硬件能正常工作編寫了鍵盤驅(qū)動(dòng)、LCD驅(qū)動(dòng)、觸摸屏驅(qū)動(dòng)、音頻驅(qū)動(dòng)、USB驅(qū)動(dòng)等驅(qū)動(dòng)。多功能掌上多媒體系統(tǒng)的正常工作首先是進(jìn)入ARM－Linux操作系統(tǒng)，然后加載各個(gè)硬件的驅(qū)動(dòng)程序并初始化各外圍設(shè)備，接著就進(jìn)入基于QT／Embedded庫的Qtopia桌面系統(tǒng)編寫的GUI圖形界面程序的播放器，最后選擇要進(jìn)行的操作。 對(duì)于Linux內(nèi)核的移植首先要移植bootloader，系統(tǒng)采用的是VIVI，其功能包括：分區(qū)管理、參數(shù)管理、啟動(dòng)Linux操作系統(tǒng)、文件系統(tǒng)管理、支持網(wǎng)絡(luò)、通過串口下載程序到Flash或者RAM等。建立嵌入式開發(fā)環(huán)境，使得能夠交叉編譯源代碼，對(duì)VIVI的源代碼進(jìn)行交叉編譯，生成能在 ARM Linux上運(yùn)行的bin文件，通過開發(fā)板的JTAG口將其燒寫到開發(fā)板的Flash中。 對(duì)內(nèi)核的移植首先要對(duì)內(nèi)核進(jìn)行修改MAKEFILE文件指定編譯器以及目標(biāo)平臺(tái)，然后配置內(nèi)核，交叉編譯生成內(nèi)核鏡像，通過UART口(串口)下載到開發(fā)板上。移植相應(yīng)的文件系統(tǒng)。文件系統(tǒng)中的文件是數(shù)據(jù)的集合，不僅包含著文件中的數(shù)據(jù)，而且還有文件系統(tǒng)的結(jié)構(gòu)，所有Linux用戶和程序看到的文件、目錄、軟連接及文件保護(hù)信息等都存儲(chǔ)在其中。在設(shè)計(jì)過程中把文件系統(tǒng)設(shè)置為可讀寫，這樣操作性強(qiáng)一些，在投入到生產(chǎn)中的時(shí)候應(yīng)該把文件系統(tǒng)設(shè)置為只讀的，這樣整個(gè)掌上多功能媒體播放器的操作系統(tǒng)就加載好了。 2．2 驅(qū)動(dòng)程序的設(shè)計(jì) 本系統(tǒng)共涉及到鍵盤驅(qū)動(dòng)、觸摸屏驅(qū)動(dòng)、LCD驅(qū)動(dòng)、音頻驅(qū)動(dòng)和USB驅(qū)動(dòng)等驅(qū)動(dòng)。因?yàn)槎嗝襟w功能是本系統(tǒng)的重點(diǎn)，所以播放器部分很重要，這里主要介紹音頻驅(qū)動(dòng)的編寫。 目前Linux下常用的音頻驅(qū)動(dòng)程序主要有兩種類型：OSS(Open Sound System) 和ALSA。最早出現(xiàn)的Linux上的編程接口是OSS，它由一套完整的內(nèi)核驅(qū)動(dòng)程序模塊組成，可為大多數(shù)音頻芯片驅(qū)動(dòng)提供統(tǒng)一的編程接口。在嵌入式系統(tǒng)中，對(duì)于特定的處理器(如本系統(tǒng)采用的S3C2410)，可以按照OSS接口標(biāo)準(zhǔn)來編寫音頻驅(qū)動(dòng)程序，以滿足Linux上的應(yīng)用程序。OSS接口已經(jīng)足夠簡單，需要完成的主要的工作就是對(duì)音頻設(shè)備(本系統(tǒng)采用的是Philips的UDA1314TS)的read，write和ioctl等操作。 系統(tǒng)音頻驅(qū)動(dòng)主要是對(duì)UDA1314TS進(jìn)行驅(qū)動(dòng)編寫，包括對(duì)UDA1314TS的L3接口的控制。首先初始化I／O和UDA1 314芯片，然后申請(qǐng)兩個(gè)DMA(Direct Memory Access)通道用于音頻傳輸(音頻數(shù)據(jù)的發(fā)送和接收都通過一個(gè)先入先出的隊(duì)列FIFO，但是只靠FIFO要保證音頻的連續(xù)播放是很困難的，所以申請(qǐng) DMA通道來解決此問題)。OSS標(biāo)準(zhǔn)中由兩個(gè)最基本的音頻設(shè)備：混音器(Mixer)和數(shù)字信號(hào)處理器(DSP)又稱編解碼器，其中混音器主要用來控制輸入輸出音量的大小，只有open和release以及幾個(gè)接管OSS標(biāo)準(zhǔn)的iotcl。而DSF設(shè)備驅(qū)動(dòng)的方法比較復(fù)雜，主要包括open、 release、read、write、poll、ioctl。其中主要在write和read方法中實(shí)現(xiàn)音頻的播放和錄音。以播放音頻來說明DSP驅(qū)動(dòng)程序的編寫，對(duì)應(yīng)了驅(qū)動(dòng)程序中的open和write方法，它們利用DMA實(shí)現(xiàn)了音頻的播放。在open中，首先判斷設(shè)備打開的方法：讀取、寫入和讀／寫，分別對(duì)應(yīng)音頻的錄音、播放以及錄音同時(shí)回放，然后申請(qǐng)兩個(gè)與音頻DMA緩沖區(qū)相關(guān)的，在初始化DMA時(shí)要用到，最后程序可以根據(jù)設(shè)備打開模式的初始化 S3C2410的工作模式，并清空所需的DMA緩沖區(qū)(在write方法被調(diào)用時(shí)創(chuàng)建)的數(shù)據(jù)結(jié)構(gòu)，把它留給緩沖區(qū)創(chuàng)建。在這里，因?yàn)槭褂昧藘蓚�(gè)DMA音頻數(shù)據(jù)傳輸，DMA緩沖的建立發(fā)生在第一次調(diào)用wri te將音頻數(shù)據(jù)傳送到設(shè)備，而OSS驅(qū)動(dòng)的調(diào)用者通常要在打開音頻設(shè)備時(shí)就期望獲得DMA緩沖的信息，然而因?yàn)榫彌_尚未建立，會(huì)使得緩沖大小為0這個(gè)結(jié)果，解決辦法時(shí)在兩個(gè)與音頻DMA緩沖區(qū)相關(guān)的程序部分一定不能少了以下代碼： if(!output_stream．buffer&&audio_setup_buf(＆out stream)) return-ENOMEM； 在Write方法中首先判斷設(shè)備文件打開的方式，具有write特性打開的設(shè)備才可以寫入，然后判斷是否沒有建立DMA緩沖區(qū)，若沒有，則通過 audio_setup_buf()來創(chuàng)建，定義一個(gè)結(jié)構(gòu)體(audio_stream_t)的指針如下： 
2．3 GUl程序的設(shè)計(jì)與播放器的實(shí)現(xiàn) 2．3．1 GUI程序的設(shè)計(jì)和實(shí)現(xiàn) 播放器的圖形界面在Qtopia視窗環(huán)境下運(yùn)行，采用Qt／Embedded2．3．7作為底層圖形庫，用于生成用戶界面。QT是一個(gè)跨平臺(tái)的c++圖形用戶界面庫，Qt／Embedded是面向嵌入式系統(tǒng)的版本，其最大的特點(diǎn)就是使信號(hào)和槽用于對(duì)象間的通信，Qt的窗口部件有多個(gè)預(yù)定義的信號(hào)，槽是一個(gè)可以被調(diào)用處理特定信號(hào)的函數(shù)。Qt的窗口部件有多個(gè)預(yù)定義的槽，當(dāng)一個(gè)特定事件發(fā)生的時(shí)候，一個(gè)信號(hào)被發(fā)射，對(duì)應(yīng)感興趣的槽就會(huì)調(diào)用對(duì)應(yīng)的相應(yīng)函數(shù)。播放器界面主要包括主界面窗口、文件操作窗口、播放列表窗口。主界面窗口有一個(gè)顯示屏和一些控制按鈕，包括播放、暫停、快進(jìn)、快退、下一首、上一首、音量調(diào)整以及播放進(jìn)度條和播放時(shí)間顯示。文件操作窗口可以使用戶選擇要播放的文件。播放列表用來播放最近播放的五個(gè)多媒體文件。 2．3．2 播放器的實(shí)現(xiàn) Linux下的播放器Mplayer是Linux上最優(yōu)秀的多媒體播放器，它能夠使用眾多的編解碼器，支持多種輸出設(shè)備�？梢圆シ攀忻嫔蠋缀跛械囊粢曨l格式。本系統(tǒng)選擇其作為播放器，對(duì)其進(jìn)行優(yōu)化和移植。進(jìn)行的優(yōu)化主要有： (1)Mplayer在系統(tǒng)上運(yùn)行的時(shí)候顏色會(huì)有偏差，因此編程校正Mplayer的色彩； (2)Mplayer正常模式不能在FramBuffer的中間顯示，帶-fs的全屏參數(shù)播放后，只能將播放位置移到中間，并不放大，修改播放顯示位置，讓它和Nplayer圖形界面的調(diào)用相符合； (3)編程實(shí)現(xiàn)播放時(shí)對(duì)鍵盤事件正�；� (4)Mplayer采用的自帶的mp3lib浮點(diǎn)音頻解碼庫的解碼效率很低，在播放音頻時(shí)會(huì)很卡，通過采用使用定點(diǎn)運(yùn)算的libmad音頻解碼庫替代原來的mp3lib庫進(jìn)行音頻解碼； (5)使用Mplayer的-input選項(xiàng)，通過FIFO從GUI向后端程序傳遞控制信息。通過優(yōu)化后，對(duì)Mplayer交叉編譯，移植到系統(tǒng)上可以流暢地播放mp3等音頻文件以及mpeg-1、mpeg-2、avi等視頻格式。 2．4 影音錄制 影音錄制的系統(tǒng)框架見圖2。通過擴(kuò)展用于視頻錄制的Philips的視頻解碼芯片SAA7113和ADI的JPEG壓縮芯片來實(shí)現(xiàn)。首先輸入的模擬視頻信號(hào)經(jīng)過SAA7113轉(zhuǎn)換為數(shù)字信號(hào)，然后傳輸給ADI的JPEG壓縮芯片JPEG2000，壓縮為JPEG圖像信號(hào)，并通過擴(kuò)展的總線接口傳輸?shù)较到y(tǒng)上。音頻信號(hào)則直接通過音頻輸入接口送到音頻解碼芯片，并轉(zhuǎn)化為數(shù)字信號(hào)進(jìn)行編碼。編寫應(yīng)用程序使傳到的音視頻數(shù)字信號(hào)一起轉(zhuǎn)化為Motion JPEG編碼的AVI格式的多媒體文件，并存入擴(kuò)展的存儲(chǔ)設(shè)備(微硬盤或者M(jìn)MC／SD卡)，這樣就可以被Mplayer播放。
3 性能優(yōu)化 盡管ARM9處理器主頻可以高達(dá)200MHz以上，但是為了降低功耗，本系統(tǒng)在保證滿足實(shí)時(shí)播放的前提下，對(duì)系統(tǒng)進(jìn)行優(yōu)化。所以，在一個(gè)資源受限的處理器上要實(shí)現(xiàn)多媒體文件的實(shí)時(shí)播放，性能優(yōu)化成為關(guān)鍵。本系統(tǒng)主要通過解碼程序優(yōu)化，打開Cache等措施來提高系統(tǒng)性能。 3．1 對(duì)解碼程序的優(yōu)化 由于解碼過程絕大部分是計(jì)算，以MP3音頻文件為例，其解碼過程主要是高精度乘法和矢量運(yùn)算，其中80％的CPU時(shí)間用于數(shù)值計(jì)算，因此對(duì)于解碼部分主要采用了以下方法進(jìn)行優(yōu)化： (1)整數(shù)運(yùn)算。在沒有硬件浮點(diǎn)單元的CPU上，浮點(diǎn)運(yùn)算是仿真方式，因此解碼代碼中應(yīng)直接采用整數(shù)運(yùn)算方式編碼，而避免浮點(diǎn)運(yùn)算； (2)通過查表方式代替很多運(yùn)算式獲取計(jì)算結(jié)果，對(duì)調(diào)用頻繁的小函數(shù)采用inline修飾； (3)關(guān)鍵代碼采用匯編語言編程，以獲得更高效的目標(biāo)代碼，來提高系統(tǒng)的運(yùn)行性能。 3．2 打開Cache ARM9處理器帶有獨(dú)立的16 kB數(shù)據(jù)Cache和16 kB的指令Cache。本系統(tǒng)中，打開指令Cache肯定能在一定程度上提高性能。至于數(shù)據(jù)Cache，由于從SD卡或者U盤讀進(jìn)來解碼的數(shù)據(jù)使用完畢后就再也不會(huì)使用了，解碼產(chǎn)生的數(shù)據(jù)也是一樣，使用一次就會(huì)被丟棄，因此數(shù)據(jù)訪問的時(shí)間局限性基本是不存在的。但是，系統(tǒng)在訪問數(shù)據(jù)時(shí)存在很強(qiáng)的"空間局限性"，所以打開數(shù)據(jù)Cache后可以提高性能，因?yàn)椋?br /> (1)Cache和IDRAM之間通過Burst方式傳遞數(shù)據(jù)，提高了總線帶寬，從而降低讀數(shù)據(jù)的延遲。 (2)Cache一次讀128bit或256bit，當(dāng)讀已在Cache中的數(shù)據(jù)時(shí)就會(huì)命中。 (3)通過WriteBuffer或WriteBack方式讀內(nèi)存時(shí)，沒有寫DRAM的延遲。 但是這樣也會(huì)帶來數(shù)據(jù)不一致的問題，主要是DMA造成數(shù)據(jù)的不一致，因?yàn)镾D卡或USB的傳輸是通過DMA進(jìn)行的，其傳輸過程無需CPU干預(yù)，DMA操作直接訪問內(nèi)存，但不會(huì)跟新Cache和寫緩存相應(yīng)的內(nèi)容，這樣就造成了數(shù)據(jù)的不一致，可用以下方法解決： (1)將SD卡或USB和CPU共享的控制數(shù)據(jù)空間設(shè)置為uncachable，否則無法保證CPU讀到的Cache中的數(shù)據(jù)是最新數(shù)據(jù)，從而可能造成系統(tǒng)運(yùn)行錯(cuò)誤。 (2)SD卡或USB輸入模塊通過DMA像主存?zhèn)鬏斘募䲠?shù)據(jù)時(shí)，寫數(shù)據(jù)的緩沖區(qū)是由文件系統(tǒng)提供的。該緩沖區(qū)的特點(diǎn)是存儲(chǔ)空間比較大而且是順序訪問的，可將其設(shè)置為cachable。 經(jīng)過上述方法的優(yōu)化以后，系統(tǒng)性能得到了大幅度的提高。經(jīng)過測(cè)試表明，優(yōu)化后解碼所需的時(shí)間為優(yōu)化前的15％左右，均小于正常播放所需的時(shí)間，完全滿足實(shí)時(shí)播放的要求。 4 結(jié)束語 本系統(tǒng)以ARM9處理器為核心建立嵌入式多媒體系統(tǒng)，并在其上移植Mplayer播放器，擴(kuò)展其功能，使mpeg-1、mpeg-2、avi等視頻格式以及MP3、WMA等音頻格式都能在其上流暢地播放，并實(shí)現(xiàn)了影音錄制功能。在測(cè)試中各模塊工作正常，達(dá)到了能全屏播放視頻，流暢播放音頻，能夠?qū)z像頭拍到的視頻傳送到Mplayer進(jìn)行播放，能讀取外接U盤或者SD卡中的多媒體文件進(jìn)行播放，能從網(wǎng)絡(luò)下載多媒體文件到擴(kuò)展存儲(chǔ)設(shè)備被Mplayer播放的設(shè)計(jì)要求。隨著多媒體技術(shù)的廣泛應(yīng)用，掌上多功能媒體播放器會(huì)有更廣闊的應(yīng)用前景。 參考文獻(xiàn) 1. Rodriguez C S.Fischer G.Smolski S.陳莉君.賀炎.劉霞林 Linux 內(nèi)核編程 2006 2. 深圳市優(yōu)龍科技有限公司 ARM9 FS2410P應(yīng)用教程 3. 孫瓊 嵌入式Linux應(yīng)用程序開發(fā)詳解 2006 4. 劉淼 嵌入式系統(tǒng)接口設(shè)計(jì)與Linux驅(qū)動(dòng)程序開發(fā) 2006 5. 倪繼利 QT 及Linux操作系統(tǒng)窗口設(shè)計(jì) 2006 6. 楊水清.張劍.施云非 ARM 嵌入式Linux系統(tǒng)開發(fā)技術(shù)詳解 2008 7. Kamal R.陳曙暉 嵌入式系統(tǒng)一體系結(jié)構(gòu)、編程與設(shè)計(jì) 2006 作者：劉立昶 （武漢大學(xué),物理科學(xué)與技術(shù)學(xué)院） 來源：電子技術(shù) 2009 36(9) |
