基于PDIUSBD12芯片的USB应用开发

一 PDIUSBD12芯片介绍 

　　进行USB开发之前要根据成本与性能选择合适的USB接口芯片。目前USB控制器芯片通常可分成3种： 

　　第一种是专为USB设计的芯片，这类芯片的主要来源是CYPRESS的M8系列和ScanLogic的SL11R系列芯片。这种芯片是为了使用在USB应用设备而特别设计的，而不是在旧的结构上改造出来的，因而其功能的实现能够达到最佳化，但是开发起来比较困难，要学全新的指令集，而且价格较较贵。 

　　第二种是与现有的芯片兼容。大部分和8051系列的芯片兼容，如AMD公司的AM186T和Motorola的68HC05/8。这种芯片的优点是开发者已经熟悉现有芯片的结构和指令集，开发起来会比较容易。 

　　第三种是需要外部微处理器接口的USB芯片。这类芯片只负责处理USB通信，它要和另一块单片机芯片一起工作。典型的主要有NS公司的USBN9603、NetChip公司的NET2888、Philip公司的PDIUSBD11/12等。使用这样的芯片的最大的好处是硬件的结构有很大的灵活性，便于发挥单片机的优良性能，同时价格便宜。 

　　综合考虑了以上几种芯片后，本课题决定选用Philip公司的PDIUSBD12芯片。这样可利用对DSP的熟悉的优势，加快产品的开发进程，同时还能提高系统的可扩展性，便于选择高性能的单片机。本芯片只支持USB1.1协议，对于速度要求高的系统可采用后文提到的支持USB2.0协议的信号转换板。 

　　基于USB1.1的Philip公司的PDIUSBD12芯片结构比较简单，它必须单片机配合才能完成USB通信功能。单片机以读写外部存储器的方式执行PDIUSBD12芯片的通信功能命令。芯片产商将给出其具体的USB操作命令。其管脚图说明如图1： 

图1 PDIUSBD12的管脚图 

　　二 USB-PC104转换板设计 

　　由于嵌入式主板价格昂贵，而在很多应用场合可以用一个成本低的USB外设替代。这里的USB外设意指嵌入式系统本身不能独立运行，需要PC机的软硬件支持。这样的嵌入式系统最先要解决的问题是开发一块USB-PC104信号转换板来替代嵌入式主板。需要转换USB总线与PC104总线的信号的原因在于这样可以让系统既拥有USB设备的优点又有PC104总线设备的高可靠性。采用DSP芯片可以提高系统的速度达到和嵌入式主板总线的要求。 

　　1 硬件设计 

　　硬件设计的主要框图如图2所示： 

图2 转换板硬件主体框图 

　　它的主要工作原理是：从主机的应用程序发出的访问PC-104总线设备的命令，经过底层的USB驱动程序将其转换为相应的USB设备标准要求送到USB接口芯片PDIUSBD12(以下简称D12)，运行于DSP的固件程序接收到这个要求，就会向PC104总线执行相应的命令，从而达到控制PC-104总线硬件的目的。 

　　2 固件程序的开发 

　　固件程序运行在USB外围设备的单片机中，由它响应主机发送过来的USB的各种要求和数据传输。固件的组成主要有两大部分，ISR(中断程序)和主程序。中断程序运行在后台，负责USB芯片与单片机MPU的USB要求中断响应与数据传输，中断程序接收到主机发送来的USB要求和数据后就将它转送给主程序并设置相应的标志位。主程序运行在前台，它根据中断程序传给它的数据及标志位而进行实际的硬件动作。后台ISR中断服务程序和前台主程序循环之间的数据交换通过事件标志和数据缓冲区来实现的。例如PDIUSBD12的批量输出端点可使用循环的数据缓冲区，当PDIUSBD12 从USB收到一个数据包那么就对MPU 产生一个中断请求，MPU立即响应中断。在ISR中固件将数据包从PDIUSBD12内部缓冲区移到循环数据缓冲区并且随后清空PDIUSBD12的内部缓冲区以使能接收新的数据包。MPU可以继续它当前的前台任务，直到完成任务后返回到主循环。同时检查循环缓冲区内是否有新的数据并开始其它的前台任务编写固件程序可用汇编语言或者C语言，用C语言得有KEIL C编译器的支持。但总体上它们的程序框架是一样的。主体程序框架如图3所示： 

图3 固件主程序框架 

　　3 驱动程序开发 

　　由于现代操作系统对内存、端口等资源均采取了保护措施。一般的应用程序不能够直接访问硬件，必须通过设备的驱动程序。设备驱动程序直接和硬件打交道的，并且运行于操作系统核心态，它像操作系统内核一样具有最高的运行权限，所以它可以直接访问硬件。 

USB设备必须使用WDM（Win32 Driver Model）驱动程序模型，它是Microsoft公司定义的WIN32驱动程序模型。WDM是操作系统发展到现在的一种新型驱动程序模型，现在已经成为Windows操作系统驱动程序的主流。 

　　在Windows系统下，和应用程序打交道主要有五层模型：硬件层、硬件抽象层、驱动程序、IO管理层和用户运用程序。从用户应用程序发出的请求一层一层地往下发送。USB的驱动程序还分为客户驱动程序、根集线器驱动程序和总线驱动程序。用户主要开发客户驱动程序即可，蓁其余更底层的操作系统已经为用户准备好。客户驱动程序由一系列的例程(也即一般程序的函数)组成，它没有main()函数入口点。因此，USB设备和驱动程序打交道必须由操作系统的IO管理层参与，它使用了一种全局量叫作IO请求包即IRP。主要工作原理如下： 

　　(1)开始时用户应用程序向驱动程序发出请求(Windows API函数)，并将相关的数据打包成IRP，IO管理器捕获这个IRP包并进行相应的处理。 

　　(2)IO管理器向客户驱动程序发送IRP请求包，请求客户驱动程序进行相应的处理。 

　　(3)客户驱动程序处理完接收到的IRP，设好相关环境后将之传给更底层的驱动程序，最后由总线驱动程序完成对硬件的操作，并将结果返回。 

　　用户要做的事就是开发客户驱动程序。本课题用的是基于WIN2000 DDK的DriverWorks驱动程序开发工具，同时还要VC++6.0编译环境。这种工具可生成驱动程序框架，用户进行修改并加入自己要实现的功能即可，大大缩短了开发的时间。 

　　4 用户应用程序 

　　应用程序是实现硬件功能的全部体现。但应用程序不能直接访问USB设备，它必须先与驱动程序通信，通过驱动程序来访问USB设备。它的工作是向硬件发送数据或命令，这些数据和命令由驱动程序经过层层处理，最后发送到硬件实现相关的动作。应用程序与驱动程序打交道主要是通过操作系统的API函数。 

　　其工作原理如下： 

　　(1)应用程序通过调用CreateFile API函数取得USB设备的句柄。该符号链接包含一个全域惟一标识符（globally unique idenTIfier,GUID）。GUID是一个128位的号码，Windows用来惟一识别一个设备对象。 

　　(2)通过这个句柄，应用程序通过调用ReadFile和WriteFile API函数来读写USB设备，将数据返回到用户缓冲区。 

　　(3)通过这个句柄，应用程序通过调用DeviceIoControl API函数来向USB设备发出控制命令，以实现特定的要求，这个函数还可能有相应的数据传输。 

　　(4)应用程序处理从USB设备接收到的数据，如果出错，将给出相应的警告，如果成功，处理完后关闭设备的句柄。