Hi, On Sun, Feb 02, 2003 at 06:02:40AM -0600, Caylan Van Larson wrote: > I purchased a cash drawer with a USB interface. It came with windows > drivers but no official linux drivers. It works great under Win98, got a > nice utility that polls/fires the selenoid. > > > Windows Side: > I have used both SnoopyPro and sniffusb to gather the information going > across the wire. Here is some setup information for you:
You should get the same information in Linux in /proc/bus/usb/devices. > 00000150 0.78464240 <<<<<<< URB 3 coming back... > 00000151 0.78466160 -- URB_FUNCTION_SELECT_CONFIGURATION: > 00000152 0.78468480 ConfigurationDescriptor = 0xc1774740 (configure) > 00000153 0.78470720 ConfigurationDescriptor : bLength = >0x09 > 00000154 0.78472960 ConfigurationDescriptor : bDescriptorType = >0x02 > 00000155 0.78475200 ConfigurationDescriptor : wTotalLength = >0x0019 > 00000156 0.78477440 ConfigurationDescriptor : bNumInterfaces = >0x01 > 00000157 0.78479600 ConfigurationDescriptor : bConfigurationValue = >0x01 > 00000158 0.78481840 ConfigurationDescriptor : iConfiguration = >0x04 > 00000159 0.78484080 ConfigurationDescriptor : bmAttributes = >0x80 > 00000160 0.78486240 ConfigurationDescriptor : MaxPower = >0xf0 > 00000161 0.78488160 ConfigurationHandle = 0xc1885820 > 00000162 0.78490320 Interface[0]: Length = 0x00000024 > 00000163 0.78492240 Interface[0]: InterfaceNumber = 0x00 > 00000164 0.78494160 Interface[0]: AlternateSetting = 0x00 > 00000165 0.78496080 Interface[0]: Class = 0x00 > 00000166 0.78498000 Interface[0]: SubClass = 0x00 > 00000167 0.78499920 Interface[0]: Protocol = 0x00 > 00000168 0.78502160 Interface[0]: InterfaceHandle = 0xc178eed0 > 00000169 0.78504160 Interface[0]: NumberOfPipes = 0x00000001 > 00000170 0.78506640 Interface[0]: Pipes[0] : MaximumPacketSize = 0x0008 > 00000171 0.78508960 Interface[0]: Pipes[0] : EndpointAddress = 0x81 > 00000172 0.78511360 Interface[0]: Pipes[0] : Interval = 0x0a > 00000173 0.78514320 Interface[0]: Pipes[0] : PipeType = 0x03 >(UsbdPipeTypeInterrupt) > 00000174 0.78516880 Interface[0]: Pipes[0] : PipeHandle = >0xc178eee8 > 00000175 0.78519440 Interface[0]: Pipes[0] : MaxTransferSize = >0x00001000 > 00000176 0.78521840 Interface[0]: Pipes[0] : PipeFlags = 0x00 One interface (0x00), one interrupt endpoint. > 00000178 0.78523840 <<<<<<< URB 3 coming back... Huh, same URB coming back twice? > And here is some "action"... > > 00004061 27.05763600 >>>>>>> URB 78 going down... > 00004062 27.05765280 -- URB_FUNCTION_VENDOR_ENDPOINT: > 00004063 27.05768320 TransferFlags = 00000001 >(USBD_TRANSFER_DIRECTION_IN, ~USBD_SHORT_TRANSFER_OK) > 00004064 27.05769920 TransferBufferLength = 00000008 > 00004065 27.05771680 TransferBuffer = c1799c5c > 00004066 27.05773280 TransferBufferMDL = 00000000 > 00004067 27.05774880 UrbLink = 00000000 > 00004068 27.05776480 RequestTypeReservedBits = 00 > 00004069 27.05778000 Request = 02 > 00004070 27.05779680 Value = 00fb > 00004071 27.05781280 Index = 0000 > 00004072 27.05783760 UsbSnoop - IRP_MJ_INTERNAL_DEVICE_CONTROL, >IOCTL_INTERNAL_USB_SUBMIT_URB Same here: The same URB is tranferred twice? > 00004086 27.06202160 <<<<<<< URB 78 coming back... > 00004087 27.06203920 -- URB_FUNCTION_CONTROL_TRANSFER: > 00004088 27.06205760 PipeHandle = c1792e5c > 00004089 27.06208640 TransferFlags = 00000003 >(USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK) > 00004090 27.06210240 TransferBufferLength = 00000008 > 00004091 27.06212080 TransferBuffer = c1799c5c > 00004092 27.06213840 TransferBufferMDL = c1799c30 > 00004094 27.06215200 0000: > 00004095 27.06220800 42 00 fb 00 00 00 08 00 > 00004096 27.06222400 UrbLink = 00000000 > 00004097 27.06229760 SetupPacket : c2 02 fb 00 00 00 08 00 > This "action" is assumed (by me) to cause the drawer to open. But isn't this a read? I.e. the data "42 00 fb 00 00 00 08 00" is transferred from the device to the host? > >From my own bleeding eye balls I could see this difference: > > Something to do with opening the drawer: > 42 00 fb 00 00 00 08 00 > > Something to do with seeing the status of the drawer: > 42 00 fa 00 00 00 08 00 The data transfered looks similar to the setup packet. So e.g. the Value is repeated in the third byte of the data. > Now when I plug this puppy into my linux box i tail /var/log/messages and I see this: > > Feb 2 05:49:52 localhost kernel: hub.c: new USB device 00:1f.2-1, assigned address 6 > Feb 2 05:49:52 localhost kernel: usb.c: USB device 6 (vend/prod 0x6e5/0x8003) is >not claimed by any active driver. > Feb 2 05:49:55 localhost /etc/hotplug/usb.agent: Setup cashdrawer for USB product >6e5/8003/110 > Feb 2 05:49:55 localhost /etc/hotplug/usb.agent: Module setup cashdrawer for USB >product 6e5/8003/110 > > The "cashdrawer" script was done by editing /etc/hotplug/usb.usermap and > adding this row: > > # usb module match_flags idVendor idProduct bcdDevice_lo bcdDevice_hi >bDeviceClass bDeviceSubClass bDeviceProtocol bInterfaceClass bInterfaceSubClass >bInterfaceProtocol driver_info > cashdrawer 0x0003 0x06e5 0x8003 0x0000 0x0000 0x00 > 0x00 0x00 0x00 0x00 0x00 > 0x00000000 > > ... and adding this script for giggles: > /etc/hotplug/usb/cashdrawer > ... it does nothing. If you don't want to do something when the device is connected (setting permissions, starting an application, loading a kernel driver) you won't need hot-plug. > So now that I was armed with this information I thought reverse-eng would > be no sweat. How wrong I really was... :( > Linux software: > > I have tried the following packages with no luck: > Perl based: > USB-0.02 I guess that one uses libusb? I have only looked at the libusb documentation, not the perl module. And I don't know perl, so the comments may be bogus. > --SNIP > $my_device = USB::usb_open($blah2); Are you sure, that $blah2 is the correct device (vendor+product ids match)? > $set_interface_results = >USB::usb_claim_interface($my_device, "0x00"); "0x00" looks like a string for me, not a number. But as I said, I don't know perl. > $reset_endpoint = USB::usb_resetep($my_device, 129); Be careful. resetep just resets the toggle on the host. It shouldn't be necessary. > $set_config_results = USB::usb_set_configuration($my_device, >1); Why do you want to set the configuration after you claimed the interface? > $longshot = USB::usb_control_msg($my_device, 00, 02, 251, >0000, "c1799c5c", 8, 100000); The "c1799c5c" should be a pointer to the buffer for the data you receive. That hex value is just the address Windows used. > $close = USB::usb_close($my_device); > --SNAP > > I could open (as in virtually) the device and close the device. But when > it came to claiming an interface it would always say "Device or resource > busy" or "Broken pipe." That may be because of the "0x00". > libusb based: > usb-robot-0.2.0 I think it uses the format of an old version of sniffusb so it won't work with the newer versions. > I used the output from the logs on the windows machine and I had to > heavily hack the perl scripts but never got anywhere. > > Here is a sample session: > > --SNIP > [root@localhost usb-robot-0.2.0]# ./usb-robot-slave product=0x08003 vendor=0x06e5 > ./usb-robot-slave: starting usb-robot version 0.2.0 > (c) 2000, 2001 John Fremlin > Licensed under the GNU Public License version 2, see file COPYING. > You didn't pay me for this program. You have no rights. > doing bus scan for: > idVendor 0x6e5 > idProduct 0x8003 > found bus 001 > scanning bus 001 > device 001 on bus 001 does not match > found device 006 on bus 001 (idVendor 0x6e5 idProduct 0x8003) > opening device 006 on bus 001 > OK: id=0 > Type help and press return for a list of commands > usb-robot> config 1 > OK: id=1 > usb-robot> interface 0 > OK: id=2 Looks ok. > usb-robot> transfer type=control size=8 ep=0x81 dir=out requesttype=0 request=2 >value=251 index=0 > For some reason it just hangs after I type the last command. Sending a control message to an interrupt endpoint? Looks suspicious. The message should be sent to the control endpoint. > Now my final try was with /usr/src/linux/drivers/usb/usb-skel.c > That was a joke, just substituted skel->cashdrawer and then tried to do a > gcc usb-cashdrawer.c and never looked back. At least if you want to use the interrupt endpoint, that's the right approach. But for just sending control messages, try libusb. If you know C better than perl, use libusb directly instead of the perl module. Bye, Henning ------------------------------------------------------- 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
