libusb/ugen interrupt read question

Hans Petter Selasky hselasky at c2i.net
Sat Jul 22 07:08:45 UTC 2006


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


More information about the freebsd-usb mailing list