Xiaofan Chen | 1 Jun 16:50 2010
Picon

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.

(Continue reading)

晓夏 崔 | 2 Jun 16:08 2010
Picon

Re: help

hello:
 
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 ? 

Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up now.
------------------------------------------------------------------------------

_______________________________________________
Libusb-win32-devel mailing list
Libusb-win32-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Xiaofan Chen | 3 Jun 07:25 2010
Picon

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
marshal.cd | 3 Jun 07:59 2010
Picon

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

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().
Setting the usb devices into a proper state is the job of simulated os,Qemu just initializes the usb interfaces of usb device by standard libusb-win32 steps:
    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);
    }
Once the usb interfaces is initialized,Qemu's responsibility is transferring USB request to libusb-win32.
Here is the key functions which plays roles of transferring USB request:
static int usb_host_handle_data(USBDevice *dev, USBPacket *p)
{
USBHostDevice *s = (USBHostDevice *)dev;
int ret = 0;
uint8_t devep = p->devep;
int pid = p->pid;
uint8_t *data = p->data;
int len = p->len;
int transmitted = 0;
void *context1 = NULL;
    /* XXX: optimize and handle all data types by looking at the
       config descriptor */
    if (pid == USB_TOKEN_IN)
        devep |= 0x80;
/*************************************************
 isochronous transfer
**********************************************/
#define TD_CTRL_IOS     (1 << 25)
/*check if this td is isochronous td*/
if(p->ctrl & TD_CTRL_IOS){
if(devep| 0x80){
printf("opt is read\n");
}
else{
printf("opt is write\n");
}
do{
/*the simulated os has devided usb request into packets whose size is no larger than wMaxPacketSize,
so we used len of this packet as parameter packetsize*/
  usb_isochronous_setup_async(s->udev,&context1,devep,len);
     ret = usb_submit_async(context1, data, len);
     if(ret < 0)
       {
         transmitted = ret;
        break;
       }
     ret = usb_reap_async_nocancel(context1, 50);
     if(ret < 0)
       {
       if(ret==-5){
transmitted = len;
printf("error in iso ignore it \n");
        
       }
else
{
         transmitted = ret;
        
}
       }
}while(0)
  
   usb_free_async(&context1);
   return transmitted;
  
}
}
It seems that the isochronous packets can't be sent by libusb-win32.
The libusb-win32 report errors(capture form debugview):
/*In the beginning, libusb-win32 succeeds in transferring one isochronous packet. 
However it fails subsequently*/
00003503 11295.52636719 LIBUSB-DRIVER - transfer(): isochronous transfer
00003504 11295.52636719 LIBUSB-DRIVER - transfer(): direction out
00003505 11295.52636719 LIBUSB-DRIVER - transfer(): endpoint 0x06
00003506 11295.52636719 LIBUSB-DRIVER - transfer(): packet_size 0xc0
00003507 11295.52636719 LIBUSB-DRIVER - transfer(): size 192
00003508 11295.52636719 LIBUSB-DRIVER - transfer(): sequence 2530
00003509 11295.52636719  
00003510 11295.53222656 LIBUSB-DRIVER - transfer_complete(): sequence 2530: 192 bytes transmitted
00003511 11295.53906250  
00003512 11295.53906250  
00003513 11295.53906250 LIBUSB-DRIVER - transfer(): isochronous transfer
00003514 11295.53906250 LIBUSB-DRIVER - transfer(): direction out
00003515 11295.53906250 LIBUSB-DRIVER - transfer(): endpoint 0x06
00003516 11295.53906250 LIBUSB-DRIVER - transfer(): packet_size 0xc0
00003517 11295.53906250 LIBUSB-DRIVER - transfer(): size 192
00003518 11295.53906250 LIBUSB-DRIVER - transfer(): sequence 2531
00003519 11295.53906250  
00003520 11295.53906250 LIBUSB-DRIVER - transfer_complete(): sequence 2531: transfer failed: status: 0xc0000001, urb-status: 0xc0000b00
00003521 11295.54589844 [6052] LIBUSB_DLL: error: usb_reap: reaping request failed, win error: A device attached to the system is not functioning. 
00003522 11295.54589844 [6052] 
00003523 11295.54785156  
00003524 11295.54785156  
00003525 11295.54785156 LIBUSB-DRIVER - transfer(): isochronous transfer
00003526 11295.54785156 LIBUSB-DRIVER - transfer(): direction out
00003527 11295.54785156 LIBUSB-DRIVER - transfer(): endpoint 0x06
00003528 11295.54785156 LIBUSB-DRIVER - transfer(): packet_size 0xc0
00003529 11295.54785156 LIBUSB-DRIVER - transfer(): size 192
00003530 11295.54785156 LIBUSB-DRIVER - transfer(): sequence 2532
00003531 11295.54785156  
00003532 11295.54785156 LIBUSB-DRIVER - transfer_complete(): sequence 2532: transfer failed: status: 0xc0000001, urb-status: 0xc0000b00
00003533 11295.55859375  
00003534 11295.55859375  
00003535 11295.55859375 LIBUSB-DRIVER - transfer(): isochronous transfer
00003536 11295.55859375 LIBUSB-DRIVER - transfer(): direction out
00003537 11295.55859375 LIBUSB-DRIVER - transfer(): endpoint 0x06
00003538 11295.55859375 LIBUSB-DRIVER - transfer(): packet_size 0xc0
00003539 11295.55859375 LIBUSB-DRIVER - transfer(): size 192
00003540 11295.55859375 LIBUSB-DRIVER - transfer(): sequence 2533
00003541 11295.55859375  
00003542 11295.55859375 LIBUSB-DRIVER - transfer_complete(): sequence 2533: transfer failed: status: 0xc0000001, urb-status: 0xc0000b00
00003543 11295.56152344 [6052] LIBUSB_DLL: error: usb_reap: reaping request failed, win error: A device attached to the system is not functioning. 
00003544 11295.56152344 [6052] 
00003545 11295.56738281  
00003546 11295.56738281  
00003547 11295.56738281 LIBUSB-DRIVER - transfer(): isochronous transfer
00003548 11295.56738281 LIBUSB-DRIVER - transfer(): direction out
00003549 11295.56738281 LIBUSB-DRIVER - transfer(): endpoint 0x06
00003550 11295.56738281 LIBUSB-DRIVER - transfer(): packet_size 0xc0
00003551 11295.56738281 LIBUSB-DRIVER - transfer(): size 192
00003552 11295.56738281 LIBUSB-DRIVER - transfer(): sequence 2534
00003553 11295.56738281  
00003554 11295.56738281 LIBUSB-DRIVER - transfer_complete(): sequence 2534: transfer failed: status: 0xc0000001, urb-status: 0xc0000b00
00003555 11295.59765625 [6052] LIBUSB_DLL: error: usb_reap: reaping request failed, win error: A device attached to the system is not functioning. 
00003556 11295.59765625 [6052] 
00003557 11295.60156250  
00003558 11295.60156250  
00003559 11295.60156250 LIBUSB-DRIVER - transfer(): isochronous transfer
00003560 11295.60156250 LIBUSB-DRIVER - transfer(): direction out
00003561 11295.60156250 LIBUSB-DRIVER - transfer(): endpoint 0x06
00003562 11295.60156250 LIBUSB-DRIVER - transfer(): packet_size 0xc0
00003563 11295.60156250 LIBUSB-DRIVER - transfer(): size 192
00003564 11295.60156250 LIBUSB-DRIVER - transfer(): sequence 2535
00003565 11295.60156250  
00003566 11295.60156250 LIBUSB-DRIVER - transfer_complete(): sequence 2535: transfer failed: status: 0xc0000001, urb-status: 0xc0000b00
00003567 11295.61718750 [6052] LIBUSB_DLL: error: usb_reap: reaping request failed, win error: A device attached to the system is not functioning. 
00003568 11295.61718750 [6052] 
 
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
    bInterfaceNumber:   1
    bAlternateSetting:  0
    bNumEndpoints:      0
    bInterfaceClass:    1
    bInterfaceSubClass: 2
    bInterfaceProtocol: 0
    iInterface:         0
    bInterfaceNumber:   1
    bAlternateSetting:  1
    bNumEndpoints:      1
    bInterfaceClass:    1
    bInterfaceSubClass: 2
    bInterfaceProtocol: 0
    iInterface:         0
      bEndpointAddress: 06h
      bmAttributes:     09h
      wMaxPacketSize:   192
      bInterval:        1
      bRefresh:         0
      bSynchAddress:    0
 
  Any suggestions will be appreciated.
Best regards,
Marshal_CD
 
 
2010-06-03
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
_______________________________________________
Libusb-win32-devel mailing list
Libusb-win32-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Xiaofan Chen | 3 Jun 09:37 2010
Picon

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
marshal.cd | 3 Jun 11:23 2010
Picon

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
Xiaofan Chen | 3 Jun 12:14 2010
Picon

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
Xiaofan Chen | 3 Jun 12:16 2010
Picon

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
Maurer | 3 Jun 14:59 2010
Picon

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
Xiaofan Chen | 3 Jun 15:16 2010
Picon

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

Gmane