2013/12/22 Anguel Stankov <ang...@gmx.net>: > 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.
There are no guarantees on the minimum latency of a bulk transfers. So your call to handle_events() might be too early. But then the next call to handle_events() should handle it, assuming it arrived in the meantime. This means your transfer handling could be delayed, but it should not get lost. >> 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. Okay, I assume you do this and (a) on the same libusbx context. Then calling handle_events() for this transfers should/can also handle the transfers in (a). That's okay. > 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). Yes, that should work. I don't see any reason why it shouldn't. > 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. I think there could be two reasons for this problem: 1) There is a bug in libusbx, your specific usage pattern triggers it and in the end your transfer is lost. Are you using the latest release/git version? If not you should update to check if the problem got fixed in the meantime. 2) There is a bug in your USB device. Once you start streaming data in (b) your device doesn't send periodic status transfers (a) anymore. A third reason could be a problem in the OS USB stack, but I think that's very unlikely. On which OS did you test this? Does it happen on different OSs, or is it specific to one OS? To debug this further you could look at the USB traffic using Wireshark (or other USB monitoring tools) to see where the periodic status transfer is lost. If you can see it in Wireshark, but not in your application then it is lost in libusbx. If you don't see it in Wireshark then your device might not be sending it at all. >> 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. Okay, I think your libusb event handling should work as it is. This wasn't clear to me from your initial description. -- Matthias Bolte http://photron.blogspot.com ------------------------------------------------------------------------------ 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
