完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
|
我知道USB包括以下传输：控制中断ButkCurrOutOutOutlook USB USB CDC使用什么？CDC可以配置为执行批量或中断传输吗？
以上来自于百度翻译 以下为原文 I'm aware that USB includes the following transfers:
0
|
|
相关推荐
5个回答
|
|
|
CDC使用批量（OUT，IN）的有效载荷数据和中断（IN）行通知。
以上来自于百度翻译 以下为原文 CDC uses bulk (out, in) for the payload data and interrupt (in) for line notifications. |
|
|
|
|
|
感谢您最新的答复。我还从别处了解到CDC在传输数据时涉及很多开销，在USB中还有其他模式可以以最小的开销传输数据但也有纠错机制吗？
以上来自于百度翻译 以下为原文 Thanks for the reply newfound. I've also read elsewhere that CDC has lot of overhead involved when transferring data, are there any other modes in USB that can transfer data with least overhead but also have error correction mechanism? |
|
|
|
|
|
当然，有理由不使用疾病预防控制中心。其中一个最重要的原因是Windows 10之前Windows版本几乎不可靠。然而，如果CDC的易用性适合您的应用程序，那么任何假定的开销（在正确实现的固件堆栈中没有以传输速度实现）都不是您不会选择CDC的原因之一。确实，微芯片CDC堆栈没有那么高效，但这不是CDC类本身的错误，这是由于CDC IN传输提供的API相当差。即使如此，它比HID要快得多，比编写主机端代码来链接到USB库要容易得多，而且如果您能自己滚动，就不必使用微芯片MLA API进行IN传输。更大的处理器可以跟上。在较快的处理器上，MLA API的开销将随着额外的性能而增加，因此它可能会被略微抵消掉。CDC没有真正的固有开销，并且带宽可以和除了一般批量-MLA低效率之外的一般批量相比。在任何情况下，中断和批量传输模式都提供彼此完全相同的错误校正。只有同步，不提供错误检测和重试。
以上来自于百度翻译 以下为原文 There are reasons not to use CDC of course. One of the top reasons is that it is just barely reliable on windows version prior to windows 10. However if the ease of use of CDC suits your application then any supposed overhead (that does not materialize in transfer speeds in a properly implemented firmware stack) just is not one of the reasons that you would not choose CDC. It is true that the microchip CDC stack is not that efficient but that is not the fault of the CDC class itself, it is down to rather poor API provided for CDC IN transfers. Even so it is much quicker than HID and easier than writing host side code to link to a USB library and you do not have to use the microchip MLA API for IN transfers if you can roll your own. If you are using a 8-bitter processor the whole thing is moot anyway as the USB bandwidth is going to be far greater that the processor can keep up with. On faster processors the MLA API overhead is going to scale with the extra performance so it tends to be cancelled out somewhat. Bottom line is stories of overhead need to be taken with a grain of salt. There is no real inherent overhead with CDC and the bandwidth is comparable to what you would typically get with say generic bulk - MLA inefficiencies aside. In anycase both interrupt and bulk transfer modes provide exactly the same error correction as each other. It is only isochronous that does not provide error detection and retry. |
|
|
|
|
|
事情也取决于你想要达到的数据速率。我运行过一个PIC24GBxxFJ系列芯片，它快速地跨过CDC链接，Windows 7笔记本电脑无法接收到持续的数据流，而桌面四核Win7系统能够——直到屏幕保护程序启动，数据才丢失。所有这些都是用Microchip MLA代码和带有Windows的CDC驱动程序完成的。
以上来自于百度翻译 以下为原文 Things also depend on the data rate you are attempting to achieve. I have run a PIC24GBxxxFJ series chip that fast across a CDC link that a Windows 7 laptop couldn't receive a sustained data stream, and a desk top quad core Win7 system could - until the screen saver kicked in, then data was lost. This was all done using the Microchip MLA code and the CDC driver that comes with windows. |
|
|
|
|
|
我对HID有很好的经验。它不需要任何特殊的驾驶员。PC/Linux／MaStAdAPI就足够简单了。这三者都有内核端缓冲，所以性能很好。HID使用中断传输，这是保证流量，所以其他USB设备不会影响它。HID可以维持接近64KBytes/sec全双工的数据速率（除了一些带有旧USB控制器的Linux机器，其中有一个bug在驱动程序将输入速率降低到32千字节/秒。除非你想要更高的速度，这才是理想的。
以上来自于百度翻译 以下为原文 I had good experience with HID. It doesn't require any special drivers. PC/Linux/Mac side API is easy enough. All three have kernel-side buffering so you get good performance. HID uses interrupt transfers, which are guaranteed traffic, so other USB devices do not affect it. HID can sustain data rates close to 64KBytes/sec full duplex (except for some Linux machines with old USB controllers, where a bug in the driver lowers the incoming rate to 32KBytes/sec). Unless you want higher speed, it's ideal. |
|
|
|
|
只有小组成员才能发言，加入小组>>
5238 浏览 9 评论
2028 浏览 8 评论
1950 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比？
3204 浏览 3 评论
请问电源和晶体值之间有什么关系吗？PIC在正常条件下运行4MHz需要多少电压？
2253 浏览 5 评论
777浏览 1评论
666浏览 1评论
有偿咨询，关于MPLAB X IPE烧录PIC32MX所遇到的问题
595浏览 1评论
PIC Kit3出现目标设备ID(00000000)与预期的设备ID(02c20000)不匹配。是什么原因
676浏览 0评论
576浏览 0评论
/6 
关注我们的微信
下载发烧友APP
德赢Vwin官网 观察
版权所有 © 湖南华秋数字科技有限公司
德赢Vwin官网 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
1338
评论
淘帖
671
