libusb-win32 version 1.1.14.0 released

libusb-win32 project is proud to release the latest 1.1.14.0 version.

Please go to libusb-win32 project page at Sourceforge to download
this latest release.
http://sourceforge.net/projects/libusb-win32/

If you have any comments about this release, please post to
the libusb-win32-devel mailing list.
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel

LibUsb-Win32 Change Log (compare to previous 0.1.12.2 release):

V1.14.1.0 (06/01/2010)

=======================
* Updated logging functions and standardized log message
display format.

* Updated inf-wizard to use the new directory format for the
libusb-win32 binaries.

* Updated package directories to reflect the winddk
BUILDARCH environment variable.
(i64 := ia64, x64 := amd64)

* Added request to get the current configuration in usb_open().

* Fixed 2960644 (reported by farthen) crash on shutdown
with x64 based systems while using inf files for each libusb device.

Re: help

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

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

Re: help

2010/6/2 晓夏 崔 <cxx_0627 <at> hotmail.com>:
> usb2.0 specification show that Maxpackagesize0 in device descriptor is 8,
> 16, 32, 64 valid.
> but the total size of my configuration descriptor , interface descriptor and
> 9 endpointers descriptor is 74.
> how  I can send 74 bytes to host at one time ?

Sorry I do not quite understand you. So hope my answer is to the point.
There is this differentiation about USB transfer and packet. A transfer
can have multiple packet. So a transfer of 74 Bytes can be in two
packets, one is 64 Bytes, the other is 10 Bytes.

I just copy Tsuneo's answer here since it is very helpful.

-- 
Xiaofan http://mcuee.blogspot.com

==============================================
http://www.cygnal.org/ubb/Forum9/HTML/001627.html
Post by Tsuneo.

1) Transfer - transaction - packet

Transfer is the greatest unit of communication structure on USB.
USB carries transfer, splitting it into transactions on the bus. The
wMaxPacketSize field of the endpoint descriptor determines the
size of division unit.

The hardware parts, the host controller and the USB engine (SIE:
Serial Interface Engine) on the MCU, interpret transaction into
packets, like IN-DATA-ACK or OUT-DATA-ACK.

Host app handles transfer directly, and firmware does in the split
shape, a sequence of transactions.

For example, suppose that a host app sends 200 bytes of data. It
is sent by single WriteFile (or equivalent call) to the device driver.
The device driver and the host controller splits it into transactions,
according to the wMaxPacketSize of the endpoint. When
wMaxPacketSize = 64, the firmware sees this sequence of
transactions, as 200 bytes transfer.

64, 64, 64, 8

In the opposite direction, also, the reverse process is done; the
firmware sends a sequence of transactions, they are combined
together into a single block, and handed to the host app as a
single transfer over single ReadFile().

In this way, any size of transfer is carried over USB, even if it
grows up to MBytes.

Therefore,
- You don't see any USB packet or ACK packet on the coding of
host app. It is true even on the firmware coding.

- When error occurs on the transfer, ReadFile and WriteFile
returns error, either directly (synchronous call), or indirectly
(asynchronous call). When these APIs succeed, the transfers
succeed without error.

- On the coding of host app, you don't need to be aware of the
packet payload size (wMaxPacketSize). It is handled
automatically by the host controller.

OK, go one step further.

2) Termination of transfer

USB spec defines the end of bulk and interrupt transfer as follows,

    a) Has transferred exactly the amount of data expected
    b) Transfers a transaction with a payload size less than
wMaxPacketSize or transfers a zero-length packet

    5.8.3 Bulk Transfer Packet Size Constraints (usb_20.pdf p53)
    5.7.3 Interrupt Transfer Packet Size Constraints (usb_20.pdf p49)

a) Expected transfer size
This is the primary criteria.
The host side always knows the expected transfer size, because
any transfer is initiated by the host, regardless of the transfer
direction, IN (from device to host) or OUT (from host to device).

