Date: Sat, 22 Jul 2006 10:31:05 -0500 From: Robert Nilsson <robert@nilssonstudios.com> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: libusb/ugen interrupt read question Message-ID: <5AD64714-BC00-4870-9B39-96FBF078FEBC@nilssonstudios.com> In-Reply-To: <200607220908.45131.hselasky@c2i.net> References: <5439254.post@talk.nabble.com> <200607220908.45131.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
USBD_SHORT_XFER_OK is being set by libusb. The problem is that input data is queuing up in the background (from what I can tell). I have a buffer full of status messages. What I need is a way to stop the polling in the background from queuing the messages. With debugging on, ugen shows that it gets 32 characters and is in sync with my app until finally there is a 16 byte read. With usb debugging on I can see a constant stream of 16 byte reads on EP1 (see below), per the polling interval. For a mouse or keyboard this would be ideal, but in my case I only want the current reading. Rob. Jul 22 09:05:31 bsdtest kernel: usb_transfer_complete: pipe=0xc3c97900 xfer=0xc3c19400 status=0 actlen=16 Jul 22 09:05:31 bsdtest kernel: usb_transfer_complete: repeat=1 new head=0xc3c19400 Jul 22 09:05:31 bsdtest kernel: usb_transfer_complete: pipe=0xc3c97900 xfer=0xc3c19400 status=0 actlen=16 Jul 22 09:05:31 bsdtest kernel: usb_transfer_complete: repeat=1 new head=0xc3c19400 Jul 22 09:05:31 bsdtest kernel: usb_transfer_complete: pipe=0xc3c97900 xfer=0xc3c19400 status=0 actlen=16 Jul 22 09:05:31 bsdtest kernel: usb_transfer_complete: repeat=1 new head=0xc3c19400 Rob. On Jul 22, 2006, at 2:08 AM, Hans Petter Selasky wrote: > On Friday 21 July 2006 21:46, rnilsson wrote: >> I am working on porting owfs over to FreeBSD, and I've run into a >> strange >> issue when I'm trying to read the status of a device (DS2490 >> http://pdfserv.maxim-ic.com/en/ds/DS2490.pdf) on EP 1, an >> interrupt IN >> endpoint. >> >> One of the routines (a data request) writes data to ep 2, sends a >> control >> message that indicates a read from bus operation, and then gets >> status on >> EP 1, waiting for a register to reflect the proper number of bytes >> available for read. EP 1 can return up to 32 bytes of data, but >> will only >> provide 16 bytes unless there is an error condition. >> >> On Linux this works correctly. Each call to read EP1 will return >> when >> there is new data available from the device. On the FreeBSD side, >> from the >> time a control message is issued, status messages on EP1 start >> queuing up. >> Each read will return 32 bytes of data (or more if I make the buffer >> larger) until I exhaust the buffer - the only way I can get only >> the 16 >> expected. This can take anywhere from 5 to 50 loops reading EP1 to >> clear >> out the data, depending on the time between the control command >> and the >> read. >> >> I thought the USB device (INTERRUPT mode endpoint) was supposed to >> wait >> until data was requested to send it's information. This is >> running through >> libusb, and I've turned on debug in the ugen driver to make sure >> it really >> is interrupt driven. >> >> Is there some setting that causes this type of queing of interrupt >> data? >> I've seen other messages about the timeout not working with interrupt >> reads, so is this device related? >> Where can I go from here? > > The buffer you allocate should be 32 bytes long. Then you must use > the flag > USBD_SHORT_XFER_OK. Then you check the "xfer->actlen" after that > the transfer > has happened. Isn't this 16 bytes ? > > --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5AD64714-BC00-4870-9B39-96FBF078FEBC>