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 _______________________________________________ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"