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