第二十六篇:USB3.0高带宽ISO(48KBytes/125us)实战

2024-08-29 17:08

本文主要是介绍第二十六篇:USB3.0高带宽ISO(48KBytes/125us)实战,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

USB3.1技术已经推出, 10Gbps的速率足以满足数据, HD视频传输的要求.

要步入USB3.1的研发, 还得将USB3.0的基础打扎实.


微软提供的SUPER MUTT只包含一个接口0, 其下有两个ALT, ALT 1与ALT 2, 分别包含了两对ISO IN/OUT端点, 不过, 只有ALT 2下的ISO OUT EP的bMaxBurst为1, 而其它三个ISO EP的bMaxBurst均为0, 而所有的ISO EP的Mult均为0.

即只有一个ISO EP支持2KBytes/125us的能力, 其余三个ISO EP只支持1KBytes/125us的能力, 技术上来讲, 远远未达到高带宽(48KBytes/125us)的上限.


这样的设备,甚至都不如一个高带宽的USB2.0的设备(3KBytes/125us),用来衡量系统中USB3.0 xHCI HOST的高带宽能力也就无从谈起了.

于是, 利用自开发的USB3.0 silicon, 对设备端驱动稍作修改, 经过Lecory Advisor T3 USB3.0分析仪的验证, 证明设备端的ISO EP具有接收与发送48KBytes/125us的能力.


接下来, 则需要用该设备来验证xHCI USB3.0 HOST的ISO高带宽能力.

测试平台为INTEL xHCI USB3.0 HOST, Win8 USB3 STACK.

先给出测试结果:

(1.1) HOST发送48*8KBYTES的数据

ISO MaxPacketSize = 49152

000000830.01842206read-write irp failed with status C0000001

000000850.01842534urb header status C0000B00
00000089 0.01843355IsoPacket[0].offset = 0           IsoPacket[0].Length = 49152 IsoPacket[0].Status = c0030000
00000091 0.01843889IsoPacket[1].offset = 49152   IsoPacket[1].Length = 49152 IsoPacket[1].Status = c0030000
00000093 0.01844382IsoPacket[2].offset = 98304   IsoPacket[2].Length = 49152 IsoPacket[2].Status = c0030000
00000095 0.01844915IsoPacket[3].offset = 147456 IsoPacket[3].Length = 49152 IsoPacket[3].Status = c0030000
00000097 0.01846065IsoPacket[4].offset = 196608 IsoPacket[4].Length = 49152 IsoPacket[4].Status = c0030000
00000099 0.01846393IsoPacket[5].offset = 245760 IsoPacket[5].Length = 49152 IsoPacket[5].Status = c0030000
00000101 0.01846763IsoPacket[6].offset = 294912 IsoPacket[6].Length = 49152 IsoPacket[6].Status = c0030000
00000103 0.01847091IsoPacket[7].offset = 344064 IsoPacket[7].Length = 49152 IsoPacket[7].Status = c0030000

Total data transferred = 0(dec), 0(hex)


(1.2)  HOST接收48*8KBYTES的数据

000001690.02440798IsoPacket[0].offset = 0           IsoPacket[0].Length = 49152     IsoPacket[0].Status = 0
00000171 0.02441290IsoPacket[1].offset = 49152   IsoPacket[1].Length = 49152     IsoPacket[1].Status = 0
00000173 0.02441824IsoPacket[2].offset = 98304   IsoPacket[2].Length = 0             IsoPacket[2].Status = c0030000
00000175 0.02442317IsoPacket[3].offset = 147456 IsoPacket[3].Length = 0             IsoPacket[3].Status = c0030000
00000177 0.02442850IsoPacket[4].offset = 196608 IsoPacket[4].Length = 49152     IsoPacket[4].Status = c0030000
00000179 0.02443343IsoPacket[5].offset = 245760 IsoPacket[5].Length = 0             IsoPacket[5].Status = c0030000
00000181 0.02444533IsoPacket[6].offset = 294912 IsoPacket[6].Length = 0             IsoPacket[6].Status = c0030000
00000183 0.02444821IsoPacket[7].offset = 344064 IsoPacket[7].Length = 49152     IsoPacket[7].Status = 0

这里比较有意思的是:

