Tricky USB device.

[Bernd Walter]

On Fri, Apr 08, 2005 at 06:12:33PM -0400, David Gilbert wrote:
> Bernd> Has this device multiple interfaces?  e.g. one HID and another
> Bernd> as described.  I often thought about getting ugen working at
> Bernd> interface level too.
> 
> Here's the output of udesc_dump on it.  Right now, using the current
> version of libusb (not the version from ports), I can use
> usb_interrupt_write(dev, 1, "MK255", 5, 0) to send data to it --- and
> the data is sent --- at least lights on the USB hub flash.  If I
> replace '1' with anything else, it doesn't accept it.  However, it
> doesn't seem to have opened the relays.

Yes - you must use 1 - there is only one out-endpoint.
0x81 is for receiving data and endpoint 0 is the mandandory control
endpoint.
Interrupt Endpoints are not variable in size.
Both interrupt endpoints are 8 Bytes, so you must read and write exact
8 Bytes per transfer - 5 shouldn't work for USB compliant devices.

Btw: you shouldn't use 0 as timeout value - this is OK under FreeBSD
for having no timeout, but Linux understands it as 0 seconds and things
fail.
Having a timeout isn't bad anyway - you can still restart the transfer
if you want.
If portability is not an issue you should take Maksim's advice and
directly use ugen* access.

> I'm also not entirely clear how/when to use usb_interrupt_read()
> ... as many of the commands listed in the manual return data, but
> usb_inerrupt_write() doesn't seem to allow for data to be returned,
> but following usb_interrupt_write(), the read will hang.

Depends on the device's firmware.
I wouldn't be surprised if the whole device just hangs after receiving
bogus data - it seems to be broken in many points.
But it may block if the device has nothing to send.
An easy way to check out is using tools like usbdevs -v and see if
it hangs when accessing this device.

> ... so I'm somewhat at a loss, but I also can't find my multitester
> ... and will be fetching another one tonight.
> 
> I'd appreciate any random knowledge anyone can summon on this topic.
> 
> Standard Device Descriptor:
>   bLength            18
>   bDescriptorType    01
>   bcdUSB             0110
>   bDeviceClass       00
>   bDeviceSubClass    00
>   bDeviceProtocol    00
>   bMaxPacketSize     8
>   idVendor           0a07
>   idProduct          00d0
>   bcdDevice          0000
>   iManufacturer      1
>   iProduct           2
>   iSerialNumber      3
>   bNumConfigurations 1
> 
> Configuration 0:
> 	Standard Configuration Descriptor:
> 	  bLength             9
> 	  bDescriptorType     02
> 	  wTotalLength        41
> 	  bNumInterface       1
> 	  bConfigurationValue 1
> 	  iConfiguration      4
> 	  bmAttributes        a0 (remote-wakeup)
> 	  bMaxPower           100 (200 mA)
> 
> 	Standard Interface Descriptor:
> 	  bLength            9
> 	  bDescriptorType    04
> 	  bInterfaceNumber   0
> 	  bAlternateSetting  0
> 	  bNumEndpoints      2
> 	  bInterfaceClass    03
> 	  bInterfaceSubClass 00
> 	  bInterfaceProtocol 00
> 	  iInterface         5
> 
> 		HID Descriptor:
> 		  bLength           9
> 		  bDescriptorType   21
> 		  bcdHID            0100
> 		  bCountryCode      00
> 		  bNumDescriptors   1
> 		  bDescriptorType   22
> 		  wDescriptorLength 102
> 
> 
> 	Standard Endpoint Descriptor:
> 	  bLength          7
> 	  bDescriptorType  05
> 	  bEndpointAddress 81 (in)
> 	  bmAttributes     03 (Interrupt)
> 	  wMaxPacketSize   8
> 	  bInterval        10
> 
> 	Standard Endpoint Descriptor:
> 	  bLength          7
> 	  bDescriptorType  05
> 	  bEndpointAddress 01 (out)
> 	  bmAttributes     03 (Interrupt)
> 	  wMaxPacketSize   8
> 	  bInterval        10

OK - exactly one interface, which claims to be HID.
I'm not familar with HID to say if it really is HID compatible.
I personally would say that they took some sample code and just hacked
it without really knowing what they do.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd at bwct.de                                  info at bwct.de