On Sun, Feb 09, 2003 at 01:24:55PM -0500, John Homppi wrote: > **** > An aside for Jeff: > Please indicate whether the following analysis matches your research > regarding the Evolution Robots platform. > ****
Your analysis follows mine exactly. > It is important to differentiate the endpoints in this discussion. > Control in/out endpoint - always assumed present > Interrupt in endpoint - for data inbound to the PC > Interrupt out endpoint - for data outbound to the peripheral device > > The interrupt out endpoint was NOT present in the USB 1.0 spec. It was > a new concept added in the USB 1.1 spec. My conclusion, after looking over the hiddev code, is that it complies with USB 1.0, and did not seem to address the interrupt OUT features of USB 1.1. I originally e-mailed Brad, asking about interrupt OUT support in the kernel, and he suggested that I pose the question to usb-devel. I'm very glad that you're taking a look at our problem, Brad! > The ADU device uses control endpoints for enumeration only. This is consistent with our device. > The ADU board transmits all inbound data via the interrupt in endpoint. My current driver for our IR sensor peripheral uses the HIDDEV interface. It performs read() on /dev/usb/hiddevX, which results in interrupt transfers of all inbound data. Kudos to Mr. Stewart and Mr. Pavlik for making this very simple! > The ADU board receives all outbound data via the interrupt out endpoint. The Evolution Robotics Gripper and IR sensor pack also use interrupt endpoints for outbound data. I'm currently posing questions to the LegoUSB tower guys (http://legousb.sourceforge.net/legousbtower/index.shtml), who claim, on their website, that development of a user-space daemon for their hardware is currently stalled due to lack of support of interrupt out transfers. I'm wondering if extending the HIDDEV interface, as John has proposed, will satisfy their requirements. > We need the ability to write data to the interrupt out endpoint > of a hid class device (not just to the control out endpoint). > This is an extension of the functionality already in place, not a > replacement of any functionality. All of the normal enumeration, > control messages and reports must continue to operate. I completely agree. > Seeing as the hiddev_read function reads data from the interrupt > endpoint, I thought the logical place to write to the interrupt > endpoint would be "hiddev_write". The current hiddev_write > function returns -EINVAL so changing it should not break anything. > The HIDIOCSREPORT should continue to communicate via > the control endpoint, while the hiddev_write uses the interrupt > endpoint. This would be very convenient! > The "data" is an opaque string of bytes, it is neither a > control message nor a report as defined in the USB spec. > It is just a data-load to be delivered to the device. (Similar to > the buffer in the existing hiddev_read.) > > > NOTE: The ADU board uses a Microchip PIC processor that has USB > support built in as a combination of firmware and silicon > circuitry. I would really like to see a generic solution so that > all similarly designed HID class devices could use their > interrupt out endpoints. (ie. the Ontrak ADU board, the Evolution > Robot, the Labjack board, etcetera). One of the nicest features of the Microchip PIC-USB is that it is a very inexpensive solution for a hobbyist who is interested in interfacing hardware to their PC through the ubiquitous USB interface. I'm considering using it in my own personal projects, and would certainly rather develop on the Linux platform. Gathering from previous e-mail, it appears that certain force-feedback joysticks also use the interrupt OUT transfers, and I think that a generalized solution would be preferable to development of special kernel modules for each type of force-feedback joystick? Thank you all for your attention concerning this issue. Regards, Jeff -- Jeffrey Baitis - Associate Software Engineer Evolution Robotics, Inc. 130 West Union Street Pasadena CA 91103 tel: 626.535.2776 | fax: 626.535.2777 | [EMAIL PROTECTED] ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