8个包中, 有三个(0, 1, 7)是成功传输了48K的, 还有一个虽然也传输了48K, 但系统USB3.0 STACK认为该ISO PACKET(4)是不成功的.

这个不成功的原因, 后文中会解释原因.

我所说的有意思是, USB3 STACK在填UrbIsochronousTransfer.TransferBufferLength的时候, 却是4*48K, 而不是3*48K.



从以上USB分析仪中的数据可以发现, 这8次写失败的原因有两个:

1. xHCI HOST没有在一个UFRAME中将数据发完,

2. XHCI HOST根本没有发数据, 甚至都没有在这个UFRAME中发出PING

归结起来, 就是系统USB SUBSYSTEM, 甚至包括MEMORY CONTROLLER, 系统总线等一系列的因素所导致.


对于读成功的情况, 则是在一个UFRAME中, XHCI HOST引发了(32+16)个1K的包的读.

对于不成功的情况, 则是UFRAME中, XHCI HOST没有发出ACK IN来读取设备端的数据, 也甚至连PING都没有发出.


(2.1) 48K*1写:

00000082 0.00891627 read-write irp failed with status C0000001
00000084 0.00891914 urb header status C0000B00
00000088 0.00892735 IsoPacket[0].offset = 0           IsoPacket[0].Length = 49152 IsoPacket[0].Status = c0030000
00000090 0.00893269 IsoPacket[1].offset = 49152   IsoPacket[1].Length = 0         IsoPacket[1].Status = c0020000
00000092 0.00893803 IsoPacket[2].offset = 98304   IsoPacket[2].Length = 0         IsoPacket[2].Status = c0020000
00000094 0.00894295 IsoPacket[3].offset = 147456 IsoPacket[3].Length = 0         IsoPacket[3].Status = c0020000 
00000096 0.00895527 IsoPacket[4].offset = 196608 IsoPacket[4].Length = 0         IsoPacket[4].Status = c0020000
00000098 0.00895855 IsoPacket[5].offset = 245760 IsoPacket[5].Length = 0         IsoPacket[5].Status = c0020000
00000100 0.00896184 IsoPacket[6].offset = 294912 IsoPacket[6].Length = 0         IsoPacket[6].Status = c0020000
00000102 0.00896471 IsoPacket[7].offset = 344064 IsoPacket[7].Length = 0         IsoPacket[7].Status = c0020000
00000110 0.00897498 Total data transferred = 0(dec), 0(hex)


其中, 写没成功, 原因与48*8K相同, 没有在一个UFRAME将数据发完.

后面的ERROR CODE c0020000并非真正的错误, 而是上层没有数据可发导致.


(2.2)48K*1读:

00000168 0.01482911 IsoPacket[0].offset = 0           IsoPacket[0].Length = 49152   IsoPacket[0].Status = 0
00000170 0.01483404 IsoPacket[1].offset = 49152   IsoPacket[1].Length = 0           IsoPacket[1].Status = c0030000
00000172 0.01483938 IsoPacket[2].offset = 98304   IsoPacket[2].Length = 0           IsoPacket[2].Status = c0030000
00000174 0.01484389 IsoPacket[3].offset = 147456 IsoPacket[3].Length = 49152   IsoPacket[3].Status = 0
00000176 0.01485498 IsoPacket[4].offset = 196608 IsoPacket[4].Length = 0           IsoPacket[4].Status = c0030000
00000178 0.01485826 IsoPacket[5].offset = 245760 IsoPacket[5].Length = 0           IsoPacket[5].Status = c0030000
00000182 0.01486196 IsoPacket[6].offset = 294912 IsoPacket[6].Length = 49152   IsoPacket[6].Status = 0
00000186 0.01486524 IsoPacket[7].offset = 344064 IsoPacket[7].Length = 0           IsoPacket[7].Status = c0030000

情况和48K*8情况相同.

只是这里没有出现既传输了数据, 又是出错的情况.


(3.1) 32K*8 WRITE

(3.2) 32K*8 READ

都成功.



总结:

INTEL的xHCI系统加上WIN8的USB3 STACK可以达到32KB/UFRAME的能力, 但不能达到48KB/UFRAME的能力.


这篇关于第二十六篇:USB3.0高带宽ISO(48KBytes/125us)实战的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1118453

