otg_fs host IN通道请求队列

只看该作者 · 2013-8-6 15:37

otg_fs资料真是很混乱，对照参考手册和例程发现越来越看不懂

2.1库的host msc例程中

接收FIFO时，in通道只在DFIFO[0]上接收，不管实际是哪个通道，可是手册对DFIFO的解释确是每个通道对应一个DFIFO地址(包括IN通道类型)，没有任何解释

从主机参考手册对otg_fs调度器的解释，所有通道请求，不管in还是out类型，都有传输请求队列，花了好半天，终于从抠字眼中找出HNPTXSTS和HPTXSTS这两个寄存器的命名中看出端倪，原来关于请求队列的内容都在这里，不仅仅是out通道，只不过txfifo内容只针对out通道而且，这个也不强调一下，我估计很对人没注意这个问题对于请求队列头部的部分内容也解释不对( 01：0长度的传输包(设备IN/ 主机OUT)，这个寄存器只在host下有效，怎么会是设备IN呢)

就算IN通道也有请求队列， 26.6.4 主机调度器一节中对IN通道传输请求发起一说，也没有像out传输一样，确认下相应的请求队列是否已满就直接使能了并认为已经插入了in传输请求，这是否有bug呢，当然如果情况是传输请求队列满的时候，通道使能后只会在等到队列未满时才插入请求这样的话，结果也没错，只是解释是错的

我看到库中USB_OTG_HC_StartXfer 使能通道后实际上也没检查传输请求队列有没有空，如果上个情况属实的话，反正也没错就过去了，接下来直接写入fifo就怪了，写入时没检查txfifo是否有写入空间，只检查写入数量比可用空间大时要打开txfifo非空中断，然后就直接写入这么多数量，这是什么玩意？？？

只看该作者 · 2013-8-6 19:18

不是很懂这一块楼主帮你顶一个看看别人的意见

只看该作者 · 2013-8-7 15:39

现在思考的结果，我发现基本上不可能出现请求队列满的情况，理由如下
stm32f107最多可以使用的主机通道数是8，请求队列也是最多8个，即使你把全部通道都用起来也就是8个请求呀，不可能某个通道已经挂起后，再使用此通道
唯一可能的情况就是8个通道都已经用起来并且提交了请求，此时想要挂起其中一个通道，这个时候才需要判断请求队列非空

只要你没有用完所有通道，完全不必考虑这个问题

stm32的usb库，水很深啊。。。。。。。。