Re: [Libusb-devel] Synchronous Interrupt support

[David G. <da...@cs...>]

This works for the write but when it gets to the subsequent read I get 
Alarm Clock printed out. I have tried to put sleeps in my application 
but that makes Alarm Clock message appear earlier.

Johannes Erdfelt wrote:

>Ahh, that may be the problem.
>
>Not all of the HCDs support multi-packet Interrupt transfers. This is
>the code in usb-uhci.c that's tripping it up:
>
>        // INT allows only one packet
>        if (urb->transfer_buffer_length > usb_maxpacket (urb->dev, pipe, usb_pipeout (pipe)))
>                return -EINVAL;
>
>I can workaround this in libusb.
>
>For now, can you try one write of 8 bytes and then one write of 3 bytes
>instead of one write of 11 bytes and see if that works?
>
>JE
>
>On Tue, Mar 18, 2003, David Glance <da...@cs...> wrote:
>  
>
>>That prompted me to look further - I think it has to do with the size, 
>>the wMaxPacketSize is 8 and I am passing 7 in the first instance and 11 
>>in the second - When I change the second write to 7 it works and fails 
>>later - am I write then in thinking that it won't accept anything 
>>greater than 8 in this case?
>>
>>Johannes Erdfelt wrote:
>>
>>    
>>
>>>That's good news, but I can't figure out why you would get that error on
>>>the second call.
>>>
>>>Are you using the same buffer, size and endpoint?
>>>
>>>JE
>>>
>>>On Mon, Mar 17, 2003, David Glance <da...@cs...> wrote:
>>> 
>>>
>>>      
>>>
>>>>Getting better. I can now write and then read. However, on the second 
>>>>write I get this error again:
>>>>
>>>>USB error: error submitting interrupt URB: Invalid argument
>>>>
>>>>david
>>>>
>>>>Johannes Erdfelt wrote:
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>No, all of the HCDs should work fine. I was just curious which one you
>>>>>were using since sometimes the return codes in corner cases will differ.
>>>>>
>>>>>A timeout of 1000 (1 second) sounds fine.
>>>>>
>>>>>Let me know how it goes when you test again.
>>>>>
>>>>>JE
>>>>>
>>>>>On Mon, Mar 17, 2003, David Glance <da...@cs...> wrote:
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>it is usb-uhci - I can try ohci if you think it would be different. The 
>>>>>>timeout is set to 1000 - I will check this out again tonight and let you 
>>>>>>know how I get on.
>>>>>>
>>>>>>Johannes Erdfelt wrote:
>>>>>>
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>-103 (on x86 atleast) is -ECONNABORTED. That looks like it's a timeout
>>>>>>>condition. Are you using usb-uhci?
>>>>>>>
>>>>>>>I've checked in some changes that should handle the timeout case better.
>>>>>>>
>>>>>>>However, you're writing which would mean in this case the device kept on
>>>>>>>NAKing, assuming the code in libusb is correct. That's kinda rare, so I
>>>>>>>don't think that would happen. What is LINUX_USB_TIMEOUT set to?
>>>>>>>
>>>>>>>Unfortunately, I don't have easy access to any devices that use
>>>>>>>interrupt endpoints, so I'm testing this with a duplicate of this
>>>>>>>function but using control transfers.
>>>>>>>
>>>>>>>JE
>>>>>>>
>>>>>>>On Mon, Mar 17, 2003, David Glance <da...@cs...> wrote:
>>>>>>>
>>>>>>>
>>>>>>>    
>>>>>>>
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>-------------------------------------------------------
>>>>This SF.net email is sponsored by:Crypto Challenge is now open! 
>>>>Get cracking and register here for some mind boggling fun and 
>>>>the chance of winning an Apple iPod:
>>>>http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
>>>>_______________________________________________
>>>>Libusb-devel mailing list
>>>>Lib...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/libusb-devel
>>>>   
>>>>
>>>>        
>>>>
>>> 
>>>
>>>      
>>>
>
>
>  
>