欧美极品高清xxxxhd,国产日产欧美最新,无码AV国产东京热AV无码,国产精品人与动性XXX,国产传媒亚洲综合一区二区,四库影院永久国产精品,毛片免费免费高清视频,福利所导航夜趣136

標題: USB開發中的幾個問題學習與總結 [打印本頁]

作者: 15546636181 時間: 2018-9-10 11:40
標題: USB開發中的幾個問題學習與總結
最初買了北通25塊錢的小手柄，然后通過USBVIEW軟件觀察到了如下信息：

這些信息是當手柄插入電腦USB時，主機請求手柄發送它的各方面信息，手柄回傳給電腦的。
對于一個可編程的USB設備，我們將這些信息封裝到一個數據機構中，當電腦詢問時，我們回傳給電腦，電腦有了這些信息之后我們就可以和電腦進行通信了。（參見本文件下的《USB的八個問題和答案》中第八個問題）

從USB基礎到完整驅動開發...
1 USB標準
在新的USB2.0標準中，USB1.1的說法已經不復存在了，都被統稱為USB2.0，在它下面又細分三種規格：Low-speed，Full-speed，High-speed 。乍一看這三種接口都是USB2.0但他們的傳輸速率相差甚遠，USB2.0 Low-speed主要用于鍵盤，鼠標等設備，它的傳輸速率只有1.5Mbps；USB2.0 Full-speed就是曾經的 USB1.0，他的傳輸速率理論上可以達到12Mbps，適用于一些對數據傳輸要求不高的設備的接口； USB2.0 High-speed 才是真正意義上的USB2.0，他的傳輸速率理論上可達到480Mbps。
2. USB中斷傳輸的精彩討論
Escape ：
呵呵。大家好！ ;)
我想請教一個問題：

usb中斷傳輸，調用函數UsbBuildGetInterrupt orBulkTransferRequest

后，數據是怎樣通過底層軟件的輪詢，被傳輸到緩沖區的。
是不是上層驅動程序完全不需要關心這個輪詢的過程？
輪詢過程已經被完全封裝了？
Jinghuiren：

對的，當你調用了IoCallDriver()后，底層驅動會按照你設置的輪詢間隔（比如1ms），向設備發送in或者out令牌，直到本次調用的數據全部完成（比如64k）后返回操作方式和批量傳輸完全一樣。

Pengenwen：
在中斷傳輸中，驅動一般需要維持一個永不完成的URB，以便驅動不斷地從固件查詢數據，然后通過事件方式通知應用程序。
Windrv：
pengenwen 說的不對。
USB是共享總線，如果在USB HUB上有多個設備同時進行大數據量傳輸。例如設備A在傳輸4MB的數據，那么設備B在設備A數據傳輸期間有可能得不到響應。如何保證設備B在其它設備傳輸數據時也能及時得到響應？設備B可以設立中斷傳輸端口，這樣Host Controller會每隔一定的時間間隔(例如1ms)，保證向設備B發出IN令牌，使得B有機會發出數據。

所以中斷傳輸的數據量不能太大，在USB1.1中最多只能16bytes.

USB 2.0的協議作了一些修改，中斷傳輸與Bulk傳輸的區別不大，數據量的限制也沒有了。不過，中斷傳輸的上述機制還是在的。
如果USB的host controller總是被一個設備獨占，那也就沒有中斷傳輸與Bulk傳輸的區別了。
至于pengenwen說的是USB設備驅動程序上的實現技術，與中斷傳輸的特點無關。事實上，這個“永不完成的URB”也可以用來讀Bulk傳輸。
Lejianz：
請教windrv一個問題，在固件編程時，USB通信一般通過外部中斷來實現，如果我在做某些工作時，不能及時響應此中斷，那么不響應這個中斷的時間有多長？我知道總線如果在3ms里沒響應，將會掛起，這段時間是否跟中斷傳輸有關？
Jinghuiren：
對于控制傳輸，通常沒有數據階段傳輸的要在50ms內完成，如果有數據階段則第一個數據包要在500ms內發送給主機，之后的一次增加500ms
對于批量傳輸，如果驅動程序沒有超時控制，則什么時候響應都行
如果有則要在超時控制的時間范圍內完成
對于中斷傳輸，和批量傳輸基本一樣
對于ISO傳輸，應該是立即響應吧，要不然怎么能保證同步數據流呢？
Escape：
對于控制傳輸，通常沒有數據階段傳輸的要在50ms內完成，如果有數據階段則第一個數據包要在500ms內發送給主機，之后的一次增加500ms
對于批量傳輸，如果驅動程序沒有超時控制，則什么時候響應都行
如果有則要在超時控制的時間范圍內完成
對于中斷傳輸，和批量傳輸基本一樣
對于ISO傳輸，應該是立即響應吧，要不然怎么能保證同步數據流呢？
有道理。
iso傳輸在競爭帶寬的時候，容易獲得成功。iso傳輸
最大可獲取90%的可用帶寬。在這種情況下，需要iso傳輸
的另外一個設備的傳輸請求有可能會失敗。
Windrv：
USB是主從通訊模式，由Host controller控制何時與哪個設備的哪個端口通訊。當它需要從某個EP讀入數據時，它會發一個IN令牌給此端口。端口收到令牌后，必須在某一時間間隔內把數據發給Host Controller然后返回一個"OK"令牌；如果端口在此時間內無法返回數據，也必須返回一個NAK令牌，那么Host Controller下次會繼續發IN令牌給此端口。如果端口在此時間間隔內沒有任何令牌返回，Host Controller會把這端口標為STALL，下次不再查詢此端口。
對于lejianz所說的問題，我覺得firmware在做某些工作時，在3ms內沒有返回NAK token以響應總線的IN token，所以被總線掛起，即STALL。不過，掛起了也還可以用ResetPipe()恢復此端口。
EZUSB做的比較好，它的USB core在數據沒有Ready的時候會自動返回NAK令牌，不占CPU的資源。所以，在批量/中斷傳輸時，什么時候響應都行。
不過，對于這類總線掛起的問題，最好用總線分析儀去監測一下。Host Controller的生產廠商不一樣，有時候是USB卡的問題。
Lejianz：
謝謝windrv大俠的精彩答復，按大俠所說，如果EZUSB設備的一個IN令牌包傳輸過程中，SIE能自動發也NAK，而不是STALL，那么我可以在很長一段時間里不響應此IN中斷，因為有NAK說明設備在忙。這也印證我在ICE仿真時，當在中斷里下斷點時，設備管理器里的設備不會消失。但我想這段時間并不是jinghuiren大俠所說的500ms時間，我一直沒有找到相關的敘述。windrv大俠能否再看一下。
Windrv：
只要設備能回應NAK，讀數的URB等多長時間都沒有問題，通訊不會斷掉。在我們的應用中，讀數的URB經常會等好幾個小時。
不過，你說的設備在設備管理器里消失是另外一個問題。即使EP被STALL，USB 的設備對象還是在Windows系統里的，不會消失。
Mboma：
windrv,我覺得pengenwen說的"在中斷傳輸中，驅動一般需要維持一個永不完成的URB，以便驅動不斷地從固件查詢數據，然后通過事件方式通知應用程序"沒有什么不對的啊，通常在usb驅動中處理中斷傳輸都可以用這種實現方式的啊。我覺得他說的東西跟你說的不是一個側重點。在Oney的書中也是用的這種方式。
想請教您一個問題，中斷傳輸只能獲取in的數據么？如果我有host向usb設備發出的用戶數據，但是usb設備只有一個控制端點和2個interrupt端點，能否實現out數據？謝謝！
Metalwing：
WINDRV又見你了,想問你個問題.
我的板子在20MHZ(DMA讀寫)頻率下很正常,可是我把頻率提到40MHZ就不行了,無法接到總線上DMA數據傳輸到的中斷,也無法接到DMA傳輸完成的中斷(DMA一直在傳輸),我用的是ISP 1581芯片.是否是51的處理頻率(12MHZ,一個工作周期是1微秒)跟不上?

全部資料51hei下載地址：

USB開發中的幾個問題.rar (1.07 MB, 下載次數: 14)

作者: xikree 時間: 2020-5-26 19:59
資料很不錯�。≌诟鉛SB，使用的是ST的芯片，但是發現device->host 控制傳輸大于32字節的數據就收不到了，或者說發不出去了。不知道什么原因，bushound抓包什么都抓不到。

作者: ioriysu 時間: 2020-5-27 07:24
這個資料很不錯，學習了。

歡迎光臨 (http://m.raoushi.com/bbs/)