Date: Fri, 21 Jul 2006 12:46:28 -0700 (PDT) From: rnilsson <robert@nilssonstudios.com> To: freebsd-usb@freebsd.org Subject: libusb/ugen interrupt read question Message-ID: <5439254.post@talk.nabble.com>
next in thread | raw e-mail | index | archive | help
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? Rob. -- View this message in context: http://www.nabble.com/libusb-ugen-interrupt-read-question-tf1981915.html#a5439254 Sent from the freebsd-usb forum at Nabble.com.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5439254.post>