libusb-win32-devel

Re: [Libusb-win32-devel] USB transfers are sometimes lost

[Dave H. <DAV...@ni...>]

> From: lib...@li...
> [mailto:lib...@li...]
> On Behalf Of Kjell Eirik Andersen
> Sent: 2007 June 19 14:21
> To: lib...@li...
> Subject: [Libusb-win32-devel] USB transfers are sometimes lost
>
> After having used libusb-win32 exstensively for more than a year
> I have come across a problem with usb_bulk_read().
>
> After several hours of errorfree communication, an usb bulk read
> package is lost (it shows on a SW bus analyzer).
>
> A bulk endpoint is continously read like this :
>
> while ( ! TerminateThread )
> {
>      i =3D usb_bulk_read( pDevH, 0x82, buffer, 64, 1000 );   // 1 sec
timeout
>      if ( i > 0 )
>            process the data
>      else if ( i !=3D TIMEOUT )
>            process error
> }
>
> Q1 : Can anybody confirm that using the libusb API in this way
> may result in lost packages ?

Not strictly an answer to your question, but I have used the
Linux version of libusb with interrupt transfers, in other
respects like you show above.  Yes, I lost packets occasionally.
I had to buy a USB analyser to show where the problem occurred.

You need to set the timeout high enough that it will only ever
be invoked in the case of a genuine failure.

If this gives you a problem of responsiveness in your programme,
i.e. you really need asynchronous transfers, then yes, it's a
problem.  I solved it by using pthreads and a FIFO.  I'm pleased
to report that pthreads seems to work OK under win32 too.

Dave


***************************************************************************=
***************************************************************************=
***************************************************************************=
****************

NICE CTI Systems UK Limited ("NICE") is registered in England under company=
 number, 3403044.  The registered office of NICE is at Tollbar Way, Hedge E=
nd, Southampton, Hampshire SO30 2ZP.

Confidentiality: This communication and any attachments are intended for th=
e above-named persons only and may be confidential and/or legally privilege=
d. Any opinions expressed in this communication are not necessarily those o=
f NICE. If this communication has come to you in error you must take no act=
ion based on it, nor must you copy or show it to anyone; please delete/dest=
roy and inform the sender by e-mail immediately.

Monitoring: NICE may monitor incoming and outgoing e-mails.

Viruses:  Although we have taken steps toward ensuring that this e-mail and=
 attachments are free from any virus, we advise that in keeping with good c=
omputing practice the recipient should ensure they are actually virus free.

***************************************************************************=
***************************************************************************=
***************************************************************************=
*******************

=20

[Libusb-win32-devel] USB transfers are sometimes lost

[Kjell E. A. <kje...@ta...>]

=20

After having used libusb-win32 exstensively for more than a year I have
come across a problem with usb_bulk_read().

After several hours of errorfree communication, an usb bulk read package
is lost (it shows on a SW bus analyzer).

=20

=20

A bulk endpoint is continously read like this :

=20

while ( ! TerminateThread )

{

      i =3D usb_bulk_read( pDevH, 0x82, buffer, 64, 1000 );   // 1 sec
timeout

      if ( i > 0 )

            process the data

      else if ( i !=3D TIMEOUT )

            process error

}

=20

Q1 : Can anybody confirm that using the libusb API in this way may
result in lost packages ?

=20

The plan now is to try using the async API with 2 buffers (ping-pong)
like shown below and check if the problem disappears :

=20

i =3D 0;

i +=3D usb_bulk_setup_async( pDevH, &context1, 0x82 );

i +=3D usb_bulk_setup_async( pDevH, &context2, 0x82 );

i +=3D usb_submit_async( context1, ibuf1, 64 );

i +=3D usb_submit_async( context2, ibuf2, 64 );

if ( i !=3D 0 )

      printf( "\nErrors : %d", i ); // Close down, replug etc. ??

=20

while ( ! TerminateThread )               =20

      {

      //--- Buffer 1 ---

      i =3D usb_reap_async( context1, INFINITE ); // INIFINITE =3D -1

      if ( i < 0 )

            printf( "\nReap 1 error : %d", i );

      else

            {

            printf( "\nReap 1 received : %d, %c", i, ibuf1[0] );

            process data

}

      i =3D 0;  =20

      //i +=3D usb_free_async( &context1 );

//i +=3D usb_bulk_setup_async( pDevH, &context1, 0x82 );

      i +=3D usb_submit_async( context1, ibuf1, 64 );

      if ( i !=3D 0 )

            printf( "\nErrors : %d", i ); // Close down, replug etc. ??

    =20

      //--- Buffer 2 ---

      i =3D usb_reap_async( context2, INFINITE );

      if ( i < 0 )

            printf( "\nReap 2 error : %d", i );

      else

{

            printf( "\nReap 2 received : %d, %c", i, ibuf2[0] );

            process data

}

      i =3D 0;  =20

      //i +=3D usb_free_async( &context2 );

//i +=3D usb_bulk_setup_async( pDevH, &context2, 0x82 );

i +=3D usb_submit_async( context2, ibuf2, 64 );

      if ( i !=3D 0 )

            printf( "\nErrors : %d", i ); // Close down, replug etc. ??

      }

=20

i  =3D usb_cancel_async( context1 );

i +=3D usb_cancel_async( context2 );

i +=3D usb_free_async( &context1 );

i +=3D usb_free_async( &context2 );

=20

Q2 : Is this the correct way to use the async API ?

=20

Q3 : Am I right in assuming that the usb_free_async() and
usb_bulk_setup_async() which is commented out inside the loop is really
unneccessary ? (it seems to work with a small limited testprogram)

=20

Any response on my three questions would be greatly appreciated !

=20

Best regards,

Kjell Eirik

[Libusb-win32-devel] Selective suspend

[Dan E. <dan...@ne...>]

