qse drf wrote:
>
> I am trying to communicate with a device via a simple bulk transfer
> protocol under 64-bit Win7, it doesn't require high bandwidth. I
> don't have access to to the device firmware, but I know it is working
> properly because I have some software that communicates with it
> correctly under WinXP.
Well, just because it happens to work in one location does not
necessarily mean it is working properly. However, in this case, I don't
think that's relevant...
> I installed libusbx 1.0.15 using the WinUSB driver, and it works until
> command 2, when I get an error response. I used a USB sniffer and
> discovered that I'm getting a sequence like:
>
> [reset device]
>
> [initiate communication]
> bulk out - 16 bytes start command
> bulk in - 16 bytes ready response
>
> [start processing data]
> bulk out - 2KB command 1 with data followed immediately by command 2
> with it's data
> bulk in - 16 bytes command 1 response (OK)
> bulk in - 16 bytes command 2 response (error)
>
> Looking deeper, I noticed that the 1KB transferrs should consist
> of two 512byte packets followed by a zero byte packet. What I'm
> seeing are four 512 byte packets. I'm using synchronous API calls
> so I expected each of the transfers to complete before the next call,
> but it seems that the data is being queued somehow and sent as a
> single concatenated transfer so the device doesn't recognize the
> second command.
Well, wait a minute here. If you are waiting for the "bulk in" in the
middle, how could you possibly get the sequence you just described? You
wouldn't even send the second 1KB until you'd read the first response.
Are you sending the two "bulk out" calls consecutively, without waiting
for the "bulk in" in the middle? If so, then what you show is quite
possible.
There is a flag to ask for a zero-length terminator
(LIBUSB_TRANSFER_ADD_ZERO_PACKET), but I'm not sure it's available on
Windows. You should, however, be able to do another bulk out
transaction with a zero-length buffer. So, send 1K, send 0, send 1K,
send 0.
This is a tricky problem. USB allows arbitrarily large "transfers",
terminated by a short packet. The operating systems libusb supports do
not all support arbitrarily large memory buffers. So, if you want to
send a 16MB transfer, you can't do that in a single call. You have to
chop it up into a series of multiple-of-512-byte calls. Because of
that, libusb cannot tell whether your 1K transfer is a single transfer,
or part of a larger transfer. It cannot know when it should send a ZLP.
> I also tried using the WinUSB API directly, but it only finds the
> interface with endpoint 0, rather the interface the bulk endpoints, so
> I have been unable to even establish communication with the device.
> I'd rather use libusbx, but WinUSB will be fine if I can figure out
> how to get a handle to the bulk endpoints.
Do you actually have multiple interfaces? Did you write your INF to
match the composite device, or did you match the specific interface you
want (with #MI_01, for example)?
--
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
