Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
I am writing software that deals with a device that's under development. The device collects data for a period of time, which is programmable, and sends the result as a block of 64k bytes to the PC via FX3. I receive the block through a CCyUSBDevice's BulkInEndPt by calling XferData(). I am finding that if I choose a timeout value short enough for the function to fail (because the data is yet to arrive) that it sometimes never succeeds on subsequent calls. Effectively, the data is lost. If I sit in a loop calling XferData(), the probability of losing the data increases as the timeout value I choose gets shorter. If I don't call it until after the data should have arrived, it never fails. Is this known behaviour of XferData(), or is the problem likely to be in the device? If it's the device, can anyone suggest a likely cause? (I am not a hardware person, but I can pass on responses to the device's designer.)
Largely, yes. Streamer succeeds more often than my code, but it still loses data. I set "Packets to Xer" to 128 (x 512 = 64k) and "Xfers to Queue" to 1, then started it. Then I got the device to send a buffer of data 30 times, one buffer per mouse click. With the timeout at 100, Streamer got all 30. With a timeout of 10 it got 25, and with a timeout of 1 it got 5 (then 8 then 10 in repetitions).
The programmer's reference says that XferData() calls Abort() internally "if operation fail". If by "fail" it means times out, then could that be the problem? I'm new to this and don't know exactly what Abort() does, but I'm wondering if data would be lost if it arrives during the small window between the timeout expiring and the Abort() call.
Since I posted I tried receiving the data with the set of BeginDataXfer(), WaitForXfer() and FinishDataXfer() instead of XferData(). If WaitForXfer() times out I just call it again. It seems to be working. In early testing it has lost no data even with a timeout of 1. However, I'm not sure if it's right to keep it that simple (meaning, could I be leaving something in a bad state?). Sample code I've seen using those functions also calls Abort() if WaitForXfer() times out and does other things such as check for ERROR_IO_PENDING and the endpoint statuses. The sample code also loses data if I use it as is, which also seems to point the finger at Abort().