Have there been any thoughts about adding support for selective suspend 
to the API? I don't think I've seen anything mentioning this on the 
libusb mailing list for the new API (and possibly the other OSes don't 
support it very well anyway), but there is quite well defined support 
within Windows for this (reporting idle notification).

Also my colleague Krzysztof Uchronski 
<krz...@di...> has not been able to successfully 
subscribe to this list, any idea why?

thanks,

Dan.

Re: [Libusb-win32-devel] =?iso-8859-15?q?Multiple_interfaces_from_dif?= =?iso-8859-15?q?ferent_processes?=

[Stephan M. <ste...@we...>]

Hi Dan,

thanks a lot for your patch.
I applied it as follows:

* I added a 'file_object' parameter to the claim/release functions and moved your code
   to these functions
* I removed the redundant 'interface.claimed' struct member
* I also removed the 'dev.ref_count' member since it's not needed any more

You'll find my changes in the SVN:
http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/libusb/

The code still passes all of my unit-test so I'm quite confident that my
modifications didn't break anything.

Please let me know is anything doesn't work as expected.

Stephan


> 
> This is the patch we've come up with to handle multiple interfaces from 
> different processes properly, and the releasing thereof if a dying 
> process fails to call release_interface (svn revisions our from our own 
> tree):
> 
> Index: C:/Projects/software/libusb/win32/src/driver/dispatch.c
> ===================================================================
> --- C:/Projects/software/libusb/win32/src/driver/dispatch.c    (revision 
> 6445)
> +++ C:/Projects/software/libusb/win32/src/driver/dispatch.c    (revision 
> 6446)
> @@ -71,13 +71,28 @@
>              }
>           
>          case IRP_MJ_CLOSE:
> +          {
> +            int i;
>           
> -          if(!InterlockedDecrement(&dev->ref_count))
> -            {
> -              /* release all interfaces when the last handle is closed */
> -              release_all_interfaces(dev);
> -            }
> -          return complete_irp(irp, STATUS_SUCCESS, 0);
> +            if(!InterlockedDecrement(&dev->ref_count))
> +              {
> +                /* release all interfaces when the last handle is closed */
> +                release_all_interfaces(dev);
> +              }
> +            else
> +              {
> +                /* release all interfaces that were connected with the 
> handle */
> +                for(i = 0; i < LIBUSB_MAX_NUMBER_OF_INTERFACES; i++)
> +                  {
> +                    
> if((ULONG_PTR)IoGetCurrentIrpStackLocation(irp)->FileObject ==
> +                      dev->config.interfaces[i].file_object)
> +                      {
> +                        release_interface(dev, i);
> +                      }
> +                  }
> +              }
> +            return complete_irp(irp, STATUS_SUCCESS, 0);
> +          }
>           
>          case IRP_MJ_CLEANUP:
>  
> Index: C:/Projects/software/libusb/win32/src/driver/release_interface.c
> ===================================================================
> --- C:/Projects/software/libusb/win32/src/driver/release_interface.c    
> (revision 6445)
> +++ C:/Projects/software/libusb/win32/src/driver/release_interface.c    
> (revision 6446)
> @@ -52,6 +52,7 @@
>      }
>  
>    dev->config.interfaces[interface].claimed = FALSE;
> +  dev->config.interfaces[interface].file_object = (ULONG_PTR)NULL;
>  
>    return STATUS_SUCCESS;
>  }
> @@ -63,6 +64,7 @@
>    for(i = 0; i < LIBUSB_MAX_NUMBER_OF_INTERFACES; i++)
>      {
>        dev->config.interfaces[i].claimed = FALSE;
> +      dev->config.interfaces[i].file_object = (ULONG_PTR)NULL;
>      }
>  
>    return STATUS_SUCCESS;
> Index: C:/Projects/software/libusb/win32/src/driver/libusb_driver.h
> ===================================================================
> --- C:/Projects/software/libusb/win32/src/driver/libusb_driver.h    
> (revision 6445)
> +++ C:/Projects/software/libusb/win32/src/driver/libusb_driver.h    
> (revision 6446)
> @@ -116,6 +116,7 @@
>  {
>    int valid;
>    int claimed;
> +  ULONG_PTR file_object;
>    libusb_endpoint_t endpoints[LIBUSB_MAX_NUMBER_OF_ENDPOINTS];
>  } libusb_interface_t;
>  
> Index: C:/Projects/software/libusb/win32/src/driver/ioctl.c
> ===================================================================
> --- C:/Projects/software/libusb/win32/src/driver/ioctl.c    (revision 6445)
> +++ C:/Projects/software/libusb/win32/src/driver/ioctl.c    (revision 6446)
> @@ -285,6 +285,18 @@
>  
>      case LIBUSB_IOCTL_CLAIM_INTERFACE:
>        status = claim_interface(dev, request->interface.interface);
> +
> +      /* add FileObject tracing to release the interface in the future, */
> +      /* when its handle will be closed */
> +      if (NT_SUCCESS(status))
> +        {
> +          
> dev->config.interfaces[request->interface.interface].file_object =
> +            (ULONG_PTR)stack_location->FileObject;
> +        }
> +      else
> +        {
> +          
> dev->config.interfaces[request->interface.interface].file_object = 
> (ULONG_PTR)NULL;
> +        }
>        break;
>  
>      case LIBUSB_IOCTL_RELEASE_INTERFACE:
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Libusb-win32-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
> 


_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

[Libusb-win32-devel] Multiple interfaces from different processes

[Dan E. <dan...@ne...>]

This is the patch we've come up with to handle multiple interfaces from 
different processes properly, and the releasing thereof if a dying 
process fails to call release_interface (svn revisions our from our own 
tree):

