《CDC类虚拟串口固件设计 毕业论文.doc》由会员分享，可在线阅读，更多相关《CDC类虚拟串口固件设计 毕业论文.doc（41页珍藏版）》请在三一文库上搜索。
1、CDC类虚拟串口固件设计学 院计算机学院专 业计算机科学与技术班 级7401101学 号200704011027姓 名 指导教师 负责教师沈阳航空航天大学2011年6月 摘 要在接口技术高速发展的今天，串口即将成为历史。USB等接口将逐步取代串口成为新一代最常用的接口。然而，由于之前串口较为普及，针对串口的应用程序也非常多，而且有些功能还非常强大，如何能够最大限度地减少接口更新对应用程序的影响，成为了当今接口技术的一个新课题。本文就基于USB的CDC类，在带有USB口的C8051F340单片机上，以开发USB虚拟串口固件为目标，通过标准请求、设备管理、数据传输等模块的设计与论证，并结合固件开发
2、的实际，完成了USB到虚拟串口的转换的设计。本文的核心是建立ACM模型，即抽象控制模型。根据这个模型，对CDC类下的通信接口类和数据接口类进行设计开发，并着重对通信接口和数据接口的各个端点进行设计论证。在此基础上，实现对USB设备的枚举，控制以及数据传输等功能，从而为实现USB到虚拟串口的转换提供了保证。关键词：USB；虚拟串口；CDC；抽象控制模型The Design of a Virtual Serial Port Firmware Based On Communication Device ClassAbstractNowadays, as the interface technolog
3、y develops in a high speed, the serial port is going to be history. Interface such as USB will replace serial port gradually and be the most common one in a new generation. However, since the widely spreading of serial port in past with great deal of development programs of serial port, and some fun
4、ctions are powerful, it has been a new problem that how to reduce the influence caused by interface update to application program to the maxima limit. The paper focuses on how to convert Universal Serial Bus (USB) to a serial port in the C8051F340 microcontroller with USB port. In order to realize t
5、he function of virtual serial port, we combine with the actual firmware, design and demonstrate the standard request, device management and data transmission moduleThe core of this paper is to establish an ACM , that is the Abstract Control Model. Based on this model, the data communication interfac
6、e class and interface class which under the CDC are designed and developed. Focusing on the various endpoints which are included in the communication interface and data interface it has a demonstration. On this basis, it have realized the enumeration and control on the USB device, also, data transfe
7、r capabilities. Thus, it guarantees the alteration from USB to virtual serial port.Keywords: USB; virtual serial port; Abstract Control Model目 录1 引言11.1 课题背景11.2 课题要求11.3 课题意义22 相关技术及开发工具32.1 CDC类简述32.2 C8051F340单片机简介32.3 开发环境简介43 总体设计63.1 应用软件的模块设计73.2 应用软件的功能设计74 详细设计104.1 标准请求104.1.1 设备描述符104.1.2
8、 配置描述符114.1.3 接口描述符124.1.4 端点描述符134.1.5 字符串描述符144.1.6 描述符设计要求144.1.7 标准命令154.2 类请求的实现174.2.1 SEND_ENCAPSULATED_COMMAND请求174.2.2 GET_ENCAPSULATED_RESPONSE请求174.2.3 GET_LINE_CODING 请求174.2.4 SET_LINE_CODING 请求184.2.5 SET_CONTROL_LINE_STATE请求194.3 数据传输的实现194.3.1 令牌包194.3.2 数据包204.3.3 握手包204.3.4 数据传输204
9、.4 INF文件的创建214.4.2 INF文件的规范234.4.3 INF文件的内容235 联机调试265.1 调试设置265.2 下载调试266 固件测试及结论306.1 串口调试工具设置316.2 数据传输测试316.3 结论31参考文献33致 谢35 IV沈阳航空航天大学毕业设计（论文）1 引言现代嵌入式系统中，异步串行通信接口往往作为标准外设出现在单片机和嵌入式系统中。但是随着个人计算机通用外围设备越来越少地使用串口，串口正在逐渐从个人计算机特别是便携式电脑上消失。而现在的个人计算机普遍拥有4个以上的USB接口，使用USB接口代替串口，完成PC机和嵌入式系统的通信也就成为了当今接口技
10、术发展的一个重要课题。1.1 课题背景当下越来越多带USB接口的器件涌现出来，如带USB接口的单片机，或独立的USB接口器件，而且这些器件的成本已经很接近于使用RS-232电平转换芯片所带来的成本。市场上也出现了一些USB接口转串口的芯片，这些芯片一头为串口，另一头为USB接口，在其内部完成串口到USB协议的转换。该芯片通过USB口连接到个人计算机后，在操作系统中表现为一个串口设备，这意味着USB接口对于传统的串口调试工具（Hyper Terninal）和用户基于串口的应用程序是透明的，开发人员完全不用更改PC端的调试和应用程序。但是这些器件的USB类不属于标准的USB设备类，因此需要在Win
11、dows和Linux操作系统上安装额外的设备驱动。另外，由于不是操作系统自带的设备驱动，而且通信经过了由串口到串口，从USB设备到USB主机的多次转换，当调试遇到问题时常常无法确定是串口出了问题还是USB出了问题。因此，应该使嵌入式系统直接和PC通过USB总线接口连接（通过片上的USB接口或片外USB接口芯片），由单片机直接完成USB虚拟串口的协议转换。而现在的个人计算机普遍拥有多个USB接口，如能使用USB接口代替串口，则可为PC机与嵌入式系统之间的通信提供方便。1.2 课题要求本课题要求在熟悉C8051F340单片机工作原理和开发环境以及USB通信协议和CDC类工作原理的基础上，在带有US
12、B接口的C8051F340单片机上实现基于CDC类的USB虚拟串口功能。此外，要求对这个虚拟串口固件进行数据传输测试，验证其实用性、准确性。1.3 课题意义在USB标准子类中，有一类称之为CDC类，可以实现虚拟串口通信的协议，而且由于大部分的操作系统（Windows和Linux）都带有支持CDC类的设备驱动程序，可以自动识别CDC类的设备，免去了写专用设备驱动程序的负担，为USB代替串口的实现提供了可能。在单片机上实现基于CDC类的USB虚拟串口很好地适应了当前计算机外设接口的发展，同时因为这样的接口在PC操作系统中仍然映射为一个串口，所以又避免了大量的PC端调试程序和应用程序的重新编写。2
13、相关技术及开发工具为了更好地进行虚拟固件的设计开发，在设计应用软件设计之前，需要对CDC类的原理、C8051F340单片机的相关理论以及软件开发工具作简要的叙述。2.1 CDC类简述USB为了实现不同的应用，将具有特定属性与服务的一类设备划分为一个Class。如果提供相似格式数据流或者相似的主从机交换方式，两个设备则被统一在一个Class中。如USB标准就有Audio Class、Communication Device Class、HID Class、Video Class等用于在USB接口上实现不同设备接口。在USB标准协议中，有一类专用于通讯设备(主要包括电信通信设备和中速网络通信设备)
14、的CDC协议，可以通过该协议实现将USB接口虚拟为其他通讯接口。USB的CDC类是USB通信设备类（Communication Device Class）的简称。根据CDC类所针对通信设备的不同，CDC类又被分成以下不同的模型：USB传统纯电话业务（POTS）模型，USB ISDN模型和USB网络模型。其中，USB传统纯电话业务模型，又可分为直接线控制模型（Direct Line Control Model）、抽象控制模型（Abstract Control Model）和USB电话模型（USB Telephone Model）。本文所讨论的虚拟串口就属于USB传统纯电话业务模型下的抽象控制模型
15、（Abstract Control Model）。CDC协议由三个子类组成：通信设备类（Communication Device Class）、通信接口类（Communication Interface Class）和数据接口类（Data Interface Class）。通信设备类是设备层次的定义，通常用于标示一个通信设备，该设备可以提供相应的接口。通信接口类则定义了相应的通信服务，包括如何对设备进行管理和控制。数据接口类则定义了如何传送数据。2.2 C8051F340单片机简介C8051F340单片机是美国Silicon Laboratories公司推出的完全集成的混合信号片上系统型MCU
16、。它具有以下特性和资源：高速、流水线结构的8051兼容的微控制器内核（可达48MIPS）；全速、非侵入式的在系统调试接口（片内）；通用串行总线(USB)功能控制器，8个灵活的端点管道，集成收发器和1K FIFO RAM；10位200ksps的单端/差分ADC，带模拟多路器；片内电压基准和温度传感器；精确校准的12MHz内部振荡器和4倍时钟乘法器；多达64KB的片内FLASH存储器；多达4352字节片内RAM（256+4KB）；多达40个端口I/O（容许5V电压输入）。具有片内上电复位、VDD监视器、电压调整器、看门狗定时器和时钟振荡器的C8051F340器件是真正能独立工作的片上系统。其FLA
17、SH存储器还具有在系统重新编程能力，可用于非易失性数据存储，并允许现场更新8051固件。用户软件对所有外设具有完全的控制，可以关断任何一个或所有外设以节省功耗。图2.1 C8051F340单片机功能框图2.3 开发环境简介Keil C51 是美国Keil Software 公司出品的51 系列兼容单片机C 语言软件开发系统，与汇编相比，C 语言在功能上、结构性、可读性、可维护性上有明显的优势，因而易学易用。用过汇编语言后再使用C语言来开发，体会更加深刻。Keil C51 提供了包括C编译器、宏汇编、连接器、库管理和一个功能强大的仿真调试器等在内的完整开发方案，通过一个集成开发环境（uVisio
18、n）将这些部份组合在一起。软件除提供丰富的库函数和功能强大的集成开发调试工具外，又是全Windows界面。另外重要的一点，只要看一下编译后生成的汇编代码，就能体会到Keil C51生成的目标代码效率非常之高，多数语句生成的汇编代码很紧凑，容易理解。在开发大型软件时更能体现高级语言的优势。3 总体设计按照USB的CDC类协议，实现虚拟串口需要建立抽象控制模型（Abstract Control Model），即ACM模型。而这个模型的实现，又需要建立在两个子类接口上，它们是通信接口类（Communication Interface Class）和数据接口类（Data Interface Class
19、）。一个ACM功能设备，也应该具有CDC类应该具备的三种基本的职责：(1)设备管理(Device Management)；(2)通话管理(Call Management)；(3)数据传输(Data Transmission)。CDC类设备通常用通信接口去完成设备管理，由数据接口去完成数据传输。而通话管理可以由通信接口去完成，也可以由数据接口去完成，依具体的情况而定。不过ACM功能大多是通过数据接口来完成通话管理的。通过这个模型，我们架构出这么一个设备：这个USB设备由通信接口类和数据接口类组成。通信接口类需要一个控制端点(Control Endpoint)和一个可选的中断(Interrupt)
20、端点，数据接口类需要一个方向为输入(IN)的批处理端点和一个方向为输出(OUT)的批处理端点。其中控制端点主要用于USB设备的枚举和虚拟串口的波特率和数据类型(数据位数、停止位和起始位)设置的通信。输出（OUT）方向的批处理端点用于主机(Host)向从设备(Device)发送数据，相当于传统物理串口中的TXD线；输入（IN）方向的批处理端点用于从设备向主机发送数据，相当于传统物理串口中的RXD线。而为了简化开发的难度，而又可以不影响功能，故没有实现通话管理。在PC端，由于Windows2000以上系统已经提供了usbser. sys驱动去支持CDC类设备，因此我们只要将设备按照规定的类协议去设
21、计，驱动就不需要我们去开发了。对于应用程序，完全可以移植过来直接使用，我们需要设置的仅仅是将这个应用程序对应的COM口改为所要实现的USB设备在PC端映射的串口即可。不过，由于Windows操作系统的要求，我们还须提供一个INF文件给PC操作系统，这样USB的这个虚拟串口才能安装在PC机上。3.1 应用软件的模块设计任何一个设备功能的实现都必须完成控制传输。这种传输在USB中是非常重要的，它要保证数据的正确性，在设备的枚举过程中都是使用控制传输。控制传输包括三个过程：建立（SETUP）过程、可选的数据过程和状态过程。建立过程都是由USB主机发起的。它开始于一个SETUP令牌包，后面紧跟一个DA
22、TA0数据包，接着就是数据过程。如果是控制读传输，那么数据过程就是输入数据；如果是控制写传输，那么数据过程就是输出过程。数据过程之后是状态过程。状态过程是用来确认所有的数据是否都已经正常传输完成。状态过程刚好与数据过程的数据传输方向相反：如果是控制读传输，则状态过程是一个输出数据包；如果是控制写传输，则状态过程是一个输入数据包。CDC类设备的实现，除了对设备进行枚举之外，还需要完成类请求，进而完全地实现虚拟串口的功能。因此，软件的开发也涉及到三个模块，一个模块用来完成标准请求，一个模块用来完成设备管理，一个模块用来完成串口数据传输。任何一个USB控制器，都会提供一些中断寄存器，通过判断中断寄存
23、器中相应的中断位，确认相应的中断源，进而执行相应的操作。这里，我们没有采用中断的方式来判断USB控制器的中断寄存器，而是通过轮询的方式来实现的，通过不断地轮询寄存器获取中断的相关信息。程序流程如图3.1所示。3.2 应用软件的功能设计按照CDC类抽象控制模型对端点的需求，将单片机0号端点和1号端点分配给通信接口子类，分别作为控制端点（完成枚举和串口参数设置）和中断端点，而将2号和3号端点分配给数据接口子类，分别作为IN和OUT端点，虚拟串口的数据主要从这两端点来进行传送。由于各个端点的行为相对独立，对于每个端点的控制过程又有相似性，在这里以2号端点即作为数据接口的IN端点为例，说明软件是如何对
24、端点进行操作和控制的，其控制流程图如图3.2所示。图3.1 轮询方式流程2号端点是一个IN的端点，它的主要工作是模拟物理串口的TXD线，向主设备发送数据。当主设备发出IN的请求时，如果FIFO不空，就向主设备发送FIFO的内容；如果FIFO为空，则向主设备发送一个空包作为回应。C8051F340单片机在收到IN的请求时，会触发USB中断，在中断处理程序中，如图3.2所示，首先判断中断的触发源是哪个端点，如果是2号端点，将USB寄存器组映射到2号端点的那一组，然后将需要发送的串口数据填入FIFO寄存器，置TXReady位，表示FIFO中的数据已经准备好，这时USB接口就会自动响应IN请求，并将F
25、IFO中的数据发送出去，程序则可退出中断服务程序。对于其他的端点，其处理过程也是相似的。图3.2 端点控制流程4 详细设计应用软件主要分为三个模块：标准请求、设备管理、串口数据传输。以下就这三个模块做具体说明。4.1 标准请求标准请求主要是按照CDC类协议上的规定去设计描述符。标准的USB描述符主要有5种，即设备描述符（Device Descriptor)、配置描述符（Configuration Descriptor）、接口描述符（Interface Descriptor）、端点描述符（Endpoint Descriptor）和字符串描述符（String Descriptor）。每个USB设备
26、只有一个设备描述符，而一个设备中可包含一个或多个配置描述符，即USB设备可以有多种配置。设备的每一个配置中又可以包含一个或多个接口描述符，即USB设备可以支持多种功能（接口）。在接口描述符里又定义了该接口有多少个端点，每个端点都有一个端点描述符。端点描述符定义了端点的大小、类型等。如果有类特殊描述符，它就跟在相应的接口描述符之后。由此可以看出，USB的描述符之间的关系是一层一层的，最上一层是设备描述符，接下来是配置描述符，接着再获取接口描述符，最下面是端点描述符。在USB主机访问USB设备的描述符时，USB设备依照设备描述符、配置描述符、接口描述符、端点描述符、字符串描述符顺序将所有描述符传给
27、主机。USB设备至少要包含设备描述符、配置描述符和接口描述符，如果USB设备没有端点描述符，则它可以通过默认管道与主机进行数据传输。4.1.1 设备描述符设备描述符给出了USB设备的一般信息，包括对设备及在设备配置中起全程作用的信息，包括制造商标识号ID、产品序列号、所属设备类号、默认端点的最大包长度和配置描述符的个数等。一个USB设备必须有且仅有一个设备描述符。设备描述符是设备连接到总线上时USB主机所读取的第一个描述符，它包含了14个字段，结构如下：struct _ Device Descriptor BYTE bLength; / 设备描述符的字节数大小BYTE bDescriptorT
28、ype; / 描述符类型编号WORD bcdUSB; / USB版本号，由于本课题使用的是USB2.0，设置为0x02BYTE bDeviceClass; / USB分配的设备类代码BYTE bDeviceSubClass; / USB分配的子类代码，值由USB规定和分配BYTE bDeviceProtocl; / USB分配的设备协议代码BYTE bMaxPacketSize0; / 端点0的最大包的大小 WORD idVendor; / 厂商编号WORD idProduct; / 产品编号 WORD bcdDevice; / 设备出厂编号 BYTE iManufacturer; / 描述厂
29、商字符串的索引 BYTE iProduct; / 描述产品字符串的索引 BYTE iSerialNumber; / 描述设备序列号字符串的索引 BYTE bNumConfiguration;/ 可能的配置数量 4.1.2 配置描述符配置描述符中包括了描述符的长度（属于此描述符的所有接口描述符和端点描述符的长度的和）、供电方式（自供电/总线供电）、最大耗电量等。如果主机发出USB标准命令Get_Descriptor要求得到设备的某个配置描述符，那么除了此配置描述符以外，此配置包含的所有接口描述符与端点描述符都将提供给USB主机。其结构如下： struct _ Configuration Desc
30、riptor BYTE bLength; / 设备描述符的字节数大小BYTE bDescriptorType; / 描述符类型编号WORD wTotalLength; / 配置所返回的所有数量的大小 BYTE bNumInterface; / 此配置所支持的接口数量 BYTE bConfigurationVale; / Set_Configuration命令需要的参数值 BYTE iConfiguration; / 描述该配置的字符串的索引值 BYTE bmAttribute; / 供电模式的选择 BYTE MaxPower; / 设备从总线获取的最大电流 4.1.3 接口描述符配置描述符中包
31、含了一个或多个接口描述符，这里的“接口”并不是指物理存在的接口，在这里把它称之为“功能”更易理解些。接口描述符主要记录的信息有：接口的编号、接口的端点数、接口所使用的类、子类、协议等。如果一个配置描述符不止支持一个接口描述符，并且每个接口描述符都有一个或多个端点描述符，那么在响应USB主机的配置描述符命令时，USB设备的端点描述符总是紧跟着相关的接口描述符后面，作为配置描述符的一部分被返回。接口描述符不可直接用Set_Descriptor和Get_Descriptor来存取。其结构如下：struct _ Interface Descriptor） BYTE bLength; / 设备描述符的字
32、节数大小 BYTE bDescriptorType; / 描述符类型编号BYTE bInterfaceNunber; / 接口的编号 BYTE bAlternateSetting; / 备用的接口描述符编号 BYTE bNumEndpoints; / 该接口使用端点数，不包括端点0 BYTE bInterfaceClass; / 接口类型 BYTE bInterfaceSubClass; / 接口子类型 BYTE bInterfaceProtocol; / 接口所遵循的协议BYTE bInterface; / 描述该接口的字符串索引值 4.1.4 端点描述符端点是设备与主机之间进行数据传输的逻
33、辑接口，除配置使用的端点0（控制端点，一般一个设备只有一个控制端点）为双向端口外，其它均为单向。端点描述符描述了数据的传输类型、传输方向、数据包大小和端点号（也可称为端点地址）等。除了描述符中描述的端点外，每个设备必须要有一个默认的控制型端点，地址为0，它的数据传输为双向，而且没有专门的描述符，只是在设备描述符中定义了它的最大包长度。主机通过此端点向设备发送命令，获得设备的各种描述符的信息，并通过它来配置设备。其结构如下：struct _ Endpoint Descriptor BYTE bLength; / 设备描述符的字节数大小BYTE bDescriptorType; / 描述符类型编号
34、BYTE bEndpointAddress; / 端点地址及输入输出属性 BYTE bmAttribute; / 端点的传输类型属性 WORD wMaxPacketSize; / 端点收、发的最大包的大小 BYTE bInterval; / 主机查询端点的时间间隔 4.1.5 字符串描述符字符串描述符是一种可选的USB标准描述符，描述了如制造商、设备名称或序列号等信息。如果一个设备无字符串描述符，则其它描述符中与字符串有关的索引值都必须为0。字符串使用的是Unicode编码。主机请求得到某个字符串描述符时一般分成两步：首先主机向设备发出USB标准命令Get_Descriptor，其中所使用的字
35、符串的索引值为0，设备返回一个字符串描述符，此描述符的结构如下：struct _ String DescriptorBYTE bLength; / 设备描述符的字节数大小BYTE bDescriptorType; / 描述符类型编号BYTE SomeDescriptor36; / UNICODE编码的字符串4.1.6 描述符设计要求(1)设备描述符中的设备类定义必须定义为通信设备类，子类和遵从协议可以不定义，但在通信接口中必须定义。(2)配置描述符中的wTotalLength指的是除设备描述符和字符串描述符之外的所有的描述符之和。(3)VID与PID一定要和INF文件中指定的一致，否则的话，将
36、安装不了驱动。(4)CDC类除了以前阐述的五个标准描述符之外，还包括三个功能描述符：Header、ACM和Union（因为没有用到通话管理，所以没有Call Management描述符）。这是CDC类与其他的USB类设备的区别。这三个描述符将通信接口和数据接口关联起来，而且还阐述了具体支持类请求命令，因此，合理而且正确的设置它们将非常关键。此外，描述符的设计中，还需要有功能描述符（function-descriptors）的支持；它主要用来描述接口的功能。功能描述符放在CDC接口之后，功能描述符完毕之后就是主接口的端点描述符，再接下去是其它接口以及它们的端点描述符。4.1.7 标准命令在USB
37、规范中，所有的USB设备都要求对主机发给自己的控制命令作出响应，USB规范定义了11个标准命令，它们分别是：Clear_Feature、Get_Configuration、Get_Descriptor、Get_Interface、Get_Status、Set_Address、Set_Configuration、Set_Descriptor、Set_Interface、Set_Feature、Synch_Frame。所有USB设备都必须支持这些命令（个别命令除外，如Set_Descriptor、Synch_Frame）。所有的命令虽然有不同的数据格式和使用目的，但是USB命令结构是一样的。表4.
38、1所示为USB命令的结构。.表4.1 USB命令的结构偏移量域长度（字节）值描述0bmRequestType1位图请求特征：D7：传输方向； 0=主机至设备； 1=设备至主机 ；D6.5：种类； 0=标准 ；1=类；2=厂商； 3=保留 ；D4.0：接受者； 0=设备； 1=接口；2=端点； 3=其他；1bRequest1值命令类型编码值（见表4.3）2wValue2值根据不同的命令，含义也不同4wIndex2索引或偏移根据不同的命令，含义也不同，主要用于传送索引或偏移6wLength2如有数据传送阶段，此为数据字节数。表4.2列出了USB的11种标准命令。表4.2 USB的11种标准命令命令
39、bmRequestTypebRequestwValuewIndexwLengthDataClear_Feature00000000B00000001B00000010BCLEAR_FEATURE特性选择符零接口号端点号零无Get_Configuration10000000BGET_CONFIGURATION零零一配置值Get_Descriptor10000000BGET_DESCRIPTOR描述表种类(高字节）和索引（低字节）零或语言标志描述表长描述表表4.2 USB的11种标准命令（续）命令bmRequestTypebRequestwValuewIndexwLengthDataGet_Int
40、erface10000001BGET_INTERFACE零接口号一可选设置Get_Status10000000B10000001B10000010BGET_STATUS零零（返回设备状态）接口号（对象是接口时）端点号（对象是端点时）二设备,接口 ,或 端点状态Set_Address00000000BSET_ADDRESS设备地址零零无Set_Configuration00000000BSET_CONFIGURATION配置值（高字节为0，低字节表示要设置的配置值）零零无Set_Descriptor00000000BSET_DESCRIPTOR描述表种类（高字节）和索引（低字节）零或语言标志描述
41、表长描述表Set_Feature00000000B00000001B00000010BSET_FEATURE特性选择符(1表示设备，0表示端点）零接口号端点号零无Set_Interface00000001BSET_INTERFACE可选设置接口号零无Synch_Frame100000010BSYNCH_FRAME零端点号二帧号其中bRequest为命令编码值，含义如表4.3所示。表4.3 USB标准命令的编码值bRequestValueGET_STATUS0CLEAR_FEATURE1为将来保留2SET_FEATURE3为将来保留4SET_ADDRESS5GET_DESCRIPTOR6SET_
42、DESCRIPTOR7GET_CONFIGURATION8SET_CONFIGURATION9GET_INTERFACE10表4.3 USB标准命令的编码值（续）bRequestValueSET_INTERFACE11SYNCH_FRAME124.2 类请求的实现除了标准请求外，我们还需要实现CDC类的请求，不过它的实现具体支持什么命令，功能描述符里面会有所阐述，因此，如果功能描述符里面声明了要支持的命令，一定要支持。以下简单介绍几个关键性的请求。4.2.1 SEND_ENCAPSULATED_COMMAND请求SEND_ENCAPSULATED_COMMAND请求是用来发出在通信类的接口支持
43、控制协议格式命令。其格式如表4.4所示。表4.4 SEND_ENCAPSULATED_COMMAND请求的结构bmRequestTypebRequestwValuewIndexwLengthData00100001BSEND_ENCAPSULATED_COMMAND0接口接收者的数据量（字节）控制协议的命令4.2.2 GET_ENCAPSULATED_RESPONSE请求GET_ENCAPSULATED_RESPONSE请求是用于请求在该通信类接口支持控制协议格式的响应。其格式如表4.5所示。表4.5 GET_ENCAPSULATED_RESPONSE请求的结构bmRequestTypebRe
44、questwValuewIndexwLengthData10100001BGET_ENCAPSULATED_RESPONSE0接口接收者的数据量（字节）协议相关数据4.2.3 GET_LINE_CODING 请求在介绍GET_LINE_CODING 请求之前，我们需要将Line_Coding说明一下。Line_Coding包含了串口的波特率、停止位位数、奇偶校验位以及数据位。表4.6是Line_Coding的结构体说明。表4.6 Line_Coding结构体偏移量域大小/字节取值描述0dwDTERate4数值数据终端速率（波特率），比特每秒4bCharFormat11数值停止位位数0：1停止位
45、1：1.5停止位2：2停止位5bParityType1数值校验类型0：无1：奇数2：偶数3：标识4：空间6bDataBits1数值数据位位数（5,6,7,8，或者16）GET_LINE_CODING 请求是指主机获取串口属性的请求，包括了波特率的设置、停止位位数、校验类型以及数据位位数，其格式如表4.7所示。表4.7 GET_LINE_CODING 请求的结构bmRequestTypebRequestwValuewIndexwLengthData10100001BGET_LINE_CODING0接口数据结构大小Line Coding数据结构4.2.4 SET_LINE_CODING 请求SET
46、_LINE_CODING 请求是用来设置串口的属性，跟GET_LINE_CODING是相对的，不过后面所使用的Line_Coding格式是一样的。该请求将在控制传输的数据过程发送7字节的Line_Coding数据，其格式如表4.8所示。表4.8 SET_LINE_CODING 请求的结构bmRequestTypebRequestwValuewIndexwLengthData00100001BSET_LINE_CODING0接口数据结构大小Line Coding数据结构4.2.5 SET_CONTROL_LINE_STATE请求SET_CONTROL_LINE_STATE请求没有数据输出阶段，其中wValue字段的D0位表示DTR，D1位表示RTS，其格式如表4.9所示。表4.9 SET_CONTROL_LINE_STATE请