Re: [Libusbx-devel] Problem with transfers in parallel
Hi all! It looks like that the problem was caused by that specific embedded Linux I was using. On other Linux and Windows OS everything seems to work fine. Many thanks to Matthias Bolte for his help and advice. 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=84349831iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Problem with transfers in parallel
Hi Matthias, Thank you for the reply. Am 23.12.2013 12:15, schrieb Matthias Bolte: 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. I tried that with the latest releases of both libusb 1.0.9 and libusbx 1.0.17. The same problem appeared. 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. My device is a Cypress PSoC 5 LP. Of course it is always possible that some bug is present in their API (or in my code), although I try to keep it as simple as possible for testing. I just check if the endpoint buffer is ready to accept new data and fill it if this is the case. 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? Originally, the problem occurred on my Beaglebone Black with Angstrom Embedded Linux (Kernel 3.8). Now I tested the code on my Win XP machine and the code seems to work as expected there, at least most of the time. But from time to time after a large bulk in transfer the periodic transfer again stop to occur. Very strange, now I have it running for many minutes without any problems... What I don't do is delete and reallocate the transfers before resubmitting them. I only configure the transfer struct to point to a new buffer where required. Could this be a problem? According to the docs, when using the asynch interface it is a benefit to reuse transfers like I do. 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. Thanks for the hint. I will investigate this further. Best 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=84349831iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Problem with transfers in parallel
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
Re: [Libusbx-devel] Problem with transfers in parallel
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=84349831iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
[Libusbx-devel] Problem with transfers in parallel
Hi! I have also posted my question in the libusb list but got no reply so far, so I try my luck here. I hope that there are more experts reading here. My question is whether submitting multiple transfers in parallel and handling the results (by checking in the callback function which of the transfers actually called back during handle events) is possible in libusbx? In particular, I am trying to mix multiple transfers using the asynch interface like this: 1. On EP1 I have a periodic bulk IN transfer which I submit and after 1 s I call handle events to fetch its results. Then I resubmit this transfer and so on. This works fine so far. 2. I submit a bulk OUT transfer on EP2 to tell my USB device to start sending some larger amount of data to the host. This data is then fetched by another bulk IN transfer on EP3. This also work fine when used without the periodic transfer described in 1. The problem: Unfortunately, if the periodic transfer described in 1. is running, as soon as I submit a bulk OUT on EP2 as described in 2., this pending periodic bulk IN on EP1 never calls back. It seems to disappear somehow. Is this expected? FYI: All transfers have a timeout of 0 and I am handling all transfers in a single callback function and identify there which transfer actually called back. Thanks in advance for any hints. 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=84349831iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Problem with transfers in parallel
2013/12/20 Anguel Stankov ang...@gmx.net: Hi! I have also posted my question in the libusb list but got no reply so far, so I try my luck here. I hope that there are more experts reading here. My question is whether submitting multiple transfers in parallel and handling the results (by checking in the callback function which of the transfers actually called back during handle events) is possible in libusbx? In particular, I am trying to mix multiple transfers using the asynch interface like this: 1. On EP1 I have a periodic bulk IN transfer which I submit and after 1 s I call handle events to fetch its results. Then I resubmit this transfer and so on. This works fine so far. So you're calling handle events based on your assumption about when to call it here? 2. I submit a bulk OUT transfer on EP2 to tell my USB device to start sending some larger amount of data to the host. This data is then fetched by another bulk IN transfer on EP3. This also work fine when used without the periodic transfer described in 1. The problem: Unfortunately, if the periodic transfer described in 1. is running, as soon as I submit a bulk OUT on EP2 as described in 2., this pending periodic bulk IN on EP1 never calls back. It seems to disappear somehow. Is this expected? Are you doing the same for the handle events calling here as in the first case? 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. 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. -- 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=84349831iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