Index: C:/Projects/software/libusb/win32/src/driver/dispatch.c
===================================================================
--- C:/Projects/software/libusb/win32/src/driver/dispatch.c    (revision 
6445)
+++ C:/Projects/software/libusb/win32/src/driver/dispatch.c    (revision 
6446)
@@ -71,13 +71,28 @@
             }
          
         case IRP_MJ_CLOSE:
+          {
+            int i;
          
-          if(!InterlockedDecrement(&dev->ref_count))
-            {
-              /* release all interfaces when the last handle is closed */
-              release_all_interfaces(dev);
-            }
-          return complete_irp(irp, STATUS_SUCCESS, 0);
+            if(!InterlockedDecrement(&dev->ref_count))
+              {
+                /* release all interfaces when the last handle is closed */
+                release_all_interfaces(dev);
+              }
+            else
+              {
+                /* release all interfaces that were connected with the 
handle */
+                for(i = 0; i < LIBUSB_MAX_NUMBER_OF_INTERFACES; i++)
+                  {
+                    
if((ULONG_PTR)IoGetCurrentIrpStackLocation(irp)->FileObject ==
+                      dev->config.interfaces[i].file_object)
+                      {
+                        release_interface(dev, i);
+                      }
+                  }
+              }
+            return complete_irp(irp, STATUS_SUCCESS, 0);
+          }
          
         case IRP_MJ_CLEANUP:
 
Index: C:/Projects/software/libusb/win32/src/driver/release_interface.c
===================================================================
--- C:/Projects/software/libusb/win32/src/driver/release_interface.c    
(revision 6445)
+++ C:/Projects/software/libusb/win32/src/driver/release_interface.c    
(revision 6446)
@@ -52,6 +52,7 @@
     }
 
   dev->config.interfaces[interface].claimed = FALSE;
+  dev->config.interfaces[interface].file_object = (ULONG_PTR)NULL;
 
   return STATUS_SUCCESS;
 }
@@ -63,6 +64,7 @@
   for(i = 0; i < LIBUSB_MAX_NUMBER_OF_INTERFACES; i++)
     {
       dev->config.interfaces[i].claimed = FALSE;
+      dev->config.interfaces[i].file_object = (ULONG_PTR)NULL;
     }
 
   return STATUS_SUCCESS;
Index: C:/Projects/software/libusb/win32/src/driver/libusb_driver.h
===================================================================
--- C:/Projects/software/libusb/win32/src/driver/libusb_driver.h    
(revision 6445)
+++ C:/Projects/software/libusb/win32/src/driver/libusb_driver.h    
(revision 6446)
@@ -116,6 +116,7 @@
 {
   int valid;
   int claimed;
+  ULONG_PTR file_object;
   libusb_endpoint_t endpoints[LIBUSB_MAX_NUMBER_OF_ENDPOINTS];
 } libusb_interface_t;
 
Index: C:/Projects/software/libusb/win32/src/driver/ioctl.c
===================================================================
--- C:/Projects/software/libusb/win32/src/driver/ioctl.c    (revision 6445)
+++ C:/Projects/software/libusb/win32/src/driver/ioctl.c    (revision 6446)
@@ -285,6 +285,18 @@
 
     case LIBUSB_IOCTL_CLAIM_INTERFACE:
       status = claim_interface(dev, request->interface.interface);
+
+      /* add FileObject tracing to release the interface in the future, */
+      /* when its handle will be closed */
+      if (NT_SUCCESS(status))
+        {
+          
dev->config.interfaces[request->interface.interface].file_object =
+            (ULONG_PTR)stack_location->FileObject;
+        }
+      else
+        {
+          
dev->config.interfaces[request->interface.interface].file_object = 
(ULONG_PTR)NULL;
+        }
       break;
 
     case LIBUSB_IOCTL_RELEASE_INTERFACE:

Re: [Libusb-win32-devel] Everything but usb_bulk_read works...

[Bertrik S. <be...@si...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adam Kropelin wrote:
> On Mon, Jun 11, 2007 at 03:47:31PM +0100, Dave Higton wrote:
>>> -----Original Message-----
>>> From: lib...@li... 
>>> [mailto:lib...@li...] On 
>>> Behalf Of Adam Kropelin
>>> Sent: 2007 June 11 15:43
>>> To: lib...@li...
>>> Subject: Re: [Libusb-win32-devel] Everything but 
>>> usb_bulk_read works...
>>>
>>> On Mon, Jun 11, 2007 at 03:23:38PM +0100, Dave Higton wrote:
>>>> Error 22 is an invalid parameter.  Input endpoint addresses
>>>> have to have the top bit set - this is incompatible with the
>>>> Linux version.
>>> It's not incompatible at all. Not setting that bit is a bug on any
>>> platform. It just so happens that Linux lets you get away with it.
>> It depends on your POV.  When you talk to somebody, do you refer to
>> endpoint 0x81 or endpoint 1?  I refer to 1, and I bet you do too.
>> Linux has explicit code to set the top bit so that either is equally
>> valid.
> 
> There is an argument to made for the API to be forgiving; you're
> performing a read, so obviously you must have meant to provide an input
> endpoint address. Since you didn't, the library will fix it up for
> you. That type of API makes me uncomfortable; I don't like an API that
> thinks it knows more about what I want to do than me...but some 
> people like to program that way. There's also an argument to be made 
> for consistency; not every API call can easily do such a fixup for you. 
> See usb_resetep(), for example. That one is even explicitly documented.
> 
> Personally I prefer consistency and exactness: Supply the actual
> endpoint address, as specified in bEndpointAddress. Since we have to do
> that for some API calls already, its best to do it for all of them.

I agree completely.

The libusb API is not exact on what is meant with the 'ep' parameter.
The USB2.0 specification differentiates between an *endpoint number*
and an *endpoint address*, where the endpoint number is a simple 4-bit
number and the endpoint address is the endpoint number combined with
the direction bit.

USB2.0 specification suggests that it is possible for a device to
have both a 0x01 and 0x81 endpoint address (see for example paragraph
5.3.1.2: "Full-speed devices can have additional endpoints only limited
by the protocol definition (i.e., a maximum of 15 additional input
endpoints and 15 additional output endpoints).")
In that case, having libusb setting or clearing the top bit
would amount to converting the endpoint into a different and
possibly unrelated endpoint address, which is not acceptable.

IMO, the Linux implementation is wrong because it allows people to
be sloppy about this.

Regards,
Bertrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGbtyYETD6mlrWxPURAkD1AJ4qwJaQxIcOQ/xB7sa9rpeG4DmZ7wCgvMN0
Bf7kLCiO9cMY8bPJBlbjvZs=
=dh9I
-----END PGP SIGNATURE-----

[Libusb-win32-devel] USB driver problems

[<mu...@as...>]

Hi all,

=20

I am on a project, which uses this driver for the USB communication betwe=
en a software on PC, and Motorola DSP. I can currently use the driver wit=
hout problem, but have some problems when I try to change somethings.=20

=20

1 ) As it can be seen in code that follows, the endpoint's buffer size is=
=2064, I know that the ideal packet size to obtain higher speeds is to be=
=20a multiple of endpoint's buffer size, 64. But the problem is, when I t=
ry to send packets from PC to DSP whose size is a multiple of 64; 1024 fo=
r example, the packet reachs DSP but the USB_bulkOutDatHandler() method i=
s not called, so the semaphore is not given etc. I see the packet of size=
=201024 bytes correctly on my receive buffer, but why do you think the ha=
ndler is not invoked?? When the packet size is 1032 bytes there is no suc=
h problem.

=20

2 ) The packet is sent from the PC using the function as;