For example, these parameters of ReadFile and WriteFile mean
the expected transfer size.
ReadFile( ..., nNumberOfBytesToRead, ...)
WriteFile(..., nNumberOfBytesToWrite, ...)

On the other hand, the firmware doesn't know the expected size,
unless the host sends it to the firmware beforehand,
OR, it is documented explicitly as the protocol design.

b) Short packet
This is the secondary criteria.
Short packet means a transaction shorter than wMaxPacketSize,
including ZLP (Zero-Length Packet).
As above example shows, each transaction on a transfer has
wMaxPacketSize of data, until the last one. A short packet
appears at the end of transfer.

Using short packet, the firmware can cut off the transfer, before
the transfer size reaches to the expected size. When the transfer
size is just the multiple of wMaxPacketSize, ZLP is appended
to the transfer to stop the transfer in halfway.

For example, the host app requests 200 bytes transfer,
nNumberOfBytesToRead = 200;
ReadFile( ..., nNumberOfBytesToRead, ...);

But the firmware returns 128 bytes (wMaxPacketSize = 64),
64, 64, ZLP

ZLP is appended because the firmware cuts off the transfer.

However, the host app requests just 128 bytes here, no ZLP is
appended, because it matches to the expected size.

nNumberOfBytesToRead = 128;
ReadFile( ..., nNumberOfBytesToRead, ...);
64, 64 (no ZLP)

Please note, ZLP is seen just for IN transfers, not for OUT transfers,
because host always sends just the expected size of OUT transfers.
No way to stop it without error.

3) Protocol design

When you design an original protocol carried over USB, you have to
make "expected transfer size" always clear for the firmware.

For transfers of fixed length,
Define "expected transfer size" for each type of transfer explicitly,
and apply it to both of the host app and the firmware as the
common constants in a common header file, or documentation.

For transfers of variable length,
- Send the "expected transfer size" beforehand from the host,
using above fixed-length transfer.
OR
- For OUT transfer, the first byte(s) of the transfer holds the transfer
size of this transfer.
- For IN transfers, define "expected transfer size" of large enough,
and cut off the transfer by a short packet (including ZLP) on
the firmware.

==============================================

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Libusb-win32-devel mailing list
Libusb-win32-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel

isochronous error: usb_reap: reaping request failed, win error: A device attached to the system is not functioning

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo

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

Re: isochronous error: usb_reap: reaping request failed, win error: A device attached to the system is not functioning

2010/6/3 marshal.cd <marshal.cd <at> gmail.com>:
> Hi all,
> I am now working for adding libusb-win32 isochronous
> transfer into Qemu(a open source simulator acts like vmware).

That is great!

>     for (interface = 0; interface < nb_interfaces; interface++) {
>
>         ret = usb_claim_interface(udev, interface);
>     }

This will claim interface 0 and interface 1. But it did not
set the alternative interface. For isochronous device,
the alternative setting 0 typically did not request any
bandwidth from the host. You have to use other alternative
settings.

This is the one you want to use.
http://libusb.sourceforge.net/doc/function.usbsetaltinterface.html
http://sourceforge.net/apps/trac/libusb-win32/wiki/libusbwin32_documentation

int usb_set_altinterface(usb_dev_handle *dev, int alternate);

For you case, alternate = 1.

>
> Here is my usb device information:
> bus/device  idVendor/idProduct
> bus-0/\\.\libusb0-0001--0x0d8c-0x0103     0D8C/0103
> - Manufacturer : C-Media INC.
> - Product      : USB Sound Device
>   wTotalLength:         116
>   bNumInterfaces:       2
>   bConfigurationValue:  1
>   iConfiguration:       0
>   bmAttributes:         80h
>   MaxPower:             250
>     bInterfaceNumber:   0
>     bAlternateSetting:  0
>     bNumEndpoints:      0
>     bInterfaceClass:    1
>     bInterfaceSubClass: 1
>     bInterfaceProtocol: 0
>     iInterface:         0

