headers
Alan Stern | 1 Sep 2010 19:45
Picon
Favicon

Re: libusb_bulk_transfer

On Mon, 30 Aug 2010, cruiser wrote:

> 
> Aditionally,
> I findd out a documnet in this site.
> So, I try to add libusb_claim_interface(handle, 0); and
> libusb_set_interface_alt_setting(handle, 0, 0);
> But the result is the same with previous situation.
> And I can see next log...
> ERRO Aug 31 15:14:05 T538380256 libusb_claim_interface fail -6
> ERRO Aug 31 15:14:05 T538380256 libusb_set_interface_alt_setting fail -5
> 
> So, I try to detach Bluez Deamon. I confirmed the down to use "hcitool
> scan".
> But the result is the same.
> 
> what I have to do next? hum... hum...

You need to detach the Bluetooth driver, not the Bluez daemon.  Use 
libusb_detach_kernel_driver().

Alan Stern

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
(Continue reading)

Permalink | Reply | 0 comments |
headers
libusb Trac | 2 Sep 2010 11:04
Favicon

Re: [libusb] #23: libusb_get_device_list OS X

#23: libusb_get_device_list OS X
-----------------------------+----------------------------------------------
 Reporter:  auser01          |        Owner:  hjelmn
     Type:  defect           |       Status:  closed
Component:  libusb-1.0       |   Resolution:  fixed 
 Keywords:  get_device_list  |       Blocks:        
Blocked By:                   |  
-----------------------------+----------------------------------------------

Comment (by susancai):

 Awesome！Thank you for sharing the tips! They are very useful. <a
 href="http://www.jihoy.com">cheap advertising</a> |<a
 href="http://www.jihoy.com/classifieds/Employment/5">jobs</a>|<a
 href="http://www.astrabeds.com/mattresses.html">mattresses</a>

--

-- 
Ticket URL: <http://libusb.org/ticket/23#comment:6>
libusb <http://libusb.org/>
C library for writing portable USB drivers in userspace
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Libusb-devel mailing list
Libusb-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tim Roberts | 2 Sep 2010 18:25

Re: [libusb] #23: libusb_get_device_list OS X

 libusb Trac wrote:
> #23: libusb_get_device_list OS X
> -----------------------------+----------------------------------------------
>  Reporter:  auser01          |        Owner:  hjelmn
>      Type:  defect           |       Status:  closed
> Component:  libusb-1.0       |   Resolution:  fixed 
>  Keywords:  get_device_list  |       Blocks:        
> Blocked By:                   |  
> -----------------------------+----------------------------------------------
>
> Comment (by susancai):
>
>  Awesome！Thank you for sharing the tips! They are very useful. <a
>  href="http://www.jihoy.com">cheap advertising</a> |<a
>  href="http://www.jihoy.com/classifieds/Employment/5">jobs</a>|<a
>  href="http://www.astrabeds.com/mattresses.html">mattresses</a>

The psychology of this dreck fascinates me.  Is there really any human
being in the world who has bought a mattress by clicking a link in a
forum spam message?

--

-- 
Tim Roberts, timr <at> probo.com
Providenza & Boekelheide, Inc.

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
(Continue reading)

Permalink | Reply | 0 comments |
headers
libusb Trac | 3 Sep 2010 04:05
Favicon

Re: [libusb] #27: Libusb 1.0.6 Big Endian issue

#27: Libusb 1.0.6 Big Endian issue
------------------------+---------------------------------------------------
 Reporter:  mig_143     |        Owner:        
     Type:  defect      |       Status:  closed
Component:  libusb-1.0  |   Resolution:  fixed 
 Keywords:  Big Endian  |       Blocks:        
Blocked By:              |  
------------------------+---------------------------------------------------

Comment (by susancai):

 It's nice to share that. I think you can try it again to see the details.
 http://www.astrabeds.com/mattresses.html

--

-- 
Ticket URL: <http://libusb.org/ticket/27#comment:13>
libusb <http://libusb.org/>
C library for writing portable USB drivers in userspace
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
Permalink | Reply | 0 comments |
headers
libusb Trac | 3 Sep 2010 04:07
Favicon

Re: [libusb] #30: [PATCH] Darwin big endian issue

#30: [PATCH] Darwin big endian issue
------------------------+---------------------------------------------------
 Reporter:  mk          |        Owner:  hjelmn
     Type:  defect      |       Status:  closed
Component:  libusb-1.0  |   Resolution:  fixed 
 Keywords:              |       Blocks:        
Blocked By:              |  
------------------------+---------------------------------------------------

Comment (by susancai):

 It's nice to read that. I want to have a try see what's up.
 http://www.astrabeds.com/mattresses.html