=20                       ret =3D usb_bulk_write(usb_handle, 0x02, USBSt.=
txBuffer, 1032, 300);=20

Since this code runs on PC, the buffer is 1032 bytes, not words. So a buf=
fer of 516 words (plus some extensions for header etc.) must be enough on=
=20DSP. But the code does not work correctly if the size of this receivin=
g buffer on DSP is less than about 1050 (!). The data is stored in the fi=
rst 516 words correctly and remaining part of the buffer never changes. B=
ut it still must be that long. This is really strange, I must be making s=
ome mistake, but I dont know what is wrong.=20

=20

3 ) I cannot change the endpoint's buffer size, when I change it, problem=
s occur.. (Actually I have no problem with this, but I am writing in case=
=20it helps for the solution of the other problems)

=20

Here are some important parts of the code... Your help is appreciated.=20

=20

---------------------------------------------------------------------

#define WLEN_USBPROBUFFER   1050

#define BLEN_USBPROBUFFER   WLEN_USBPROBUFFER*2

Uint16 USBInBuffer[WLEN_USBPROBUFFER];

=20

USB_EpHandle  myUsbConfig[] =3D {&usbEpObjOut0, &usbEpObjIn0, &usbEpObjOu=
t2,

=20                              &usbEpObjIn2, NULL};

interrupt void _USB_isr()

{

=20 USB_evDispatch( );

}

---------------------------------------------------------------------

UsbInit()

{

=20USB_setAPIVectorAddress();

=20event_mask =3D USB_EVENT_RESET | USB_EVENT_SETUP | USB_EVENT_SUSPEND |=


=20                USB_EVENT_RESUME | USB_EVENT_EOT;

=20

=20usb_status =3D USB_initEndptObj(USB0, &usbEpObjOut0, USB_OUT_EP0, USB_=
CTRL,

=20                               0x40, event_mask, USB_ctl_handler);

=20usb_status =3D USB_initEndptObj(USB0, &usbEpObjIn0, USB_IN_EP0, USB_CT=
RL,

=20                               0x40, USB_EVENT_EOT,USB_ctl_handler);

=20usb_status =3D USB_initEndptObj(USB0, &usbEpObjOut2, USB_OUT_EP2, USB_=
BULK,

=20                               0x40, USB_EVENT_EOT,USB_bulkOutEvHandle=
r);

=20usb_status =3D USB_initEndptObj(USB0, &usbEpObjIn2, USB_IN_EP2, USB_BU=
LK, 0x40,

=20                               USB_EVENT_HINT|USB_EVENT_EOT|          =
=20 =20

=20                               USB_EVENT_RESET,USB_bulkInEvHandler);

=20

=20usb_status =3D USB_init(USB0, myUsbConfig, 0x80);

=20IRQ_clear(usbId);

=20IRQ_enable(usbId);

=20IRQ_plug(usbId,&_USB_isr);

=20IRQ_globalEnable();

=20if (usb_status) USB_connectDev(USB0);

}

---------------------------------------------------------------------

void USB_bulkOutEvHandler()

{

=20 USB_bulkOutDatHandler(&usbEpObjIn2, &usbEpObjOut2);

}

---------------------------------------------------------------------

void USB_bulkOutDatHandler(USB_EpHandle hEpIn, USB_EpHandle hEpOut)

{

=20 if (USB_isTransactionDone(hEpOut))

=20 {

=20   USB_postTransaction(hEpOut, BLEN_USBPROBUFFER, USBInBuffer, USB_IOF=
LAG_SWAP);

=20   newpack_received++;

=20   SEM_post(&SEM_UsbPacketReceived);

=20 }

}

---------------------------------------------------------------------

void USB_bulkInEvHandler()

{

=20 ev =3D USB_peekEvents(&usbEpObjIn2);

=20 USB_bulkInDatHandler(&usbEpObjIn2, &usbEpObjOut2);

=20  =20

=20 if(USB_peekEvents(&usbEpObjIn2) & USB_EVENT_EOT) {

=20   asm("   nop");

=20   asm("   nop");

=20 }

}

---------------------------------------------------------------------

void USB_bulkInDatHandler(USB_EpHandle hEpIn, USB_EpHandle hEpOut)

