|
1， STM32F103的USB引脚只有PA11和PA12
2， STM32F103的USB引脚不需要初始化
3， PB14是USE_STM3210E_EVAL板上用来控制实现USB模拟插拔的引脚，该引脚可以是任意I/O口，只是用来控制DP脚的上拉电阻，实现USB设备的模拟插拔
USB设备的模拟插拔功能非常实用，特别对于总线供电的USB设备。PC主机在检测到插入设备的DP脚上拉之后，即认为设备已插入，会立即开始USB枚举。如果此时，设备刚刚获得供电，还没有进行USB模块的初始化，还不能进行USB通信，会无法响应主机的枚举请求，枚举就会失败。所以需要实现USB模拟插拔，仅仅在USB模块已经准备好通信的时候，才使能DP引脚的上拉。
4，USB是主从的工作方式，如果主机不主动要数据，设备是无法发送出数据的。 5，收发数据是对主机而言的（电脑PC），所以EP*_IN_Callback()是单片机发送数据到主机PC端，EP*_OUT_Callback()是PC端发送数据东单片机 6，各位高手，最近在研究stm32的usb程序，virtual com port 的DEMO程序usb_endp.c中有一段程序
void SOF_Callback(void)
{
static uint32_t FrameCount = 0;
if(bDeviceState == CONFIGURED)
{
if (FrameCount++ == VCOMPORT_IN_FRAME_INTERVAL)
{
/* Reset the frame counter */
FrameCount = 0;
/* Check the data to be sent through IN pipe */
Handle_USBAsynchXfer();
}
}
}
一直不太明白是做什么用的 ，请高手帮小弟解释一下，不胜感激 答案：SOF是帧首，对于全速设备来说，每1毫秒有1个帧首信号，因此，每1毫秒会调用1次这个帧首中断回调函数。
在这里，这个中断用做定时，每1毫秒×VCOMPORT_IN_FRAME_INTERVAL的间隔时间，判断下是否有从USART收到的数据要通过USB发到主机。
（这里的USART指的是什么，那个USART口？？？） 7，EP1_IN_Callback，EP3_OUT_Callback这两个回调函数是怎么进去的？ 答案：USB_LP_CAN1_RX0_IRQHandler(USB中断) －> USB_Istr(中断处理函数) －> CTR_LP(CTR正确的传输中断):
根据IN/OUT的方向分别调用：
(*pEpInt_OUT[EPindex-1])();
或
(*pEpInt_IN[EPindex-1])();
EPindex-1指示端点号。 （USB中断怎么触发的？）
中断中调用的两个回调函数数组定义：
void (*pEpInt_IN[7])(void) =
{
EP1_IN_Callback,
EP2_IN_Callback,
EP3_IN_Callback,
EP4_IN_Callback,
EP5_IN_Callback,
EP6_IN_Callback,
EP7_IN_Callback,
};
void (*pEpInt_OUT[7])(void) =
{
EP1_OUT_Callback,
EP2_OUT_Callback,
EP3_OUT_Callback,
EP4_OUT_Callback,
EP5_OUT_Callback,
EP6_OUT_Callback,
EP7_OUT_Callback,
}; 8、 首先，要明白两个观点。第一，USB总线上所有的事务（数据流传输）都是由USB Host主动发起，而USB设备永远永远都是只是被动地接收然后处理USB Host发来的各种各样的命令（要求）。第二，中断是USB Host和USB设备之间的信令员，USB Host所有的要求都是通过这个信令员即中断来通知USB设备。 我们可以将整个USB数据通信过程看成是由一个一个的数据包构成， 而这些数据包又分很多类，比如：令牌包，数据包，握手包，帧起始包。令牌包又分In包，Out包，Setup包。有一点我觉得对于刚开始接触USB的人来说，一定要弄清楚这么多包，哪些是由硬件自动来处理，哪些是要由驱动程序去处理的，如果这点没有弄清楚，写或者看驱动代码时往往会摸不着头脑.下面通过分析USB Host读取USB设备描述符整个过程来说明这个问题： 题： http://p.blog.csdn.net/images/p_blog_csdn_net/aaronychen/EntryImages/20090106/%E6%9C%AA%E5%91%BD%E5%90%8D.JPG
<!--[if !vml]--><!--[endif]--> 1．上图中粉红色的Packet#表示是主机发出，设备接收包；淡青色的Packet#表示是设备发出，主机接收包。如果区分不了这两种颜色，可以根据箭头的方向来区分，“－>”这个表示是主机发出，设备接收的包；”<－” 表示是设备发出，主机接收的包。
2．图中灰色的部分表示，这些包在写驱动的时候是不太需要关心的地方，但是要了解有这么一个过程，这些灰色的部分都是由硬件自动处理.
3．那设备驱动要做的是什么呢？就是根据设备产生的中断来读取、解析、回应相应的数据包，注意上图中土黄色和淡蓝色两个数据包。
4. 下面详细分析整个过程，以及设备驱动该干些什么？
1) 在控制传输阶段，任何一个传输都是由Setup包发起(Packet#96)
2) 当USB设备接收到这个包，并识别出这是一个Setup包时，USB设备会产生一个Setup中断，有的称之为控制端点/端点0中断，以便通知MCU主机有任务下来啦，准备开始做事啦，这个动作都是由硬件自动完成
3) 紧接着Setup包的是，USB主机下达给USB设备具体是什么任务了，我们可以认为这个过程几乎是和Setup中断同时完成. (Packet#97)
4) 既然发生了Setup中断，USB设备驱动就可以认为主机有命令下达，USB设备收到主机下达命令后，由USB设备驱动发送一个Setup应答包，表示说“长官，命令已经收到” ?(Packet#98)
5) 设备已经接收到了主机的命令，那么USB设备驱动现在就要解析这个命令，来得知USB主机到底下达的是什么命令，在这里通过解析黄色数据 ” 80 06 00 01 00 00 40 00”可以得知该命令的意思是主机要求设备发送设备描述符，具体解析过程就是协议规范的内容了…
6) 既然USB设备已经成功得知了USB主机的命令是要发送设备描述符，那USB设备就赶紧去查找这些设备描述符在哪里？
7) 那驱动已经找到了设备描述符了，驱动是不是该把这个设备描述符发给USB主机呢？答案是No，No，No，原因就是开篇就提到的，所有的传输都是有主机主动发起，设备被动响应。现在虽然USB主机通知设备主机要设备描述符信息，但是主机目前并没有要求主机将这些信息发回去，所以，设备就算已经找到了描述符，也不能主动给主机发这些信息。打一个不太恰当的比喻，就好比一场足球比赛，教练让你”活动活动,准备上场”,现在你准备活动已经做完了，那你可不能立马就冲到场上去踢球，即使你活动完了，你还得等待教练的下一步指示，因为教练还得安排决定让谁下场，什么时候下场比较合适…. 等到教练说”上场吧”，那你就可以上场了… 好像比较扯了….哈哈 ?
8) USB主机下一个IN包通知USB设备回应刚才的命令，相当于教练喊”上场”，当USB设备收到这个IN包时，产生一个IN中断来通知MCU，那这时表示设备收到了”上场”的命令了。(Packet#103)
9) 这时，USB设备驱动把找到的设备描述符发送给USB主机。(Packet#104)
10) 主机收到设备回应的设备描述符后，给设备发一个握手包，表示已经收到设备的回应包了。(Packet#105) 11) 接下来，USB主机会发送一个0字节的数据包来作为状态响应，并且设备发一个握手包来结束整个过程，这是由硬件自动完成. (Packet#108/109/110)
由此可见，在控制传输过程中，USB设备驱动比较关心的应该是4，5，6，8，9这些步骤，其他的差不多都由硬件自动完成了。
|
