USBUART_PutData（）不适用于64字节

嗨，Anguel，这是个难题。当然，把文本分成64字节以下的数据包。这是一个方便的方式，但不是你想要的答案。请询问柏树案件。



     以下为原文
          Hi Anguel, A difficult problem.   
Of course separate the text into packet below 64byte.   
That is a handy way but is not an answer you want.   
Please ask for Cypress Mycase.   

PSoC03，谢谢你的回答。MyCox是开放的，但与此同时，我意识到问题可能与此有关：HTTP://wwwyCysP.COM/？ID＝4和；RID＝38107 BTW，为了达到最大效率，每个包必须使用完整的64字节。事实上，我希望从像柏树这样的USB专家那里了解API的更多信息。在那时，更多的是猜测API函数真正做了什么……安吉尔



     以下为原文
          PSoC73, thank you for the answer. The myCase is open but in the meantime I realized that the problem may be related to this: http://www.cypress.com/?id=4&rID=38107 BTW, to achieve max. efficiency, one must use the full 64 bytes per packet. Actually I expected more info on the APIs from a USB specialist like Cypress. At the time it is more about guessing what the API functions really do... Anguel   

虽然我认为似乎能够解决这个问题，因为他们知道原因。他们说“这个问题将在PSD5.0 SP6中修复，预计2009年9月底”HUUM…如果你需要，你可以自己修理。将用户模块程序复制到原始名称和方向。解决问题。



     以下为原文
          Although I think to seem to be able to resolve it because they know the cause.   
They say "This problem will be fixed in PSD5.0 SP6, which is expected by the end of September 2009" huum...   
If you need, you can fix by yourself.   
copy user module program into original name and your directry.   
and fix the problem.   

嗯，我认为可以发送尽可能多的64字节数据包，当我完成时，只要按照USB标准发送一个零长度包，以确保主机确认最后的数据包，即我做一个长度参数为0的UBUTARTURPUDATA（）。
实际上，我不确定CyPress实现有多有效，但是正如在缺陷报告中所说的“修复bug”可能会使PSoC在每个64字节背靠背之后发送零长度包，这将降低吞吐量。通过一个接一个地发送64个字节的数据包，并且仅仅检查USB是否能接受更多的数据，我已经达到了大约每秒590千字节，这对于USB CDC不是很坏。这可能是在没有完全改写驱动程序的情况下实现的最好的…
安吉尔



     以下为原文
  Well, I think it is possible to send as many 64 byte packets as I like and when I am done just send a zero-length packet as required by the u*** standard to make sure that the host acknowledges the last packets, i.e. I do a USBUART_PutData() with length parameter =0.
     
    Actually I am not sure how efficient the Cypress implementation is, but "fixing the bug" as they say in the defect report would probably make the PSoC send a zero-length packet after each 64 byte backet and this would decrease throughput. By sending 64 byte packets one after the other and just checking if USB can accept more data inbetween I have reached about 590 KBytes per second which is not very bad for USB CDC. This is probably the best one can achieve without completely rewriting the driver...
     
    Anguel

我懂了。590kb/s是一种很好的性能。我不可能这么快就完成。我的平均记录是50kb/s，但它是用回音、回传传输的。我认为，60字节的数据包，或者62, 63字节不是坏的，而不是64字节。不管怎样，你可以在这个网站找到CysB.DLL的源文件。当你修改记录时，让我们知道。



     以下为原文
          I see.   
590KB/s is a very good performance.   
I couldn't never achieve so fast.   
My average record is 50KB/s, It is with echo back, loop back transfer, however.   
I thought, 60byte packet, or 62, 63 byte is not bad rather than 64byte.   
Anyway, you can be find a source file of CyUSB.dll in this site.   
When you revise the record, let us know.   

为了实现USB CDC全速的最大速度，你应该：
1。将最大可能字节放在CDC的一个包中＝64字节
2。尝试发送尽可能多的数据包在1ms的框架：多达19个包是可能的，但这只是一个免费的USB总线，在实践中，你不会达到19，也许16左右。
三。当然，速度也取决于USB硬件和驱动程序。
查看此帖子获得更多信息：HTTP://www. McCHIP.COM/FUMMS/M450163-Prim.ASPX
对于PIC32，它们大约有800千字节/秒。在一些CyPress AppNOTER中，我看到CDC只有80千兆字节/秒，但这可能不正确。
安吉尔



     以下为原文
  To achieve max speed for USB CDC Full Speed you should:
     
    1. Put max possible bytes in one packet = 64 bytes for CDC
     
    2. Try to send as many packets as possible in a 1ms frame: up to 19 packets is possible but this is only for a free USB bus, in practice you will not reach 19, maybe 16 or so
     
    3. Of course the speed also depends on the USB hardware and the driver.
     
    See this post for more info: http://www.microchip.com/forums/m450163-print.aspx
    For a PIC32 they get about 800 KBytes/s. In some Cypress appnote I saw that only 80 KBytes/s were possible for CDC but this is probably not correct.
     
    Anguel

如果最后一个包是64字节，则应该在空包之后发送。



     以下为原文
  If the last packet is 64 bytes that should be sent after the null packet.

我的翻译弄错了。最后一个必须是零包。



     以下为原文
  my translator was mistaken. The last one must be a zero packet.