The question I have is how to take the data from the URBs shown below, and
turn that into usb_control_msg() call.
How does the VENDOR_DEVICE and CONTROL_TRANSFER URBs get generated in libusb, or some other protocol?
How do you send the setup packet of the VENDOR_DEVICE?
If someone could translate the URBs below, or point to an example of such a conversion, I think we can start doing bulk read and writes. Any pointers/hints appreciated!
-Doug
Im sort of in the same position, so I'll add what I've come up with and maybe it will be so wrong that someone will want to straighten it all out before I go destroying my usb device or something.
ret = usb_control_msg( dev_handle, USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_DEVICE, 0x81, 0, 0, data, 4096, 5000 );
This is just one that I have been playing with. The CONTROL_TRANSFER in usbSnoopy is just indicating a control transfer is taking place. the bmRequestType is a bitmap of OR'd values. USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_DEVICE corroborates the bmRequestType of 00 in your first example below.
but, heres where things get murky. Does data hold info I send TO the device? Or FROM? Or does it automagically take data when a transfer buffer is needed, and fill up when we are supposed to receive a transfer buffer? (based on the value of USB_DIR_IN/OUT? or maybe wValue?)
If this is all too basic, I apologize. but ive been having quite a time just trying to get the basics down. i have a bit of information I got from googling for usb_control_msg..hopefully enough to shed some light when i can get time to sift through it.
Matthew Dharm <[EMAIL PROTECTED]> said:
I'm no USB-Snoopy expert, but I think you may only have 139 packets.
They're not really 'packets' -- they're URBs (USB Request Blocks). Each URB specifies a transfer (to or from the device) of a certain type (control, bulk, interrupt, or iso).
What I imagine you're seeing is that the 'robot' driver is sending a request. You see is going 'down' as the request goes out to the USB interface hardware. That hardware performs the requested exchange (in/out of some type), and the the URB comes back ('up') to the driver -- the driver can now examine the status of the transfer and look at the data in the buffer (if appropriate).
Matt
On Sun, Jan 18, 2004 at 11:24:28PM -0000, [EMAIL PROTECTED] wrote:
Ok, thanks to this group I have been snoopying a USB-based robot. I see that when I plug the USB in under Windows with the proprietary device handler in place, 278 packets are sent back and forth (139 ups + 139 downs).
I suspect that there are some config data being set in that first 139 packets. I have been able to do bulk reads and writes using libusb, but I'm not getting the correct data back (on the Input endpoint).
Here is a bit of the code to read/write under Linux:
printf("Reading...\n"); retval = usb_bulk_read(udev, 0x81, buff, 64, 50); // printf("Retval = %d\n", retval); print_buffer( buff, retval);
printf("Writing...\n"); retval = usb_bulk_write(udev, 0x02, buffer, 4, 50); // timeout printf("Retval = %d\n", retval);
That works, except for not getting back the same values that we get under snoopy/Windows.
I think if I could figure out how to convert a VENDOR_DEVICE/CONTROL_TRANSFER pair of packets (see below) into C code, then I can replicate the 139 packets. Am I right to guess that I would do that with the usb_control_msg() function?
If so, maybe someone could help be turn sequences 140 and 141 (below) into such commands.
Any help would be much appreciated!
-Doug
---------------------------------------------------------------------------- 140 out down n/a 27.780 VENDOR_DEVICE - URB Header (length: 80) SequenceNumber: 140 Function: 0017 (VENDOR_DEVICE) PipeHandle: 82696d40
SetupPacket: 0000: 00 00 00 00 00 00 00 00 bmRequestType: 00 DIR: Host-To-Device TYPE: Standard RECIPIENT: Device bRequest: 00 GET_STATUS
No TransferBuffer ---------------------------------------------------------------------------- 140 out up n/a 27.780 CONTROL_TRANSFER - 0x00000000 URB Header (length: 80) SequenceNumber: 140 Function: 0008 (CONTROL_TRANSFER) PipeHandle: 82696d40
SetupPacket: 0000: 40 00 00 00 00 00 00 00 bmRequestType: 40 DIR: Host-To-Device TYPE: Vendor RECIPIENT: Device bRequest: 00
No TransferBuffer ---------------------------------------------------------------------------- 141 in down n/a 27.800 VENDOR_DEVICE - URB Header (length: 80) SequenceNumber: 141 Function: 0017 (VENDOR_DEVICE) PipeHandle: 82696d40
SetupPacket: 0000: 00 05 00 00 00 00 00 00 bmRequestType: 00 DIR: Host-To-Device TYPE: Standard RECIPIENT: Device bRequest: 05 SET_ADDRESS
No TransferBuffer ---------------------------------------------------------------------------- 141 in up n/a 27.800 CONTROL_TRANSFER 01 60 0x00000000 URB Header (length: 80) SequenceNumber: 141 Function: 0008 (CONTROL_TRANSFER) PipeHandle: 82696d40
SetupPacket: 0000: c0 05 00 00 00 00 02 00 bmRequestType: c0 DIR: Device-To-Host TYPE: Vendor RECIPIENT: Device bRequest: 05
TransferBuffer: 0x00000002 (2) length 0000: 01 60 ----------------------------------------------------------------------------
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
--
Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver
You suck Stef.
-- Greg User Friendly, 11/29/97
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
