I have been interfacing with a USB device through WinUSB. Instead of using control transfers, I would like to use reads and/or writes on a pipe instead. Is this possible? My device has an interrupt pipe as pipe 0.
I’m thinking this will increase throughput to send the USB device commands through my fast interrupt pipe…
Am I way off here?
–Brian Hindman
All endpoints types other then control are unidirectional. If you want
to both read and write, you would need 2 interrupt endpoints, one IN,
one OUT. I would assume your interrupt endpoint that you currently have
sends data to the host right?
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@dalsemi.com
Sent: Wednesday, June 13, 2007 11:33 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WinUSB control transfers versus pipes
I have been interfacing with a USB device through WinUSB. Instead of
using control transfers, I would like to use reads and/or writes on a
pipe instead. Is this possible? My device has an interrupt pipe as
pipe 0.
I’m thinking this will increase throughput to send the USB device
commands through my fast interrupt pipe…
Am I way off here?
–Brian Hindman
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>I have been interfacing with a USB device through WinUSB. Instead of using
control transfers, I would like to use reads and/or writes on a pipe instead.
Is this possible? My device has an interrupt pipe as pipe 0.I’m thinking this will increase throughput to send the USB device commands
through my fast interrupt pipe…
A full or low speed interrupt endpoint can transfer at most one packet per frame while a control endpoint can transfer multiple packets per frame. If the endpoint max packet sizes are the same the throughput would likely be higher on a control endpoint than on an interrupt endpoint. The throughput should be highest on a bulk endpoint.
Glen/Doran,
Thanks for clarifying. Yes, apparently I have 4 endpoints (I mixed up control with interrupt):
So, control transfers are faster than interrupt. OK, it’s beginning to make some sense now. Believe it or not, I actually have fully functioning code (based on a former driver), but one of my control transfers is much slower for some reason in my WinUSB implementation when compared to the former driver code. What are the typical bottlenecks for control transfers? Any optimization hints?
Thanks,
–Brian Hindman
One more question:
For WinUSB, can you open a pipe to write to the default control endpoint? Or, do you have to use the WinUsb_ControlTransfer() function?
–Brian Hindman
WinUsb_ControlTransfer is it, you can’t address the endpoint with the
read/write pipe APIs
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@dalsemi.com
Sent: Wednesday, June 13, 2007 2:06 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WinUSB control transfers versus pipes
One more question:
For WinUSB, can you open a pipe to write to the default control
endpoint? Or, do you have to use the WinUsb_ControlTransfer() function?
–Brian Hindman
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Brian Hindman wrote:
What are the typical bottlenecks for control transfers? Any optimization
hints?
Not transferring enough bytes per URB, or not using overlapped URBs, but this applies to any kind of pipe really.
xxxxx@dalsemi.com wrote:
Thanks for clarifying. Yes, apparently I have 4 endpoints (I mixed up control with interrupt):
- Control (send commands to USB device)
- Interrupt (host read – for device status )
- Bulk (host read)
- Bulk (host write)
So, control transfers are faster than interrupt.
No, it isn’t that simple. All pipes run at the same speed – 480 Mbps.
The key is the packeting. USB transfers happen in packets; the
different types of pipes do different types of packeting. Control pipe
transfers are limited to 64 bytes per packet, but there can be several
of them in a frame. Bulk pipe transfers are limited to 512 bytes per
packet, but again you can cram many of them into a single frame.
Interrupt pipe are guaranteed a piece of the frame time, but they cannot
transmit except during their slot. So, if an interrupt pipe is
configured to have one packet in every 4 microframes, the host will
guarantee that you always get that time, but you can’t get any more than
that. Isochronous pipes use a similar reservation scheme.
Bulk and control share whatever bandwidth is leftover after the
interrupt and isochronous reservations. That’s the danger of a bulk
pipe. If you have three high-speed cameras plugged in, each with a big
isochronous reservation, the bulk pipe has to battle for what it left.
Believe it or not, I actually have fully functioning code (based on a former driver), but one of my control transfers is much slower for some reason in my WinUSB implementation when compared to the former driver code. What are the typical bottlenecks for control transfers?
How large is the transfer? Control pipe transfers are very small, and
they do have more overhead. If you’re transferring hundreds of
kilobytes, you should try to do it on your bulk pipe instead. If it’s
just tens of bytes, then the pipe type is probably irrelevane.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.