--

-- 
Ticket URL: <http://libusb.org/ticket/30#comment:3>
libusb <http://libusb.org/>
C library for writing portable USB drivers in userspace
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
Permalink | Reply | 0 comments |
headers
libusb Trac | 3 Sep 2010 04:09
Favicon

Re: [libusb] #33: Mac OS X libusb 1.0 native HID backend

#33: Mac OS X libusb 1.0 native HID backend
-----------------------------------+----------------------------------------
 Reporter:  xiaofan                |        Owner:     
     Type:  enhancement            |       Status:  new
Component:  libusb-1.0             |   Resolution:     
 Keywords:  Mac OS X, libusb, HID  |       Blocks:     
Blocked By:                         |  
-----------------------------------+----------------------------------------

Comment (by susancai):

 That's really a good idea. I know it's very useful.
 http://www.astrabeds.com/mattresses.html

--

-- 
Ticket URL: <http://libusb.org/ticket/33#comment:4>
libusb <http://libusb.org/>
C library for writing portable USB drivers in userspace
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
Permalink | Reply | 5 comments |
headers
Graeme Gill | 3 Sep 2010 08:38

Re: [libusb] #33: Mac OS X libusb 1.0 native HID backend

Enough is enough - can someone with admin capability delete
this joker from your bugtracker, and block them from creating
a login again please.

Graeme Gill.

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
Permalink | Reply | 4 comments |
headers
bch36 | 3 Sep 2010 19:59
Picon

libusb_bulk_transfer and overflow errors


First off, thanks for the great library!  It's been very useful so far.

Talking over USB to a device, I've been getting a lot of overflow errors. 
Per the page on handling overflow errors, I've set the buffer size of
libusb_bulk_transfer to various multiples of the endpoint max packet size.

wMaxPacketSize     0x0040  1x 64 bytes

The sizes I've tried are 64 bytes, 960 bytes, and even 64000 bytes. 
Regardless of the buffer size, I quickly (after a few seconds) get a -8
error, LIBUSB_ERROR_OVERFLOW.  

My code:

//handle, bEndpointAddressIn, and actualLength are all defined earlier
unsigned char buffer[64];
int error = libusb_bulk_transfer(handle, bEndpointAddressIn, (unsigned
char*)buffer, 64, &actualLength, 0);

The page on overflow errors seemed to suggest that it was impossible to get
an overflow error if the buffer size was a multiple of the endpoint's max
packet size, but apparently that's not true.  Am I missing something?

Relatedly, is it better to have a small multiple, or a large multiple of the
packet size as the buffer size?  When I was setting the buffer size to 64000
bytes, it appeared that libusb_bulk_transfer was filling the entire buffer
before returning.  I.e., the actualLength value would be the 64000.

Any help would be greatly appreciated!
(Continue reading)

Permalink | Reply | 11 comments |
headers
Peter Stuge | 3 Sep 2010 20:47
Picon

Re: libusb_bulk_transfer and overflow errors

bch36 wrote:
> Relatedly, is it better to have a small multiple, or a large
> multiple of the packet size as the buffer size?

You should use the buffer size that suits the communication with the
device.

> ======= FWIW =======
> Bus 007 Device 063: ID 0403:e729 Future Technology Devices International, Ltd 

I really don't think their products are very good solutions for
adding USB support to a project. I would strongly suggest using a
general USB hardware instead, which allows using *all* features that
USB has to offer.

For FTDI though maybe you could benefit from using libftdi instead.

//Peter

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
Permalink | Reply | 10 comments |
headers
bch36 | 3 Sep 2010 21:23
Picon

Re: libusb_bulk_transfer and overflow errors


Peter Stuge wrote:
> 
> I really don't think their products are very good solutions for
> adding USB support to a project. I would strongly suggest using a
> general USB hardware instead, which allows using *all* features that
> USB has to offer.
> 
> For FTDI though maybe you could benefit from using libftdi instead.
> 

The device I'm talking to is a Segway robot.  It's apparently using an FTDI
chip to send out its comms over USB, but I have no control over that.  I'm
not using FTDI on my end, but I'm not even sure of the ramifications of
that.  Can I not talk to an FTDI chip using libusb without problems arising?  

I can already "mostly" talk to the Segway in that I can connect, read for a
while, and write for a while before odd problems like the overflow error
crop up.  Thanks for your help so far!
--

-- 
View this message in context: http://libusb.6.n5.nabble.com/libusb-bulk-transfer-and-overflow-errors-tp2802636p2802829.html
Sent from the LibUSB Dev mailing list archive at Nabble.com.

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
(Continue reading)

Permalink | Reply | 9 comments |

Gmane