你的浏览器版本过低,可能导致网站不能正常访问!
为了你能正常使用网站功能,请使用这些浏览器。

【实战经验】USB CDC类入门培训  

[复制链接]
zero99 发布时间:2017-7-28 17:27
USB CDC类入门培训
) z% j2 G4 B3 \( N+ X4 w" Z
1 前言
) g/ d, h: R' e) ]5 W* g: i6 n本文节选自2017年度USB CDC类培训内容的整理,主要目的是以方便些没有到现场参加培训的碟粉们可以参阅学习。本文力求从理论到实践,尽量给读者一个整体了解USB CDC类的窗口。当然,阅读此文,还是需要基本的USB知识,这个请读者自行预备。6 M; R0 P6 ^- B- f+ L' J4 Q" N
, h+ f7 f# Y& ^; Y* M" B3 e
2 USB CDC类基础理论知识介绍9 Z, P% g3 z: k
7 x& Y* I% `8 i- l% h, K! G1 H9 G4 w
2.1 USB CDC类、USB2.0标准与PSTN之间的关系/ O8 V; L# P5 D8 `  I* n; o) q
CDC(Communication Device Class)类是USB2.0标准下的一个子类,定义了通信相关设备的抽象集合。它与USB2.0标准以及其下的子类的相互关系如下图所示:1 P3 c1 G7 l8 r$ \, g* |+ K
11.png / N2 ^% V4 ^- I+ x
图 1 USB2.0标准、CDC、PSTN之间的关系' n8 d6 R% |7 b, }- ^  G0 ?8 g

