首页 > 电子设计 > 电源技术 > 电源技术 > 基于DSP／BIoS设备驱动模型的视频驱动程序开发

基于DSP／BIoS设备驱动模型的视频驱动程序开发

录入：edatop.com 点击：

通过给外部设备编写驱动程序是一种有效的控制外设的方法。随着DSP的应用越来越广泛，DSP实时系统的日趋复杂及新技术的出现，DSP处理器所连接的外部设备也是种类繁多，各不相同，而每一个外设都需要一个特定的驱动程序来支持外设的正常工作，这就要为每一个外设编写驱动程序，这是一项十分繁杂的工作。如何能够使系统开发人员从这些编写繁杂的驱动程序工作中解脱出来，进而能够专心投入到应用程序的开发中呢 TI公司提出了基于DSP／BIOS的设备驱动模型，该模型分为两层：类驱动即与硬件不相关的层和微型驱动即与硬件相关的层。使用这种结构，应用程序只需调用类驱动的API函数，通过类驱动使用微型驱动，用微型驱动来控制外设。这种结构，将驱动程序合理分层，使得驱动程序模块化，可移植性、复用性大大增强，缩短了驱动程序的开发时间。

1 DSP／BIOS设备驱动模型工

1.1 类／微型驱动模型

DSP／BIOS是TI公司所设计开发的一个尺寸可裁剪的实时多任务操作系统内核，通过使用DSP／BIOS提供的丰富的内核服务，开发者能快速地创建满足实时性能要求的精细复杂的多任务应用程序。为了使开发设备驱动更加简单方便，提出了DSP／BIOS DeviceDriver Kit，定义了标准的设备驱动模型，一种将设备驱动分为与硬件无关和与硬件相关的双层结构，这样就使开发驱动程序不像以前那样复杂了，为开发者提供了便利。这两层结构称为“类／微型驱动模型，它们每一层都有各自通用的接口，所以相似设备驱动程序的主要部分可以复用，驱动代码的移植成为可能，使开发驱动的过程大大简化。

与硬件无关的层称为类驱动(Class Driver)，它处在应用程序与微型驱动之间，提供对多线程I／O请求的串行化和同步，并且维护设备数据缓冲区，向上提供API接口供应用程序调用，向下通过适配层与微型驱动相连，实现API接口函数到微型驱动层的映射。

与硬件相关的层称为微型驱动(Mini－driver)，它处在类驱动与芯片支持库(Chip Support Library)之间，对于类驱动的接口是统一的，即每一个微型驱动都为类驱动和DSP／BIOS设备驱动管理提供了标准接口。微型驱动采用芯片支持库(CSL)管理外围设备的寄存器、内存和中断资源。但由于硬件是千差万别的，所以微型驱动对底层硬件的操作是根据硬件的不同而不同的。对于完成同样功能的不同外设，只需稍加修改微型驱动，而不需重新编写驱动程序，就可以实现驱动程序的移植与复用，使驱动程序的开发过程大大简化。类／微型驱动模型结构如图1所示。

闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鐐劤缂嶅﹪寮婚悢鍏尖拻閻庨潧澹婂Σ顔剧磼閻愵剙鍔ょ紓宥咃躬瀵鎮㈤崗灏栨嫽闁诲酣娼ф竟濠偽ｉ鍓х＜闁绘劦鍓欓崝銈囩磽瀹ュ拑韬€殿喖顭烽幃銏ゅ礂鐏忔牗瀚介梺璇查叄濞佳勭珶婵犲伣锝夘敊閸撗咃紲闂佽鍨庨崘锝嗗瘱闂備胶顢婂▍鏇㈠箲閸ヮ剙鐏抽柡鍐ㄧ墕缁€鍐┿亜韫囧海顦﹀ù婊堢畺閺屻劌鈹戦崱娆忓毈缂備降鍔岄妶鎼佸蓟閻斿吋鍎岄柛婵勫劤琚﹂梻浣告惈閻绱炴笟鈧妴浣割潨閳ь剟骞冨▎鎾崇妞ゆ挾鍣ュΛ褔姊婚崒娆戠獢婵炰匠鍏炬稑鈻庨幋鐐存闂佸湱鍎ら〃鎰礊閺嶃劎绡€闂傚牊渚楅崕鎰版煛閸涱喚鍙€闁哄本绋戦埥澶愬础閻愬樊娼绘俊鐐€戦崕鏌ユ嚌妤ｅ啫鐓橀柟瀵稿仜缁犵娀姊虹粙鍖℃敾妞ゃ劌妫濋獮鍫ュΩ閳哄倸鈧鏌﹀Ο渚Ш闁挎稒绋戦埞鎴︽倷閺夋垹浜堕梺鐟扮－閸嬨倕鐣烽崼鏇ㄦ晢濞达綁鏅茬紓鎾剁磽閸屾瑧顦︽い鎴濇嚇閹ê鈹戠€ｎ偄鈧灚銇勯幘璺烘瀺缂佽妫濋弻鏇㈠醇濠靛牏顔婇梺鍛婂笂閸楁娊寮诲☉銏″亞濞达綁鏅茬花鐣岀磽娓氬洤鏋︽い鏇嗗洤鐓″璺好￠悢鑽ょ杸闁规儳澧庢闂備浇妗ㄩ悞锕傚礉濞嗗繒鏆﹂柕濞炬櫓閺佸﹪鎮规笟顖滃帥闁衡偓閵娧呯＝闁稿本鑹鹃埀顒勵棑缁牊绗熼埀顒勩€侀弽顓炵妞ゆ牗绋戝▓鎴︽⒑閸涘﹥灏柣鎺炵畵閿濈偤寮撮姀锛勫幍闂佺顫夐崝锕傚吹濞嗘垹妫柟顖嗗啯鍊梺閫涚┒閸斿矂锝炲⿰鍫濆耿婵°倐鍋撴鐐差儔濮婅櫣绮欏▎鎯у壉闂佸湱鎳撳ú顓㈢嵁閸愩劉鍫柛顐ゅ枎濞堢喖姊洪棃娑辨Ф闁稿寒鍣ｅ畷鎴﹀箻鐠囨煡鏁滃┑掳鍊撻懗鍫曞矗閸℃稒鈷戦柛婵嗗婢跺嫭鎱ㄥΟ绋垮鐎规洘绻傞鍏煎緞鐎ｎ剙骞嶉梻浣告啞閸旀ḿ浜稿▎鎾村€块柛娑橈攻閸欏繐鈹戦悩鎻掝伀閻㈩垱鐩弻鐔风暋閻楀牆娈楅悗瑙勬磸閸斿秶鎹㈠┑瀣＜婵炴垶鐟ч弳顓㈡⒒閸屾艾鈧嘲霉閸パ呮殾闁汇垻枪缁愭鏌涢埄鍐槈缁炬儳娼￠弻鐔煎箚閻楀牜妫勭紓浣哄У閻擄繝寮婚弴锛勭杸闁哄洨鍎愰埀顒€鏈换娑氱箔閸濆嫬顫囬梺鍝勮嫰缁夌兘篓娓氣偓閺屾盯骞樼€靛憡鍣板銈冨灪瀹€鎼佸极閹版澘骞㈡繛鍡樺灩濡插洦绻濆▓鍨灍闁挎洍鏅犲畷銏ゅ礂閼测晩娲稿┑鐘诧工閹虫劗澹曟總鍛婄厽闁逛即娼ф晶顔姐亜鎼淬垻鐭婃い顏勫暟閳ь剚绋掕摫闁稿﹥鍔楅埀顒侇問閸犳鎮￠敓鐘偓浣肝旈崨顓狀槹濡炪倖鍨兼慨銈団偓姘偢濮婄粯鎷呴崨濠呯闁哄浜濈换娑㈠箻椤曞懏顥栫紓渚囧枛椤兘鐛Ο灏栧亾闂堟稒鎲告い鏃€娲熼弻锝夋偐閸欏宸堕梺鍛婁緱閸樺ジ鎮￠崒鐐粹拺閺夌偞澹嗛ˇ锕傛煟濡も偓閿曘儳绮氭潏銊х瘈闁搞儺鐏涜閺屾稑鈽夐崡鐐寸亪濠电偛鎳岄崐婵嗩潖閾忓湱鐭欐繛鍡樺劤閸擃剟姊洪崨濠冨鞍缂佽瀚伴獮鎴﹀閻橆偅鏂€闂佹悶鍎弲婵嬫儊閸儲鈷戠紒瀣濠€鎵磼鐎ｎ偄鐏ラ柍璇茬Ч閺佹劙宕担鐟扮槣闂備線娼ч悧鍡欐崲閹烘绀嗗ù鐓庣摠閻撳繘鏌涢銈呮瀾闁稿﹥鍔栭〃銉╂倷閹绘帗娈茬紓浣稿€圭敮鐐哄焵椤掑﹦鍒伴柣蹇斿哺瀵煡顢楅埀顒勫煘閹达附鍊烽柡澶嬪灩娴犳悂鏌﹂崘顔绘喚闁诡喖缍婂畷鍫曞煛娴ｉ攱顫曟繝娈垮枛閿曘劌鈻嶉敐澶婄闁绘ǹ顕ч悘鎶芥煣韫囷絽浜炲ù婊冪埣濮婄粯鎷呴挊澶婃優闂侀潻缍囬梽鍕┍婵犲洤鐐婃い鎺嗗亾缂佺姵鐓￠弻鏇＄疀閺囩倫娑㈡煛閳ь剚绂掔€ｎ偄鈧敻鏌ㄥ┑鍡欏嚬缂併劋绮欓弻娑欑節閸曨偂妲愬┑顔硷攻濡炶棄螞閸愵煁褰掑Χ閸℃瑦鍒涢悗瑙勬礃閿曘垺淇婇幖浣肝ㄦい鏃囨閺嬬姵绻濋悽闈浶ラ柡浣告啞閹便劑鎮滈挊澶嬬€梺鍛婄☉閿曘儵宕ｈ箛娑欑厽闁硅揪绲鹃ˉ澶愭煛鐎ｂ晝绐旈柡宀€鍠栧鑽も偓闈涘濡差喚绱掗悙顒€绀冩い顐㈩樀婵＄敻宕熼姘敤濡炪倖鍔﹀鈧紒顔肩埣濮婅櫣绱掑Ο铏圭懆闂佽绻戝畝鍛婁繆閻㈢ǹ绀嬫い鏍ㄦ皑椤斿﹪姊洪悷鎵憼缂佽绉电粋鎺楁嚃閳哄啰锛滈梺缁樺姦閸撴瑩宕濋妶鍡愪簻妞ゆ挾濮撮崢瀵糕偓娈垮枛椤兘骞冮姀銈嗗亗閹艰揪缍嗗Σ鍫曟煟閻斿摜鐭婄紒缁樺浮瀵偊顢欑亸鏍潔闂侀潧楠忕槐鏇㈠储娴犲鈷戦悷娆忓閸斻倖銇勯弴銊ュ箹閻撱倝鏌熺紒銏犳灍闁绘挻鐟﹂妵鍕籍閸屾粍鎲樺┑鐐茬墛缁捇寮婚埄鍐╁闁荤喐婢橀～宥夋⒑鐠団€崇仭婵☆偄鍟村畷瑙勩偅閸愨晛娈ゅ銈嗗笂閻掞箑鈻嶉敃鈧埞鎴︽偐閸偅姣勬繝娈垮櫘閸欏啴鐛箛娑樼妞ゆ棁鍋愰ˇ銊ヮ渻閵堝懐绠伴柛鐔哄閵囨瑩骞庨懞銉㈡嫽婵炴挻鍩冮崑鎾绘煃瑜滈崜姘辩矙閹捐鐓橀柟鐑橆殕閻撴洟鏌￠崒婵囩《閼叉牠姊洪悷鎵暛闁搞劌缍婇崺鐐哄箣閻橆偄浜鹃柨婵嗙凹缁ㄨ崵绱掗幇顓犫槈妞ゎ亜鍟存俊鍫曞幢濡⒈妲梻浣烘嚀閸熻法绮旈悷鎵殾妞ゆ劏鎳￠弮鍫濆窛妞ゆ棁顫夌€氳棄鈹戦悙鑸靛涧缂佽弓绮欓獮澶愭晬閸曨剙顏搁梺璺ㄥ枔婵敻鎮″▎鎾寸叄闊浄绲芥禍婵嬫倶韫囨洘鏆柡灞界Х椤т線鏌涢幘纾嬪妞ゎ偅绻堟俊鎼佹晜閼恒儳褰挎繝寰锋澘鈧捇鎳楅崼鏇炵厴鐎广儱鎳夐弨浠嬫煟濡搫绾ч柟鍏煎姉缁辨帡鎮╅崹顐㈡畬闂傚洤顦甸弻銊モ攽閸℃瑥顣洪梺閫炲苯鍘哥紒顔界懄娣囧﹪骞栨担鍝ュ幐闂佺ǹ鏈划灞筋嚕閹惰姤鈷掑ù锝呮啞閹牓鏌涢悢鍝勨枅鐎规洘鍨块獮妯肩磼濡厧骞堥梺纭呭閹活亞妲愰弴銏℃櫖鐎广儱娲ㄧ壕濂稿级閸碍娅呭ù鐘洪哺椤ㄣ儵鎮欓弶鎴犵懆闁剧粯鐗曢湁闁挎繂鎳庣痪褔鎮楀顐ょ煓婵﹦绮幏鍛村川闂堟稓绉虹€殿喚鏁婚、妤呭礋椤掆偓娴狀參姊洪棃娴ュ牓寮插☉姘辩焼闁稿本澹曢崑鎾诲礂婢跺﹣澹曢梻浣告啞濞诧箓宕滃☉銏犲偍闁汇垹鎲￠埛鎴︽煙椤栧棗瀚々浼存⒑缁嬫鍎忛柟鍐查叄閹儳鐣￠幍顔芥畷闂侀€炲苯澧撮柛鈹惧亾濡炪倖甯掗崰姘缚閹邦厾绠鹃柛娆忣槺閻帞鈧鍣崑鍡涘箯閻樺樊鍟呮い鏂垮悑椤撳灝鈹戦悙宸殶濠殿喗鎸抽、鏍箛閺夋寧鐎梺鎼炲労閸撴岸鎮￠悢鍏肩厵闂侇叏绠戝楣冩煕閻旈绠婚柡灞剧洴閹瑩宕归锝嗙槗婵犳鍠栭敃锔惧垝椤栫偛绠柛娑樼摠閸ゅ秹鏌曟竟顖欒閸嬫挻绻濋崶銊㈡嫼闂傚倸鐗冮弲婵堢矓閸撲胶纾奸柣妯挎珪瀹曞矂鏌ｅ☉鍗炴灕缂佺姵绋戦埥澶娾枎閹邦収浠ч梻鍌欐祰濞夋洟宕抽敃鍌氱闁跨噦鎷�...

