Author Topic: USB HID Ping-Pong feature ???  (Read 29219 times)

Tomcopy

  • Member
  • ***
  • Posts: 5
USB HID Ping-Pong feature ???
« on: September 05, 2010, 04:58:36 am »
Hello all,

I have one project and need to sample A/D data (16bit) on 40kHz and transfer it out of PIC
to PC. Ordinary HID transfer is limited to 64kbyte/s and I need 40kHz x 2byte -> 80kbyte/s.
Possibility is to use BULK transfer ? Or what solution will be the best ? HID is without PC
driver :o)

Question is, can I use Ping-Pong on two (or more) 64byte buffers to send/receive two
(or more) packets in 1ms frame under HID ? If yes, data flow will be 128byte / 1ms which
is enough for this application. Therefore no BULK transfer and external driver are needed.

I'll really appreciate if somebody please advise what is possible and give me some hints
what to do on PC side and PIC framework ?

Thank you

Tomas

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: USB HID Ping-Pong feature ???
« Reply #1 on: September 05, 2010, 06:30:43 pm »
If you want more bandwidth for HID interrupt endpoints, you will need to create a composite device with two or more HID interfaces. Each interface can have one interrupt IN endpoint and one interrupt OUT endpoint. The host application opens a handle to each HID. The host doesn't know or care what kind of buffers the device is using.

To maximize throughput, use long reports and/or increase the ReadFile buffer size to enable reading multiple reports at once. (Each call to ReadFile/WriteFile adds overhead, and ReadFile returns as many reports as are available, up to ReadFile's buffer size.)

For bulk transfers you could try a CDC or FTDI virtual COM port. Bulk transfers have no guaranteed bandwidth, however, and thus may be slow on a busy bus.

There are other options, but more work - use a high-speed chip with a custom driver that can select an interface with a larger max endpoint size for interrupt transfers (the default interface should be 64 bytes to comply with the spec).

Jan


Tomcopy

  • Member
  • ***
  • Posts: 5
Re: USB HID Ping-Pong feature ???
« Reply #2 on: September 06, 2010, 04:58:08 am »
Thank you for answer. Idea with multiple HID interface is quite good, as long, as
I have any example to work with :o) I'll try to search www.

I was thinking a bit and there is also, maybe another idea what to do. Please
tell me if this solution will be working or not.

Bulk tansfer will be only from PIC to PC. Thus I want to configure device with
one IN/OUT interrupt endpoint, 64B lenght for transferring data to PIC and back
and another for example 6 BULK IN endpoinds for transferring raw data from PIC.

So if I'll send buffer 6x64B in length to BULK pipe, it should be processeed in once ?
Or do I need to send each buffers to each BULK pipe ? One by one ?

Thank you

Tomas

Guido Koerber

  • Frequent Contributor
  • ****
  • Posts: 72
Re: USB HID Ping-Pong feature ???
« Reply #3 on: September 06, 2010, 07:03:56 am »
???
Hard to understand what you mean.

If you want to use Bulk transfer you have to write your own device driver.
If you want to use HID to avoid writing a driver you have no Bulk transfer available.

Tomcopy

  • Member
  • ***
  • Posts: 5
Re: USB HID Ping-Pong feature ???
« Reply #4 on: September 06, 2010, 12:40:56 pm »
Yes, I need driver for BULK transfer. Particulary LibUSB-w32 is quite good.
If HID can't manage fast enough transfer, then I'll switch to custom
driver, no choice.... Question is, if end device can be configured the way
described above. One IN/OUT int pipe and 6 BULK one way...
And what needs to be done on PC side in user sw. I ma slowly giving up HID
idea for this project :(

Tomas


Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: USB HID Ping-Pong feature ???
« Reply #5 on: September 07, 2010, 03:03:33 pm »
How to access the device and whether you can have multiple bulk endpoints in one direction depends on the driver. If you're writing the driver, you can do it any way you want. Why do you need six bulk endpoints?

Jan

Tomcopy

  • Member
  • ***
  • Posts: 5
Re: USB HID Ping-Pong feature ???
« Reply #6 on: September 07, 2010, 09:26:05 pm »
I don't actually need 6 endpoinys, there is possibility for sampling 6 x A/D on PIC side
and if I'll send every A/D channel via its own endpoint (one by one), there will be
very easy data processing on PC side. I can also merge A/D sample buffers to one
6x60byte buffer and send it once. Question is, how big will be time difference when
I'll process 6 pipes 64 byte one-by-one or one pipe 360 byte ??? any idea ???

Sampling time of each A/D will be very different, so separate pipes would be nice.
But if this idea is silly, just please advise how to solve this issue.

Thank you

Tomas
     

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: USB HID Ping-Pong feature ???
« Reply #7 on: September 08, 2010, 12:27:51 pm »
Every API call adds some overhead, so it's more efficient to do fewer, larger transfers. Also more efficient to send at least wMaxPacketSize data (use 64 for full speed, 512 for high). But if the device hardware and driver support 6 bulk endpoints and the throughput is acceptable, you can do it that way.

Jan

st2000

  • Member
  • ***
  • Posts: 44
Re: USB HID Ping-Pong feature ???
« Reply #8 on: September 09, 2010, 06:28:52 pm »

Nothing to do w/USB, but you said:

"...I have one project and need to sample A/D data (16bit) on 40kHz..."

...sounds like audio to me. 

Have you thought about compressing the data before sending it out of the PIC?  Nothing fancy, maybe run-length-encoding (http://en.wikipedia.org/wiki/Run-length_encoding).  Just enough to cut your BW requirement so you can use a HID class driver.

-good luck

Tomcopy

  • Member
  • ***
  • Posts: 5
Re: USB HID Ping-Pong feature ???
« Reply #9 on: September 10, 2010, 01:20:40 am »
I was experimenting a bit and there is problem with hardware, PC is "shouting" that USB controller is not sufficent
for connected device with configuration of 6 BULK endpoints. When number of endpoints was lowered to 4 all was
fine. So I'll work with one endpoint and large data buffer as suggested by Jan.

Data are not audio, its laboratory board for measuring of various events during physics lessons. I don't know why
they need 40kHz sample for reading of bumping pendulo :o)

Compression helps, but it needs some processing time on PIC side and  don't have margin for that.

Thank you for answers

Tomas