从设备FIFO OUT吞吐量

当我使用带Keil演示板和CySal.IIC的拖缆时，我看到了32 Mb/s。
当我使用自己的应用程序发送4个16MB数据块时，我看到27 Mb/s。我已经将XFEXSIZE设置为1MB和4个循环的16个结果的StasXFER调用+等待16个WaWixFER和FinishXfer调用。Pseudocode：
对于i＝1到4，获得j＝1到16的启动时间（1MB，重叠），对于j＝1到16 WaitXfer FinishXfer得到结束时间累积转移时间。



     以下为原文
   When I use Streamer with the Keil demoboard and CYStream.iic I see 32 MB/s.
    When I use my own application which sends 4 chunks of 16MB data I see 27 MB/s. I've set XferSize to 1MB and time 4 loops of 16 consequentive StartXfer calls + wait for 16 WaitXfer and FinishXfer calls. Pseudocode:
    for i=1 to 4     get start time     for j=1 to 16         StartXfer (1MB, overlapped)     for j=1 to 16         WaitXfer         FinishXfer     get end time accumulate transfer times

CySt流只是获取数据包并丢弃它。在OUT的情况下，它会产生被拖缆丢弃的垃圾包。
在你的情况下，你有其他依赖关系，即固件，主机应用程序做的东西与包和接口等是不同的。你应该能够改变VID/PID到04B4／1003，绑定到流和发送数据包。这将给你一个可以实现的吞吐量的好主意。
通过比较CyStase+ StuffER与你的应用程序+固件，我们比较两个未知数，即工作未知，隔离和理解可以在哪里进行改进。
当做，
阿南德



     以下为原文
  Cystream just gets the packets and discards it. In the case of out it generates junk packets which are discarded by streamer.
    In your case you've other dependencies i.e. firmware, host app doing something with packet and interface etc etc is different. You should be able to change the VID/PID to 04B4/1003, bind to streamer and send packets. This would give you a good idea of the throughput achieveable.
    By comparing cystream + streamer with your application + firmware we're comparing two unknowns i.e. work the unknowns to isolate and understand where the improvement can be made...
    Regards,
    Anand

虽然我发现很奇怪，但我越来越近了。
我有一个DLL，它有一个函数，它从一个Apple中提取数据，把它切成块，然后把它发送给FX2。当我传递一个数组gt；1MB，我访问数组中至少一个字节时，传输速度减慢。如果我不触摸数组内容，而是在DLL中使用一个哑数组，则传输速度很快。如果我在块和1MB中通过另一个函数填充这个哑，它会保持很快。如果我只通过一个大数组，传输就会变慢。在大数组访问和传输之间有多少时间似乎并不重要。看起来，当我通过一个大数组来减缓所有的事情时，就会触发某种保护算法。它甚至与数组的大小成比例。
有人知道我面对的是什么吗？



     以下为原文
  Even though what I find is very weird, I am getting closer.
     
    I have a DLL with a function that takes the data from an apllication, chops it in chunks and sends it to the FX2. When I pass an array of >1MB and I access at least one byte in that array the transfer slows down. If I do not touch the array contents but instead use a dummy array within the DLL the transfer is fast. If I fill up this dummy through another function in chunks <1MB it stays fast. If I only once pass a large array the transfer becomes slower. It doesn't seem to matter how much time there is between the large array access and the transfer. It looks as if some protection algorithm is triggered once I pass a large array that slows everything down. It even scales with how much bigger the array is.
     
    Does anyone have an idea what it is I am facing here?

我不确定你面临的1字节访问问题，
这很可能是由于OS或您的变量类型（在DLL）的保护机制，以避免数据损坏，即只允许句柄访问阵列一次。
关于大型阵列传递，最可能是由于主机控制器驱动器中的大小分配。默认情况下，CysB.Se请求在主机控制器驱动器中分配8＊端点大小缓冲器，用于对应于特定端点的传输。假设你触发一个大的传输，每次缓冲区填充它将被传送到OS中的内存，然后只有主机控制器才能接受更多的数据。这个过程将减缓转移。
尝试使用XFIZSIZE变量更改此缓冲区分配。64K是推荐值。
当做，
阿南德



     以下为原文
  I'm not sure about the 1 byte access problem you're facing,
    It is most probably due to the OS or your variable type (in your DLLs) protection mechanism to avoid data corruption i.e. allow only handle to access the array at a time.
    With regards to the large array passing, it is most probably due to the size allocation in the host controller driver. By default CyUSB.sys request allocation of 8*endpoint size buffer in the host controller driver for transfers corresponding to a particular endpoint. Say you trigger a large transfer, every time the buffer fills it will be transferred to memory in the OS and then only the host controller can accept more data. This process will slow down the transfer.
    Try changing this buffer allocation using XferSize variable. 64k is the recommended value.
    Regards,
    Anand