Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IOUSBPipe->Read() performance



I think it would be best if you framed your question in USB bus terms. Packets on the USB bus are transferred in MaxPacketSize chunks. This is 512 bytes for high-speed bulk endpoints. What you are asking for is to see a IN token on the bus every 256 microSeconds. This must be sustained for 240 packets - about 60 milliseconds.

This should not normally be a problem (and a single read of 240*512 is the way to go), however you are sharing the USB bus with other devices, and you may not be able to count on this throughput depending upon the bus topology (ie, what other devices are connected).

Given that your device has such critical timing, you should really be using a USB bus analyzer to examine what is happening you need to be lookinng for answers to the following questions:

-- Does the host issue IN token with sufficient frequency?
-- Does the device respond with data, or is it sending NYET tokens?
-- Are the packets received correctly (host sends ACK), or retried?
-- Does the data toggle seem to be working correctly?  (DATA0/DATA1) packets

If you IOUSBPipeRead() function is timing out, that indicates your device isn't sending the data... Perhaps you have the timeout value set to small value, and the device isn't ready to start sending data yet... Or the device isn't handling PING correctly....

Good Luck!

David Ferguson
USB Software Team



At 7:44 PM -0700 7/5/05, Mike Smith wrote:
Hi list,

I have a USB 2.0 device that I am having trouble
reading data from its bulks' endpoint.
For every data request the device sends 240*512 bytes.
To make sure that there is no data lost, the host has
to pull 512 bytes in 256 us otherwise the transaction
will be aborted by the device after detecting a buffer
over run.

To make the bulk transfer fast I tried to use a large
transfer
by setting the length of IOMemoryDescriptor in
IOUSBPipe->Read() equal to 240*512  bytes, but that
didn't meet the required pulling time (512 bytes in
256 us). The transaction times out since the device
already aborted the request after detecting a buffer
over run on its side (the data hasn't been pulled from
the buffer in 256 us).

Does that sound an expected performance from the
function IOUSBPipe->Read()?

Does the function IOUSBPipe->Read() overlap the
transfers?

I am only able to get 1024 bytes (by having the length
of IOMemoryDescriptor = 1024) out of 240*512 before
the device terminates the transaction. If  I use a
IOMemoryDescriptor larger than 1024, the function
IOUSBPipe->Read() times out because the device detects
a buffer over run and terminates the transaction.

By using smaller buffers  (1024 bytes) and overlapping
the transfers, it seems I am able to get more data
from the device before timing out. I am not sure if
that is the best way to handle this kind of situation,
but I think it will be  inefficient  to use a very
small buffer (1024 bytes) to get all the 240*512 bytes
from the device.
Is there a better way to achieve that?

Your suggestions and recommendations will be very
appreciated....

Thanks,
Mike








____________________________________________________ Sell on Yahoo! Auctions – no fees. Bid on great items. http://auctions.yahoo.com/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Usb mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/usb/email@hidden

This email sent to email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Usb mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/usb/email@hidden

This email sent to email@hidden
References: 
 >IOUSBPipe->Read() performance (From: Mike Smith <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.