usb_interrupt_* in 0.1.8 ?

I found the usb_pickit on the web where it points out that:

  no longer support low speed bulk mode transfers-- they give
  "invalid argument", errno=-22, on any attempt to do a low speed
  bulk write.

I'm running libusb 0.1.8 and Kernel 2.6 and I'm wondering if the
usb_interrupt routine are working in the general release or do I
need to pull down the CVS release?

Also I really don't know what I'm doing with USB but I'm learning
any good tutorials to figure out how to communicate with usb
devices that we really don't have the protocols to?

Thanks

--

-- 
Linux Home Automation         Neil Cherry       ncherry <at> comcast.net
http://home.comcast.net/~ncherry/               (Text only)
http://hcs.sourceforge.net/                     (HCS II)
http://linuxha.blogspot.com/                    My HA Blog

-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

usb_bulk/interrupt timeouts ?

OK. I found that 2.6 needs the usb_interrupt routine and that it
is in libusb 0.1.8. Now I'm trying to use the routines with the
timeouts set to 10ms and it never times out. Do they work for
anyone else?

--

-- 
Linux Home Automation         Neil Cherry       ncherry <at> comcast.net
http://home.comcast.net/~ncherry/               (Text only)
http://hcs.sourceforge.net/                     (HCS II)
http://linuxha.blogspot.com/                    My HA Blog

-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: usb_bulk/interrupt timeouts ?

On Fri, Nov 05, 2004, Neil Cherry <ncherry <at> comcast.net> wrote:
> OK. I found that 2.6 needs the usb_interrupt routine and that it
> is in libusb 0.1.8. Now I'm trying to use the routines with the
> timeouts set to 10ms and it never times out. Do they work for
> anyone else?

It should work, but I haven't tested it much myself. Can you give us a
snippet of your code?

Can you try the CVS version of libusb? The code has changed a bit.

BTW - Do you live in East Windsor? I grew up there.

JE

-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: usb_bulk/interrupt timeouts ?

Johannes Erdfelt wrote:
> On Fri, Nov 05, 2004, Neil Cherry <ncherry <at> comcast.net> wrote:

Well dang, the thing now works! Thanks.

--

-- 
Linux Home Automation         Neil Cherry       ncherry <at> comcast.net
http://home.comcast.net/~ncherry/               (Text only)
http://hcs.sourceforge.net/                     (HCS II)
http://linuxha.blogspot.com/                    My HA Blog

-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

usb_release_interface() + usb_close() -> broke communication

Re: usb_release_interface() + usb_close() -> broke communication

On Mon, Nov 08, 2004, Martin Vaillancourt <mvaillancourt <at> memoryexpertsinc.com> wrote:
> I'm using the LibUsb0.1.8 since many months to test USB Mass Storage
> Device. It works fine on our ClipDrive and ClipDrive Bio products. (For
> Ref Only. http://www.memoryexpertsinc.com/en/clipdrive.php);
>  
> Today, I try another Mass Storage Device. This one has a Texa Instrument
> controller and a HDD of 40GB.
>  
> The problem is this one:
>  
> -I do this:
> *	usb_open(dev) + usb_claim_interface(). 
> *	Send CBW Commands (Ex. Test Unit Ready (00h), Write (2Ah), Read
> (28h), Read Capacity (25h), etc)
> *	This works fine, until that I release the interface and close
> the handle?
> Now, even if re-open and re-claim the interface return me successful
> message, I cannot send CBW commands anymore?
>  
> Does anyone has seen /solved this problem. I think that a usb_reset()
> could be a "patch", but I will prefer to fix the real problem.

What platform and kernel version are you using?

Atleast under Linux, I don't think that usb_release_interface() and
usb_close() will send any data to the device or reset any internal
state.

It would be interesting if you could release the interface and then
reclaim it without closing the device to see if the failure still
exists. That would allow us to determine if it's the release or the
close that is causing the problem.

JE

-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

RE: usb_release_interface() + usb_close() -> broke communication

Hello,
My 2 previous email seems too large!
Now, I know exactly the cause of the problem, so I do a resume...

The Bulk Transaction with some data must toggle between the DATA PID
DATA0 and DATA1. (Ref USB Specification 1.1 or 2.0)

So, when I Release the interface, do a usb_close, do a usb_open and
re-claim the interface, the software resend by default the usb bulk
command with the DATA0 even if the device is expecting it on the DATA1?

Question: Is there a flag somewhere in LibUSB that keep tracking of the
DATA PID to used? 

Thank's
Martin

-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: usb_release_interface() + usb_close() -> broke communication

On Tue, Nov 09, 2004, Martin Vaillancourt <mvaillancourt <at> memoryexpertsinc.com> wrote:
> My 2 previous email seems too large!
> Now, I know exactly the cause of the problem, so I do a resume...
> 
> The Bulk Transaction with some data must toggle between the DATA PID
> DATA0 and DATA1. (Ref USB Specification 1.1 or 2.0)
> 
> So, when I Release the interface, do a usb_close, do a usb_open and
> re-claim the interface, the software resend by default the usb bulk
> command with the DATA0 even if the device is expecting it on the DATA1?
> 
> Question: Is there a flag somewhere in LibUSB that keep tracking of the
> DATA PID to used? 

libusb doesn't track anything to do with the data toggle. That is
handled by the kernel in all cases.

However, the SET_INTERFACE command is a control transaction that occurs
on the default control pipe. Data toggles rules are fixed for control
transfers, not to mention that the data toggle is per pipe.

I don't see how the SET_INTERFACE could interfere, unless the device
reset the data toggle when that occurs. I'll have to check the USB spec
to see what behavior the spec defines in this case.

JE

-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

RE: usb_release_interface() + usb_close() -> broke communication

Hi,

I do not believe that it is the SET_INTERFACE command send from the
ReleaseInterface() that causes the problem.

I think that it is the fact that the first DATA PID used after an
usb_open() and ClaimInterface() is the DATA0! So if we send only
1xusb_bulk command to a device, Release&Close() without reset the device
(Hardreset or softreset), next usb_bulk command after the usb_open() and
ClaimInterface() will use again the DATA0 even if the device expects the
DATA1. This is what I see with CATC.

My solution, except if you have a better one to suggest, will be to keep
tracking of the number of usb_bulk command send on each endpoint in my
application. So before to ReleaseAndClose() the device,  I will send a
dummy usb_bulk command on DATA1 if required? This will set the device to
expect the next usb_bulk command on DATA0.

	What do you think?
	Do you know a Linux Kernel 2.6.x without this problem?

Thank you again!
Martin

-----Original Message-----
From: Johannes Erdfelt [mailto:johannes <at> erdfelt.com] 
Sent: Tuesday, November 09, 2004 13:07
To: Martin Vaillancourt
Cc: libusb-devel <at> lists.sourceforge.net
Subject: Re: [Libusb-devel] usb_release_interface() + usb_close() ->
broke communication

On Tue, Nov 09, 2004, Martin Vaillancourt
<mvaillancourt <at> memoryexpertsinc.com> wrote:
> My 2 previous email seems too large!
> Now, I know exactly the cause of the problem, so I do a resume...
> 
> The Bulk Transaction with some data must toggle between the DATA PID
> DATA0 and DATA1. (Ref USB Specification 1.1 or 2.0)
> 
> So, when I Release the interface, do a usb_close, do a usb_open and
> re-claim the interface, the software resend by default the usb bulk
> command with the DATA0 even if the device is expecting it on the
DATA1?
> 
> Question: Is there a flag somewhere in LibUSB that keep tracking of
the
> DATA PID to used? 

libusb doesn't track anything to do with the data toggle. That is
handled by the kernel in all cases.

However, the SET_INTERFACE command is a control transaction that occurs
on the default control pipe. Data toggles rules are fixed for control
transfers, not to mention that the data toggle is per pipe.

I don't see how the SET_INTERFACE could interfere, unless the device
reset the data toggle when that occurs. I'll have to check the USB spec
to see what behavior the spec defines in this case.

JE

-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

RE: usb_release_interface() + usb_close() -> broke communication

"Martin Vaillancourt" <mvaillancourt <at> memoryexpertsinc.com> schrieb am 09.11.04 19:24:28:
> 
> Hi,
> 
> I do not believe that it is the SET_INTERFACE command send from the
> ReleaseInterface() that causes the problem.
> 
> I think that it is the fact that the first DATA PID used after an
> usb_open() and ClaimInterface() is the DATA0! So if we send only
> 1xusb_bulk command to a device, Release&Close() without reset the device
> (Hardreset or softreset), next usb_bulk command after the usb_open() and
> ClaimInterface() will use again the DATA0 even if the device expects the
> DATA1. This is what I see with CATC.
> 
> My solution, except if you have a better one to suggest, will be to keep
> tracking of the number of usb_bulk command send on each endpoint in my
> application. So before to ReleaseAndClose() the device,  I will send a
> dummy usb_bulk command on DATA1 if required? This will set the device to
> expect the next usb_bulk command on DATA0.
> 
> 	What do you think?

I think that the behavior of the host is correct.

From the specs v2.0, section 9.1.1.5:

"Before a USB device’s function may be used, the device must be configured. 
From the device’s perspective, configuration involves correctly processing a 
SetConfiguration() request with a non-zero configuration value. Configuring 
a device or changing an alternate setting causes all of the status and configuration 
values associated with endpoints in the affected interfaces to be set to their default values.
This includes setting the data toggle of any endpoint using data toggles to the value DATA0." 

That means that the device has to reset the data toggle bit(s) whenever it
receives a valid SET_INTERFACE or SET_CONFIGURATION request. So it seems
as if your device firmware has a problem.

Stephan

> 	Do you know a Linux Kernel 2.6.x without this problem?
> 
> Thank you again!
> Martin
> 
> -----Original Message-----
> From: Johannes Erdfelt [mailto:johannes <at> erdfelt.com] 
> Sent: Tuesday, November 09, 2004 13:07
> To: Martin Vaillancourt
> Cc: libusb-devel <at> lists.sourceforge.net
> Subject: Re: [Libusb-devel] usb_release_interface() + usb_close() ->
> broke communication
> 
> On Tue, Nov 09, 2004, Martin Vaillancourt
> <mvaillancourt <at> memoryexpertsinc.com> wrote:
> > My 2 previous email seems too large!
> > Now, I know exactly the cause of the problem, so I do a resume...
> > 
> > The Bulk Transaction with some data must toggle between the DATA PID
> > DATA0 and DATA1. (Ref USB Specification 1.1 or 2.0)
> > 
> > So, when I Release the interface, do a usb_close, do a usb_open and
> > re-claim the interface, the software resend by default the usb bulk
> > command with the DATA0 even if the device is expecting it on the
> DATA1?
> > 
> > Question: Is there a flag somewhere in LibUSB that keep tracking of
> the
> > DATA PID to used? 
> 
> libusb doesn't track anything to do with the data toggle. That is
> handled by the kernel in all cases.
> 
> However, the SET_INTERFACE command is a control transaction that occurs
> on the default control pipe. Data toggles rules are fixed for control
> transfers, not to mention that the data toggle is per pipe.
> 
> I don't see how the SET_INTERFACE could interfere, unless the device
> reset the data toggle when that occurs. I'll have to check the USB spec
> to see what behavior the spec defines in this case.
> 
> JE
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Libusb-devel mailing list
> Libusb-devel <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libusb-devel

________________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193

-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_idU88&alloc_id065&op=click