USB CDC类入门培训 . p7 F+ G @' T0 o4 @1 前言 本文节选自2017年度USB CDC类培训内容的整理,主要目的是以方便些没有到现场参加培训的碟粉们可以参阅学习。本文力求从理论到实践,尽量给读者一个整体了解USB CDC类的窗口。当然,阅读此文,还是需要基本的USB知识,这个请读者自行预备。 8 @ r3 I+ s, j1 `2 [/ v 2 USB CDC类基础理论知识介绍6 q. ?, D2 G0 @$ n! E - v! {& b: X$ D: [0 X4 Y p 2.1 USB CDC类、USB2.0标准与PSTN之间的关系! z3 N5 c7 Y0 x0 {& F CDC(Communication Device Class)类是USB2.0标准下的一个子类,定义了通信相关设备的抽象集合。它与USB2.0标准以及其下的子类的相互关系如下图所示:3 @2 B% D- k8 Z/ z! t8 } 图 1 USB2.0标准、CDC、PSTN之间的关系+ m' h+ q1 Y* W7 x9 d% i 如上图,USB2.0标准下定义了很多子类,有音频类,CDC类,HID,打印,大容量存储类,HUB,智能卡等等,这些在urb.org官网上有具体的定义,这里我们主要讲的是通信类CDC,CDC类下面,根据具体的应用场合,又有一些子类,这里我们主要讲的是PSTN(Public Switched Telephone Network)。从PSTN官方标准文档来看,PSTN子类是一个与电信相关的子类,而这里,我们只是将它作为一个普通的通信设备使用,并没有使用到它的一些电话特性。 % F% e, X0 }+ W* V, |* f 2.2 从一个具体的CDC类通信数据说起 图 2 一个具体的CDC类设备通信数据 如上图,USB CDC类的通信部分主要包含三部分:枚举过程、虚拟串口操作和数据通信。其中虚拟串口操作部分并不一定强制需要,因为若跳过这些虚拟串口的操作,实际上USB依然是可以通信的,这也就是为什么上图中,在操作虚拟串口之前会有两条数据通信的数据。之所以会有虚拟串口操作,主要是我们通常使用PC作为Host端,在PC端使用一个串口工具来与其进行通信,PC端的对应驱动将其虚拟成一个普通串口,这样一来,可以方便PC端软件通过操作串口的方式来与其进行通信,但实际上,Host端与Device端物理上是通过USB总线来进行通信的,与串口没有关系,这一虚拟化过程,起决定性作用的是对应驱动,包含如何将每一条具体的虚拟串口操作对应到实际上的USB操作。这里需要注意地是,Host端与Device端的USB通信速率并不受所谓的串口波特率影响,它就是标准的USB2.0全速(12Mbps)速度,实际速率取决于总线的实际使用率、驱动访问USB外设有效速率(两边)以及外部环境对通信本身造成的干扰率等等因素组成。 2.3 CDC类设备枚举过程" u- \' g5 |1 a1 b+ L+ ?7 U CDC类设备与其他标准USB设备枚举过程的并没有什么特殊的地方。在设备描述符内可以使用DeviceClass=0x00, SubClass=0x00, Protocol=0x00 表示此类信息在接口描述符内给出;或者也可以使用0x02,0x00,0x00;来表明该设备为CDC类设备。或者使用0xef, 0x02,0x01表示当前为复合设备。 + ~" s# [( i5 F9 L9 t CDC类设备在枚举过程中最主要的信息存储在配置描述符内:, s0 Z p# X$ z# @4 G H 图 3 USB CDC类配置描述符的结构, u4 p& S) h. i & F% i' o( \/ ], B3 G6 X 如上图所示,CDC类的配置描述符一般包含两个接口(Interface 0),一个控制接口,另外一个是数据接口(Interface 1), 除此之外,还有一个虚线指向的IAD(Interface Association Description),这个表示这个是不是可选的,得根据实际情况来确定其是否真实存在。8 [0 ?+ A w$ M5 y ( T- E, [% Y6 v) I; x 7 M) W5 S! x1 k( f- V5 b, s 2.3 1 控制接口 控制接口下包含类描述符合一个端点(ie:0x82),这个端点(中断传输模式)为异步通知消息的端点,当设备端需要向Host端发送异步消息时,可以通错此端点来发送,但平时主机端都是通过端点0来向设备端发送控制消息的,比如那些虚拟串口的操作指令等等。! D& d! {! }' h8 n7 a- i8 I& l N5 _/ z' Z% h 除这异步通知端点外,控制接口下还包含CDC类相关描述符,这其中就包含Header描述符,Call Management描述符,ACM描述符以及Union描述符。这些功能描述符整合在一起用来描述此USB设备的一些功能特性,比如AT指令支持情况,ACM模型下的指令集支持情况,以及还有哪些接口与此接口一起对应Host端的一个功能(驱动)。 在具体配置描述符内的控制接口内,功能描述符紧跟在接口描述符后,最后才是端点描述符。( g( ]! ~9 G Y: x ! v* |; I" n; p8 X) v ● 控制接口 图 4 控制接口描述符 控制接口主要用来做设备管理和电话管理(可选),设备管理涉及到请求(request)和通知(notification),端点0一般用做请求,一般用来控制和配置设备的运行状态,而非0端点(0x82)一般用作异步事件通知,设备端通过此端点向主机端发送设备内部的一些事件,比如串口状态变化事件,电话状态改变等等。( L4 n) ~1 q7 [: X 这里使用到ACM模型,后续将讲到这个模型,并且这里指明使用到V250版本的AT指令,这些指令是与电话相关的,但在我们这里讲的CDC通信实际上并不需要使用这些与电话相关的指令,它只是简单通信而已,这里指出AT指令也没有关系,只是实际不用它而已。; g( o4 R' O K8 M3 r8 g, D2 g 如上图,bNumEndpoints表示此接口下包含的端点数,这里为1个,即那个异步通知端点。bInterfaceSubClass为0x02,ACM通信模型,bInterfaceProtocol表示AT指令集的版本,虽然这里举例为V2.50,但实际上并没有使用到任何AT指令,因此它放0 r1 R4 j. q% t, m# A1 W" ~* m% l ● Header功能描述符* v3 F- y+ N s+ n8 F; i 图 5 Header功能描述符2 L& f! w% ?. D Header功能描述符表示功能描述符的开始,其他紧跟的内容就是此设备的功能描述符的内容。bcdCDC表示的是CDC的版本。 8 z5 [. ~: ~/ R' |! `0 f ●ACM功能描述符2 `1 c3 U7 p) W3 ` 图 6 ACM功能描述符 ACM(Abstract Control Model),即抽象控制模型,PSTN下,除了ACM模型还有还有DLM(Direct Line Mode), TCM(Telephone Control Model)。 ! `. L! s1 f) p PSTN定义了三种模型LM(Direct Line Mode),ACM(Abstract Control Model)和TCM(Telephone Control Model). • DLM模型下,USB设备直接将模拟信号转化为数字信号,并放到USB上传输,数据接口直接使用Audio类传输音频数据,控制接口传输的也都是些比较原始的指令,比如脉宽设置,发送脉宽等等;0 w3 j$ L; a+ _' \) S! l0 N • ACM模型则可以很好的支持AT V250指令集,数据接口可以使用Audio类或CDC DATA,控制接口传输的也是比较抽象的高层指令,比如设置、获取波特率,设置获取与通信相关的参数等等,而AT指令可以通过控制接口或者数据接口,这个在控制接口下的功能描述符Call Management Descriptor中指明。 • TCM是指在物理上存在多个连接,可以将接口0和接口1分别对应到不同的物理连接上。 此外,不同的通信模型对应的指令集合(控制指令)也是不同的,而上图中bmCapliblities为位图,内部bit0~bit3分别表示4类控制指令集在此设备的支持情况。 图 7 ACM模型下的控制指令集5 s, f% {1 r) w- C : r, l. q* S. U! {1 C& z$ N 如上表,为ACM模型下的指令集,但不是说,这些个指令就一定会在ACM模型下存在,此USB设备是不是支持此某个控制指令,还得看bmCapliblities这个参数具体对应位是否使能。 ! P u4 H6 x, ^ 在实际的STM32 USB协议栈中,针对于CDC类,使用LineStateCoding,GetLineCoding,SetControlState类指令,用来读取,设置串口波特率以及串口的打开与关闭,这个具体的映射实现是通过主机端的驱动来实现;从设备端来看,当设备端收到这些来自主机端操作串口的控制指令时,这些指令具体怎么执行完全取决于设备端,也就说,所有的这些操作,比如设置波特率为115200,对于设备端来说这个只是个通过SetLineCoding指令传过来的一个参数而已,具体怎么处理这个参数,取决于设备端应用程序具体怎么处理这个参数,这个有用户来处理,这个115200波特率与USB本身的波特率12Mbps(全速)是没有关系的。 ● Call Management功能描述符 图 8 Call Management功能描述符- n5 y4 S+ }8 _6 u/ f8 c 3 X" w: R9 I* B9 M1 J Call Management描述的就是电话相关的东西,AT指令集的支持情况。但在这里,我们并没有用到任何与电话相关的指令,因此bmCapabilities下的位图各个位都是为0:Bit0:是否支持电话相关的指令(AT指令集);Bit1:电话相关的指令(AT指令集)是否经过Comm. Class Interface; bDataInterface表示如有电话时,电话数据内容对应的接口号。 ● Union功能描述符% c7 ^9 _ L# v5 t* } 图 9 Union功能描述符& ~, ^# ?$ c; E9 { U1 @0 W 8 c1 t3 K1 z. I/ b Union描述符就是用来告诉主机端,哪些接口是联合在一起的,对应着一个功能,这个功能需要主机装载对应的驱动来实现,因此,功能与驱动是一对一的关系。这里bControlInterface值为0,则表示接口0为控制接口,bSubBoardinateInterface0值为1,表示接口1为控制接口0的下级接口,即数据接口。在CDC标准中,控制接口是必须的,而数据接口是可选的,因此,数据接口为控制接口的附属。 3 H* s5 R# y; o, \9 p# }0 S 2.3.2 数据接口 图 10 数据接口 \" u0 |8 s3 x ) v6 ~2 H; l' ~" B/ w6 T2 c 数据接口比较简单,就是数据通信的,用到两个端点IN/OUT 0x81/0x01,为块传输类型。 2.3.3 IAD(Interface Association Descriptor) 图 11 IAD描述符- G: u# S; x" G$ z) V G7 s7 X5 n1 ]2 } USB刚出来的时候,一开始默认是一个接口对应一个功能,而一个功能对应着主机端的一个驱动,这在当时是OK的,但是后来,人们发现,需要多个接口对应一个功能的时候,比如这个CDC,除了数据接口外还需要控制接口,这在当时是没有这方面的统一标准,于是就出了Union来表示多个接口对应一个功能的情况。再后来,USB标准协会又增加了IAD。 0 b+ H9 a0 B$ }* e5 U: a, c IAD与Union类似,Union是旧版本下实现多个接口对应一个功能的功能描述符,而IAD是USB协会后来针对多个接口对应一个功能的情况而扩展的,旧的主机可能只支持Union方式,但IAD并不会影响旧版本主机对设备的识别,因为旧版本主机会通过Union来识别哪些接口是联合在一起的,对于IAD则跳过忽略;而新版主机则可以通过IAD来识别,跳过忽略老的Union,因此两者可以完美兼容,互不影响。因而主机端可以精确地装载对应的驱动。; d9 L$ W( \! y; y; D( w! }. Y 4 i# O" h( L- K) v$ P$ i$ [ IAD只用在设备描述符中只用了device class code,并且指明了使用IAD来识别设备,比如bDeviceClass: Miscellaneous (0xef), bDeviceSubClass: Common (0x02), bDeviceProtocol: Interface Association Descriptor (0x01)就是一个例子; 0x02,0x00,0x00是另外一个例子。' ]0 h' I1 ]1 j: o, P$ i5 u . r2 P, p& k' m0 w( F* N# @ 如上图,bFirstInterface值为0,表示第一个接口个接口0,默认为控制接口;bInterfaceCount值为2,标志此功能总共存在2个接口,那么第二个接口就是接口1,因为USB2.0 IAD ECN补充标准规定,这里提到的接口号必须是连续的,也就是说,接口0为第一个控制接口,那么接口1则为数据接口。0 {- [1 a) ?, l+ ]9 w* j 2 i# |- `5 o' M/ D! D9 h8 B 下面我们来个具体的IAD例子:. P+ b" U* u4 z. {8 O" ? 图 12 IAD存在时的设备描述符4 m- l, X0 ~6 `8 G 图 13 IAD/ o" F- ]4 D& p; z D! H. L 如上图所示,一般IAD存在的情况下,在设备描述符中DeviceClass等三个参数不再都为0x00,图12中为0xef,0x02,0x01,这个表示是复合设备,此时,可以使用IAD来定义多个接口联合起来对应一个USB驱动。从IAD中可以看出,bFunctionClass参数就定义了此IAD表示的设备为CDC类设备,ACM模型。就这样,通过IAD描述符,实现了与Union功能描述符相同的功能。: D+ G$ S: ^7 l# Z' Z, ? 5 h* H% L# X' c& @) Z 2.3.4 ACM模型! T" w$ i- c7 @6 X% Q 之前我们已经在控制接口中的功能描述符中已有对ACM(Abstract Control Mode)模型的简介,也有提到过,在PSTN中,除了ACM模式,还有TCM,DLM模式。这三种模式,不同的模式下包含的控制指令集是不尽相同的,有部分控制指令可能同时存在两个或三个模式下,除了控制指令,还有异步通知消息,这个在三个不同模式下也是不相同的。 图 14 ACM模式下的控制指令集% C! U, f& p; e# Z6 P0 N5 S 图 15 ACM模式下的异步通知消息6 n P7 Z! Z" o' G0 h. \ 图 16 DLM模式下的控制指令集" j; ?: W) g' b4 a! s 图 17 DLM模式下的异步通知消息 " |) _# @& J+ l' s. i2 y 图 18 TCM模式下的控制指令集% ?# k: B7 e; g3 ] 图 19 TCM模式下的异步通知消息 s* Y- d6 D e: `+ T- V$ w( m+ H 由图14~19可知,当设备选择了某个模型后,其控制指令集和异步通知消息也就得符合此模式下的对应集合,否则则不符合标准。这里我们主要是使用到ACM模式,因此,此ACM模式下的有Host端发现Device端的控制指令和有Device端向Host端发送的异步通知消息都是固定的那么几条指令或消息,但并不是说,只要是ACM模式,那么就表示此模式下的所有控制指令和异步通知消息都必须支持。控制指令在设备端的控制接口描述符中的ACM功能描述符中的bCapabilities字段有按 位定义ACM模式下的控制指令的支持情况,而异步通知消息,则完全看device端的应用情况是否需要,并没有在任何描述符中指出那些消息是否支持。 在ST给出的CDC例程中,主要是使用到了SetLineCoding指令来设置和修改虚拟串口的波特率,使用GetLineCoding来获取当前波特率,使用SetControlLineState来打开或关闭串口,这种操作是在Host端CDC驱动来具体映射实现的,至于Device端收到这些个控制指令该怎么处理,就是另外一回事了,Device端也可以完全不做任何处理,有CubeMx自动生成的CDC类代码就是这样,对接收到的任何控制指令到没有做任何处理,当然,如果需要的话,则按应用的需要来处理,这个完全取决于用户。 图 20 控制指令操作虚拟串口. K& a" N# S4 F% B( D0 j 图 21 一个ACM模式下的异步通知消息例子* ^. U, ?! @) P2 x / O9 n; q& h9 a3 \- X 3 CDC类软件框架介绍 3.1 CDC软件框架简介 图 22 CDC类软件框架 如上图所示,黄色USB Device Core部分为USB设备库文件,属于中间件,它为USB协议栈的核心源文件,一般不需要修改:* s4 h4 V' F6 N; a' z5 h( V4 h ● USB Device Core中,Log/debug为打印/调试开关; ● core为USB设备核心; ● USB request中定义了枚举过程中各种标准请求的处理;) Y* W, w" E$ `. |8 ]$ F7 O0 h* R) q+ F ● I/O request为底层针对USB通信接口的封装。, q K+ f7 x" O% k2 f 3 P1 A1 j, y0 n( W8 K& @# r8 Z) a 黄色USB Device Class部分为USB类文件,也属于中间件,USB设备库,目前ST DEMO中支持的类有HID, Customer HID, CDC, MSC, DFU, Audio, ST提供了这些类的源码框架,其他的Class或者是复合设备需要自己根据实际需求情况进行扩展或定制。如果用户需求只是需要一个标准类,比如CDC通信,那么最好就使用现成的代码,不需要做任何修改就可以实现这个CDC类通信的功能。 蓝色USB Device HAL Driver为HAL库部分,是对USB外设接口的封装,属于底层驱动,不需要修改,它分为PCD和LL Driver,PCD处于LL Driver之上。# s; l& X: Z( a; J! O ) i/ p) w/ \* p( _1 K8 | 洋红色USB Device Configuration为USB配置封装,位于USB底层HAL层驱动与中间件USB协议栈之间,一方面向上层(USB设备库)提供各种操作调用接口,另一方面,向底层USB驱动提供各种回调接口。正是由于它的存在,使得USB协议栈(USB设备库)与底层硬件完全分离,从而使USB设备库具有更加兼容所有STM32的通用性。USB Device Configuration为开放给用户的源文件,用户可以根据自己的某些特殊需要进行修改,也可以使用默认的源文件,假如没有任何特殊要求的话,我们使用默认即可。9 h' n( @6 W( }- |4 ~/ E8 Q- V 0 \) I7 \; C, Z1 Z+ \ Application为应用层,USB Device Class有可能将自己对应该的操作接口封装在一个操作数据结构中,由应用来具体实现这些操作,在系统初始化时,由应用将已经定义好的操作接口注册到对应的USB类中,比如usbd_cdc_if, 就这样,使得应用层的应用代码与属于中间件层的USB协议栈分离。同时,USB协议栈会将一些字符串描述符放到APP中,当USB初始化时将这些已经定义好的字符串通过指针初始化到USB协议栈中,以便后续需要时获取。 # L7 V% o/ E- X$ R ' @' _/ h1 Z1 B! b: l$ Q1 C7 } 3.2 工程源码文件与软件框架的对应关系 . `6 }( d6 u o5 a) Q 图23 CDC工程中源码与软件框架的对应关系9 [; a- c3 Z7 [; ]9 z) Z1 [ 0 P; r4 Z$ N2 ^& n5 H4 V 3.3 USBD内核与USBD_CDC的关系. d8 p9 h0 T3 {, ^- P4 r+ S# p 3.1节中,我们已经提到过ST官方Cube库中提供的官方USB协议栈,主要是包含了USBD内核与USB各种类。USBD内核一般是固定的,用户一般不需要修改,但USBD类,如果用户需要修改或者扩展,比如复合设备或者用户自定义设备,还有就是,ST目前官方提供的USB设备类的DEMO程序并没有囊括所有USB类,因此,若用户需要实现这些官方提供DEMO之外的USB类时,则用户需要根据自己的需要来定制化自己的USB类,那么又该如何开始呢?9 C7 @) o: f: X+ d1 y- `1 n 我们已经知道,ST提供的USB协议栈中已经有USBD内核,且这个内核源文件一般是不需要修改的,那么这里我们需要自定义这么一个USB类,那么我们首先得知道,这个我们需要自定义的USB类是如何与USBD内核打交道的? USB协议栈将所有USB类都抽象成一个数据结构:USBD_ClassTypeDef,其定义如下所示: ( Q7 k* d" S+ K. Y( C4 M 这个结构体是一个抽象类,定义了一些虚拟函数,比如初始化,反初始化,类请求指令处理函数,端点0发送完成,端点0接收处理,数据发送完成,数据接收处理,SOF中断处理,同步传输发送未完成,同步传输接收未完成处理等等;用户在实现自己具体的USB类的时候需要将它实例化,USBD_ClassTypeDef结构体是USBD内核提供给外部定义一个USB设备类的窗口,而USB类文件(如usbd_cdc.c)实际就是实现这个结构体具体实例化的过程。最后将这个具体实例化的对象注册到USBD内核的同时, USBD内核与USBD类也进行了关联。 图 24 USBD核与CDC类的关系/ j9 Z- n- [ S( K j a* u$ H9 b1 L1 ? X2 } M5 R ...... ...... ( n1 m& V0 B5 M+ i S3 J! r% d& T) r9 t: f4 b 由于帖子过长,更多详细信息下方文档中的PDF及代码!1 |! \ d% S+ _: o3 m ! n- m1 N: U' f3 J, W7 v/ N- z $ K" ?3 |3 l2 b5 O1 ]$ ]9 R4 v8 w8 Q; t ; |+ e2 y. V" }* { 文档下载, N c- p& m6 y6 ~" o6 n * B3 \7 z7 ]+ m2 d 更多实战经验 |
牛逼。 |
太牛逼。。 |
破总牛逼 |
牛逼,写的非常详细 |
初级入门中,上面没看明白!!!保存下来。 |
签到签到 |
看不懂额2 C3 ]1 r7 X# [' @+ V |
太牛逼。。 |
您好!我想问下,如果在基于CDC类ACM上开发组合设备,就是基于一个设备上配置多个接口设备功能,即CDC_ACM+Mass Storage这样的有问题吗? |
好资源啊 学习! |
厉害 |
讲解有深度。。。。。。。。。3ks |
楼主有没有原培训资料的附件啊,正常培训资料里有个 CDC_training.tdc 的USB 报文 |
MARK |
最全USB HID开发资料,悉心整理一个月,亲自测试
USB Audio设计与实现
【MCU实战经验】+STM32F107的USB使用
圈圈发布USB图书第二版有感,以及分享一些我学习USB过程...
STM32F4-DISC 实现USB主机(U盘)和USB设备(虚拟串口)自动切换
STM32 USB-HID通信移植步骤STM32 USB HID键盘例程
【经验分享】在进行 USB CDC 类开发时,无法发送 64整数倍的数据
如何让CDC类USB设备批量接收64字节以上数据
用STM32F4实现的USB摄像头UVC,配合上位机可识别车牌
STM32 USB CDC 虚拟多串口