|David Gilbert||Apr 8, 2005 9:40 am|
|Maksim Yevmenkin||Apr 8, 2005 9:48 am|
|David Gilbert||Apr 8, 2005 9:56 am|
|Maksim Yevmenkin||Apr 8, 2005 10:10 am|
|David Gilbert||Apr 8, 2005 10:16 am|
|Bernd Walter||Apr 8, 2005 12:05 pm|
|David Gilbert||Apr 8, 2005 3:12 pm|
|Maksim Yevmenkin||Apr 8, 2005 3:33 pm|
|Bernd Walter||Apr 8, 2005 4:12 pm|
|Bernd Walter||Apr 8, 2005 4:33 pm|
|Maksim Yevmenkin||Apr 8, 2005 4:47 pm|
|Bernd Walter||Apr 8, 2005 5:31 pm|
|Julian Elischer||Apr 8, 2005 6:06 pm|
|Bernd Walter||Apr 8, 2005 9:02 pm|
|David Gilbert||Apr 9, 2005 2:05 pm|
|Bernd Walter||Apr 9, 2005 2:24 pm|
|David Gilbert||Apr 9, 2005 2:48 pm|
|Bernd Walter||Apr 9, 2005 2:57 pm|
|David Gilbert||Apr 9, 2005 7:39 pm|
|Subject:||Tricky USB device.|
|From:||Bernd Walter (tic...@cicely12.cicely.de)|
|Date:||Apr 8, 2005 5:31:55 pm|
On Fri, Apr 08, 2005 at 04:47:43PM -0700, Maksim Yevmenkin wrote:
Bernd Walter wrote:
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.
hmmm... i was always confused about bMaxPacketSize. i was thinking that it limits the size of one usb transaction, and it could take several usb transactions to transfer one data packet.
It is a bit more complicated. For control endpoints packets transfers that are bigger than one packet can be transfered using multiple packets using a shortened last packet, which can be even of 0 length if the transfer exactly fits in packets. For bulk endpoints things can be handled specific to the protocol requirements - e.g. most serials don't track transfer borders. We have interrupt endpoints - you are right smaller than max packets are allowed - just checked the specs. The remaining is the same as for bulk endpoints, but interrupt endpoint are different in bus time calculations.
for example i have a bluetooth usb dongle that has
Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 81 (in) bmAttributes 03 (Interruput) wMaxPacketSize 16 bInterval 1
and i certanly can receive data packets from this endpoint that are more (and less) then 16 bytes in size. so, i would guess (and i might be wrong) that it is ok to send/receive data packets that are not equal to bMaxPacketSize in size.
As corrected above - you are really allowed to have smaller packets. But you can't have larger ones - however you can transfer multiple packets in one transaction, but this is not optimal speedwise as interrupt endpoints are laid out in a specific timeline. bInterval=1 means one packet per 1ms will be transfered and not more. Doing a transfer with e.g. 2 packets will take 1ms longer - even if the bus is idle in the meantime. This is because interrupt endpoints get garantied bus time.