8 Replies Latest reply on Jul 4, 2011 6:38 AM by @zju.edu.cn.2

    why the speeds are so slow?

      Hello!every one.i've been bothered by the slow speed transfer for several days.


      I configured the CY7C68013 in slave fifo auto in mode,endpoint 2 to be a 1024 depth and quad buffer. I wrote 2KB 16-bit datum into 68013.After this operation, the host use function "BeginDataXfer","WaitForXfer"and "FinishDataXfer" to read 512 bytes 4 times with no interval. then I use "QueryPerformanceCounter" and "QueryPerformanceFrequency" in VC++ to compute the consumed time. The result is 2ms in interrupt transfer and 16 ms in bulk transfer.So the speed is 8Mbps in interrupet transfer and 1Mbps in bulk transfer.It's only the speed of full speed rather than the speed of high-speed.(the polling interval is set to be 1 in dscr.a51)


      I thought the SIE may work in full-speed mode, so I try to set the HSM bit of register USBCS,but the speed doesn't change. I thought there may be time interval between four 512 bytes, so I try to read one time of the 512 bytes, but the time consumed in interrupt transfer is 0.5ms, the speed is still 8Mbps. I can't find any other idea for why the speed is so slow now




      Furthermore,there are 2 other questions of the interrupt transfer:


         1,I configure the endpoint 2 to be 1024 depth ,quad buffer , interrupt endpoint and 16-bit wide, the other endpoint are invalid. I wrote 2KB or more 16 datum into CY7C68013. Then I use the CyConsole.exe to read,I found there are only 2KB bytes in the endpoint2. I don't know why.


         2, In the visual C++ if I read more than 512 bytes one time,then the datum after the 512th bytes are 0(the initial value of memory), that 's why I  only read only 512 bytes one time.




      May the problems are humble, but I can't settle them these days,I need your help. Thank you,everyone. 

        • 1. Re: why the speeds are so slow?

          Are you configuring the FIFO for 1024 bytes for bulk transfer as well??


          Are you queuing Begindataxfer/waitforxfer/finishdataxfer or are you calling them 4 times end to end??


          When you use Queryperformancecounter and stuff you're actually looking at the host application level speed not the bus speed i.e. it will include time taking for the request to reach the host controller driver then the host controller to execute then the time taken for the same path back up.


          CATC would be the best for these kind of measurement or you would have to do a bigger transfer to reduce this host app level overhead.


          If you're reading 0s after 512 bytes you're most probably committing 512 bytes packet onto the FIFO. This would explain the 2KB only being received case as well. FX2LP FIFOs are quantum FIFOs. So if you even write only 1 byte packet into a 1024 byte FIFO buffer then that entire buffer is used up.





          • 2. Re: why the speeds are so slow?
                    1,I just configure FIFO to be 512 bytes in bulk transfer. 2,I do Begindataxfer/waitforxfer/finishdataxfer for inbuf1,then Begindataxfer/waitforxfer/finishdataxfer for inbuf2,then inbuf3, then inbuf4. 3,yes,you are right,the time includes the application calling the driver and the driver calling the hardware,but what should I do to make it faster? it's too slow.this question is most important. 4,yes,I konw your meaning of quantum FIFOs,but the same writting operation to FIFO,if I read 512 bytes four time the datum are right,if I read 2048 bytes one time, the bytes after 512th byte are zeros. this phenomenum happens only in interrupt transfer,the bulk transfer is right. ###After all,thank you!Anand! thank you for discussing this with me.   
            • 3. Re: why the speeds are so slow?

              You should be doing Begindataxfer for inbuf1, inbuf2... till inbuf4 (This way as soon as 1 request completes the next is queued) then waitforxfer for the 4 calls and then finishdataxfer for the 4. This will give you better speed. Your current approach is similar to calling xferdata four times.


              You are declaring your interrupt endpoint size of 1024 bytes. So any packet smaller than that is a short packet and will terminate the transfer. So when you request a transfer of 2048 bytes, sending 512 bytes is terminating the transfer. So only you're seeing this behavior. This is in accordance with USB spec.





              • 4. Re: why the speeds are so slow?
                        thank you, your explanation is clear, so how to avoid the short packet? I wrote 2048 16-bit datum to the FIFO one time,then stop writting, then I launch a 1024-bytes interrupt transfer,but the rear 512 bytes are zeros.however when two 512 bytes interrupt transfer there are no zeros   
                • 5. Re: why the speeds are so slow?

                  Most probably you're still committing 512 byte packets from the firmware. Please check on this.


                  Your firmware is supposed to sending out 1024 byte packets rather than sending short packet (in your case 512 bytes).





                  • 6. Re: why the speeds are so slow?

                     when did the firmware commit the packet do you think?on wrtting datum into fifo,or FX2 reply the host request?I set it in auto mode, and there are no code in TD_POLL.could the firmware do it in ISR?

                    • 7. Re: why the speeds are so slow?

                      In AUTO mode you would have set the AUTOINLEN register values to define the packet size right? It could be this or if you use the PKTEND pin then the master could be committing 512 byte packets by asserting it after sending 512 bytes.





                      • 8. Re: why the speeds are so slow?

                         Yes!Anand,you are exactly right! You are so sharp! \*O*/  \*O*/