1.2 类驱动

通过将应用软件，驱动程序分层之后，可以看到，位于顶层的应用程序并不直接与微型驱动产生联系，而是通过类驱动与微型驱动连接。每一种类驱动向上层应用程序提供一个API接口，并且与微型驱动接口进行通信。

DSP／BIOS定义了三种类驱动：流输入输出模块(SIO)，管道管理模块(PIP)，通用输入输出模块(GIO)。其中，SIO和PIP分别需要使用适配器DIO和PIO来与微型驱动进行通信。SIO／DIO是基于流的I／O模型，使用异步方式来操作I／O，对于数据的读写、处理可以同时进行。PIP／PIO是基于管道的I／O模型，每个管道维护着一个被划分为多个大小相同的帧的缓冲区。GIO类驱动采用基于流的同步I／O数据传输模式，适合大流量数据的传输，更适合文件系统。与SIO／DIO和PIP／PIO不同，GIO包含内置的IOM(I／OManager输入输出管理)适配层，可以直接与微型驱动进行通信。

GIO模块与其他两个模块相比，有一个很重要的特性，就是可以扩展API函数支持新的应用领域，这样就实现了对GIO类驱动的扩展。这种可扩展API的特性正好可以用在视频驱动开发方面。例如这种扩展可以满足视频设备存储区的需要。另外，在提供了视频驱动和应用程序之间的视频数据同步机制之后，这种扩展也能够允许使用一个单独的调用来“交换”视频缓冲区。这种交换缓冲区的机制对于实时视频信号的采集与显示是十分重要的。所以，在视频驱动中，我们采用通用输入输出模块GIO。应用程序可以直接地调用GIO API函数和IOM微型驱动程序进行交互，这些GIO API就可以看作是类驱动。GIO类驱动接口如图2所示。

