Author Topic: HID transfer speed influenced by host controller and protocol analyzer  (Read 13086 times)

AshAll

  • Member
  • ***
  • Posts: 9
Hello everybody,

I designed a HID high speed interrupt based transfer device. I have a small test program that loops through a writefile and readfile operation. I am using overlapped reading.

What perplexed me is that this loop operates at drastically different speed when I change the host controller.

It operates at desired high speed (round trip of writefile and readfile is about 400us) only with a PCI USB 2.0 card.

It operates much slower (more than 10 times) with the native PC’s enhanced usb port (in the situation where there is no other usb traffic on the bus).

It operates 100 times slower when I hooked the Beagle 480 protocol analyzer to check things out.

I toggle an IO line in the firmware to indicate time of receiving the command and time of finishing transferring data out to the PC. The time in between is the firmware execution time. I measured it on the scope; it is already 5us in between with whatever host controller or whether Beagle is connected or not. The distance between this pulse is the how long is takes to finish one writefile/readfile loop. Its times varies drastically based on what the host controller is and whether the deice is going through the beagle protocol analyzer.

In the case with the Beagle 480, the Beagle reports normal OUT operation, but it reports a lot NACK from the device for the IN operation (although this does not seem right because the IO line indicates the IN operation from the device finishes within 5us of receiving the command).

Please help me with your experience.

Thank you very much for your reponse.

Ashall

Tsuneo

  • Frequent Contributor
  • ****
  • Posts: 145
Quote
It operates much slower (more than 10 times) with the native PC’s enhanced usb port (in the situation where there is no other usb traffic on the bus).
Does the device happen to run on Full-speed, instead of High-speed?

Quote
It operates 100 times slower when I hooked the Beagle 480 protocol analyzer to check things out.
Did you run the beagle's PC application, Data Center, on the same target PC? As Data Center app eats up much CPU usage for "real-time" trace, I recommend you to run it on a separate PC from the target. Beagle's dongle doesn't disturb USB line, of course, but Beagle's PC app impacts your PC app. "Real-time" trace feature is fine, but heavy :-)

Also, this is one of the evidence for
"The bottom line is that Windows isn't a real-time OS." by Jan
on your another thread
http://www.lvr.com/forum/index.php?topic=451.0


Quote
In the case with the Beagle 480, the Beagle reports normal OUT operation, but it reports a lot NACK from the device for the IN operation (although this does not seem right because the IO line indicates the IN operation from the device finishes within 5us of receiving the command).
It's an expected result.
As explained on your other thread,
http://www.lvr.com/forum/index.php?topic=444.0
HID class driver always holds at least one IN transfer request (qTD) on the host controller queue. While any IN transfer request exists on the queue, host controller repeats IN transactions, as long as the device is NAKing.

NACK is applied to I2C, USB term is NAK :-)

Tsuneo

AshAll

  • Member
  • ***
  • Posts: 9
Hello Tsuneo,

Thanks so much for all of your support! Really appreciate the detailed information.

As for the previous query, I found the Beagle is wrongly connected and now the HID opeartes the same speed as on the PCI card with Beagle in between.

I still see big difference on the HID speed with native high speed port and PCI card. I will do some more research in this regard at a later time.

Thanks again! I will get back to this later.

Ashall