From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 9 00:32:14 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90AC216A4CE for ; Sat, 9 Apr 2005 00:32:14 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0B9643D2F for ; Sat, 9 Apr 2005 00:32:13 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0)j390W7np018031 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 9 Apr 2005 02:32:09 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j390VJhs084403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Apr 2005 02:31:19 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j390VIwQ007107; Sat, 9 Apr 2005 02:31:18 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j390VIRn007106; Sat, 9 Apr 2005 02:31:18 +0200 (CEST) (envelope-from ticso) Date: Sat, 9 Apr 2005 02:31:18 +0200 From: Bernd Walter To: Maksim Yevmenkin Message-ID: <20050409003117.GX96690@cicely12.cicely.de> References: <16982.46075.115518.130213@canoe.dclg.ca> <4256B5EB.9080506@savvis.net> <16982.47024.135663.645297@canoe.dclg.ca> <20050408190514.GS96690@cicely12.cicely.de> <16983.465.572693.73195@canoe.dclg.ca> <20050408233301.GW96690@cicely12.cicely.de> <4257181F.1040904@savvis.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4257181F.1040904@savvis.net> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=no version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0001] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de cc: freebsd-hackers@freebsd.org cc: ticso@cicely.de cc: David Gilbert Subject: Re: Tricky USB device. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2005 00:32:14 -0000 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. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de