{

=20 cnt ++;

=20 cntk++;

=20

=20 if (USB_isTransactionDone(hEpIn))

=20 {

=20   if (USBSt.replyBufFlag) {

=20     USB_postTransaction(&usbEpObjIn2, USBSt.replyLength, USBSt.replyB=
uf, USB_IOFLAG_SWAP);

=20   }

=20   else

=20     USB_postTransaction(&usbEpObjIn2, 0, USBSt.replyBuf, USB_IOFLAG_S=
WAP);

=20 }

}

-------------------------------------------------------------------

void TSK_Usb()

{

=20 while(1)

=20 {

=20   SEM_pend(&SEM_UsbPacketReceived, SYS_FOREVER);

=20   if (newpack_received>0)

=20   {

=20     if(newpack_received>1) printf("slow packet handling!\n");

=20

=20     PcRcvStateMachine(); //input buffer is processed here, replyBuf, =
replyLength are set

=20

=20     if (reply_packet>1) printf("slow reply handling!\n");

=20   }

=20 }

}

-------------------------------------------------------
=20
######################################################################
Dikkat:

Bu elektronik posta mesaji kisisel ve ozeldir. Eger size=20
gonderilmediyse lutfen gondericiyi bilgilendirip mesaji siliniz.=20
Firmamiza gelen ve giden mesajlar virus taramasindan gecirilmekte,=20
guvenlik nedeni ile kontrol edilerek saklanmaktadir. Mesajdaki=20
gorusler ve bakis acisi gondericiye ait olup Aselsan A.S. resmi=20
gorusu olmak zorunda degildir.

######################################################################
Attention:=20

This e-mail message is privileged and confidential. If you are=20
not the intended recipient please delete the message and notify=20
the sender. E-mails to and from the company are monitored for=20
operational reasons and in accordance with lawful business practices.=20
Any views or opinions presented are solely those of the author and=20
do not necessarily represent the views of the company.

######################################################################

Re: [Libusb-win32-devel] Everything but usb_bulk_read works...

[Dave H. <DAV...@ni...>]

> -----Original Message-----
> From: lib...@li...=20
> [mailto:lib...@li...] On=20
> Behalf Of Guillaume Dargaud
> Sent: 2007 June 12 08:55
> To: lib...@li...
> Subject: Re: [Libusb-win32-devel] Everything but=20
> usb_bulk_read works...
>=20
> I may be new here, but what is the point of having two=20
> functions called=20
> usb_bulk_write and usb_bulk_read if you ALSO have to pass in them=20
> USB_DIR_OUT or USB_DIR_IN ?
> Seems to defeat the purpose.

Hey, this is Windoze.  It /has/ to be difficult.

Dave


***************************************************************************=
***************************************************************************=
***************************************************************************=
****************

NICE CTI Systems UK Limited ("NICE") is registered in England under company=
 number, 3403044.  The registered office of NICE is at Tollbar Way, Hedge E=
nd, Southampton, Hampshire SO30 2ZP.

Confidentiality: This communication and any attachments are intended for th=
e above-named persons only and may be confidential and/or legally privilege=
d. Any opinions expressed in this communication are not necessarily those o=
f NICE. If this communication has come to you in error you must take no act=
ion based on it, nor must you copy or show it to anyone; please delete/dest=
roy and inform the sender by e-mail immediately.

Monitoring: NICE may monitor incoming and outgoing e-mails.

Viruses:  Although we have taken steps toward ensuring that this e-mail and=
 attachments are free from any virus, we advise that in keeping with good c=
omputing practice the recipient should ensure they are actually virus free.

***************************************************************************=
***************************************************************************=
***************************************************************************=
*******************

=20

Re: [Libusb-win32-devel] Everything but usb_bulk_read works...

[Guillaume D. <us...@gd...>]

I may be new here, but what is the point of having two functions called 
usb_bulk_write and usb_bulk_read if you ALSO have to pass in them 
USB_DIR_OUT or USB_DIR_IN ?
Seems to defeat the purpose.
-- 
Guillaume Dargaud
http://www.gdargaud.net/
  "Error, no keyboard - press F1 to continue." 

Re: [Libusb-win32-devel] Everything but usb_bulk_read works...

[Graeme G. <gr...@ar...>]

Adam Kropelin wrote:

> There is an argument to made for the API to be forgiving; you're
> performing a read, so obviously you must have meant to provide an input
> endpoint address. Since you didn't, the library will fix it up for
> you. That type of API makes me uncomfortable; I don't like an API that
> thinks it knows more about what I want to do than me...but some 
> people like to program that way. 

One solution (if there is a mechanism for it) would be for
the API to fix it up and issue a warning. Those who are
interested in clean code will note the warning and fix
the parameter, others can ignore it.

Another approach is to have "strict" and "forgiving" settings.
Default to "forgiving", and those interested in cleaning up their
code will turn on "strict".

Graeme Gill.

Re: [Libusb-win32-devel] Everything but usb_bulk_read works...

[Guillaume D. <us...@gd...>]

>> > Error 22 is an invalid parameter.  Input endpoint addresses
>> > have to have the top bit set - this is incompatible with the
>> > Linux version.

That was it. Thanks guys.

BTW, in the process I discovered the undocumented functions usb_strerror() 
and usb_set_debug(255)
-- 
Guillaume Dargaud
http://www.gdargaud.net/

Re: [Libusb-win32-devel] Everything but usb_bulk_read works...

[Adam K. <akr...@ro...>]

