On Sun, Dec 21, 2003 at 01:40:05PM -0500, John Homppi wrote: > Some people have suggested that the ADU200 can be accessed > from user space thru the bulk endpoint routines in libusb. > > Here is what prevents an ADU200 from using libusb-0.1.7 > > from uhci_submit_bulk() function of uhci-hcd.c > > /* Can't have low speed bulk transfers */ > if (urb->dev->speed == USB_SPEED_LOW) > return -EINVAL; > > Section 5.8.4 on page 47 of the USB 1.1 specification states: > "Bulk transfers can be used only by full-speed devices." > > The ADU200 (and all PIC16C745 based boards) are **LOW** speed > devices and thus cannot be accessed through bulk endpoints. > > libusb-0.1.7 does NOT provide interrupt endpoint handling.
Yes, this is a problem. > devio.c does NOT provide ioctls for interrupt writes and reads. In fact, this is not entirely correct. While a simple interface like USBDEVFS_CONTROL or USBDEVFS_BULK is not provided, the more generic USBDEVFS_SUBMITURB ioctl can be used to work with interrupt endpoints (USBDEVFS_URB_TYPE_INTERRUPT). Even better, this interface is already available even in 2.4.x. > My Solution > ============ > I modified my version of libusb to add usb_interrupt_write and > usb_interrupt_read entry points. This required minor additions to > the underlying devio.c and message.c routines in the 2.6.0 kernel. > Preliminary testing shows that it works properly. Probably it would be better to use the existing ioctls instead of adding new ones - this way your program will not require to upgrade the kernel. > The change provides user-space access to the ADU200 and possibly to > other PIC16C745-based boards. (and hopefully any other USB > peripherals that use low-speed interrupt endpoint I/O without > the capability of bulk endpoints). > > Offer > ======= > If anyone wants to use this approach I can create patch files for > libusb and the 2.6.0 kernel routines that are affected.
pgp00000.pgp
Description: PGP signature