This interface has no endpoints associated with it
(other than the control endpoint EP0)

>     bInterfaceNumber:   1
>     bAlternateSetting:  0
>     bNumEndpoints:      0
>     bInterfaceClass:    1
>     bInterfaceSubClass: 2
>     bInterfaceProtocol: 0
>     iInterface:         0

This alternative setting 0 has no endpoints associated with it.

>     bInterfaceNumber:   1
>     bAlternateSetting:  1

AlternateSetting 1 has the real endpoints you want to use.

>     bNumEndpoints:      1
>     bInterfaceClass:    1
>     bInterfaceSubClass: 2
>     bInterfaceProtocol: 0
>     iInterface:         0
>       bEndpointAddress: 06h
>       bmAttributes:     09h
>       wMaxPacketSize:   192
>       bInterval:        1
>       bRefresh:         0
>       bSynchAddress:    0

--

-- 
Xiaofan http://mcuee.blogspot.com

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo

Re: isochronous error: usb_reap: reapingrequest failed, win error: A device attached to the system is not functioning

First thanks for xiaofan's suggestion.I have tried it ,but get the same error finally.
Here the new initialization code:
{
    usb_init();
    usb_set_debug(255);
    usb_find_busses();
    usb_find_devices();
    usb_get_descriptor();
    usb_set_configuration(udev, 1);

    for (interface = 0; interface < nb_interfaces; interface++) {

        ret = usb_claim_interface(udev, interface);
    }
/*according to xiaofan's suggestion,I add  set_altersetting*/
   usb_set_altinterface(udev,1);
/*add test code in initialization */
     usb_trigger_test(udev,100);
}
static uint8_t temp_buf[192];
void usb_trigger_test(struct usb_dev_handle *udev,int times){
	void *context1= NULL;
	int ret;
	memset(temp_buf,0,192) ;
	ret = usb_isochronous_setup_async(udev,&context1,0x6,192);

	if(ret < 0){
		printf("%s usb_isochronous_setup_async error \n",__FUNCTION__);
		return ;
		}
	  while(times){
			times--;
    		ret = usb_submit_async(context1, temp_buf, 192);
			if(ret < 0)
      		{
			printf("usb_submit_async error time %d",times);
       		}
			ret = usb_reap_async_nocancel(context1, 50);
           if(ret < 0)
      		{	printf("usb_reap_async_nocancel error time %d",times);
			}
		/*Sleep(300);*/
	  	}
  if(!times)
  	printf("iso test ok\n");
  else
  	printf("iso test fail\n");
  usb_free_async(&context1);

}
It's  strange that I can just send the  first iso transfer.
When I inserts Sleep(300) after every usb_reap_async_nocancel() , the testing is past without errors. 
Best wishes
marshal.cd

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo

Re: isochronous error: usb_reap: reapingrequest failed, win error: A device attached to the system is not functioning

On Thu, Jun 3, 2010 at 5:23 PM, marshal.cd <marshal.cd <at> gmail.com> wrote:
> First thanks for xiaofan's suggestion.I have tried it ,but get the same error finally.
> Here the new initialization code:
> {
>    usb_init();
>    usb_set_debug(255);
>    usb_find_busses();
>    usb_find_devices();
>    usb_get_descriptor();
>    usb_set_configuration(udev, 1);
>
>    for (interface = 0; interface < nb_interfaces; interface++) {
>
>        ret = usb_claim_interface(udev, interface);
>    }
> /*according to xiaofan's suggestion,I add  set_altersetting*/
>   usb_set_altinterface(udev,1);
> /*add test code in initialization */
>     usb_trigger_test(udev,100);
> }
> static uint8_t temp_buf[192];
> void usb_trigger_test(struct usb_dev_handle *udev,int times){
>        void *context1= NULL;
>        int ret;
>        memset(temp_buf,0,192) ;
>        ret = usb_isochronous_setup_async(udev,&context1,0x6,192);
>
>        if(ret < 0){
>                printf("%s usb_isochronous_setup_async error \n",__FUNCTION__);
>                return ;
>                }
>          while(times){
>                        times--;
>                ret = usb_submit_async(context1, temp_buf, 192);
>                        if(ret < 0)
>                {
>                        printf("usb_submit_async error time %d",times);
>                }
>                        ret = usb_reap_async_nocancel(context1, 50);
>           if(ret < 0)
>                {       printf("usb_reap_async_nocancel error time %d",times);
>                        }
>                /*Sleep(300);*/
>                }
>  if(!times)
>        printf("iso test ok\n");
>  else
>        printf("iso test fail\n");
>  usb_free_async(&context1);
>
> }
> It's  strange that I can just send the  first iso transfer.
> When I inserts Sleep(300) after every usb_reap_async_nocancel() , the testing
> is past without errors.

