Re: Handling short transfers

On Fri, 2009-07-31 at 15:34 -0400, Alan Stern wrote:
> Daniel and David:
> 
> This kernel patch implements the plan we discussed for handling short 
> bulk transfers.  It adds a new URB flag: USBDEVFS_URB_XFER_START.  

Alan,

I tried this patch, modified libusb accordingly, and it works!

My test is a particular camera that sends a short packet to indicate
that the host is not keeping up.  I need the remaining URBs in the frame
to be canceled in order to keep in sync with the frame boundaries.

With your patch and the libusb modifications, keeping sync seems to be
completely reliable.  With the old method of doing the URB cancelation
in libusb, I would often lose sync.

Some more thoughts below...

> But for bulk-IN URBs that do have this flag bit set, any fault other
> than an unlink will cause the kernel to immediately cancel all the
> following URBs for the same endpoint and refuse to accept any new ones.  
> This state of affairs will persist until an URB that also has
> USBDEVFS_URB_XFER_START is encountered, at which point the behavior
> reverts to normal.  Such an URB would of course mark the beginning of a 
> new transfer.
> 

For backwards compatibility reasons, I am a little bit concerned about

Re: Handling short transfers

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

_______________________________________________
Libusb-devel mailing list
Libusb-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: Handling short transfers

On Sat, 1 Aug 2009, David Moore wrote:

> On Fri, 2009-07-31 at 15:34 -0400, Alan Stern wrote:
> > Daniel and David:
> > 
> > This kernel patch implements the plan we discussed for handling short 
> > bulk transfers.  It adds a new URB flag: USBDEVFS_URB_XFER_START.  
> 
> Alan,
> 
> I tried this patch, modified libusb accordingly, and it works!

Great!

> My test is a particular camera that sends a short packet to indicate
> that the host is not keeping up.  I need the remaining URBs in the frame
> to be canceled in order to keep in sync with the frame boundaries.
> 
> With your patch and the libusb modifications, keeping sync seems to be
> completely reliable.  With the old method of doing the URB cancelation
> in libusb, I would often lose sync.
> 
> Some more thoughts below...
> 
> > But for bulk-IN URBs that do have this flag bit set, any fault other
> > than an unlink will cause the kernel to immediately cancel all the
> > following URBs for the same endpoint and refuse to accept any new ones.  
> > This state of affairs will persist until an URB that also has
> > USBDEVFS_URB_XFER_START is encountered, at which point the behavior
> > reverts to normal.  Such an URB would of course mark the beginning of a 
> > new transfer.
> > 
> 
> For backwards compatibility reasons, I am a little bit concerned about
> the change in semantics of USBDEVFS_URB_SHORT_NOT_OK.  The old behavior
> would only cancel one URB (the short packet) automatically.  The new
> behavior causes all packets to be canceled.  Won't this cause unexpected
> behavior for apps that previously used USBDEVFS_URB_SHORT_NOT_OK?

I doubt there are any such apps.  USBDEVFS_URB_SHORT_NOT_OK was added 
in April last year, and there isn't any support for it in libusb.

> As a suggestion, maybe the meaning of USBDEVFS_URB_XFER_START could be
> exactly inverted and it could be renamed, perhaps to
> "USBDEVFS_URB_CANCEL_ON_ERROR"?  The behavior would then be to cancel
> any URBs that immediately follow an URB with an error, but only up until
> an URB that has URB_CANCEL_ON_ERROR unset.

Or rather, up until an URB that has URB_SHORT_NOT_OK set and 
URB_CANCEL_ON_ERROR unset.

Daniel, do you have any thoughts?  I can change the code pretty easily.

> Also, what do you suggest as the best way to test at runtime whether a
> particular kernel has this flag available?  With firewire, we have an
> ioctl that gives you a version for the API at run-time to test against.

It's simple: uname(2).  If the release value is >= 2.6.32 (or whenever
this feature gets merged) then the new flag is available, otherwise it
isn't.

> I suppose I could just try to submit an URB with the new flag set and
> see if it fails.

That also works.  

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bidirectional endpoints under libusb 1.0?

Hello,

I am new to this list.

I have been using libusb 0.1 for some of my projects (UUUSB board, SIDI 
interferometer), and now I would like to switch to version 1.0. Upon reading 
the API description, I noticed a potential problem.

On my projects I am using the Cypress "EZ-USB FX-2" chip. One of it's 
endpoints (endpoint 1) is bidirectional. Under libusb 0.1 I could randomly 
read and write to it using usb_bulk_read() and usb_bulk_write().

Now, under libusb 1.0 synchronous mode, there is only a single function, that 
determiners the direction from the descriptors.
How can I switch between reading and writing? Can I simultaneously obtain two 
separate handles for it?
Although I do plan to go asynchronous, I would like to get things working 
under synchronous mode first...

Marko Cebokli

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

Re: Bidirectional endpoints under libusb 1.0?

Marko Cebokli wrote:
> On my projects I am using the Cypress "EZ-USB FX-2" chip. One of
> it's endpoints (endpoint 1) is bidirectional.

A USB endpoint is always unidirectional, but there can be both an
endpoint 1 IN, and an endpoint 1 OUT. They are not the same endpoint
however. You can verify that e.g. using lsusb -v.

> Now, under libusb 1.0 synchronous mode, there is only a single
> function, that determiners the direction from the descriptors.
> How can I switch between reading and writing? Can I simultaneously
> obtain two separate handles for it?

Yep, you need two separate handles, one for each endpoint.

> Although I do plan to go asynchronous, I would like to get things
> working under synchronous mode first...

It should work well.

//Peter

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

Re: Bidirectional endpoints under libusb 1.0?

Peter Stuge wrote:
>> Now, under libusb 1.0 synchronous mode, there is only a single
>> function, that determiners the direction from the descriptors.
>> How can I switch between reading and writing? Can I simultaneously
>> obtain two separate handles for it?
> 
> Yep, you need two separate handles, one for each endpoint.

libusb doesn't deal with endpoint handles, and you only need 1 device 
handle for this. Otherwise yes - libusb will work fine here. Note that 
the API takes endpoint address which encodes the direction (as opposed 
to endpoint number, which does not).

Daniel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

Re: Bidirectional endpoints under libusb 1.0?

Thanks for the lightning fast answers!

On Sunday 02 August 2009 20:02, Daniel Drake wrote:
>Note that
> the API takes endpoint address which encodes the direction (as opposed
> to endpoint number, which does not).
>
> Daniel
>

I guess this is it!
( I was wondering how to specify "1 OUT"  with a simple integer parameter 

Going back to study the API description....

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

libusb as a Host in μC

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

_______________________________________________
Libusb-devel mailing list
Libusb-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: libusb as a Host in μC

Hi,

No. Libusb is only dedicated to host side programming of applications 
that interact with USB devices.

For that you could try to use LUFA which is a framrwork for rapid usb 
devices firmware development based on atmel uCs.

Search for lufa on google. It comes with a lot of examples.

Best regards,

Nuno

Theodore Geladaris escreveu:
> Hi,
>  
> I have an Atmel microcontroller and I also have a usb connector in my 
> PCB.
> I want to connect to the USB connector any USB Memory stick. After 
> that I want the controller to send the data of the EEPROM to the usb 
> stick.
>  
> It means that the microcontroller must work as Host in the USB.
>  
> May I do it using libusb?
>  
> Any suggestions welcome...
>  
> Regards
> Theodore
>
> ------------------------------------------------------------------------
> What can you do with the new Windows Live? Find out 
> <http://www.microsoft.com/windows/windowslive/default.aspx>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> Libusb-devel mailing list
> Libusb-devel <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>   

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

Re: libusb as a Host in μC

On Mon, 3 Aug 2009, Theodore Geladaris wrote:

> Hi,
> 
>  
> 
> I have an Atmel microcontroller and I also have a usb connector in my PCB. 
> 
> I want to connect to the USB connector any USB Memory stick. After that I want the controller to send the data
of the EEPROM to the usb stick.
> 
>  
> 
> It means that the microcontroller must work as Host in the USB.
> 
>  
> 
> May I do it using libusb?

No.

> Any suggestions welcome...

Don't even try to use libusb.  Just mount the memory stick like any 
other filesystem and use normal file I/O to make the copy.

Alan Stern

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july