On Mon, Jun 11, 2007 at 03:47:31PM +0100, Dave Higton wrote:
> > -----Original Message-----
> > From: lib...@li... 
> > [mailto:lib...@li...] On 
> > Behalf Of Adam Kropelin
> > Sent: 2007 June 11 15:43
> > To: lib...@li...
> > Subject: Re: [Libusb-win32-devel] Everything but 
> > usb_bulk_read works...
> > 
> > On Mon, Jun 11, 2007 at 03:23:38PM +0100, Dave Higton wrote:
> > > 
> > > Error 22 is an invalid parameter.  Input endpoint addresses
> > > have to have the top bit set - this is incompatible with the
> > > Linux version.
> > 
> > It's not incompatible at all. Not setting that bit is a bug on any
> > platform. It just so happens that Linux lets you get away with it.
> 
> It depends on your POV.  When you talk to somebody, do you refer to
> endpoint 0x81 or endpoint 1?  I refer to 1, and I bet you do too.
> Linux has explicit code to set the top bit so that either is equally
> valid.

There is an argument to made for the API to be forgiving; you're
performing a read, so obviously you must have meant to provide an input
endpoint address. Since you didn't, the library will fix it up for
you. That type of API makes me uncomfortable; I don't like an API that
thinks it knows more about what I want to do than me...but some 
people like to program that way. There's also an argument to be made 
for consistency; not every API call can easily do such a fixup for you. 
See usb_resetep(), for example. That one is even explicitly documented.

Personally I prefer consistency and exactness: Supply the actual
endpoint address, as specified in bEndpointAddress. Since we have to do
that for some API calls already, its best to do it for all of them.

--Adam

[Libusb-win32-devel] unsubscribe

[<sav...@we...>]

unsubscribe

Re: [Libusb-win32-devel] Everything but usb_bulk_read works...

[Dave H. <DAV...@ni...>]

> -----Original Message-----
> From: lib...@li...=20
> [mailto:lib...@li...] On=20
> Behalf Of Adam Kropelin
> Sent: 2007 June 11 15:43
> To: lib...@li...
> Subject: Re: [Libusb-win32-devel] Everything but=20
> usb_bulk_read works...
>=20
> On Mon, Jun 11, 2007 at 03:23:38PM +0100, Dave Higton wrote:
> >=20
> > Error 22 is an invalid parameter.  Input endpoint addresses
> > have to have the top bit set - this is incompatible with the
> > Linux version.
>=20
> It's not incompatible at all. Not setting that bit is a bug on any
> platform. It just so happens that Linux lets you get away with it.

It depends on your POV.  When you talk to somebody, do you refer to
endpoint 0x81 or endpoint 1?  I refer to 1, and I bet you do too.
Linux has explicit code to set the top bit so that either is equally
valid.

My vote is that I prefer the Linux way.

Dave


***************************************************************************=
***************************************************************************=
***************************************************************************=
****************

NICE CTI Systems UK Limited ("NICE") is registered in England under company=
 number, 3403044.  The registered office of NICE is at Tollbar Way, Hedge E=
nd, Southampton, Hampshire SO30 2ZP.

Confidentiality: This communication and any attachments are intended for th=
e above-named persons only and may be confidential and/or legally privilege=
d. Any opinions expressed in this communication are not necessarily those o=
f NICE. If this communication has come to you in error you must take no act=
ion based on it, nor must you copy or show it to anyone; please delete/dest=
roy and inform the sender by e-mail immediately.

Monitoring: NICE may monitor incoming and outgoing e-mails.

Viruses:  Although we have taken steps toward ensuring that this e-mail and=
 attachments are free from any virus, we advise that in keeping with good c=
omputing practice the recipient should ensure they are actually virus free.

***************************************************************************=
***************************************************************************=
***************************************************************************=
*******************

=20

Re: [Libusb-win32-devel] Everything but usb_bulk_read works...

[Adam K. <akr...@ro...>]

On Mon, Jun 11, 2007 at 03:23:38PM +0100, Dave Higton wrote:
> > -----Original Message-----
> > From: lib...@li... 
> > [mailto:lib...@li...] On 
> > Behalf Of Guillaume Dargaud
> > Sent: 2007 June 11 15:21
> > To: lib...@li...
> > Subject: [Libusb-win32-devel] Everything but usb_bulk_read works...
> > 
> > Hello all,
> > I just took my newly formed USB code for Linux and tried it 
> > on Windows with
> > LibUsbWin32.
> > 
> > Everything seems to work fine, including the firmware upload and
> > usb_bulk_write, but usb_bulk_read returns -22.
> > 
> > Strangely i couldn't find a table of possible return error 
> > codes. Any idea ?
> 
> Error 22 is an invalid parameter.  Input endpoint addresses
> have to have the top bit set - this is incompatible with the
> Linux version.

It's not incompatible at all. Not setting that bit is a bug on any
platform. It just so happens that Linux lets you get away with it.

--Adam

Re: [Libusb-win32-devel] Everything but usb_bulk_read works...

[Dave H. <DAV...@ni...>]

> -----Original Message-----
> From: lib...@li...=20
> [mailto:lib...@li...] On=20
> Behalf Of Guillaume Dargaud
> Sent: 2007 June 11 15:21
> To: lib...@li...
> Subject: [Libusb-win32-devel] Everything but usb_bulk_read works...
>=20
> Hello all,
> I just took my newly formed USB code for Linux and tried it=20
> on Windows with
> LibUsbWin32.
>=20
> Everything seems to work fine, including the firmware upload and
> usb_bulk_write, but usb_bulk_read returns -22.
>=20
> Strangely i couldn't find a table of possible return error=20
> codes. Any idea ?

Error 22 is an invalid parameter.  Input endpoint addresses
have to have the top bit set - this is incompatible with the
Linux version.

Dave


***************************************************************************=
***************************************************************************=
***************************************************************************=
****************

NICE CTI Systems UK Limited ("NICE") is registered in England under company=
 number, 3403044.  The registered office of NICE is at Tollbar Way, Hedge E=
nd, Southampton, Hampshire SO30 2ZP.

