Hi Matthias, Thank you very much for your reply and sorry for my delayed answer.
So once again to sum up, I have the following scheme: (a) On EP1 I have short periodic status transfers from device to host, e.g. every 250 ms. These can be "bulk in" or "interrupt in" type. (b) I have large data transfers from device to host - let's call them data streaming. To trigger that I first do a "bulk out" transfer on EP2 and then start fetching the streamed data through a large "bulk in" transfer on EP3. > So you're calling "handle events" based on your assumption about when > to call it here? For (a): For the short periodic bulk in (or interrupt in) transfers my idea was the following: 1. Submit this periodic transfer 2. Call handle_events() in non-blocking style after some time, i.e. when I expect the transfer to be fulfilled by the USB device. E.g. every 250 ms. This will then fetch the result of the transfer and I handle it in the callback. 3. Immediately submit the next periodic transfer. 4. After another 250 ms I call again handle_events(). And so on... This seems to work ok so far. > Are you doing the same for the "handle events" calling here as in the > first case? For (b): For starting my data streaming and than fetching the streamed data I would do the following: 1. Submit "bulk out" transfer (e.g. let's call it "start streaming") 2. Call handle_events() in blocking style in a loop that just waits for this transfer to complete. 3. Submit "bulk in" transfer that fetches a larger amount of data from the USB device. 4. Again, call handle_events() in blocking style in a loop that just waits for this transfer to complete. This data streaming also works ok, as long as I don't mix it with the periodic status transfers described in (a). Now my idea was that using the asynch libusbx interface I could mix the periodic status in transfers (a) with my data streaming (b). So let's say I submit a periodic transfer (a) and then I start data streaming (b). As described in (b) the data streaming calls handle_events() in a loop so the previously submitted periodic transfer should also call back as soon as it completes. FYI: I identify which transfer has finished in the callback. But for some reason the periodic transfer never calls back as soon as I send the bulk out transfer that starts my data streaming. Somehow this previously submitted bulk in periodic transfer gets lost. It also does not complete after data streaming has finished. It seems to simply disappear. From the libusbx docs I don't understand why this happens. > Maybe your assumption about when to call it don't work out anymore > when your combine the two? I have a libusb based application that > keeps 5 bulk IN transfers submitted on a single endpoint to read data > and I use bulk OUT transfers to send commands to the device. I'm using > the poll based approach for event handling with libusb. So libusb is > basically telling my when to call "handle events" instead of me > guessing when to call it. This works without any problems. I understand but I did not want to go very low level, so that the application stays portable. Also, it looks like my problems appear when I start calling handle events more often in a loop, not when I call it infrequently. So I don't think this is the problem. > Maybe you need to do something similar for event handling and remove > the assumptions about when to call "handle events". You can also just > use a dedicated thread to constantly call "handle events" to get rid > of the guessing. I didn't use an extra thread because I already had a > poll based event loop in my application. I don't want to use an extra thread as I am already using multiple Qt Threads for other things, so I prefer to keep libusb stuff in one thread. To sum up: It looks like the problem is that if I submit a transfer and then submit another one (even on a different endpoint) the first transfer does not complete for some reason... Any hints or ideas are welcome. Regards, Anguel ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
