From: bomma <ke...@in...> - 2008-05-15 20:19:18
|
Hello, I am trying to send commands to a USB device. At first I got a hard time detecting any devices. Apparently I needed a fstab entry and also sudo (chowning and chmodding the devices didn't do the trick). For the record: I run debian testing, stock kernel: 2.6.24-1-486 Now I can find the device, remove the kernel driver and claim it. But when using usb_control_msg I always get a timeout. I do something like this: usb_control_msg(rfid->dev, USB_ENDPOINT_IN + USB_TYPE_VENDOR, req, value, index, (char*)buf, buflen, TIMEOUT); with: TIMEOUT = 10000 rfid is a pointer to the device Is there something I do wrong, or do I miss anything? Any help is greatly appreciated, pointers to good documentation also. Thanks! -- View this message in context: http://www.nabble.com/control-message-to-rfid-device%3A-connection-timeout-tp17184869p17184869.html Sent from the LibUSB Dev mailing list archive at Nabble.com. |
From: Tim R. <ti...@pr...> - 2008-05-15 20:44:48
|
bomma wrote: > ... > Now I can find the device, remove the kernel driver and claim it. > But when using usb_control_msg I always get a timeout. > I do something like this: > > usb_control_msg(rfid->dev, USB_ENDPOINT_IN + USB_TYPE_VENDOR, req, value, > index, (char*)buf, buflen, TIMEOUT); > > with: > TIMEOUT = 10000 > rfid is a pointer to the device > > Is there something I do wrong, or do I miss anything? > There's nothing inherently wrong with this, although you might want to add USB_RECIP_DEVICE to the second parameter. You shouldn't need to claim the interface to send a control message, but that's neither here nor there. Are you convinced that the request, value, and index numbers map to a vendor command that the device understands, and to a request that expects to return data to you? -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. |
From: Kevin P. <ke...@in...> - 2008-05-16 08:50:51
|
On 15 May 2008, at 22:44, Tim Roberts wrote: > bomma wrote: >> ... >> Now I can find the device, remove the kernel driver and claim it. >> But when using usb_control_msg I always get a timeout. >> I do something like this: >> >> usb_control_msg(rfid->dev, USB_ENDPOINT_IN + USB_TYPE_VENDOR, req, >> value, >> index, (char*)buf, buflen, TIMEOUT); >> >> with: >> TIMEOUT = 10000 >> rfid is a pointer to the device >> >> Is there something I do wrong, or do I miss anything? >> > > There's nothing inherently wrong with this, although you might want to > add USB_RECIP_DEVICE to the second parameter. You shouldn't need to > claim the interface to send a control message, but that's neither here > nor there. > > Are you convinced that the request, value, and index numbers map to a > vendor command that the device understands, and to a request that > expects to return data to you? well, I'm figuring out the system manual. I was trying to send the inventory command (see: http://infogroep.be/~kpinte/sysman.pdf pages 58 and 59) I'm trying to send an inventory command. I tried: unsigned char buf[255]; usb_control_msg(rfid->dev, USB_ENDPOINT_IN + USB_TYPE_VENDOR, 0xB0, 0x0000, 0x0100, buf, sizeof(buf), TIMEOUT); and usb_control_msg(rfid->dev, USB_ENDPOINT_IN + USB_TYPE_VENDOR, 0xB0, 0x0000, 0x01, buf, sizeof(buf), TIMEOUT); also: dmesg tells me: usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd test rqt 192 rq 176 len 255 ret -110 Thanks (and sorry if I'm searching for help in the wrong place) > > > -- > Tim Roberts, ti...@pr... > Providenza & Boekelheide, Inc. > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Libusb-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel |
From: Tim R. <ti...@pr...> - 2008-05-16 18:23:01
|
Kevin Pinte wrote: > well, I'm figuring out the system manual. I was trying to send the > inventory command > > (see: http://infogroep.be/~kpinte/sysman.pdf pages 58 and 59) > > I'm trying to send an inventory command. I tried: > > unsigned char buf[255]; > usb_control_msg(rfid->dev, USB_ENDPOINT_IN + USB_TYPE_VENDOR, 0xB0, > 0x0000, 0x0100, buf, sizeof(buf), TIMEOUT); > > and > > usb_control_msg(rfid->dev, USB_ENDPOINT_IN + USB_TYPE_VENDOR, 0xB0, > 0x0000, 0x01, buf, sizeof(buf), TIMEOUT); > > also: > dmesg tells me: > usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd test rqt 192 rq 176 len > 255 ret -110 > > Thanks (and sorry if I'm searching for help in the wrong place) > The manual does not contain enough information to know how to do this. It does not say, for example, whether these commands are vendor commands for the control pipe, or whether these are messages for an interrupt pipe. There is an implication in here that this device acts like a HID device (a keyboard), and if so, all of that protocol might be HID messages traveling over the interrupt pipe. On Windows, they only support use through their custom DLL. Have you tried plugging this in to a Windows system and capturing the traffic to see how it really works? -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. |
From: Kevin P. <ke...@in...> - 2008-07-15 09:55:49
Attachments:
strace.txt
|
On 16 May 2008, at 20:22, Tim Roberts wrote: > Kevin Pinte wrote: >> well, I'm figuring out the system manual. I was trying to send the >> inventory command >> >> (see: http://infogroep.be/~kpinte/sysman.pdf pages 58 and 59) >> >> I'm trying to send an inventory command. I tried: >> >> unsigned char buf[255]; >> usb_control_msg(rfid->dev, USB_ENDPOINT_IN + USB_TYPE_VENDOR, 0xB0, >> 0x0000, 0x0100, buf, sizeof(buf), TIMEOUT); >> >> and >> >> usb_control_msg(rfid->dev, USB_ENDPOINT_IN + USB_TYPE_VENDOR, 0xB0, >> 0x0000, 0x01, buf, sizeof(buf), TIMEOUT); >> >> also: >> dmesg tells me: >> usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd test rqt 192 rq 176 len >> 255 ret -110 >> >> Thanks (and sorry if I'm searching for help in the wrong place) >> > > The manual does not contain enough information to know how to do this. > It does not say, for example, whether these commands are vendor > commands > for the control pipe, or whether these are messages for an interrupt > pipe. There is an implication in here that this device acts like a > HID > device (a keyboard), and if so, all of that protocol might be HID > messages traveling over the interrupt pipe. > > On Windows, they only support use through their custom DLL. Have you > tried plugging this in to a Windows system and capturing the traffic > to > see how it really works? On a windows machine the command that is sent is: 07 FF B0 01 00 1C 56 returning 06 00 B0 01 5C 63 Reader: No Transponder in Reader Field or something like: 11 00 B0 00 01 03 00 E0 04 01 00 01 A9 2D 3B 41 C1 OK where E0 04 01 00 01 A9 2D 3B is the serial of a tag The sent command is a ISO Host Command: [0xB0] ISO15693 Command: [0x01] Inventory the last two bytes (1C 56) are a CRC, described on page 18 in: http://infogroep.be/~kpinte/sysman.pdf the iso command is described on page 58 in attachment there is the output of an strace on my test-program. For what I can see the hex command being send is not correct, but I have no clue on how to send the correct hex-string or command. Also, is there a CRC-check being done by lib-usb before sending the commend? Thanks a lot, Kevin Pinte. |
From: Tim R. <ti...@pr...> - 2008-07-15 17:08:18
|
Kevin Pinte wrote: > > On a windows machine the command that is sent is: > > 07 FF B0 01 00 1C 56 Sent where? On which pipe? > returning > > 06 00 B0 01 5C 63 Reader: No Transponder in Reader Field > or something like: > 11 00 B0 00 01 03 00 E0 04 01 00 01 A9 2D 3B 41 C1 OK > where E0 04 01 00 01 A9 2D 3B is the serial of a tag Returned where? On which pipe? You HAVE to know this in order to talk to the device. > The sent command is a ISO Host Command: [0xB0] ISO15693 Command: > [0x01] Inventory > > the last two bytes (1C 56) are a CRC, described on page 18 in: > http://infogroep.be/~kpinte/sysman.pdf > the iso command is described on page 58 Hmmm, did you notice the warning in this document that said you were not allowed to share it with others? ;) > in attachment there is the output of an strace on my test-program. For > what I can see the hex command being send is not correct, but I have > no clue on how to send the correct hex-string or command. Also, is > there a CRC-check being done by lib-usb before sending the commend? Of course not. To USB, that's just part of the data -- random bytes without meaning. The device will check this. Fortunately, they give you the algorithm to compute the CRC. -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. |
From: Kevin P. <ke...@in...> - 2008-08-07 07:33:35
|
On 15 Jul 2008, at 19:08, Tim Roberts wrote: > Kevin Pinte wrote: >> >> On a windows machine the command that is sent is: >> >> 07 FF B0 01 00 1C 56 > > Sent where? On which pipe? how can I figure that out on a windows machine? > > >> returning >> >> 06 00 B0 01 5C 63 Reader: No Transponder in Reader Field >> or something like: >> 11 00 B0 00 01 03 00 E0 04 01 00 01 A9 2D 3B 41 C1 OK >> where E0 04 01 00 01 A9 2D 3B is the serial of a tag > > Returned where? On which pipe? You HAVE to know this in order to > talk > to the device. I'm able to detect my device using lib usb. So I got the right bus to send a host command to, no? My code can be found at: http://infogroep.be/~kpinte/rfid.c http://infogroep.be/~kpinte/rfid.h http://infogroep.be/~kpinte/test.c (don't worry, it's not a lot of code) When running the test, I successfully find the right device, but when sending a host msg, I get: IN request -- cannot read message: error sending control message: Connection timed out coming from the call to int usb_control_msg(usb_dev_handle *dev, int requesttype, int request, int value, int index, char *bytes, int size, int timeout); I figure I got the dev, requesttype, bytes, size and timeout parameters, I'm just not to sure about what I used for the request, value and index. Is the error situated in the command I'm trying to send or am I doing something else wrong? Thanks a lot! > > >> The sent command is a ISO Host Command: [0xB0] ISO15693 Command: >> [0x01] Inventory >> >> the last two bytes (1C 56) are a CRC, described on page 18 in: >> http://infogroep.be/~kpinte/sysman.pdf >> the iso command is described on page 58 > > Hmmm, did you notice the warning in this document that said you were > not > allowed to share it with others? ;) It's available online, it's not my own copy ;) > > >> in attachment there is the output of an strace on my test-program. >> For >> what I can see the hex command being send is not correct, but I have >> no clue on how to send the correct hex-string or command. Also, is >> there a CRC-check being done by lib-usb before sending the commend? > > Of course not. To USB, that's just part of the data -- random bytes > without meaning. The device will check this. Fortunately, they give > you the algorithm to compute the CRC. > > -- > Tim Roberts, ti...@pr... > Providenza & Boekelheide, Inc. > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Libusb-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel > |
From: Tim R. <ti...@pr...> - 2008-08-07 16:56:05
|
Kevin Pinte wrote: > On 15 Jul 2008, at 19:08, Tim Roberts wrote: > >> Kevin Pinte wrote: >> >>> On a windows machine the command that is sent is: >>> >>> 07 FF B0 01 00 1C 56 >>> >> Sent where? On which pipe? >> > > how can I figure that out on a windows machine? > The device specs will tell you which pipe/endpoint number to use for any particular data stream. Are you reverse engineering this from a sniffer trace? It should also be shown in the trace. >>> returning >>> >>> 06 00 B0 01 5C 63 Reader: No Transponder in Reader Field >>> or something like: >>> 11 00 B0 00 01 03 00 E0 04 01 00 01 A9 2D 3B 41 C1 OK >>> where E0 04 01 00 01 A9 2D 3B is the serial of a tag >>> >> Returned where? On which pipe? You HAVE to know this in order to >> talk to the device. >> > > I'm able to detect my device using lib usb. So I got the right bus to > send a host command to, no? > There's more to a USB device than just the device address. A USB device communicates through pipes and endpoints. Those are basically a "subaddress" within the device. Every USB transaction goes to a specific endpoint. You imply below that this is a control pipe message, on the default control endpoint #0. That's quite possible, but you need to be sure. Many RFID readers act as HID devices. In that case, these exchanges are probably NOT control transfers, but HID reports sent via an interrupt pipe. > When running the test, I successfully find the right device, but when > sending a host msg, > I get: > > IN request -- cannot read message: error sending control message: > Connection timed out > > coming from the call to > > int usb_control_msg(usb_dev_handle *dev, int requesttype, int request, > int value, int index, char *bytes, int size, int timeout); > > I figure I got the dev, requesttype, bytes, size and timeout > parameters, I'm just not to sure about what I used for the request, > value and index. > You need to know that. In the bytes you show above, for example, it's possible that some of those bytes are actually part of the control message, so they might include request, value, and index. -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. |
From: Kevin P. <ke...@in...> - 2008-08-08 09:35:45
|
On 7 Aug 2008, at 18:56, Tim Roberts wrote: > Kevin Pinte wrote: >> On 15 Jul 2008, at 19:08, Tim Roberts wrote: >> >>> Kevin Pinte wrote: >>> >>>> On a windows machine the command that is sent is: >>>> >>>> 07 FF B0 01 00 1C 56 >>>> >>> Sent where? On which pipe? >>> >> >> how can I figure that out on a windows machine? >> > > The device specs will tell you which pipe/endpoint number to use for > any > particular data stream. Are you reverse engineering this from a > sniffer > trace? It should also be shown in the trace. no, there was a disk included with a sample program (for windows, no source). The program itself shows the hex string it is sending and receiving. If anyone knows a way to sniff usb traffic/connections on a windows machine, please let me know. As far as the device specs, I only got the document I mentioned. Thats about it, there is no more info on the net either. I'll give sniffing the usb traffic on windows another go. > > >>>> returning >>>> >>>> 06 00 B0 01 5C 63 Reader: No Transponder in Reader Field >>>> or something like: >>>> 11 00 B0 00 01 03 00 E0 04 01 00 01 A9 2D 3B 41 C1 OK >>>> where E0 04 01 00 01 A9 2D 3B is the serial of a tag >>>> >>> Returned where? On which pipe? You HAVE to know this in order to >>> talk to the device. >>> >> >> I'm able to detect my device using lib usb. So I got the right bus to >> send a host command to, no? >> > > There's more to a USB device than just the device address. A USB > device > communicates through pipes and endpoints. Those are basically a > "subaddress" within the device. Every USB transaction goes to a > specific endpoint. You imply below that this is a control pipe > message, > on the default control endpoint #0. That's quite possible, but you > need > to be sure. > > > Many RFID readers act as HID devices. In that case, these exchanges > are > probably NOT control transfers, but HID reports sent via an > interrupt pipe. the device can be put in hid mode, I then acts as if it was a keyboard. That works, but the reading/writing of tags cant be controlled. Whenever a tag is read it just sends the key on it as if it was a keyboard. But i'm 100% sure the device is in host mode, not hid mode. I'm just a little clueless on how to find out the correct pipe/endpoint. > > >> When running the test, I successfully find the right device, but when >> sending a host msg, >> I get: >> >> IN request -- cannot read message: error sending control message: >> Connection timed out >> >> coming from the call to >> >> int usb_control_msg(usb_dev_handle *dev, int requesttype, int >> request, >> int value, int index, char *bytes, int size, int timeout); >> >> I figure I got the dev, requesttype, bytes, size and timeout >> parameters, I'm just not to sure about what I used for the request, >> value and index. >> > > You need to know that. In the bytes you show above, for example, it's > possible that some of those bytes are actually part of the control > message, so they might include request, value, and index. > > -- > Tim Roberts, ti...@pr... > Providenza & Boekelheide, Inc. > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Libusb-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel > |
From: Jeffrey P. <jm...@ya...> - 2008-08-08 16:25:01
|
Hi there, I am running libusb .1 on Suse Linux 10.2 and talking to a verndor's product that converts Analog data to Digital and pumps the result over the USB port. The device works fine under Windows, and is a commercial product so I am pretty sure it is doing the right thing. When I sniff the packets it also looks like the device is doing the right thing, eg IN packet is sent from my host to the device and it returns the (correct) data,but libusb reports a timeout. in the libusb code, when I stepped through it, on line 280 of linux.c, bytesdone = 0. Any ideas on why, and / or how I can find out why ? Thank You much Peace,Love,Happiness, and Fun, Jeff 8558-361-5751 --- On Fri, 8/8/08, Kevin Pinte <ke...@in...> wrote: From: Kevin Pinte <ke...@in...> Subject: Re: [Libusb-devel] control message to rfid device: connection timeout To: "Tim Roberts" <ti...@pr...> Cc: lib...@li... Date: Friday, August 8, 2008, 2:34 AM On 7 Aug 2008, at 18:56, Tim Roberts wrote: > Kevin Pinte wrote: >> On 15 Jul 2008, at 19:08, Tim Roberts wrote: >> >>> Kevin Pinte wrote: >>> >>>> On a windows machine the command that is sent is: >>>> >>>> 07 FF B0 01 00 1C 56 >>>> >>> Sent where? On which pipe? >>> >> >> how can I figure that out on a windows machine? >> > > The device specs will tell you which pipe/endpoint number to use for > any > particular data stream. Are you reverse engineering this from a > sniffer > trace? It should also be shown in the trace. no, there was a disk included with a sample program (for windows, no source). The program itself shows the hex string it is sending and receiving. If anyone knows a way to sniff usb traffic/connections on a windows machine, please let me know. As far as the device specs, I only got the document I mentioned. Thats about it, there is no more info on the net either. I'll give sniffing the usb traffic on windows another go. > > >>>> returning >>>> >>>> 06 00 B0 01 5C 63 Reader: No Transponder in Reader Field >>>> or something like: >>>> 11 00 B0 00 01 03 00 E0 04 01 00 01 A9 2D 3B 41 C1 OK >>>> where E0 04 01 00 01 A9 2D 3B is the serial of a tag >>>> >>> Returned where? On which pipe? You HAVE to know this in order to >>> talk to the device. >>> >> >> I'm able to detect my device using lib usb. So I got the right bus to >> send a host command to, no? >> > > There's more to a USB device than just the device address. A USB > device > communicates through pipes and endpoints. Those are basically a > "subaddress" within the device. Every USB transaction goes to a > specific endpoint. You imply below that this is a control pipe > message, > on the default control endpoint #0. That's quite possible, but you > need > to be sure. > > > Many RFID readers act as HID devices. In that case, these exchanges > are > probably NOT control transfers, but HID reports sent via an > interrupt pipe. the device can be put in hid mode, I then acts as if it was a keyboard. That works, but the reading/writing of tags cant be controlled. Whenever a tag is read it just sends the key on it as if it was a keyboard. But i'm 100% sure the device is in host mode, not hid mode. I'm just a little clueless on how to find out the correct pipe/endpoint. > > >> When running the test, I successfully find the right device, but when >> sending a host msg, >> I get: >> >> IN request -- cannot read message: error sending control message: >> Connection timed out >> >> coming from the call to >> >> int usb_control_msg(usb_dev_handle *dev, int requesttype, int >> request, >> int value, int index, char *bytes, int size, int timeout); >> >> I figure I got the dev, requesttype, bytes, size and timeout >> parameters, I'm just not to sure about what I used for the request, >> value and index. >> > > You need to know that. In the bytes you show above, for example, it's > possible that some of those bytes are actually part of the control > message, so they might include request, value, and index. > > -- > Tim Roberts, ti...@pr... > Providenza & Boekelheide, Inc. > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Libusb-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libusb-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libusb-devel |
From: Tim R. <ti...@pr...> - 2008-08-08 21:36:00
|
Jeffrey Price wrote: > Hi there, > > I am running libusb .1 on Suse Linux 10.2 and talking to a verndor's > product that converts Analog data to Digital and pumps the result over > the USB port. The device works fine under Windows, and is a > commercial product so I am pretty sure it is doing the right thing. > When I sniff the packets it also looks like the device is doing the > right thing, eg IN packet is sent from my host to the device and it > returns the (correct) data,but libusb reports a timeout. in the libusb > code, when I stepped through it, > > on line 280 of linux.c, bytesdone = 0. > > Any ideas on why, and / or how I can find out why ? > In your previous code, you open, set config, claim, write, release, close; then open, set config, claim, read, release, close. Are you still doing that? It's possible that setting the configuration and setting the interface are causing some kind of reset action to take place in the device. Usually, an application will open and claim once only, then read and write as much as necessary, then close before exiting. -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. |
From: Jeffrey P. <jm...@ya...> - 2008-08-10 22:38:06
|
Thanks Tim. on the device i am using, you set the analog-to-digital sample frequency up to 500Khz (500k samples/second) before you start to read the samples what i am seeing is that bulk_read call times out when the clock speed increases beyond about 200Khz, or at a lower clock speed as the volume of data requested grows; a number of reads successfully complete; sometimes most of the data is read, before the timeout occurs on the last reads required, or so I am now claiming the interface and then just calling bulk_read() in a loop, until all the requested data is read. I have tried using nanosleep() with up to 1ms delay before successive calls to bulk_read to not hog the processor as well. i am not doing any prints or other stmts between each call to bulk_read. i first had a separate thread from my main application thread (only 2 threads) and then tried to do everything in a single thread. this significantly improved the situation but the problem still exits. i also took some print stmts out that were in the read loop, and as expected this also increased the performance. i do not think i am running optimized code (gcc), and may try that, but doubt it will make much difference. as i mentioned before, under windows, up to several Megabytes of data can be successfully read at max clock speed (500Khz). the USB part in the device is the Cypress Easy-Usb FX2LP. I wonder if I cannot empty the FIFO in the part fast enough. I am not sure what happens when the FIFO gets full in the part, or my device. i know there is no buffer between my device's A/D converter and the FX2LP part. i think there have been a number of other people using libusb with that part and wonder if they have seen anything similar ? i know it depends on the device and the processor etc, but i am running a 2Ghz dual core which is not running anything but Vista (not trivial) so think there should be enough CPU to handle this. does anyone have any ideas,comments or suggestions about what i can do ? thank you for the help ! jeff Peace,Love,Happiness, and Fun, Jeff 8558-361-5751 --- On Fri, 8/8/08, Tim Roberts <ti...@pr...> wrote: From: Tim Roberts <ti...@pr...> Subject: Re: [Libusb-devel] Device sends data, but libusb timesout To: lib...@li... Date: Friday, August 8, 2008, 2:35 PM Jeffrey Price wrote: > Hi there, > > I am running libusb .1 on Suse Linux 10.2 and talking to a verndor's > product that converts Analog data to Digital and pumps the result over > the USB port. The device works fine under Windows, and is a > commercial product so I am pretty sure it is doing the right thing. > When I sniff the packets it also looks like the device is doing the > right thing, eg IN packet is sent from my host to the device and it > returns the (correct) data,but libusb reports a timeout. in the libusb > code, when I stepped through it, > > on line 280 of linux.c, bytesdone = 0. > > Any ideas on why, and / or how I can find out why ? > In your previous code, you open, set config, claim, write, release, close; then open, set config, claim, read, release, close. Are you still doing that? It's possible that setting the configuration and setting the interface are causing some kind of reset action to take place in the device. Usually, an application will open and claim once only, then read and write as much as necessary, then close before exiting. -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libusb-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libusb-devel |
From: Tim R. <ti...@pr...> - 2008-08-11 17:57:06
|
Jeffrey Price wrote: > > on the device i am using, you set the analog-to-digital sample > frequency up to 500Khz (500k samples/second) before you start to read > the samples > > what i am seeing is that bulk_read call times out when the clock > speed increases beyond about 200Khz, or at a lower clock speed as the > volume of data requested grows; a number of reads successfully > complete; sometimes most of the data is read, before the timeout > occurs on the last reads required, or so > > I am now claiming the interface and then just calling bulk_read() in a > loop, until all the requested data is read. I have tried using > nanosleep() with up to 1ms delay before successive calls to bulk_read > to not hog the processor as well. > Try making the buffer in your bulk_read much larger. If the problem is that you aren't turning around quick enough, that will help. > the USB part in the device is the Cypress Easy-Usb FX2LP. I wonder if > I cannot empty the FIFO in the part fast enough. I am not sure what > happens when the FIFO gets full in the part, or my device. i know > there is no buffer between my device's A/D converter and the FX2LP part. > When the FIFO fills, additional samples get dropped on the floor. If you are reading 512 bytes at a time, you won't be able to keep up at 500kHz. Remember that USB is scheduled in advance. The host controller driver lays out the schedule for the next microframe in advance. If you only have one request waiting, you'll only get one shot in that microframe. When the request is filled, you'll get notified, at which point you have to do your processing and send the request back. By that time, you will have missed the scheduling for the next microframe. Make larger requests, and then the host controller can fill up more of the frame. -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. |
From: Jeffrey P. <jm...@ya...> - 2008-08-12 04:54:19
|
Thanks Tim. What you say makes good sense. I am trying to make large requests (e.g. 100-200K bytes) at a time and also am passing in a buffer several Mb in length to the bulk read call. I do notice with the sniffer (Beagle-480), that i am only getting a max of 512 bytes back in any one transaction (DATA0 returned in response to an IN command). could that be because that is the max per read/transaction on the bulk-endpoint i am using ? any other suggestions on what I might do ? i am wondering how have other people have dealt with this issue , as i pretty sure i am not trying to perform any unnatural acts here..... thank you again for you help. jmp Peace,Love,Happiness, and Fun, Jeff 8558-361-5751 --- On Mon, 8/11/08, Tim Roberts <ti...@pr...> wrote: From: Tim Roberts <ti...@pr...> Subject: Re: [Libusb-devel] Device sends data, but libusb timesout To: lib...@li... Date: Monday, August 11, 2008, 10:57 AM Jeffrey Price wrote: > > on the device i am using, you set the analog-to-digital sample > frequency up to 500Khz (500k samples/second) before you start to read > the samples > > what i am seeing is that bulk_read call times out when the clock > speed increases beyond about 200Khz, or at a lower clock speed as the > volume of data requested grows; a number of reads successfully > complete; sometimes most of the data is read, before the timeout > occurs on the last reads required, or so > > I am now claiming the interface and then just calling bulk_read() in a > loop, until all the requested data is read. I have tried using > nanosleep() with up to 1ms delay before successive calls to bulk_read > to not hog the processor as well. > Try making the buffer in your bulk_read much larger. If the problem is that you aren't turning around quick enough, that will help. > the USB part in the device is the Cypress Easy-Usb FX2LP. I wonder if > I cannot empty the FIFO in the part fast enough. I am not sure what > happens when the FIFO gets full in the part, or my device. i know > there is no buffer between my device's A/D converter and the FX2LP part. > When the FIFO fills, additional samples get dropped on the floor. If you are reading 512 bytes at a time, you won't be able to keep up at 500kHz. Remember that USB is scheduled in advance. The host controller driver lays out the schedule for the next microframe in advance. If you only have one request waiting, you'll only get one shot in that microframe. When the request is filled, you'll get notified, at which point you have to do your processing and send the request back. By that time, you will have missed the scheduling for the next microframe. Make larger requests, and then the host controller can fill up more of the frame. -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libusb-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libusb-devel |
From: Tim R. <ti...@pr...> - 2008-08-08 17:09:10
|
Kevin Pinte wrote: > > no, there was a disk included with a sample program (for windows, no > source). The program itself shows the hex string it is sending and > receiving. If anyone knows a way to sniff usb traffic/connections on a > windows machine, please let me know. > There are several good software USB sniffers for Windows. "USB Monitor" from HHD Software (www.hhdsoftware.com) is the one I use. There is a trial version that works for a month or so, but even the purchase price isn't too bad. -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. |
From: Kevin P. <ke...@in...> - 2008-10-10 12:40:27
|
Hello again, the communication with my rfid device is still not working. The command I want to send is 07 FF B0 01 00 1C 56 I sniffed the usb traffic on a windows machine and got this: http://infogroep.be/~kpinte/sniffing/inventory.htm using udev I also found following values: looking at device '/class/usb_endpoint/usbdev2.3_ep00': KERNEL=="usbdev2.3_ep00" SUBSYSTEM=="usb_endpoint" DRIVER=="" ATTR{dev}=="252:13" ATTR{bLength}=="07" ATTR{bEndpointAddress}=="00" ATTR{bmAttributes}=="00" ATTR{bInterval}=="00" ATTR{wMaxPacketSize}=="0040" ATTR{interval}=="0ms" ATTR{type}=="Control" ATTR{direction}=="both" looking at parent device '/devices/pci0000:00/0000:00:1d.0/usb2/2-1': KERNELS=="2-1" SUBSYSTEMS=="usb" DRIVERS=="usb" ATTRS{dev}=="189:130" ATTRS{configuration}=="" ATTRS{bNumInterfaces}==" 2" ATTRS{bConfigurationValue}=="1" ATTRS{bmAttributes}=="80" ATTRS{bMaxPower}=="500mA" ATTRS{urbnum}=="17" ATTRS{idVendor}=="0ab1" ATTRS{idProduct}=="0002" ATTRS{bcdDevice}=="0101" ATTRS{bDeviceClass}=="00" ATTRS{bDeviceSubClass}=="00" ATTRS{bDeviceProtocol}=="00" ATTRS{bNumConfigurations}=="1" ATTRS{bMaxPacketSize0}=="64" ATTRS{speed}=="12" ATTRS{busnum}=="2" ATTRS{devnum}=="3" ATTRS{version}==" 1.10" ATTRS{maxchild}=="0" ATTRS{quirks}=="0x0" ATTRS{authorized}=="1" ATTRS{manufacturer}=="FEIG ELECTRONIC GmbH" ATTRS{product}=="OBID RFID-Reader" ATTRS{serial}=="0E9CAB11" So it seems the endpoint address is 00 Could anyone help me on how to fill in the correct parameters for the call to usb_control_msg(usb_dev_handle *dev, int requesttype, int request, int value, int index, char *bytes, int size, int timeout); Also, what is a good way to snif usb traffic on a linux machine, I googled around but did not found a good (working) solution. Thanks a lot and kind regards, Kevin Pinte. |
From: Roland K. <r.k...@ya...> - 2008-10-10 13:59:52
|
hi, > using udev I also found following values: do you know lsusb (-v) ? > Also, what is a good way to snif usb traffic on a linux machine, I > googled around but did not found a good (working) solution. - usbmon (see usbmon.txt, e.g. in your kernel-documentation-directory) this produces nice human-readable logfiles, but only contains the first bytes of data-packets. you could also use usbmon with wireshark: http://wiki.wireshark.org/USB - usbfs_snoop: writes the usbfs-transfers to syslog (http://www.linuxjournal.com/node/7582/) regards, Roland |
From: Alan S. <st...@ro...> - 2008-10-10 14:04:50
|
On Fri, 10 Oct 2008, Kevin Pinte wrote: > Hello again, > > the communication with my rfid device is still not working. > > The command I want to send is > > 07 FF B0 01 00 1C 56 > > I sniffed the usb traffic on a windows machine and got this: > > http://infogroep.be/~kpinte/sniffing/inventory.htm > Could anyone help me on how to fill in the correct parameters for the > call to > > usb_control_msg(usb_dev_handle *dev, int requesttype, int request, int > value, int index, char *bytes, int size, int timeout); You have to get dev from other library calls; see the examples in the libusb documentation. requesttype should be 0x40, request should be 0, value should be 0, index should be 0, bytes should be an array containing your seven data bytes, size should be 7, and timeout should be some reasonable value such as 5000 (in milliseconds). > Also, what is a good way to snif usb traffic on a linux machine, I > googled around but did not found a good (working) solution. Usbmon. See the kernel source file documentation/usb/usbmon.txt. Alternatively you can do echo 1 >/sys/module/usbcore/parameters/usbfs_snoop The traffic will then be sent to the kernel log. Alan Stern |
From: Kevin P. <ke...@in...> - 2008-10-11 11:01:12
|
On 10 Oct 2008, at 16:04, Alan Stern wrote: > On Fri, 10 Oct 2008, Kevin Pinte wrote: > >> Hello again, >> >> the communication with my rfid device is still not working. >> >> The command I want to send is >> >> 07 FF B0 01 00 1C 56 >> >> I sniffed the usb traffic on a windows machine and got this: >> >> http://infogroep.be/~kpinte/sniffing/inventory.htm > >> Could anyone help me on how to fill in the correct parameters for the >> call to >> >> usb_control_msg(usb_dev_handle *dev, int requesttype, int request, >> int >> value, int index, char *bytes, int size, int timeout); > > You have to get dev from other library calls; see the examples in the > libusb documentation. > > requesttype should be 0x40, request should be 0, value should be 0, > index should be 0, bytes should be an array containing your seven data > bytes, size should be 7, and timeout should be some reasonable value > such as 5000 (in milliseconds). I seem to be making some progress, I dont get a timeout anymore But I still don't get a response back. When performing the call with usb_control_msg this is the kernel log output: Oct 11 12:05:33 lenna kernel: usb 2-10: usbdev_ioctl: CONNECTINFO Oct 11 12:05:33 lenna kernel: usb 2-10: usbdev_ioctl: IOCTL Oct 11 12:05:33 lenna kernel: usb 2-10: usbdev_ioctl: CONTROL Oct 11 12:05:33 lenna kernel: usb 2-10: control write: bRequest=00 bRrequestType=40 wValue=0000 wIndex=0000 wLength=0005 Oct 11 12:05:33 lenna kernel: usb 2-10: control write: data: 05 ff 69 85 01 I also installed a vmware with WinXp with the windows program and tried the same command, the kernel log says: Oct 11 12:07:15 lenna kernel: usb 2-10: usbdev_ioctl: SUBMITURB Oct 11 12:07:15 lenna kernel: usb 2-10: control urb: bRequest=00 bRrequestType=40 wValue=0000 wIndex=0000 wLength=0005 Oct 11 12:07:15 lenna kernel: usb 2-10: direction=OUT Oct 11 12:07:15 lenna kernel: usb 2-10: userurb=08877ba4 Oct 11 12:07:15 lenna kernel: usb 2-10: transfer_buffer_length=5 Oct 11 12:07:15 lenna kernel: usb 2-10: actual_length=0 Oct 11 12:07:15 lenna kernel: usb 2-10: data: 05 ff 69 89 01 Oct 11 12:07:15 lenna kernel: usb 2-10: urb complete Oct 11 12:07:15 lenna kernel: usb 2-10: direction=OUT Oct 11 12:07:15 lenna kernel: usb 2-10: userurb=08877ba4 Oct 11 12:07:15 lenna kernel: usb 2-10: transfer_buffer_length=5 Oct 11 12:07:15 lenna kernel: usb 2-10: actual_length=5 Oct 11 12:07:15 lenna kernel: usb 2-10: data: 05 ff 69 89 01 Oct 11 12:07:15 lenna kernel: usb 2-10: usbdev_ioctl: REAPURBDELAY Oct 11 12:07:15 lenna kernel: usb 2-10: usbdev_ioctl: REAPURBDELAY Oct 11 12:07:15 lenna kernel: usb 2-10: usbdev_ioctl: SUBMITURB Oct 11 12:07:15 lenna kernel: usb 2-10: control urb: bRequest=00 bRrequestType=c0 wValue=0000 wIndex=0000 wLength=1000 Oct 11 12:07:15 lenna kernel: usb 2-10: direction=IN Oct 11 12:07:15 lenna kernel: usb 2-10: userurb=08780054 Oct 11 12:07:15 lenna kernel: usb 2-10: transfer_buffer_length=4096 Oct 11 12:07:15 lenna kernel: usb 2-10: actual_length=0 Oct 11 12:07:15 lenna kernel: usb 2-10: data: 47 50 00 00 be 01 00 00 ea 01 00 00 3d 10 00 00 06 5d 00 00 ab 3a 07 08 48 a1 00 00 24 00 00 00 b0 76 e7 49 bb 42 71 bf 49 a1 00 00 56 00 00 00 03 37 0e 84 9e ba 3f 3b e1 a1 00 00 62 00 00 [...] this doesnt seem to be a control message, but rather a message to an interrupt pipe, is that correct? I tried to do the same thing with: usb_interrupt_write(rfid->dev, 0x40, (char*)buf, sizeof(buf), 10000) where buf is an array containing the actual command: unsigned char buf[] = {0x05, 0xFF, 0x69, 0x85, 0x01} but then I get an error: error submitting URB: Invalid argument I also tried using 0x81 instead of 0x40 but then I get an error saying I should claim the device. That I tried, but it fails, saying the device is busy. Can anyone help me a little further? Thanks a lot. > > >> Also, what is a good way to snif usb traffic on a linux machine, I >> googled around but did not found a good (working) solution. > > Usbmon. See the kernel source file documentation/usb/usbmon.txt. > > Alternatively you can do > > echo 1 >/sys/module/usbcore/parameters/usbfs_snoop > > The traffic will then be sent to the kernel log. > > Alan Stern |
From: Kevin P. <ke...@in...> - 2008-10-11 12:40:46
Attachments:
LSUSB
|
On 11 Oct 2008, at 12:32, Kevin Pinte wrote: > > On 10 Oct 2008, at 16:04, Alan Stern wrote: > >> On Fri, 10 Oct 2008, Kevin Pinte wrote: >> >>> Hello again, >>> >>> the communication with my rfid device is still not working. >>> >>> The command I want to send is >>> >>> 07 FF B0 01 00 1C 56 >>> >>> I sniffed the usb traffic on a windows machine and got this: >>> >>> http://infogroep.be/~kpinte/sniffing/inventory.htm >> >>> Could anyone help me on how to fill in the correct parameters for >>> the >>> call to >>> >>> usb_control_msg(usb_dev_handle *dev, int requesttype, int request, >>> int >>> value, int index, char *bytes, int size, int timeout); >> >> You have to get dev from other library calls; see the examples in the >> libusb documentation. >> >> requesttype should be 0x40, request should be 0, value should be 0, >> index should be 0, bytes should be an array containing your seven >> data >> bytes, size should be 7, and timeout should be some reasonable value >> such as 5000 (in milliseconds). > > I seem to be making some progress, I dont get a timeout anymore But I > still don't get a response back. > > When performing the call with usb_control_msg this is the kernel log > output: > > Oct 11 12:05:33 lenna kernel: usb 2-10: usbdev_ioctl: CONNECTINFO > Oct 11 12:05:33 lenna kernel: usb 2-10: usbdev_ioctl: IOCTL > Oct 11 12:05:33 lenna kernel: usb 2-10: usbdev_ioctl: CONTROL > Oct 11 12:05:33 lenna kernel: usb 2-10: control write: bRequest=00 > bRrequestType=40 wValue=0000 wIndex=0000 wLength=0005 > Oct 11 12:05:33 lenna kernel: usb 2-10: control write: data: 05 ff 69 > 85 01 > > I also installed a vmware with WinXp with the windows program and > tried the same command, the kernel log says: > > Oct 11 12:07:15 lenna kernel: usb 2-10: usbdev_ioctl: SUBMITURB > Oct 11 12:07:15 lenna kernel: usb 2-10: control urb: bRequest=00 > bRrequestType=40 wValue=0000 wIndex=0000 wLength=0005 > Oct 11 12:07:15 lenna kernel: usb 2-10: direction=OUT > Oct 11 12:07:15 lenna kernel: usb 2-10: userurb=08877ba4 > Oct 11 12:07:15 lenna kernel: usb 2-10: transfer_buffer_length=5 > Oct 11 12:07:15 lenna kernel: usb 2-10: actual_length=0 > Oct 11 12:07:15 lenna kernel: usb 2-10: data: 05 ff 69 89 01 > Oct 11 12:07:15 lenna kernel: usb 2-10: urb complete > Oct 11 12:07:15 lenna kernel: usb 2-10: direction=OUT > Oct 11 12:07:15 lenna kernel: usb 2-10: userurb=08877ba4 > Oct 11 12:07:15 lenna kernel: usb 2-10: transfer_buffer_length=5 > Oct 11 12:07:15 lenna kernel: usb 2-10: actual_length=5 > Oct 11 12:07:15 lenna kernel: usb 2-10: data: 05 ff 69 89 01 > Oct 11 12:07:15 lenna kernel: usb 2-10: usbdev_ioctl: REAPURBDELAY > Oct 11 12:07:15 lenna kernel: usb 2-10: usbdev_ioctl: REAPURBDELAY > Oct 11 12:07:15 lenna kernel: usb 2-10: usbdev_ioctl: SUBMITURB > Oct 11 12:07:15 lenna kernel: usb 2-10: control urb: bRequest=00 > bRrequestType=c0 wValue=0000 wIndex=0000 wLength=1000 > Oct 11 12:07:15 lenna kernel: usb 2-10: direction=IN > Oct 11 12:07:15 lenna kernel: usb 2-10: userurb=08780054 > Oct 11 12:07:15 lenna kernel: usb 2-10: transfer_buffer_length=4096 > Oct 11 12:07:15 lenna kernel: usb 2-10: actual_length=0 > Oct 11 12:07:15 lenna kernel: usb 2-10: data: 47 50 00 00 be 01 00 00 > ea 01 00 00 3d 10 00 00 06 5d 00 00 ab 3a 07 08 48 a1 00 00 24 00 00 > 00 b0 76 e7 49 bb 42 71 bf 49 a1 00 00 56 00 00 00 03 37 0e 84 9e ba > 3f 3b e1 a1 00 00 62 00 00 [...] > > this doesnt seem to be a control message, but rather a message to an > interrupt pipe, is that correct? > > I tried to do the same thing with: > > usb_interrupt_write(rfid->dev, 0x40, (char*)buf, sizeof(buf), 10000) > > where buf is an array containing the actual command: > unsigned char buf[] = {0x05, 0xFF, 0x69, 0x85, 0x01} > > but then I get an error: error submitting URB: Invalid argument > > I also tried using 0x81 instead of 0x40 but then I get an error saying > I should claim the device. That I tried, but it fails, saying the > device is busy. > > Can anyone help me a little further? > > Thanks a lot. I managed to claim the device by first detaching the kernel driver, (using endpoint 81) but now the data part in the kernel log is wrong. It is not the same as what I send through the call. I get -1 as a return value but the error message is "No error" :/ the call: unsigned char buf[] = {0x05, 0xff, 0x69, 0x85, 0x01} usb_interrupt_write(dev, 0x81, buf, 5) the kernel log: Oct 11 14:25:46 lenna kernel: usb 2-10: usbdev_ioctl: DISCARDURB Oct 11 14:25:46 lenna kernel: usb 2-10: urb complete Oct 11 14:25:46 lenna kernel: usb 2-10: direction=IN Oct 11 14:25:46 lenna kernel: usb 2-10: userurb=bf9d9ec4 Oct 11 14:25:46 lenna kernel: usb 2-10: transfer_buffer_length=5 Oct 11 14:25:46 lenna kernel: usb 2-10: actual_length=0 Oct 11 14:25:46 lenna kernel: usb 2-10: data: 2e 76 69 6d 69 Oct 11 14:25:46 lenna kernel: usb 2-10: usbdev_ioctl: REAPURB the transfer_bugger_length is correct, but the actual_length should also be 5 and the data is not the data (buf) that I provided. I also tried this with: unsigned int buf[255] = {0x05, 0xff, 0x69, 0x85, 0x01} thats an array with all bytes 0 except the first 5 then the kernel log says: Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: CONNECTINFO Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: IOCTL Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: IOCTL Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: CLAIMINTERFACE Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: SUBMITURB Oct 11 14:16:29 lenna kernel: usb 2-10: interrupt urb Oct 11 14:16:29 lenna kernel: usb 2-10: direction=IN Oct 11 14:16:29 lenna kernel: usb 2-10: userurb=bfbb17b4 Oct 11 14:16:29 lenna kernel: usb 2-10: transfer_buffer_length=255 Oct 11 14:16:29 lenna kernel: usb 2-10: actual_length=0 Oct 11 14:16:29 lenna kernel: usb 2-10: data: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 03 00 03 00 01 00 00 00 10 08 00 00 34 00 00 00 a0 a6 01 00 00 00 00 00 34 00 20 00 06 00 28 00 18 00 17 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d8 97 01 00 d8 97 01 00 05 00 00 00 00 10 00 00 01 00 00 00 c0 9c 01 00 c0 ac 01 00 c0 ac 01 00 f4 08 00 00 a8 09 00 00 06 00 00 00 00 10 00 00 02 00 00 00 28 9f 01 00 28 af 01 00 48 8e d2 f6 00 00 00 00 00 1a bb bf 00 00 00 00 00 00 00 00 e8 03 00 00 e8 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 25 00 00 00 00 10 58 f7 00 10 58 f7 00 00 00 00 00 00 00 00 00 00 00 00 f5 3f bb bf 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: REAPURBDELAY the transfer_buffer_length = 255 which is correct, but again the actual_length should be 5 and the data is totally wrong Does anybody know what I'm doing wrong? for the record, I attached the output of lsusb. Thanks! |
From: Alan S. <st...@ro...> - 2008-10-11 14:04:21
|
On Sat, 11 Oct 2008, Kevin Pinte wrote: > I managed to claim the device by first detaching the kernel driver, > (using endpoint 81) but now the data part in the kernel log is wrong. > It is not the same as what I send through the call. I get -1 as a > return value but the error message is "No error" :/ > > the call: > > unsigned char buf[] = {0x05, 0xff, 0x69, 0x85, 0x01} > usb_interrupt_write(dev, 0x81, buf, 5) Don't you realize that 0x81 is the address of an IN endpoint? You can't write to it; you can only read from it. > the kernel log: > > Oct 11 14:25:46 lenna kernel: usb 2-10: usbdev_ioctl: DISCARDURB > Oct 11 14:25:46 lenna kernel: usb 2-10: urb complete > Oct 11 14:25:46 lenna kernel: usb 2-10: direction=IN Notice the direction: IN. > Oct 11 14:25:46 lenna kernel: usb 2-10: userurb=bf9d9ec4 > Oct 11 14:25:46 lenna kernel: usb 2-10: transfer_buffer_length=5 > Oct 11 14:25:46 lenna kernel: usb 2-10: actual_length=0 > Oct 11 14:25:46 lenna kernel: usb 2-10: data: 2e 76 69 6d 69 > Oct 11 14:25:46 lenna kernel: usb 2-10: usbdev_ioctl: REAPURB > > the transfer_bugger_length is correct, but the actual_length should > also be 5 > and the data is not the data (buf) that I provided. > > I also tried this with: > unsigned int buf[255] = {0x05, 0xff, 0x69, 0x85, 0x01} > > thats an array with all bytes 0 except the first 5 > > then the kernel log says: > > Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: CONNECTINFO > Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: IOCTL > Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: IOCTL > Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: CLAIMINTERFACE > Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: SUBMITURB > Oct 11 14:16:29 lenna kernel: usb 2-10: interrupt urb > Oct 11 14:16:29 lenna kernel: usb 2-10: direction=IN > Oct 11 14:16:29 lenna kernel: usb 2-10: userurb=bfbb17b4 > Oct 11 14:16:29 lenna kernel: usb 2-10: transfer_buffer_length=255 > Oct 11 14:16:29 lenna kernel: usb 2-10: actual_length=0 > Oct 11 14:16:29 lenna kernel: usb 2-10: data: 7f 45 4c 46 01 01 01 00 > 00 00 00 00 00 00 00 00 03 00 03 00 01 00 00 00 10 08 00 00 34 00 00 > 00 a0 a6 01 00 00 00 00 00 34 00 20 00 06 00 28 00 18 00 17 00 01 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d8 97 01 00 d8 97 01 00 05 > 00 00 00 00 10 00 00 01 00 00 00 c0 9c 01 00 c0 ac 01 00 c0 ac 01 00 > f4 08 00 00 a8 09 00 00 06 00 00 00 00 10 00 00 02 00 00 00 28 9f 01 > 00 28 af 01 00 48 8e d2 f6 00 00 00 00 00 1a bb bf 00 00 00 00 00 00 > 00 00 e8 03 00 00 e8 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 01 00 00 00 25 00 00 00 00 10 58 f7 00 10 58 f7 00 00 00 00 > 00 00 00 00 00 00 00 00 f5 3f bb bf 07 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: REAPURBDELAY > > the transfer_buffer_length = 255 which is correct, > but again the actual_length should be 5 > and the data is totally wrong > > Does anybody know what I'm doing wrong? Your mistake is that for some reason you think a control transfer is an interrupt transfer. It isn't. Alan Stern |
From: Kevin P. <ke...@in...> - 2008-10-11 15:02:08
|
On 11 Oct 2008, at 16:04, Alan Stern wrote: > On Sat, 11 Oct 2008, Kevin Pinte wrote: > >> I managed to claim the device by first detaching the kernel driver, >> (using endpoint 81) but now the data part in the kernel log is wrong. >> It is not the same as what I send through the call. I get -1 as a >> return value but the error message is "No error" :/ >> >> the call: >> >> unsigned char buf[] = {0x05, 0xff, 0x69, 0x85, 0x01} >> usb_interrupt_write(dev, 0x81, buf, 5) > > Don't you realize that 0x81 is the address of an IN endpoint? You > can't write to it; you can only read from it. > >> the kernel log: >> >> Oct 11 14:25:46 lenna kernel: usb 2-10: usbdev_ioctl: DISCARDURB >> Oct 11 14:25:46 lenna kernel: usb 2-10: urb complete >> Oct 11 14:25:46 lenna kernel: usb 2-10: direction=IN > > Notice the direction: IN. > >> Oct 11 14:25:46 lenna kernel: usb 2-10: userurb=bf9d9ec4 >> Oct 11 14:25:46 lenna kernel: usb 2-10: transfer_buffer_length=5 >> Oct 11 14:25:46 lenna kernel: usb 2-10: actual_length=0 >> Oct 11 14:25:46 lenna kernel: usb 2-10: data: 2e 76 69 6d 69 >> Oct 11 14:25:46 lenna kernel: usb 2-10: usbdev_ioctl: REAPURB >> >> the transfer_bugger_length is correct, but the actual_length should >> also be 5 >> and the data is not the data (buf) that I provided. >> >> I also tried this with: >> unsigned int buf[255] = {0x05, 0xff, 0x69, 0x85, 0x01} >> >> thats an array with all bytes 0 except the first 5 >> >> then the kernel log says: >> >> Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: CONNECTINFO >> Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: IOCTL >> Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: IOCTL >> Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: CLAIMINTERFACE >> Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: SUBMITURB >> Oct 11 14:16:29 lenna kernel: usb 2-10: interrupt urb >> Oct 11 14:16:29 lenna kernel: usb 2-10: direction=IN >> Oct 11 14:16:29 lenna kernel: usb 2-10: userurb=bfbb17b4 >> Oct 11 14:16:29 lenna kernel: usb 2-10: transfer_buffer_length=255 >> Oct 11 14:16:29 lenna kernel: usb 2-10: actual_length=0 >> Oct 11 14:16:29 lenna kernel: usb 2-10: data: 7f 45 4c 46 01 01 01 00 >> 00 00 00 00 00 00 00 00 03 00 03 00 01 00 00 00 10 08 00 00 34 00 00 >> 00 a0 a6 01 00 00 00 00 00 34 00 20 00 06 00 28 00 18 00 17 00 01 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d8 97 01 00 d8 97 01 00 05 >> 00 00 00 00 10 00 00 01 00 00 00 c0 9c 01 00 c0 ac 01 00 c0 ac 01 00 >> f4 08 00 00 a8 09 00 00 06 00 00 00 00 10 00 00 02 00 00 00 28 9f 01 >> 00 28 af 01 00 48 8e d2 f6 00 00 00 00 00 1a bb bf 00 00 00 00 00 00 >> 00 00 e8 03 00 00 e8 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 01 00 00 00 25 00 00 00 00 10 58 f7 00 10 58 f7 00 00 00 00 >> 00 00 00 00 00 00 00 00 f5 3f bb bf 07 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: REAPURBDELAY >> >> the transfer_buffer_length = 255 which is correct, >> but again the actual_length should be 5 >> and the data is totally wrong >> >> Does anybody know what I'm doing wrong? > > Your mistake is that for some reason you think a control transfer is > an > interrupt transfer. It isn't. Ok, thanks, I'm just a little clueless about why it fails. when doing unsigned char buf[255] = {05 ff 69 89 01} (the 85 was a mistake indeed, but it makes no difference) usb_control_msg(dev, 0x40, 0, 0, 0, buf, 5, 10000) just gives me: Oct 11 16:24:37 quinn kernel: usb 2-1: usbdev_ioctl: CONNECTINFO Oct 11 16:24:37 quinn kernel: usb 2-1: usbdev_ioctl: IOCTL Oct 11 16:24:37 quinn kernel: usb 2-1: usbdev_ioctl: CONTROL Oct 11 16:24:37 quinn kernel: usb 2-1: control write: bRequest=00 bRrequestType=40 wValue=0000 wIndex=0000 wLength=0005 Oct 11 16:24:37 quinn kernel: usb 2-1: control write: data: 05 ff 69 89 01 returning 5 and leaving the buf unchanged I also tried 0x81 (which I think should be the right endpoint) that gives me: Oct 11 16:32:49 quinn kernel: usb 2-1: usbdev_ioctl: CONNECTINFO Oct 11 16:32:49 quinn kernel: usb 2-1: usbdev_ioctl: IOCTL Oct 11 16:32:49 quinn kernel: usb 2-1: usbdev_ioctl: CONTROL Oct 11 16:32:49 quinn kernel: usb 2-1: control write: bRequest=00 bRrequestType=40 wValue=0000 wIndex=0000 wLength=0005 Oct 11 16:32:49 quinn kernel: usb 2-1: control write: data: 05 ff 69 89 01 Oct 11 16:34:22 quinn kernel: usb 2-1: usbdev_ioctl: CONNECTINFO Oct 11 16:34:22 quinn kernel: usb 2-1: usbdev_ioctl: IOCTL Oct 11 16:34:22 quinn kernel: usb 2-1: usbdev_ioctl: CONTROL Oct 11 16:34:22 quinn kernel: usb 2-1: control read: bRequest=00 bRrequestType=81 wValue=0000 wIndex=0000 wLength=0005 Oct 11 16:34:22 quinn kernel: usb 2-1: control read: data 00 00 it seems now the device actually responded something, but nowhere near the windows response. the actual response should be 06 00 69 00 f6 fa I'm sorry if I'm trying strange things, but I can't seem to get it to work the way I think it should. So I'm just trying everything. I appreciate your help a lot. > > > Alan Stern |
From: Alan S. <st...@ro...> - 2008-10-12 16:12:32
|
On Sat, 11 Oct 2008, Kevin Pinte wrote: > Ok, thanks, > I'm just a little clueless about why it fails. > > when doing > > unsigned char buf[255] = {05 ff 69 89 01} > (the 85 was a mistake indeed, but it makes no difference) > > usb_control_msg(dev, 0x40, 0, 0, 0, buf, 5, 10000) > > just gives me: > > Oct 11 16:24:37 quinn kernel: usb 2-1: usbdev_ioctl: CONNECTINFO > Oct 11 16:24:37 quinn kernel: usb 2-1: usbdev_ioctl: IOCTL > Oct 11 16:24:37 quinn kernel: usb 2-1: usbdev_ioctl: CONTROL > Oct 11 16:24:37 quinn kernel: usb 2-1: control write: bRequest=00 > bRrequestType=40 wValue=0000 wIndex=0000 wLength=0005 > Oct 11 16:24:37 quinn kernel: usb 2-1: control write: data: 05 ff 69 > 89 01 > > returning 5 and leaving the buf unchanged Isn't this exactly what you want? It is virtually the same as the start of the log from your VMWare Windows session. > I also tried 0x81 (which I think should be the right endpoint) > that gives me: > > Oct 11 16:32:49 quinn kernel: usb 2-1: usbdev_ioctl: CONNECTINFO > Oct 11 16:32:49 quinn kernel: usb 2-1: usbdev_ioctl: IOCTL > Oct 11 16:32:49 quinn kernel: usb 2-1: usbdev_ioctl: CONTROL > Oct 11 16:32:49 quinn kernel: usb 2-1: control write: bRequest=00 > bRrequestType=40 wValue=0000 wIndex=0000 wLength=0005 > Oct 11 16:32:49 quinn kernel: usb 2-1: control write: data: 05 ff 69 > 89 01 > Oct 11 16:34:22 quinn kernel: usb 2-1: usbdev_ioctl: CONNECTINFO > Oct 11 16:34:22 quinn kernel: usb 2-1: usbdev_ioctl: IOCTL > Oct 11 16:34:22 quinn kernel: usb 2-1: usbdev_ioctl: CONTROL > Oct 11 16:34:22 quinn kernel: usb 2-1: control read: bRequest=00 > bRrequestType=81 wValue=0000 wIndex=0000 wLength=0005 > Oct 11 16:34:22 quinn kernel: usb 2-1: control read: data 00 00 > > it seems now the device actually responded something, but nowhere near > the windows response. > > the actual response should be 06 00 69 00 f6 fa Now I'm getting very confused. What are you trying to accomplish? As near as I can tell, you should be trying to duplicate the information from the Windows session. Following the part that you have already succeeded in duplicating, the log goes on like this: Oct 11 12:07:15 lenna kernel: usb 2-10: usbdev_ioctl: SUBMITURB Oct 11 12:07:15 lenna kernel: usb 2-10: control urb: bRequest=00 bRrequestType=c0 wValue=0000 wIndex=0000 wLength=1000 Oct 11 12:07:15 lenna kernel: usb 2-10: direction=IN Oct 11 12:07:15 lenna kernel: usb 2-10: userurb=08780054 Oct 11 12:07:15 lenna kernel: usb 2-10: transfer_buffer_length=4096 Oct 11 12:07:15 lenna kernel: usb 2-10: actual_length=0 Oct 11 12:07:15 lenna kernel: usb 2-10: data: 47 50 00 00 be 01 00 00 ea 01 00 00 3d 10 00 00 06 5d 00 00 ab 3a 07 08 48 a1 00 00 24 00 00 00 b0 76 e7 49 bb 42 71 bf 49 a1 00 00 56 00 00 00 03 37 0e 84 9e ba 3f 3b e1 a1 00 00 62 00 00 [...] Isn't this what you want to do? If it is, why are you messing around with setting bRequestType to 0x81? > I'm sorry if I'm trying strange things, but I can't seem to get it to > work the way I think it should. So I'm just trying everything. That's a mistake. You shouldn't try things at random. Instead you should go to the effort of figuring out what the logs really mean and understanding what needs to be done. Alan Stern |
From: Kevin P. <ke...@in...> - 2008-10-11 23:26:58
|
I put my code online: http://infogroep.be/~kpinte/rfid/code/ from what I see in the lsusb output there is one IN endpoint: 0x81 with transfer type: interrupt but I don't see where I should use this value in my code. but sniffing the usb traffic when using the windows program provides me with following info: usbdev_ioctl: SUBMITURB control urb: bRequest=00 bRrequestType=40 wValue=0000 wIndex=0000 wLength=0005 direction=OUT userurb=08877ba4 transfer_buffer_length=5 actual_length=0 data: 05 ff 69 89 01 urb complete direction=OUT userurb=08877ba4 transfer_buffer_length=5 actual_length=5 data: 05 ff 69 89 01 usbdev_ioctl: REAPURBDELAY usbdev_ioctl: REAPURBDELAY usbdev_ioctl: SUBMITURB control urb: bRequest=00 bRrequestType=c0 wValue=0000 wIndex=0000 wLength=1000 direction=IN userurb=08780054 transfer_buffer_length=4096 actual_length=0 so once bRrequestType=40 and once bRrequestType=c0 another difference is that the log says "control urb: bRequest=00 bRrequestType=40 wValue=0000 wIndex=0000 wLength=0005" when I execute my code I get "control write: bRequest=00 bRrequestType=40 wValue=0000 wIndex=0000 wLength=0005" what is the difference between "control write" and "control urb"? I should be able to send commands to my device, but whatever I try, it seems to fail. I do read the documentation, but I'm still stuck. Is there any more information I should/could check? I also checked the usb traffic on a windows machine (not in a VM): e.g. http://infogroep.be/~kpinte/sniffing/inventory.htm But I do not see any more information, it just confirms that I should issue a control transfer I don't know if it matters, but I compiled libusb from cvs, working on both a debian testing/unstable and ubuntu hardy heron machines, both with the same results. I appreciate any help a great deal, Kind regards, Kevin Pinte. On 11 Oct 2008, at 17:01, Kevin Pinte wrote: > > On 11 Oct 2008, at 16:04, Alan Stern wrote: > >> On Sat, 11 Oct 2008, Kevin Pinte wrote: >> >>> I managed to claim the device by first detaching the kernel driver, >>> (using endpoint 81) but now the data part in the kernel log is >>> wrong. >>> It is not the same as what I send through the call. I get -1 as a >>> return value but the error message is "No error" :/ >>> >>> the call: >>> >>> unsigned char buf[] = {0x05, 0xff, 0x69, 0x85, 0x01} >>> usb_interrupt_write(dev, 0x81, buf, 5) >> >> Don't you realize that 0x81 is the address of an IN endpoint? You >> can't write to it; you can only read from it. >> >>> the kernel log: >>> >>> Oct 11 14:25:46 lenna kernel: usb 2-10: usbdev_ioctl: DISCARDURB >>> Oct 11 14:25:46 lenna kernel: usb 2-10: urb complete >>> Oct 11 14:25:46 lenna kernel: usb 2-10: direction=IN >> >> Notice the direction: IN. >> >>> Oct 11 14:25:46 lenna kernel: usb 2-10: userurb=bf9d9ec4 >>> Oct 11 14:25:46 lenna kernel: usb 2-10: transfer_buffer_length=5 >>> Oct 11 14:25:46 lenna kernel: usb 2-10: actual_length=0 >>> Oct 11 14:25:46 lenna kernel: usb 2-10: data: 2e 76 69 6d 69 >>> Oct 11 14:25:46 lenna kernel: usb 2-10: usbdev_ioctl: REAPURB >>> >>> the transfer_bugger_length is correct, but the actual_length should >>> also be 5 >>> and the data is not the data (buf) that I provided. >>> >>> I also tried this with: >>> unsigned int buf[255] = {0x05, 0xff, 0x69, 0x85, 0x01} >>> >>> thats an array with all bytes 0 except the first 5 >>> >>> then the kernel log says: >>> >>> Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: CONNECTINFO >>> Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: IOCTL >>> Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: IOCTL >>> Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: CLAIMINTERFACE >>> Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: SUBMITURB >>> Oct 11 14:16:29 lenna kernel: usb 2-10: interrupt urb >>> Oct 11 14:16:29 lenna kernel: usb 2-10: direction=IN >>> Oct 11 14:16:29 lenna kernel: usb 2-10: userurb=bfbb17b4 >>> Oct 11 14:16:29 lenna kernel: usb 2-10: transfer_buffer_length=255 >>> Oct 11 14:16:29 lenna kernel: usb 2-10: actual_length=0 >>> Oct 11 14:16:29 lenna kernel: usb 2-10: data: 7f 45 4c 46 01 01 01 >>> 00 >>> 00 00 00 00 00 00 00 00 03 00 03 00 01 00 00 00 10 08 00 00 34 00 00 >>> 00 a0 a6 01 00 00 00 00 00 34 00 20 00 06 00 28 00 18 00 17 00 01 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d8 97 01 00 d8 97 01 00 05 >>> 00 00 00 00 10 00 00 01 00 00 00 c0 9c 01 00 c0 ac 01 00 c0 ac 01 00 >>> f4 08 00 00 a8 09 00 00 06 00 00 00 00 10 00 00 02 00 00 00 28 9f 01 >>> 00 28 af 01 00 48 8e d2 f6 00 00 00 00 00 1a bb bf 00 00 00 00 00 00 >>> 00 00 e8 03 00 00 e8 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 01 00 00 00 25 00 00 00 00 10 58 f7 00 10 58 f7 00 00 00 00 >>> 00 00 00 00 00 00 00 00 f5 3f bb bf 07 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> Oct 11 14:16:29 lenna kernel: usb 2-10: usbdev_ioctl: REAPURBDELAY >>> >>> the transfer_buffer_length = 255 which is correct, >>> but again the actual_length should be 5 >>> and the data is totally wrong >>> >>> Does anybody know what I'm doing wrong? >> >> Your mistake is that for some reason you think a control transfer is >> an >> interrupt transfer. It isn't. > > Ok, thanks, > I'm just a little clueless about why it fails. > > when doing > > unsigned char buf[255] = {05 ff 69 89 01} > (the 85 was a mistake indeed, but it makes no difference) > > usb_control_msg(dev, 0x40, 0, 0, 0, buf, 5, 10000) > > just gives me: > > Oct 11 16:24:37 quinn kernel: usb 2-1: usbdev_ioctl: CONNECTINFO > Oct 11 16:24:37 quinn kernel: usb 2-1: usbdev_ioctl: IOCTL > Oct 11 16:24:37 quinn kernel: usb 2-1: usbdev_ioctl: CONTROL > Oct 11 16:24:37 quinn kernel: usb 2-1: control write: bRequest=00 > bRrequestType=40 wValue=0000 wIndex=0000 wLength=0005 > Oct 11 16:24:37 quinn kernel: usb 2-1: control write: data: 05 ff 69 > 89 01 > > returning 5 and leaving the buf unchanged > > I also tried 0x81 (which I think should be the right endpoint) > that gives me: > > Oct 11 16:32:49 quinn kernel: usb 2-1: usbdev_ioctl: CONNECTINFO > Oct 11 16:32:49 quinn kernel: usb 2-1: usbdev_ioctl: IOCTL > Oct 11 16:32:49 quinn kernel: usb 2-1: usbdev_ioctl: CONTROL > Oct 11 16:32:49 quinn kernel: usb 2-1: control write: bRequest=00 > bRrequestType=40 wValue=0000 wIndex=0000 wLength=0005 > Oct 11 16:32:49 quinn kernel: usb 2-1: control write: data: 05 ff 69 > 89 01 > Oct 11 16:34:22 quinn kernel: usb 2-1: usbdev_ioctl: CONNECTINFO > Oct 11 16:34:22 quinn kernel: usb 2-1: usbdev_ioctl: IOCTL > Oct 11 16:34:22 quinn kernel: usb 2-1: usbdev_ioctl: CONTROL > Oct 11 16:34:22 quinn kernel: usb 2-1: control read: bRequest=00 > bRrequestType=81 wValue=0000 wIndex=0000 wLength=0005 > Oct 11 16:34:22 quinn kernel: usb 2-1: control read: data 00 00 > > it seems now the device actually responded something, but nowhere near > the windows response. > > the actual response should be 06 00 69 00 f6 fa > > I'm sorry if I'm trying strange things, but I can't seem to get it to > work the way I think it should. So I'm just trying everything. > > I appreciate your help a lot. > > >> >> >> Alan Stern > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Libusb-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel |
From: Alan S. <st...@ro...> - 2008-10-12 16:18:41
|
On Sun, 12 Oct 2008, Kevin Pinte wrote: > I put my code online: > > http://infogroep.be/~kpinte/rfid/code/ > > from what I see in the lsusb output there is one IN endpoint: 0x81 > with transfer type: interrupt > but I don't see where I should use this value in my code. > > but sniffing the usb traffic when using the windows program provides > me with following info: > > usbdev_ioctl: SUBMITURB > control urb: bRequest=00 bRrequestType=40 wValue=0000 wIndex=0000 > wLength=0005 > direction=OUT > userurb=08877ba4 > transfer_buffer_length=5 > actual_length=0 > data: 05 ff 69 89 01 > urb complete > direction=OUT > userurb=08877ba4 > transfer_buffer_length=5 > actual_length=5 > data: 05 ff 69 89 01 > usbdev_ioctl: REAPURBDELAY > usbdev_ioctl: REAPURBDELAY > usbdev_ioctl: SUBMITURB > control urb: bRequest=00 bRrequestType=c0 wValue=0000 wIndex=0000 > wLength=1000 > direction=IN > userurb=08780054 > transfer_buffer_length=4096 > actual_length=0 > > so once bRrequestType=40 and once bRrequestType=c0 > > another difference is that the log says "control urb: bRequest=00 > bRrequestType=40 wValue=0000 wIndex=0000 wLength=0005" > > when I execute my code I get "control write: bRequest=00 > bRrequestType=40 wValue=0000 wIndex=0000 wLength=0005" > > what is the difference between "control write" and "control urb"? The difference is minimal. It means that one request was submitted using the USBDEVFS_CONTROL ioctl and the other was submitted using the USBDEVFS_SUBMIT_URB ioctl. Either way, the end result is to send a control transfer. > I should be able to send commands to my device, but whatever I try, it > seems to fail. You have to send the _right_ commands! > I do read the documentation, but I'm still stuck. Is > there any more information I should/could check? Have you looked at the USB 2.0 specification? You don't need to absorb all the technical details, but you should at least understand how USB works. Alan Stern |