GIO_create会为一个特定的IOM通道实例创建一个GIO对象，这是类驱动使用微型驱动的第一步，首先创建对象及IOM通道，然后在此通道上进行数据传输工作。其结构体类型为GIO_Obj：

1.3 微型驱动 [p]

微型驱动主要通过一些函数来完成对外部设备的直接控制。只要微型驱动创建了规定的函数，应用程序就可以方便地通过DIO适配模块、PIo适配模块或(和)GIO类驱动调用。

例如：GIO_create被调用时，会运行mdCreate-Chan来创建一个通道。

这些微型驱动函数包括：mdBindDev／mdUBind-Dev(绑定／删除通道函数)：在程序建立接口时调用，完成设备的初始化硬件设备／在程序结束时调用，卸载设备。mdCreateChan／mdDeleteChan(创建／删除通道)：需要在应用程序与设备实例之间创建一个逻辑通信通道，用于交换驱动数据。应用程序可创建一个或多个逻辑通道，微型驱动用通道对象来代表这些通道。这两个函数就是用来分配和释放通道对象。mdSubmitChan(递交I／O请求)：该函数处理传递给它的IOM_Pack-et结构体中的命令代码(cmd)，根据命令代码，完成相应的处理或返回错误代码。ISR(服务设备中断并完成I／O操作)：IOM微型驱动在中断的ISR中将以处理完的IOM_Packet请求出队，启动下一次传输或服务请求，调用类驱动的回调函数与应用程序进行同步，并返回出队的IOM_Packet。mdControlChan(控制设备)：用来操作外部设备。