Confidentiality: This communication and any attachments are intended for th=
e above-named persons only and may be confidential and/or legally privilege=
d. Any opinions expressed in this communication are not necessarily those o=
f NICE. If this communication has come to you in error you must take no act=
ion based on it, nor must you copy or show it to anyone; please delete/dest=
roy and inform the sender by e-mail immediately.

Monitoring: NICE may monitor incoming and outgoing e-mails.

Viruses:  Although we have taken steps toward ensuring that this e-mail and=
 attachments are free from any virus, we advise that in keeping with good c=
omputing practice the recipient should ensure they are actually virus free.

***************************************************************************=
***************************************************************************=
***************************************************************************=
*******************

=20

[Libusb-win32-devel] Everything but usb_bulk_read works...

[Guillaume D. <us...@gd...>]

Hello all,
I just took my newly formed USB code for Linux and tried it on Windows with
LibUsbWin32.

Everything seems to work fine, including the firmware upload and
usb_bulk_write, but usb_bulk_read returns -22.

Strangely i couldn't find a table of possible return error codes. Any idea ?

Thanks
-- 
Guillaume Dargaud
http://www.gdargaud.net/
  "I have a quantum car. Every time I look at the speedometer I get lost..."

Re: [Libusb-win32-devel] intermittent usb_interrupt_write fail

[Craig B. <cra...@gm...>]

On 10/06/07, Stephan Meyer <ste...@we...> wrote:
>
> This look like your device doesn't handle DATA0/DATA1 toggle
> correctly and therefore discards every second packet without
> generating an error on the host side.
>
> Stephan
>

Hmmm. That is a very interesting suggestion. It is quite possible that
my toggling code is not correct, but I had assumed that if it wasn't,
I would get an error somewhere, most likely at the host. I will
definitely need to reexamine that code.

Thanks for your ideas,
Craig

ps. Oh, and thanks for libusb win32. It's fantastic!

Re: [Libusb-win32-devel] intermittent usb_interrupt_write fail

[Stephan M. <ste...@we...>]

This look like your device doesn't handle DATA0/DATA1 toggle
correctly and therefore discards every second packet without
generating an error on the host side.

Stephan

 

> 
> Hi all,
> 
> I have an app which calls usb_interrupt_write. Half the time it works
> fine. The other half it doesn't seem to send the data at all, but
> doesn't return any error - it returns the correct number of bytes it
> should have written.
> 
> Now I wrote the firmware on the device, so there is every chance that
> it is buggy, but I thought that if there was a problem transferring
> the data over the usb, then libusb should have flagged something. I
> know I'm not getting the data on the device because I have debugging
> code on the device showing stages of the transaction.
> 
> A tough one I know. I just don't know what to try next. Should I try
> to debug the libusb driver to see if anything comes up? I have the
> WinDDK debugger although I've never used it.
> 
> Cheer,
> Craig
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Libusb-win32-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
> 


_______________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

Re: [Libusb-win32-devel] LibUSB & composite USB devices

[Stephan M. <ste...@we...>]

Version 0.1.12.1 doesn't support composite device interfaces but adding
this feature is easy. 
Attached to this mail you'll find a patched version of the driver that supports
this feature.

To install it you'll have to:

* rename libusb0_sys.pdf to libusb0.sys
* copy libusb0.sys to <windir>/system32/drivers
* unplug and replug all USB devices handled by libusb

Please let me know if it works,

Stephan

 
> 
> 
> Hello, all!
> 
> I have been searching mailing list archive and the web for a while, but it
> is still not clear to me -- does LibUSB support composite USB devices on
> Win32 (Windows XP, etc.), or not?
> 
> I have composite device with two interfaces: one of HID class, and one is
> vendor-defined class. I would like to use LibUSB for communication with the
> second (vendor-defined) interface. So I downloaded version 0.1.12.1 of
> LibUSB-Win32 and used infwizard to generate INF file. After that, I changed
> hardware IDs in the INF to match my second interface's ID like that:
> 
> USB\VID_4242&PID_0008 -> USB\VID_4242&PID_0008&MI_01
> 
> Driver is installed OK, and it is visible in the Device Manager, but
> testusblib-win.exe does not show any LibUSB devices.
> What could be wrong?
> 
> Any comments are appreciated.
> 
> Best regards,
> Alexei Adadurov.
> 
> 
> 
> 
> -- 
> View this message in context: http://www.nabble.com/LibUSB---composite-USB-devices-tf3890089.html#a11027391
> Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com.
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Libusb-win32-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
> 


_______________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

[Libusb-win32-devel] intermittent usb_interrupt_write fail

[Craig B. <cra...@gm...>]

Hi all,

I have an app which calls usb_interrupt_write. Half the time it works
fine. The other half it doesn't seem to send the data at all, but
doesn't return any error - it returns the correct number of bytes it
should have written.

Now I wrote the firmware on the device, so there is every chance that
it is buggy, but I thought that if there was a problem transferring
the data over the usb, then libusb should have flagged something. I
know I'm not getting the data on the device because I have debugging
code on the device showing stages of the transaction.

A tough one I know. I just don't know what to try next. Should I try
to debug the libusb driver to see if anything comes up? I have the
WinDDK debugger although I've never used it.

Cheer,
Craig

[Libusb-win32-devel] LibUSB & composite USB devices

[Alexei A. <ale...@ne...>]

Hello, all!

I have been searching mailing list archive and the web for a while, but it
is still not clear to me -- does LibUSB support composite USB devices on
Win32 (Windows XP, etc.), or not?

I have composite device with two interfaces: one of HID class, and one is
vendor-defined class. I would like to use LibUSB for communication with the
second (vendor-defined) interface. So I downloaded version 0.1.12.1 of
LibUSB-Win32 and used infwizard to generate INF file. After that, I changed
hardware IDs in the INF to match my second interface's ID like that:

USB\VID_4242&PID_0008 -> USB\VID_4242&PID_0008&MI_01

