driver help with libusb
 

I can't believe that a usb controlled rocket launcher hasn't fallen into the hands of a programmer before. So I'm determined to make this work. I have a usb data sniffer and got a bunch of data for each of the rocket launcher's movements, but don't know how to translate that into libusb calls.

I see the usb_control_msg function in libusb and I think I can work that out, but I don't know what the "Class-Specific Request" stuff is... and it looks important. Can someone help me interpret these?

Here is the data I gathered for moving the launcher arm up. Under the "Class-specific request" section where the 8 bytes of data have a 1 for the first byte signify the up movement. down is 2, right is 4 and left is 8.

138321: Class-Specific Request (DOWN), 17.12.2006 22:15:36.6081536 +0.0
Destination: Inrterface, Index 0
Reserved Bits: 34
Request: 0x9
Value: 0x200
Send 0x8 bytes to the device

00 00 00 00 00 00 00 00 ........

138322: Control Transfer (UP), 17.12.2006 22:15:36.6081536 +0.0
Pipe Handle: 0xff8e65c8

00 00 00 00 00 00 00 00 ........
Setup Packet
21 09 00 02 00 00 08 00 !.......
Recipient: Inrterface
Request Type: Class
Direction: Host->Device
Request: 0x9 (Unknown)
Value: 0x200
Index: 0x0
Length: 0x8

138323: Class-Specific Request (DOWN), 17.12.2006 22:15:36.6081536 +0.0
Destination: Inrterface, Index 0
Reserved Bits: 34
Request: 0x9
Value: 0x200
Send 0x8 bytes to the device

01 00 00 00 00 00 00 00 ........

138324: Control Transfer (UP), 17.12.2006 22:15:36.6081536 +0.0
Pipe Handle: 0xff8e65c8

01 00 00 00 00 00 00 00 ........
Setup Packet
21 09 00 02 00 00 08 00 !.......
Recipient: Inrterface
Request Type: Class
Direction: Host->Device
Request: 0x9 (Unknown)
Value: 0x200
Index: 0x0
Length: 0x8

138329: Class-Specific Request (DOWN), 17.12.2006 22:15:36.6482112 +0.0100144
Destination: Inrterface, Index 0
Reserved Bits: 34
Request: 0x9
Value: 0x200
Send 0x8 bytes to the device

00 00 00 00 00 00 00 00 ........

138330: Control Transfer (UP), 17.12.2006 22:15:36.6482112 +0.0
Pipe Handle: 0xff8e65c8

00 00 00 00 00 00 00 00 ........
Setup Packet
21 09 00 02 00 00 08 00 !.......
Recipient: Inrterface
Request Type: Class
Direction: Host->Device
Request: 0x9 (Unknown)
Value: 0x200
Index: 0x0
Length: 0x8

Thanks so much,
Jim

Have you considered this for getting more help on this subject ;)

allowing links

okay...now that i can use links in my post

http://www.beyondlogic.org/usbnutshell/usb1.htm

the above link has an overview of the USB standard which may be of use to you. I have been working on the same project for a few hours and am finding that my only block at the moment is that the documentation for libusb is so terrible that it seems as though randomly hitting buttons until something works would be almost as effective.

okay...i can control the thing now. let me know if you want the code.

I'm sure that would help. What device are you trying to make work?

I thought about scraping the libusb program and going for a device driver and noticed that the kernel functions were pretty much the same. I was able to find several documents on creating usb device drivers. This also lets me keep track of the device so I don't have to reset it before every use to put it in a "known" state and position... We are talking about nerf-like rockets... I need precision. :)

If I had the libusb program, I'm sure I could convert it to a driver.

Thanks for your help. Let me know how I can peek at the code.

Jim

I'll post the source code and an explanation this afternoon. Look for it at

http://www.amctrl.com/rocketlauncher.html

and by afternoon i mean before lunch. its up now

Wouldn't you know I didn't bring my rocket launcher home... I have to wait until tomorrow to try it out. I'll be shooting my co-workers yet!

I think my problem might have been a bad vendor ID. I read it 3 times from that stupid sniffer, but it might have been pointed at a device between us. I also had the index value wrong for the first and third packet. Otherwise I think the rest looks pretty much the same. Well, I won't be getting my work done tomorrow. :D

Thanks for your help.

Jim

ok, it doesn't work for me. It fails when trying to claim the interface. Do you have any ideas? Do I need to release the device from a driver? I tried the libusb call to usb_detach_kernel_driver_np but it fails as well.

I also noticed that my vendor id was a hex 1941 which is the same as your decimal 6465... so the only difference was the index value. That and I can't claim the interface.

Do you have the device on a USB hub?

