STM32 OTG的一点心得和问题

只看该作者 · 2011-7-25 09:12

本帖最后由 coreduo 于 2011-7-25 10:49 编辑

最近要用USB Host扩展wifi，所以抽几天空研究了下stm32的otg，这里有几个心得：

1. 官方OTG库写的不错，他的框架是while循环调用的状态机，大量的中断来驱动数据收发和设备拔插。官方的HID，Mass class类驱动都是要人工加载，而不是自动识别的，这个不太好。

2. 为了应用程序可移植性，一般我都是自己重写驱动。对stm32的otg host模式有些感悟：
.能轮询的东西就不用中断, 比如检测device拔插，对实时性没啥要求，用中断没意思，还会造成系统状态机复杂化
. stm32的中断有两种，一种是全局中断GINTSTS，比如设备拔插，发送缓冲区空，接收缓冲区满等。一种是通道中断HCINT（0..7)，里面包括通道trnansaction成功，ack，nak，stall反馈等。所以对于收发数据，需要根据GINTSTS中断来决定读写数据，从HCINT获取transaction是否结束或者失败。这个搞清楚了，这个驱动就没什么难度了。

另外有个疑问：
目前发现stm32的接收行为，是写一次HCCHAR寄存器，他发一个IN token，无论收到nak还是ack，后面都停下来了。
有没有一种模式，写一次HCCAHR命令，他能一直工作到ack为止，如果收到nak，他就不不停的IN？这对于网卡接收数据是至关重要的。
如果只能写一次 HCCHAR，发动一次IN，那岂不是变成轮询了？完全没效率啊。

只看该作者 · 2011-7-25 10:04

楼主对otg搞得似乎挺熟悉的，本人对USB核其实不是很了解，只对其中的一些函数调用有一些知识，请问楼主一个有关usb的发送数据问题，bulk发送数据，块传输过程中有令牌、数据、握手的过程，那么发送完数据之后，STM32应该人发送一个ACK给PC机，那么这个发送的过程是什么样的呢，具体在哪个函数里面发送接收的状况的呢

只看该作者 · 2011-7-25 10:30

发送数据最简单：
调用发送函数，官方驱动在usb_core.c里面USB_OTG_HC_StartXfer函数。
接收完成后会触发好几次中断，具体你看硬件参考文档里的Normal bulk and control OUT/SETUP operations
官方的中断处理程序在usb_hcd_int.c

官方驱动最最最不好的地方就是，usb host逻辑和硬件驱动交叉混在一起，完全没有可移植性。

只看该作者 · 2011-7-25 11:10

官方驱动的usb_core.c有这个函数吗，我用的是Version : V3.1.0，还有想明白的一点是，握手包是如何发送回Host的

1万 · 2011-7-25 11:14

官方驱动的usb_core.c有这个函数吗，我用的是Version : V3.1.0，还有想明白的一点是，握手包是如何发送回Host的
desomond 发表于 2011-7-25 11:10

握手包是由STM32的USB模块自动发送回Host的。

只看该作者 · 2011-7-25 11:26

握手包是由STM32的USB模块自动发送回Host的。
香水城发表于 2011-7-25 11:14

香主，你好，所谓的自动发送......本人理解是：BULK发送的握手包有ACK表示正确接收完成，是软件自动发送，那也应该有相应的代码的，本人碰到的问题怀疑没有正确发送回ACK，所以有所疑问

只看该作者 · 2011-7-25 11:29

或许是在端点2的接收缓冲区里面，一旦完成接收，就发送回ACK

1万 · 2011-7-25 11:38

香主，你好，所谓的自动发送......本人理解是：BULK发送的握手包有ACK表示正确接收完成，是软件自动发送，那也应该有相应的代码的，本人碰到的问题怀疑没有正确发送回ACK，所以有所疑问 ...
desomond 发表于 2011-7-25 11:26

ACK不是软件自动发送，是由STM32的USB模块(硬件)自动发送回Host的。

只看该作者 · 2011-7-25 13:16

ack肯定是硬件发的。所有token信息都是硬件发的。

1万 · 2011-7-25 14:27

对于LZ的疑问：目前发现stm32的接收行为，是写一次HCCHAR寄存器，他发一个IN token，无论收到nak还是ack，后面都停下来了。
有没有一种模式，写一次HCCAHR命令，他能一直工作到ack为止，如果收到nak，他就不不停的IN？这对于网卡接收数据是至关重要的。
如果只能写一次 HCCHAR，发动一次IN，那岂不是变成轮询了？完全没效率啊。

我没有看过文档，不知道它是怎么操作的。但我认为收到NAK由软件干预再发IN，从硬件角度讲比较容易实现；如果要硬件实现收到NAK后自动发送IN，则硬件不好设计，同时系统的灵活性较差。

作为Host要合理调度总线的使用，不能让一个设备占掉所有的带宽，也就是说收到NAK后，需要有一定的延迟才会发下一个IN，这个延迟时间需要根据当时的具体情况调整，使用硬件进行这样的延迟，大大增加了硬件的复杂性。NAK时自动发送IN，还需要考虑没有收到NAK的超时处理。因为需要考虑的因素太多，理论上可以实现收到NAK时自动发送IN，但把这个任务交给软件完成，可以使系统更加灵活。