hi all, i am doing some time-critical data transfer on EZ-USB FX2LP(cy68013a)

I use the isochronous mode, maxPacketSize = 1024, 1 transaction per uframe( 1/8 ms);

now i want to transfer data every ms,  so i should set the xfer size = 8KB

that is the outlen = 8*1024.

If it works as i think, i should get the 8KB data in 1ms, but it  costs about 5ms to do that.

and if i setup to get  1024KB data in 128ms, it costs about 132 ms.

Since what i am doing is time-critical, i have to find out the reason. Have you guys any idea about it?

 Here is the code:

    QueryPerformanceCounter(&lPerformanceCount_Start);
    UCHAR  *inContext = dlg->USBDevice->IsocInEndPt->BeginDataXfer(inData,inlen,&inOvLap);
  if(!dlg->USBDevice->IsocInEndPt->WaitForXfer(&inOvLap,150))
  {
     
    AfxMessageBox("Time out!");
    dlg->USBDevice->IsocInEndPt->Abort();
    WaitForSingleObject(inOvLap.hEvent,INFINITE);
}
   
    success = dlg->USBDevice->IsocInEndPt->FinishDataXfer(inData, inlen, &inOvLap,inContext,
                  isoPktInfos);
    
    QueryPerformanceCounter(&lPerformanceCount_End);

Hi,

Most probably you're looking at the system time rather than the actual bus time (timing in terms of the USB bus). In both cases the difference is 4ms??

Queue up the transfers i.e. calls a bunch of begindataxfer then corresponding number of waitforxfer and finishdataxfer and check the timing. The main purpose of begindataxfer, waitforxfer, finishdataxfer i.e. asynchronous approach is more bandwidth utilization by queueing up the requests.

Cheers,

Anand

thank you very much~ I have done some more work on it in these days. But I am still not sure the certain problem.

First, I download the software whicn can capture the data on the USB databus, so I can know more detail. 

And I find the redundent 4ms is cause by the URB to RESET PIPE.

If there is no data in the stream, every time I call  the function "BeginDataXfer",it will RESET PIPE. Queue up the transfers  will make the data pending. Pending data will not be cancelled by the RESET operation(See in the CyAPI.h.pdf). So I do as aasi said. It really helps and solve the problem if I only  want to do IN transaction. 

However, what I want to do is  4 IN transaction and 1 OUT transaction in 5ms. ( 4*8KB IN and 1*8KB OUT)  Now I find every time I switch from IN transaction to OUT transaction, RESET PIPE is not avoidable. It seems that I cannot find solve unless I have the source code of the driver,and choose whether or not to RESET PIPE every time begindataxfer.

So what should I do now??

It seems that the souce code of cyusb.lib is unavailable, should contact the Cypress Corp. and get some help?

p.s. I am not sure whether the RESET PIPE operation is wrapped in the high level Cyapi.lib or the low level cyusb.sys. 

1.  RESET PIPE is wrapped in function BeginDataXfer()???

or 2. RESET PIPE is wrapped in the cyusb.sys that when I call BeginDataXfer(), the cyusb.sys would reset the pipe.

I hope I have make my question understood...

RESET_PIPE was mandatory for isochronous endpoints in older driver model.

I've worked with CATC capture of devices that use CyUSB.sys and CyAPI.lib. Don't remember seeing a RESET_PIPE in any of them. What are the endpoint type of the 2 endpoints you are working with?

I have configurated the EP2IN  as  1024 x 2;  EP6OUT as 1024 x 2;

Is there any problem? I have no idea for it.

Now I have change my code in PC and the firmware. I make it worked under the Bulk mode.

The good news is that there is no RESET PIPE operation while the bad news is that I cannot control the time cost in the data xfer...

If you are ok with the bandwidth that isochronous endpoint has to offer then why not try interrupt endpoint? It would give you the guaranteed latency and you shouldn't see RESET_PIPE as well.

Regards,

Anand