I have read numerous reports that the device does not like to work unless it is physically plugged into the ports on the back of the machine. Even ports on the front tend to be problematic. There doesnt seem to be a solution to that problem.

If not, then I have no idea. My understanding of USB is poor at best and the first time I tried to claim the interface I had no issues so I moved onto other things. I'll look into it bit more.

On a final note, I have always been running the program as root. This shouldn't affect anything, though, as the whole point of libusb is to allow non-root users tha ability to use usb devices.

-edit-> what error do you get when claiming the interface?

ok, I have success... sort of. It does work as root when plugged into the machine itself. As a regular user I get a -1 returned from the call to claim the interface. I'm still trying to figure out where the "-EBUSY" and "-ENOMEM" that libusb's api talk about are defined.

I guess if I'm just going to turn around and do a kernel driver for this, it might just be a moot issue. This is cool though.

Jim

well...the root hub thing seems to be a manufacturing flaw, so there isnt really anything to about that.

My research (e.g. running strerror() on +1) indicaties that a return of -1 means that there is a permissions error. I don't know which devices are USB, but I would look there and make sure that non-root users have usb read and write permissions.

-ADDENDUM-

if you have usbfs enabled in your kernel, you can set permissions in /proc/bus/usb/

I noticed (at least on Fedora Core 6) that when I plug in the rocket launcher the kernel assigns a driver to it. I have to release the kernel driver with the usb_detach_kernel_driver_np function.

Regardless for whatever reason it assigns the user/group for usb devices to root/root with a mode of 644 and have not had the chance to research how to make it respect my authority. I assume this is the reason root needs to be the one to claim the interface. I hate it when my computer tries to think for me. This is why I don't like Windows.

I got my program working, mostly. I was just going for movement first and will work on firing (charging seperate from firing) and a reset function to put it into a known position. Then I'll play more with a kernel driver.

I noticed that the control messages with the index of 1 and the all-0 message is not needed and actually errors, so I changed mine to send nothing to the device until you tell it to and then sends all 0 message, the command, then all 0 message all with an index of 0.

Very cool, thanks again for your help.

Jim

can not claim the usb device
 

hi there!
i'm stucked too with the claiming of the device - i receive -16 as return code - any ideas?
it's the same with user or root permissions.

many thanks!

-> update: was able to implement the detach-thingy and was finally able to claim the device as root. but now, the movements & everything is not working...

What is it doing?

All messages have this list of parameters (take note of the buffer var) :
device handle, 0x21, 0x9, 0x200, 0, <buffer>, 8, 1000

The buffer var is the command portion. All buffers have 8 bytes.

A stop message (sent at least after any command to signal a stop) has bytes of all 0's (character '\0' or a integer value of 0)

A movement/fire message is the same except for the first byte which is either a 1, 2, 4, 8, or 16. After all movement/fire commands you will want to wait for some timeout before sending the stop command. For movements I wait for 50000000 nanoseconds and for a fire I wait 5 seconds.

I'm still looking at cleaning this up into a kernel module at sometime so that I don't have to worry about permissions and knowing what position it starts in. As with everything, time is the enemy that prevents things from getting done.

If anyone can figure out how to get the device to give back information would help me in that.

Jim

I'm still trying to read from the device as well. I cannot find anything in the libusb documentation nor the usb spec which is helpful. There is a hint in the libusb examples section telling us to look in some camera drivers that they link to. However, school has started so I am rather busy and dont have time to put enough effort into digging through their code to get anything useful out of it. Also, I doubt that a camera which needs a sustained transfer would work in the same way as this little guy, which presumably just uses control messages. However, there may be is something useful in the camera config and discovery mechansims.

maniaq: if you want to know the error string associated with the number code, just do a strerror(errnum) (unix error codes are positive, but for some reason the libusb guy flips the sign, so you need to flip it back)

If I set up an SVN or CVS server, would either of you use it? Communicating like this is kinda inefficient, we need to share code.

okay...my professor is giving me dirty looks for not paying attention, gotta go.

Hi,

How can I know the index parameter in
if I'm using SnoopyPro. Or anything else can help me out?

Thanks.

For the device we are using, the index value is always 0. If memory serves, I believe the index had something to do with a predefined command for a given usb device class. Since the device we were using didn't fall into any of the usb device classes, it wasn't any use for us.

As I am not really an expert on it, and it was about a year since there was any movement on this on my part, I can't really say for sure. I seem to remember that index was the only bit of information that my sniffer didn't tell me.

You might try reading the usb specification at www.usb.org. I wouldn't bother with libusb's documentation. It is a single step on the far side of useless.

That's true. The index for my case is 0 too. I use sniffusb to generate the code. Hic

Thanks,