This is mysterious part. I admit I do not know well the internal working
mechanism of the libusb-win32 isochronous API.

There are similar reports in the past.

I have the collection about libusb-win32 programs.
http://www.microchip.com/forums/fb.aspx?m=472078

In one of the thread, Martin initially also need the sleep() code
to get the program working. But in the end, it seems to me
that he do not need the sleep() code any more.
http://www.microchip.com/forums/tm.aspx?m=468280

Maybe Stephan Meyer can show us more light.

--

-- 
Xiaofan http://mcuee.blogspot.com

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo

Re: isochronous error: usb_reap: reaping request failed, win error: A device attached to the system is not functioning

2010/6/3 marshal.cd <marshal.cd <at> gmail.com>:
> Hi all,
> I am now working for adding libusb-win32 isochronous
> transfer into Qemu(a open source simulator acts like vmare).
> In Qemu,simulated os writes its usb TD into fake UCHI which is a
> component of Qemu.Fake UCHI will  transfer TD into USB packet,
> and finally passes these packets to function usb_host_handle_data().

Another suggestion, try to remove QEMU from the equation
first and use a normal Windows installation. After the normal
Windows installation to work, then you can try QEMU.

--

-- 
Xiaofan http://mcuee.blogspot.com

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo

Offtopic: Alternative for USB Forum (which is meanwhile only accessable by members) ?

Hello,

my question is a bit off topic:
During earlier USB development (non libusb-win32 question, general things) i 
often used the forum of usb.org.
When i looked correctly, meanwhile you need an USB membership to access the 
forum. For a hobbyist this is too expensive to get a membership.

Does someone know an alternative place for discussing general (technical) 
USB things (e.g. about content of USB descriptors, support of features by 
certain OS, ...) ?

Best regards,

     Martin

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo

Re: Offtopic: Alternative for USB Forum (which is meanwhile only accessable by members) ?

On Thu, Jun 3, 2010 at 8:59 PM, Maurer <capiman <at> online.de> wrote:

> my question is a bit off topic:
> During earlier USB development (non libusb-win32 question, general things) i
> often used the forum of usb.org.
> When i looked correctly, meanwhile you need an USB membership to access the
> forum. For a hobbyist this is too expensive to get a membership.

I believe the USB forum is down. That is why they prompt a password.
They lost all the data at one day. After a few days, you got the password
prompt page. I think they just closed the forum.

> Does someone know an alternative place for discussing general (technical)
> USB things (e.g. about content of USB descriptors, support of features by
> certain OS, ...) ?
>

I do not know if any other such forum exist.

Microchip USB forum is quite active but it is related to USB MCUs from
Microchip. Travis and I both use this forum.
http://www.microchip.com/forums/tt.aspx?forumid=102

Cygnal (Silabs) has a forum with a USB sub section as well.
The expert there Tsuneo now also frequents Microchip forum.
http://www.cygnal.org/scripts/Ultimate.cgi

Then there are many MCU forums (TI/Luminary, ST, NXP, etc)
which covers a bit of USB.

--

-- 
Xiaofan http://mcuee.blogspot.com

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo