Alan Stern wrote:
You seem to be saying that the device doesn't
work right when the last packet also contains 512 bytes.
It looks that way. I suspect that the device USB implementation has all
sorts of quirks. I now have a USB capture from the Windows application
that communicates with the device. I can see that all messages sent to
the device are multiples of 512 bytes followed by a zero byte message.
The published protocol never mentions this and in fact would suggest
that the device should be capable to accept messages of any length up to
0xFFFF, since it uses the first two bytes to specify the length of the
message payload as an unsigned 16 bit quantity.
Will an USBDEVFS_BULK with
usbdevfs_bulktransfer.len = 0 have the same effect?
In principle it ought to. If the ioctl works then it will have the same
effect. However it might not work, since the usbdevfs code doesn't really
expect to see transfer lengths of 0. Try it and see.
Well, my test with 2.6.12-gentoo-r7 didn't end up being productive.
Attempting to send a bulk message of zero bytes results in: ehci_hcd
0000:00:1d.7: devpath 5 ep1out 3strikes. The usbfs ioctl() call returns
with -EPROTO "Protocol error"
It looks like I'll have to go down the path of submitting URBs so that I
can set the URB_ZERO_PACKET flag. The usbfs doco is a bit sketchy on
this, so perhaps I'll have to resort to writing a USB device driver for
this device after all.
Thanks,
Peter Urbanec
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