Driver is installed OK, and it is visible in the Device Manager, but
testusblib-win.exe does not show any LibUSB devices.
What could be wrong?

Any comments are appreciated.

Best regards,
Alexei Adadurov.




-- 
View this message in context: http://www.nabble.com/LibUSB---composite-USB-devices-tf3890089.html#a11027391
Sent from the LibUSB Dev - Win32 mailing list archive at Nabble.com.

Re: [Libusb-win32-devel] Help, please

[Dan E. <dan...@ne...>]

Dave Higton wrote:
>
> > -----Original Message-----
> > From: lib...@li...
> > [mailto:lib...@li...] On
> > Behalf Of Bertrik Sikken
> > Sent: 2007 June 06 17:53
> > To: lib...@li...
> > Subject: Re: [Libusb-win32-devel] Help, please
> >
> > Stephan Meyer wrote:
> > > Try to replace:
> > >
> > > uci = usb_claim_interface (udev, 0);
> > >
> > > with
> > >
> > > usb_set_configuation(udev, 1);
> > > uci = usb_claim_interface (udev, 0);
> > >
> > > It should work then.
> >
> > I think I recently saw a recommendation on the libusb list to NOT
> > do an explicit usb_set_configuration. If I remember correctly
> > Linux already picks a configuration for you (usually devices
> > only have one configuration anyway).
>
> I don't have to do this on Linux, but I do on Win32.
>
> > What is the proper thing to do when writing something for
> > both Linux and Windows?
>
> Yes, I'd like to know too, please.  I'm writing for both.
> I've only just started with Win32 and I've discovered
> 3 incompatibilities.  All solved, of course, thanks to
> some extremely rapid help; but it would be easiest for
> everybody if there weren't any incompatibilities.
>
It's a bit of a tricky one really. Under Windows, if you claim a device 
by VID and PID, then you get to talk to it before the set configuration 
request is sent - basically the earliest time your driver could be 
called. This is good, because the OS doesn't actually know which 
configuration you're going to want (admittedly there's usually only 
one). The way Linux and at least some other libusb ports work, is that 
since there is no kernel libusb driver, if there is a class driver for 
the device, then the configuration will have been set already, and you 
then have to remove the kernel class driver somehow. If the generic 
driver is picked then it still seems to set the configuration, which 
does to me seem a little odd.

It gets more complicated if the device has multiple interfaces. Under 
Windows the compositie driver will be attached if there is no match for 
the VID/PID. If one of the interfaces has a class driver, then that will 
be loaded, and obviously the configuration will have to be set. If there 
is a proprietry driver matchin on VID/PID/Iface, then it won't have much 
choice about the configuration setting, I'm not sure what happens if it 
tries to change it.

Dan.

Re: [Libusb-win32-devel] Help, please

[Dave H. <DAV...@ni...>]

> -----Original Message-----
> From: lib...@li...=20
> [mailto:lib...@li...] On=20
> Behalf Of Bertrik Sikken
> Sent: 2007 June 06 17:53
> To: lib...@li...
> Subject: Re: [Libusb-win32-devel] Help, please
>=20
> Stephan Meyer wrote:
> > Try to replace:
> >=20
> > uci =3D usb_claim_interface (udev, 0);
> >=20
> > with
> >=20
> > usb_set_configuation(udev, 1);
> > uci =3D usb_claim_interface (udev, 0);
> >=20
> > It should work then.
>=20
> I think I recently saw a recommendation on the libusb list to NOT
> do an explicit usb_set_configuration. If I remember correctly
> Linux already picks a configuration for you (usually devices
> only have one configuration anyway).

I don't have to do this on Linux, but I do on Win32.

> What is the proper thing to do when writing something for
> both Linux and Windows?

Yes, I'd like to know too, please.  I'm writing for both.
I've only just started with Win32 and I've discovered
3 incompatibilities.  All solved, of course, thanks to
some extremely rapid help; but it would be easiest for
everybody if there weren't any incompatibilities.

Dave


***************************************************************************=
***************************************************************************=
***************************************************************************=
****************

NICE CTI Systems UK Limited ("NICE") is registered in England under company=
 number, 3403044.  The registered office of NICE is at Tollbar Way, Hedge E=
nd, Southampton, Hampshire SO30 2ZP.

Confidentiality: This communication and any attachments are intended for th=
e above-named persons only and may be confidential and/or legally privilege=
d. Any opinions expressed in this communication are not necessarily those o=
f NICE. If this communication has come to you in error you must take no act=
ion based on it, nor must you copy or show it to anyone; please delete/dest=
roy and inform the sender by e-mail immediately.

Monitoring: NICE may monitor incoming and outgoing e-mails.

Viruses:  Although we have taken steps toward ensuring that this e-mail and=
 attachments are free from any virus, we advise that in keeping with good c=
omputing practice the recipient should ensure they are actually virus free.

***************************************************************************=
***************************************************************************=
***************************************************************************=
*******************

=20

Re: [Libusb-win32-devel] Help, please

[Xiaofan C. <xia...@gm...>]

On 6/7/07, Bertrik Sikken <be...@si...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Stephan Meyer wrote:
> > Try to replace:
> >
> > uci = usb_claim_interface (udev, 0);
> >
> > with
> >
> > usb_set_configuation(udev, 1);
> > uci = usb_claim_interface (udev, 0);
> >
> > It should work then.
>
> I think I recently saw a recommendation on the libusb list to NOT
> do an explicit usb_set_configuration. If I remember correctly
> Linux already picks a configuration for you (usually devices
> only have one configuration anyway).

I believe that recommendation is wrong and for old version of Linux.
Under Linux, often it is necessary to detach the kernel driver
(eg: usbhid) before libusb can functional. This may have something to
do with problems happened when calling usb_set_configuration
under Linux.

> What is the proper thing to do when writing something for
> both Linux and Windows?
>

I believe what Stephan recommended is correct.