$ |6 V5 N% O3 J3 x如上图,USB2.0标准下定义了很多子类,有音频类,CDC类,HID,打印,大容量存储类,HUB,智能卡等等,这些在urb.org官网上有具体的定义,这里我们主要讲的是通信类CDC,CDC类下面,根据具体的应用场合,又有一些子类,这里我们主要讲的是PSTN(Public Switched Telephone Network)。从PSTN官方标准文档来看,PSTN子类是一个与电信相关的子类,而这里,我们只是将它作为一个普通的通信设备使用,并没有使用到它的一些电话特性。
6 @& D7 r6 k" u
5 |+ T9 q" F! I" Q. }  o2.2 从一个具体的CDC类通信数据说起
7 ]5 O" |: X. U. E3 `# q* L% G 12.png
6 z+ d0 p3 ^/ g) D1 N图 2 一个具体的CDC类设备通信数据
' S+ s; r6 k6 d  _: J" j% p
' a8 Q1 C1 C9 h3 j如上图,USB CDC类的通信部分主要包含三部分:枚举过程、虚拟串口操作和数据通信。其中虚拟串口操作部分并不一定强制需要,因为若跳过这些虚拟串口的操作,实际上USB依然是可以通信的,这也就是为什么上图中,在操作虚拟串口之前会有两条数据通信的数据。之所以会有虚拟串口操作,主要是我们通常使用PC作为Host端,在PC端使用一个串口工具来与其进行通信,PC端的对应驱动将其虚拟成一个普通串口,这样一来,可以方便PC端软件通过操作串口的方式来与其进行通信,但实际上,Host端与Device端物理上是通过USB总线来进行通信的,与串口没有关系,这一虚拟化过程,起决定性作用的是对应驱动,包含如何将每一条具体的虚拟串口操作对应到实际上的USB操作。这里需要注意地是,Host端与Device端的USB通信速率并不受所谓的串口波特率影响,它就是标准的USB2.0全速(12Mbps)速度,实际速率取决于总线的实际使用率、驱动访问USB外设有效速率(两边)以及外部环境对通信本身造成的干扰率等等因素组成。5 I" _- \% C1 v, u
4 U0 Q! J, {4 i0 Y6 D$ [) ~
2.3 CDC类设备枚举过程
) I+ p% b) Z% ?2 G( t8 WCDC类设备与其他标准USB设备枚举过程的并没有什么特殊的地方。在设备描述符内可以使用DeviceClass=0x00, SubClass=0x00, Protocol=0x00 表示此类信息在接口描述符内给出;或者也可以使用0x02,0x00,0x00;来表明该设备为CDC类设备。或者使用0xef, 0x02,0x01表示当前为复合设备。
) B: N- n2 f- z6 r3 h9 I: {- d) S% D/ C* ~. K* e  I
CDC类设备在枚举过程中最主要的信息存储在配置描述符内:3 D9 h9 o! h8 \6 B8 n0 A, x5 V% Z
13.png
% d' K3 ^9 w/ x- l" t* ^4 A% R- `图 3 USB CDC类配置描述符的结构/ Z& G% t1 X0 [
. ~, {3 G5 C3 c
如上图所示,CDC类的配置描述符一般包含两个接口(Interface 0),一个控制接口,另外一个是数据接口(Interface 1), 除此之外,还有一个虚线指向的IAD(Interface Association Description),这个表示这个是不是可选的,得根据实际情况来确定其是否真实存在。  [9 X: P9 Q) p6 z0 _) W5 q. Z
) d( N$ H' A$ r$ h  o% H& U6 w

0 v9 G. n8 F* v* s9 p, H$ ?2.3 1 控制接口$ E$ `( {  J* H" k. `
控制接口下包含类描述符合一个端点(ie:0x82),这个端点(中断传输模式)为异步通知消息的端点,当设备端需要向Host端发送异步消息时,可以通错此端点来发送,但平时主机端都是通过端点0来向设备端发送控制消息的,比如那些虚拟串口的操作指令等等。" n5 D# v) k& m) I; h$ d

, H% A& f7 f9 |  N/ P  ^4 K除这异步通知端点外,控制接口下还包含CDC类相关描述符,这其中就包含Header描述符,Call Management描述符,ACM描述符以及Union描述符。这些功能描述符整合在一起用来描述此USB设备的一些功能特性,比如AT指令支持情况,ACM模型下的指令集支持情况,以及还有哪些接口与此接口一起对应Host端的一个功能(驱动)。) S! c  q$ }$ N& G  |; x) U  h' @7 b
: C1 v: d, a5 U& [& c* p
在具体配置描述符内的控制接口内,功能描述符紧跟在接口描述符后,最后才是端点描述符。& c; c% M1 `! r& V5 M
, q, p0 |+ o5 k5 L) E* x7 M
●   控制接口
. P7 F; s3 x; F. ?& @ 14.png 1 v9 e& J. Q) d1 T
图 4 控制接口描述符- ]2 J/ \- k) b/ \# M& S

  v4 Y) b$ }+ F控制接口主要用来做设备管理和电话管理(可选),设备管理涉及到请求(request)和通知(notification),端点0一般用做请求,一般用来控制和配置设备的运行状态,而非0端点(0x82)一般用作异步事件通知,设备端通过此端点向主机端发送设备内部的一些事件,比如串口状态变化事件,电话状态改变等等。
7 V6 O4 v/ x7 }5 I* }( R8 H. J& B% F- L! k; Z
这里使用到ACM模型,后续将讲到这个模型,并且这里指明使用到V250版本的AT指令,这些指令是与电话相关的,但在我们这里讲的CDC通信实际上并不需要使用这些与电话相关的指令,它只是简单通信而已,这里指出AT指令也没有关系,只是实际不用它而已。, v' P) t/ E7 i5 U" |" d; V2 h7 {
. v* m5 f0 D+ B& n7 x8 z
如上图,bNumEndpoints表示此接口下包含的端点数,这里为1个,即那个异步通知端点。bInterfaceSubClass为0x02,ACM通信模型,bInterfaceProtocol表示AT指令集的版本,虽然这里举例为V2.50,但实际上并没有使用到任何AT指令,因此它放
' B; _3 U6 p% O" ^4 y7 V: t) ~! S- y& z
●   Header功能描述符
* c0 `. k. A6 j$ B4 {% P 15.png ' H4 J& Z" C* v
图 5 Header功能描述符1 D* i# s$ Y1 J* }! l% k
$ K, t6 l/ Z5 N+ ^/ g  d9 M6 H
Header功能描述符表示功能描述符的开始,其他紧跟的内容就是此设备的功能描述符的内容。bcdCDC表示的是CDC的版本。" X: t+ T1 u0 a
, E, {& |2 V4 o# Z% I
●ACM功能描述符5 x" {( ~/ `6 W/ [5 J
16.png 8 b; O1 ?3 p$ k' |" a
图 6 ACM功能描述符
5 w! W6 t) K, [2 O& N+ N2 X& k* h/ G4 L. @
ACM(Abstract Control Model),即抽象控制模型,PSTN下,除了ACM模型还有还有DLM(Direct Line Mode), TCM(Telephone Control Model)。
1 C# W9 I1 _9 W* o5 c: q& ]
. D6 }4 ~2 E2 a7 _8 {) D. @PSTN定义了三种模型LM(Direct Line Mode),ACM(Abstract Control Model)和TCM(Telephone Control Model)." D7 G9 e/ Q# f
      •    DLM模型下,USB设备直接将模拟信号转化为数字信号,并放到USB上传输,数据接口直接使用Audio类传输音频数据,控制接口传输的也都是些比较原始的指令,比如脉宽设置,发送脉宽等等;" \* Q+ [+ r; a
      •    ACM模型则可以很好的支持AT V250指令集,数据接口可以使用Audio类或CDC DATA,控制接口传输的也是比较抽象的高层指令,比如设置、获取波特率,设置获取与通信相关的参数等等,而AT指令可以通过控制接口或者数据接口,这个在控制接口下的功能描述符Call Management Descriptor中指明。1 f( [6 y! ]0 ]' `6 w1 q8 v$ d
      •    TCM是指在物理上存在多个连接,可以将接口0和接口1分别对应到不同的物理连接上。
% r+ X8 A$ e; F! B此外,不同的通信模型对应的指令集合(控制指令)也是不同的,而上图中bmCapliblities为位图,内部bit0~bit3分别表示4类控制指令集在此设备的支持情况。* D" J7 s) P" I

# h# ]$ X9 ~$ ?  F( _  [: y' F% D 17.png
$ T+ Y$ C/ u1 I. d; t9 N图 7 ACM模型下的控制指令集
) z& Z! ~) R5 D% Z' n0 e. @
. \7 d! t: M* P4 I9 `9 n如上表,为ACM模型下的指令集,但不是说,这些个指令就一定会在ACM模型下存在,此USB设备是不是支持此某个控制指令,还得看bmCapliblities这个参数具体对应位是否使能。
9 k- o/ D5 P2 w& g+ l4 o
. I' y* _& b* f! ?" z4 @. b) ?在实际的STM32 USB协议栈中,针对于CDC类,使用LineStateCoding,GetLineCoding,SetControlState类指令,用来读取,设置串口波特率以及串口的打开与关闭,这个具体的映射实现是通过主机端的驱动来实现;从设备端来看,当设备端收到这些来自主机端操作串口的控制指令时,这些指令具体怎么执行完全取决于设备端,也就说,所有的这些操作,比如设置波特率为115200,对于设备端来说这个只是个通过SetLineCoding指令传过来的一个参数而已,具体怎么处理这个参数,取决于设备端应用程序具体怎么处理这个参数,这个有用户来处理,这个115200波特率与USB本身的波特率12Mbps(全速)是没有关系的。
5 h# p  R( X) v( r4 d3 @# v: M# t$ U( X. K/ B" y6 ?
● Call Management功能描述符3 ?' n% |4 o0 {, F# ~" c% l
18.png
6 \. a3 e* M6 K$ I! c$ |# Z图 8 Call Management功能描述符
/ D" u  B" N9 r, c0 {
9 s& V7 g) M5 p( B4 gCall Management描述的就是电话相关的东西,AT指令集的支持情况。但在这里,我们并没有用到任何与电话相关的指令,因此bmCapabilities下的位图各个位都是为0:Bit0:是否支持电话相关的指令(AT指令集);Bit1:电话相关的指令(AT指令集)是否经过Comm. Class Interface; bDataInterface表示如有电话时,电话数据内容对应的接口号。
3 A6 a6 X/ b! |3 Y
2 h% n$ \/ t/ I9 ?! J●  Union功能描述符
4 U6 A+ ^" b7 d5 u/ @9 m/ a 19.png 7 @* P7 d  }6 i  R; l
图 9 Union功能描述符, V- m( H- T8 E$ o

$ M- h; L3 F  D. b% |( GUnion描述符就是用来告诉主机端,哪些接口是联合在一起的,对应着一个功能,这个功能需要主机装载对应的驱动来实现,因此,功能与驱动是一对一的关系。这里bControlInterface值为0,则表示接口0为控制接口,bSubBoardinateInterface0值为1,表示接口1为控制接口0的下级接口,即数据接口。在CDC标准中,控制接口是必须的,而数据接口是可选的,因此,数据接口为控制接口的附属。( D0 ^$ I& H7 u' n
+ R- Y6 D9 B; h" P' i5 B
2.3.2 数据接口
3 H( C% \. _, ~2 x4 J8 r  Y3 p. Z 21.png : U) c4 _1 n: P7 Y$ n& w+ `
图 10 数据接口
2 x- U* s- s0 C! c5 I+ f5 `
6 ~4 }5 X; l: r1 h数据接口比较简单,就是数据通信的,用到两个端点IN/OUT 0x81/0x01,为块传输类型。9 z. {- s2 y3 J9 O

! ?7 j  V8 d2 q1 V2.3.3 IAD(Interface Association Descriptor)- j6 o! n" V/ w( ]+ B/ j
22.jpg 3 I) Z# {# `! b# w& R& h# I
图 11 IAD描述符3 ?1 f9 Y7 b/ O1 v8 x/ K4 W& a) {
8 W; Z$ s: d2 @6 N! p" V7 |
USB刚出来的时候,一开始默认是一个接口对应一个功能,而一个功能对应着主机端的一个驱动,这在当时是OK的,但是后来,人们发现,需要多个接口对应一个功能的时候,比如这个CDC,除了数据接口外还需要控制接口,这在当时是没有这方面的统一标准,于是就出了Union来表示多个接口对应一个功能的情况。再后来,USB标准协会又增加了IAD。
8 Y" c$ D! F- T8 [1 C
7 t/ d4 U- l1 [" DIAD与Union类似,Union是旧版本下实现多个接口对应一个功能的功能描述符,而IAD是USB协会后来针对多个接口对应一个功能的情况而扩展的,旧的主机可能只支持Union方式,但IAD并不会影响旧版本主机对设备的识别,因为旧版本主机会通过Union来识别哪些接口是联合在一起的,对于IAD则跳过忽略;而新版主机则可以通过IAD来识别,跳过忽略老的Union,因此两者可以完美兼容,互不影响。因而主机端可以精确地装载对应的驱动。
* O0 u& d3 p* T' V, K7 R( |6 E  B' c& Y  t5 T5 d5 a% c5 D# Z# t9 U( k
IAD只用在设备描述符中只用了device class code,并且指明了使用IAD来识别设备,比如bDeviceClass: Miscellaneous (0xef), bDeviceSubClass: Common (0x02), bDeviceProtocol: Interface Association Descriptor (0x01)就是一个例子; 0x02,0x00,0x00是另外一个例子。
. `2 r  I6 T4 D3 u7 ^  T, N7 a' ^# R! e+ n) k( [
如上图,bFirstInterface值为0,表示第一个接口个接口0,默认为控制接口;bInterfaceCount值为2,标志此功能总共存在2个接口,那么第二个接口就是接口1,因为USB2.0 IAD ECN补充标准规定,这里提到的接口号必须是连续的,也就是说,接口0为第一个控制接口,那么接口1则为数据接口。( [: k0 a5 h. L
  P4 }( C- I4 ], g
下面我们来个具体的IAD例子:
& E: U7 J+ T# M- y9 A6 t& R" X 23.png . I. q6 I0 \: q5 h* ?! O) V% K9 M5 i
图 12 IAD存在时的设备描述符
; Y+ y0 C6 v" B8 J
/ u6 q; m4 W$ a( G3 h2 i$ u 24.png
/ f- W5 g9 F9 D/ \; ~& \图 13 IAD, u" N. N# y" C- d; E

& F6 q, o+ `$ z6 M- T如上图所示,一般IAD存在的情况下,在设备描述符中DeviceClass等三个参数不再都为0x00,图12中为0xef,0x02,0x01,这个表示是复合设备,此时,可以使用IAD来定义多个接口联合起来对应一个USB驱动。从IAD中可以看出,bFunctionClass参数就定义了此IAD表示的设备为CDC类设备,ACM模型。就这样,通过IAD描述符,实现了与Union功能描述符相同的功能。
4 M1 u5 M( w( S+ \7 j! u+ E7 Q4 I0 j8 }5 D% h+ V1 H
2.3.4 ACM模型
; x1 C7 F  [/ e8 R4 ^之前我们已经在控制接口中的功能描述符中已有对ACM(Abstract Control Mode)模型的简介,也有提到过,在PSTN中,除了ACM模式,还有TCM,DLM模式。这三种模式,不同的模式下包含的控制指令集是不尽相同的,有部分控制指令可能同时存在两个或三个模式下,除了控制指令,还有异步通知消息,这个在三个不同模式下也是不相同的。$ m+ F+ ?  G, \$ a3 H( X% P
31.jpg
  y* Z/ o  O5 n2 L6 _2 t图 14 ACM模式下的控制指令集+ i0 U, o4 e9 ?
32.jpg
% r; t, x; g# ?6 _, p9 x图 15 ACM模式下的异步通知消息' l! @( U2 u- a1 c# G, w
33.jpg
& _# K; j* ^3 ?) r& \% A图 16 DLM模式下的控制指令集6 B3 B6 t- {" X1 \, ?
34.jpg
/ M# }4 ^+ Q" k  \4 Z! x( R- l* _图 17 DLM模式下的异步通知消息

$ y/ \: D: e* f% ]% x 41.jpg * ?0 {0 O. T* Z! ^, Z
图 18 TCM模式下的控制指令集
6 E# Y7 _" N& V% T2 D 42.jpg * H0 Y# v1 N$ Y0 O4 v; b. o6 `
图 19 TCM模式下的异步通知消息
5 T; l7 R% ]7 v) F8 X
' |) w1 }& S4 O* H  F( J, o由图14~19可知,当设备选择了某个模型后,其控制指令集和异步通知消息也就得符合此模式下的对应集合,否则则不符合标准。这里我们主要是使用到ACM模式,因此,此ACM模式下的有Host端发现Device端的控制指令和有Device端向Host端发送的异步通知消息都是固定的那么几条指令或消息,但并不是说,只要是ACM模式,那么就表示此模式下的所有控制指令和异步通知消息都必须支持。控制指令在设备端的控制接口描述符中的ACM功能描述符中的bCapabilities字段有按' v" l2 o% q: A; d4 z
位定义ACM模式下的控制指令的支持情况,而异步通知消息,则完全看device端的应用情况是否需要,并没有在任何描述符中指出那些消息是否支持。
2 l- A. `9 R. e
- A8 `  J* P/ k+ X在ST给出的CDC例程中,主要是使用到了SetLineCoding指令来设置和修改虚拟串口的波特率,使用GetLineCoding来获取当前波特率,使用SetControlLineState来打开或关闭串口,这种操作是在Host端CDC驱动来具体映射实现的,至于Device端收到这些个控制指令该怎么处理,就是另外一回事了,Device端也可以完全不做任何处理,有CubeMx自动生成的CDC类代码就是这样,对接收到的任何控制指令到没有做任何处理,当然,如果需要的话,则按应用的需要来处理,这个完全取决于用户。# t$ q9 l# D$ r6 e4 b
41.png
4 X% v' _" m2 I2 b% q" E% {) \3 y* ]图 20 控制指令操作虚拟串口
9 K4 P; j5 c1 h( M$ O/ ? 42.png
% J8 P6 w2 M. a. J图 21 一个ACM模式下的异步通知消息例子
1 ?+ n& R/ N9 H! E9 i+ l8 ~; c
1 K1 O8 y3 R2 ^9 ~: p3 CDC类软件框架介绍% H6 S) A, _% s* [; j4 z7 e
: d' j/ E, W. L8 [6 r$ n& {
3.1 CDC软件框架简介6 g; m) I7 P% h& d) h0 B; e
43.png
. t" v/ b, d$ A" y, i& `图 22 CDC类软件框架
' q3 r( p. ]9 r, f; D5 F! k8 E, {- B* b: }" e$ L4 p
如上图所示,黄色USB Device Core部分为USB设备库文件,属于中间件,它为USB协议栈的核心源文件,一般不需要修改:* G  @5 K& ]8 Z4 E2 i) w
●    USB Device Core中,Log/debug为打印/调试开关;
1 N+ b4 R" P, E/ l0 s; `●    core为USB设备核心;7 i* p! m. G# a5 w1 u
●    USB request中定义了枚举过程中各种标准请求的处理;
- X8 a0 l$ P6 ~+ k7 u●    I/O request为底层针对USB通信接口的封装。; b! s2 `# _1 }7 L

+ M# t9 u4 m; V& Y- D8 D, A黄色USB Device Class部分为USB类文件,也属于中间件,USB设备库,目前ST DEMO中支持的类有HID, Customer HID, CDC, MSC, DFU, Audio, ST提供了这些类的源码框架,其他的Class或者是复合设备需要自己根据实际需求情况进行扩展或定制。如果用户需求只是需要一个标准类,比如CDC通信,那么最好就使用现成的代码,不需要做任何修改就可以实现这个CDC类通信的功能。
0 ^5 t; ?8 t6 Y$ A
3 O7 w/ T; p- P蓝色USB Device HAL Driver为HAL库部分,是对USB外设接口的封装,属于底层驱动,不需要修改,它分为PCD和LL Driver,PCD处于LL Driver之上。
8 W8 k! D$ Z+ Y8 O# H
* c/ o4 \7 j5 w' q) \/ b洋红色USB Device Configuration为USB配置封装,位于USB底层HAL层驱动与中间件USB协议栈之间,一方面向上层(USB设备库)提供各种操作调用接口,另一方面,向底层USB驱动提供各种回调接口。正是由于它的存在,使得USB协议栈(USB设备库)与底层硬件完全分离,从而使USB设备库具有更加兼容所有STM32的通用性。USB Device Configuration为开放给用户的源文件,用户可以根据自己的某些特殊需要进行修改,也可以使用默认的源文件,假如没有任何特殊要求的话,我们使用默认即可。
9 @7 w% j+ d+ h6 Y1 O  _' Q
/ x1 h9 d. n# W; SApplication为应用层,USB Device Class有可能将自己对应该的操作接口封装在一个操作数据结构中,由应用来具体实现这些操作,在系统初始化时,由应用将已经定义好的操作接口注册到对应的USB类中,比如usbd_cdc_if, 就这样,使得应用层的应用代码与属于中间件层的USB协议栈分离。同时,USB协议栈会将一些字符串描述符放到APP中,当USB初始化时将这些已经定义好的字符串通过指针初始化到USB协议栈中,以便后续需要时获取。
2 X/ K5 ]; g1 r6 }6 N: {: s/ m1 c$ Y  `( ~: p
0 P! _9 |* W( A% ?! s5 _
3.2 工程源码文件与软件框架的对应关系 0 {+ e  J: Q9 O! |7 |) I: @0 n
44.jpg
4 q8 a; G0 o. L  t图23 CDC工程中源码与软件框架的对应关系
# H* I: ?3 R4 S7 i# l/ A& H6 d5 i5 ], i2 K) R6 P
3.3 USBD内核与USBD_CDC的关系
- _* H6 d* p6 A( K- I# T3 e3.1节中,我们已经提到过ST官方Cube库中提供的官方USB协议栈,主要是包含了USBD内核与USB各种类。USBD内核一般是固定的,用户一般不需要修改,但USBD类,如果用户需要修改或者扩展,比如复合设备或者用户自定义设备,还有就是,ST目前官方提供的USB设备类的DEMO程序并没有囊括所有USB类,因此,若用户需要实现这些官方提供DEMO之外的USB类时,则用户需要根据自己的需要来定制化自己的USB类,那么又该如何开始呢?' n1 I0 ]; S& u' [4 a

- Y1 a) W1 k8 g8 v4 E1 J; U我们已经知道,ST提供的USB协议栈中已经有USBD内核,且这个内核源文件一般是不需要修改的,那么这里我们需要自定义这么一个USB类,那么我们首先得知道,这个我们需要自定义的USB类是如何与USBD内核打交道的?
8 Z! B. m& j6 X' m5 V, g
9 h% R, O7 j4 s+ m  c3 w' IUSB协议栈将所有USB类都抽象成一个数据结构:USBD_ClassTypeDef,其定义如下所示:
$ _. v' L8 m% o$ r$ o' I' T7 m- U" p; | 45.jpg
% V( U0 L7 [  \; ?" N. f, n+ H 46.png
$ J) `+ }, B8 l& p5 O
. Z5 q. Y, }+ `这个结构体是一个抽象类,定义了一些虚拟函数,比如初始化,反初始化,类请求指令处理函数,端点0发送完成,端点0接收处理,数据发送完成,数据接收处理,SOF中断处理,同步传输发送未完成,同步传输接收未完成处理等等;用户在实现自己具体的USB类的时候需要将它实例化,USBD_ClassTypeDef结构体是USBD内核提供给外部定义一个USB设备类的窗口,而USB类文件(如usbd_cdc.c)实际就是实现这个结构体具体实例化的过程。最后将这个具体实例化的对象注册到USBD内核的同时, USBD内核与USBD类也进行了关联。# v' ?& }( c) E2 G3 M/ `' X; _3 h
47.jpg
, Q% S, d2 `) j* n+ s+ {' ~图 24 USBD核与CDC类的关系
8 x2 _' o! h( a7 t0 e1 h9 `/ n
......   ......  
* _( F0 I' J: r; O) O
& `4 P4 }9 Q2 Y8 b3 f3 e: T$ k. V
" I7 b0 [, d5 b4 p! `% h" Q& e; F/ p4 c+ n# R3 z, v9 t4 I
由于帖子过长,更多详细信息下方文档中的PDF及代码!
+ }) _! k1 k( }$ r! Q
4 a- \7 q( ^* k6 ~; m
9 @! d: _3 `$ n

# N# _2 P- {8 c! L$ I# w7 M5 ?' D% d: K; m2 a

: [* Y/ W0 p. m' N) j! {8 a文档下载* o9 [& J* y  u( T& t
9 ]# c# I/ O! S. u

, [! n. z6 G$ r' q* m更多实战经验
' G$ c1 Q' }5 ]) A, x* a2 t! I8 ?# D% u
收藏 9 评论15 发布时间:2017-7-28 17:27

举报

15个回答
creep 回答时间:2017-7-28 17:46:16
牛逼。         
Paderboy 回答时间:2017-7-28 20:10:27
太牛逼。。
Stm32McuLover 回答时间:2017-7-28 20:27:31
破总牛逼
群星闪烁 回答时间:2017-7-30 18:24:36
牛逼,写的非常详细
asmhai 回答时间:2017-9-12 10:45:05
初级入门中,上面没看明白!!!保存下来。
asmhai 回答时间:2017-9-12 11:16:31
签到签到
枫天123 回答时间:2017-12-7 16:09:31
看不懂额% ~- k! S5 \* g! G
zzfd97 回答时间:2017-12-14 14:31:17
太牛逼。。
wylew 回答时间:2018-1-11 15:17:01
您好!我想问下,如果在基于CDC类ACM上开发组合设备,就是基于一个设备上配置多个接口设备功能,即CDC_ACM+Mass Storage这样的有问题吗?
Mr.Luav 回答时间:2018-2-4 14:01:11
好资源啊   学习!
路平 回答时间:2018-4-27 10:49:22
厉害
liuer2004_82 回答时间:2018-5-22 21:33:56
讲解有深度。。。。。。。。。3ks
ZCShou 回答时间:2018-7-28 18:30:15
楼主有没有原培训资料的附件啊,正常培训资料里有个 CDC_training.tdc 的USB 报文
467386895 回答时间:2020-11-17 21:27:45
MARK
12下一页

所属标签

相似分享

官网相关资源

关于
我们是谁
投资者关系
意法半导体可持续发展举措
创新与技术
意法半导体官网
联系我们
联系ST分支机构
寻找销售人员和分销渠道
社区
媒体中心
活动与培训
隐私策略
隐私策略
Cookies管理
行使您的权利
官方最新发布
STM32N6 AI生态系统
STM32MCU,MPU高性能GUI
ST ACEPACK电源模块
意法半导体生物传感器
STM32Cube扩展软件包
关注我们
st-img 微信公众号
st-img 手机版