这些微型驱动的函数入口放在接口表(IOM_Fxns)中，供适配模块或GIO类驱动调用。

2 TMS320DM642视频驱动

下面以TMS320DM842芯片为例，介绍有关TMS320DM642视频采集与显示的驱动程序的开发。通过编写驱动程序，完成视频信号的实时采集与显示功能。TMS320DM642是TI公司推出的一款专门用于视频／图像处理的定点数字信号处理器，它基于C64x内核，带有3个可配置的视频端口，与视频采集芯片直接相连，无需外加逻辑电路或FIFO缓存，只需编写相关解编码芯片的驱动程序，就可以完成视频信号的采集与显示。在这里使用的解码、编码芯片分别为PHILIPS SAA7115和SAA7105。

2.1 视频类驱动

在视频驱动程序结构中，为了最大程度地提高视频驱动代码的复用性和通用性，将类驱动又划分为两层结构，其中上层为FVID模型，它是在DSP／BIOS GIO类驱动之上的简单封装，下层是GIO类驱动程序。GIO类驱动提供独立的、一般的API函数集并且为微型驱动提供广泛的服务，而上层的FVID模型向上层的视频采集、显示结构提供定制的API函数。

在视频驱动中，主要是通过调用FVID模块函数来完成类驱动代码的编写工作。FVID主要有以下几个API函数：FVID_create：分配并初始化通道对象；FVID_control：向微型驱动发送控制命令；FVID_al-loc：向应用程序分配视频端口缓冲区；FVID_ex-change：交换缓冲区；FVID_free：释放缓冲区；FVID_delete：删除通道对象。

在配备视频接口的设备驱动时，至少指定它要开设3个以上的视频缓冲区(FVID模型中，默认分配3个缓冲区)，帧缓冲区通过FVID_alloc()，FVID_free()，FVID_exchange()三个函数在应用程序与驱动之间交换。

2.2 视频微型驱动

视频微型驱动也分为两层结构，上层为通用视频端口层部分，下层为指定编解码芯片微驱动层部分，它们通过外部设备控制接口(External Device Control，EDC)实现对外围芯片的操作。这种微驱动结构的好处是，当使用不同的芯片时，只需修改指定编解码芯片微驱动那一部分，不需将整个微驱动重新编写，使得驱动的复用性大大增强。

视频驱动程序模型如图3所示。

2.3 TMS320DM642视频驱动设计步骤

2.3.1 注册微型驱动

由于应用程序、类驱动最终都是要通过微型驱动的函数来完成对外部设备的直接控制，所以驱动程序设计的第一步就是要在DSP／BIOS Config中的Input／Output->Device Drivers->Uger-Defined Devices项目添加设备并注册微驱动，进行属性的设置，并指明IOM_Fxns函数表地址和设备参数地址，如图4所示。

DSP／BIOS会在内部维护一个“设备表”，其中包含User-Defined Devices对象进行配置的设备实例。

2.3.2 编写类驱动代码

FVID函数会在设备表中查找已注册的微驱动，并调用微驱动函数完成对外部设备的操作控制。 [p]

通常，首先利用FVID_create函数完成分配并初始化通道对象，返回值为设备实例句柄，这个句柄用于后续其他FVID函数调用这个已经创建的通道。然后调用FVID_control函数向微型驱动发送控制命令，如配置编解码器，发送开始采集或显示图像的控制命令。然后利用FVID_alloc分配缓冲区，接着应用程序将缓冲区的数据进行复制的搬移工作，当应用程序完成对缓冲区数据的采集后，调用FVID_exchange来交换缓冲区，保证视频数据能够实时地、源源不断地供应用程序使用。

过程的流程图如图5所示。

下面是简单的视频采集显示驱动的部分实现代码：

3 结语

本文介绍了基于TI公司的类／微型驱动模型进行视频驱动设计的原理及主要方法，利用这两层的驱动模型不仅简化了驱动程序的编写过程，缩短了开发时间，而且使代码的复用性和可移植性大大提高，稍加改动相应的底层接口就可以用于其他的DSP系统中，真正使视频驱动的开发过程得到简化。

射频工程师养成培训教程套装，助您快速成为一名优秀射频工程师...

天线设计工程师培训课程套装，资深专家授课，让天线设计不再难...

上一篇：一种嵌入式视频记录系统的设计与实现
下一篇：DSP的SPI口和串行EEPROM在变频器中的应用