Page 1 of 1

Question Regarding Libusb and Interupt in

Posted: Fri Feb 22, 2008 6:17 am
by Rukus
Christian, I have AVRUSB running on my atmega64. I have interupt in and out transfers working using libusb.

I have a couple of questions regarding libusb and AVRUSB.

What would you suggest the proper sequence of events should be to open up interupt transfers to the AVR from the host side using libusb. I've followed your example for powerswitch and made the proper changes to get interupt transfers going. But there is a small problem and I'd like to be sure I'm not buggering anything up first.

What I do to get the transfers happening in (psudo code) as I don't have the app infront of me.

1.) initialize libusb

2.) open the usb device ( this uses the search functions that you used in power switch to locate the PID of my device.

3.) call the setconfiguration and make it config 1

4.) claim the interface

5.) I open a worker thread and have it call interupt in's and interupt outs on a set period (20 ms)

The problem I'm seeing is minor, however noticable. When my host application opens up the USB link, I will frequently notice that I get lower transfer speeds back and forth. I'll close the USB link and re-establish it, and it sometimes corrects the problem. Other times it will take several opens and closes to get things right. After that the link will stay running at the higher speed.

I have done alot of testing to see where the problem is. I've debug stepped through the host program and all of the status feedbacks from the calls to open the link and claim etc. are without errors, but still this problem will show itself about 50% to 75% of the time, then I have to close then re-open, sometimes several times to get the speed back up. It is about a 50% reduction in transfer speed.

The speed appears to be reduced as the interuptread and interuptwrite commands appear to take alot longer when the problem is occuring.

Through much playing around I found that if I do a setconfiguration command 10 or 15 times in a row, prior to claiming the interface the problem will not happen. I'm stumped.

I programmed a LED on the device side to toggle after I've built the messages and done the setinterupt command on the device side.

I tryed a test. I go through the Open sequence on the host( and hammering the setconfiguration), but I don't trigger the worker thread to do the interuptreads and writes till a little later.

What happens when the link connects without this problem, the LED's are not toggleing on the device side. I assume its stuck in the poll routine waiting for something from the host side. The LED starts blinking when I start the worker thread and it begins the interuptin and out transfers.

When I do have this problem, there is blinking on the LED all the time an there is no interruptreads or writes being done from the host program at that time as I havn't started the workerthread yet. Its like windows never relinquishes its polling of the device.

I may have this wrong but I thought when I open the usb, setconfiguration and claim the interface, I'm in direct control of the USB at that point, Windows stops its polling. The only activity should be what my host program is generating?

I think when the problem is occuring, the interuptreads and writes are taking longer because the windows polling is not stopped and I'm also doing interupt read and writes so there is 2 hosts talking to it. Is this possible? I just downloaded a usbsniffer, I'll try to get some captures and post a few iterations of the tranfers.

Sorry for the long post. I can post clips of the program if needed. Any insight would be appreciated.

Posted: Sun Feb 24, 2008 3:19 pm
by Rukus
Well, viewing the sniffer data it seems that my reads where faster because alot of aborts were being sent from the host. I was getting
the Interupt In's about every other transmittion. Thats why it appeared to be working right as I was seeing data, but it was every other transmittion or so.