相关文章

SQL Server跟踪自动统计信息更新实战指南

《SQLServer跟踪自动统计信息更新实战指南》本文详解SQLServer自动统计信息更新的跟踪方法,推荐使用扩展事件实时捕获更新操作及详细信息,同时结合系统视图快速检查统计信息状态,重点强调修... 目录SQL Server 如何跟踪自动统计信息更新:深入解析与实战指南 核心跟踪方法1️⃣ 利用系统目录

java中pdf模版填充表单踩坑实战记录(itextPdf、openPdf、pdfbox)

《java中pdf模版填充表单踩坑实战记录(itextPdf、openPdf、pdfbox)》:本文主要介绍java中pdf模版填充表单踩坑的相关资料,OpenPDF、iText、PDFBox是三... 目录准备Pdf模版方法1:itextpdf7填充表单(1)加入依赖(2)代码(3)遇到的问题方法2:pd

PyTorch中的词嵌入层(nn.Embedding)详解与实战应用示例

《PyTorch中的词嵌入层(nn.Embedding)详解与实战应用示例》词嵌入解决NLP维度灾难,捕捉语义关系,PyTorch的nn.Embedding模块提供灵活实现,支持参数配置、预训练及变长... 目录一、词嵌入(Word Embedding)简介为什么需要词嵌入?二、PyTorch中的nn.Em

在IntelliJ IDEA中高效运行与调试Spring Boot项目的实战步骤

《在IntelliJIDEA中高效运行与调试SpringBoot项目的实战步骤》本章详解SpringBoot项目导入IntelliJIDEA的流程,教授运行与调试技巧,包括断点设置与变量查看,奠定... 目录引言:为良驹配上好鞍一、为何选择IntelliJ IDEA?二、实战:导入并运行你的第一个项目步骤1

Spring Boot3.0新特性全面解析与应用实战

《SpringBoot3.0新特性全面解析与应用实战》SpringBoot3.0作为Spring生态系统的一个重要里程碑,带来了众多令人兴奋的新特性和改进,本文将深入解析SpringBoot3.0的... 目录核心变化概览Java版本要求提升迁移至Jakarta EE重要新特性详解1. Native Ima

Spring Boot 与微服务入门实战详细总结

《SpringBoot与微服务入门实战详细总结》本文讲解SpringBoot框架的核心特性如快速构建、自动配置、零XML与微服务架构的定义、演进及优缺点,涵盖开发环境准备和HelloWorld实战... 目录一、Spring Boot 核心概述二、微服务架构详解1. 微服务的定义与演进2. 微服务的优缺点三

SpringBoot集成MyBatis实现SQL拦截器的实战指南

《SpringBoot集成MyBatis实现SQL拦截器的实战指南》这篇文章主要为大家详细介绍了SpringBoot集成MyBatis实现SQL拦截器的相关知识,文中的示例代码讲解详细,有需要的小伙伴... 目录一、为什么需要SQL拦截器?二、MyBATis拦截器基础2.1 核心接口:Interceptor

从入门到进阶讲解Python自动化Playwright实战指南

《从入门到进阶讲解Python自动化Playwright实战指南》Playwright是针对Python语言的纯自动化工具,它可以通过单个API自动执行Chromium,Firefox和WebKit... 目录Playwright 简介核心优势安装步骤观点与案例结合Playwright 核心功能从零开始学习

Java docx4j高效处理Word文档的实战指南

《Javadocx4j高效处理Word文档的实战指南》对于需要在Java应用程序中生成、修改或处理Word文档的开发者来说,docx4j是一个强大而专业的选择,下面我们就来看看docx4j的具体使用... 目录引言一、环境准备与基础配置1.1 Maven依赖配置1.2 初始化测试类二、增强版文档操作示例2.

MySQL 多列 IN 查询之语法、性能与实战技巧(最新整理)

《MySQL多列IN查询之语法、性能与实战技巧(最新整理)》本文详解MySQL多列IN查询,对比传统OR写法,强调其简洁高效,适合批量匹配复合键,通过联合索引、分批次优化提升性能,兼容多种数据库... 目录一、基础语法:多列 IN 的两种写法1. 直接值列表2. 子查询二、对比传统 OR 的写法三、性能分析