Author Topic: best practices sending a non fixed size report?  (Read 9841 times)

ulao

  • Frequent Contributor
  • ****
  • Posts: 172
best practices sending a non fixed size report?
« on: May 07, 2018, 07:38:30 am »
If I had to send a usb 1.1 device data ranging from 1 to 512 bytes, what is the best way to do this?

So far the best I have came up with is to send 512 bytes via a feature report and use the first data byte as my size. The pit fall here is that sending 512 bytes of data can take a long time. So the smaller payloads suffer. I never played with output bulk but I could imagine that would take forever on usb 1.1.
 
Is there another way?

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: best practices sending a non fixed size report?
« Reply #1 on: May 07, 2018, 11:26:57 am »
The method you describe is the only one I know for sending variable-length HID reports though you could use Input/Output reports instead of Feature reports. You could define multiple reports of different lengths and have the host or device send whichever one comes closest to the report being sent.

Bulk transfers will be faster than HID on a bus that isn't busy but might be slower on a bus with a lot of traffic.

ulao

  • Frequent Contributor
  • ****
  • Posts: 172
Re: best practices sending a non fixed size report?
« Reply #2 on: May 07, 2018, 06:24:54 pm »
Oh wow, I learn so much from you.

Please  "more input" as Jonny 5 says.

1. You said "Input/Output reports instead of Feature" and then said "You could define multiple reports". Was this one thought or two? Reason I ask is there an advantage I'm not seeing using Input/Output that woudl not require a fixed size?

2. Bulk... I though they had to be guaranteed at the specified interval in the device description. Are you saying other devices on the buss can cause the packets not to hit the specified time?

3. One last thought I had. but I'm not sure if this would slow things down to a crawl. I guess just your best 2 cents on this idea. Keep my report at 32 bytes but send a byte counter. Telling the device how many to expect. The the software just sends consecutively, much like CAN. For that matter I could cut it down to 8. Though in many cases I will want to send 512 bytes with in a few hundred milliseconds. My fear is that it will send the chunk very spread apart and not full-fill my time window.
 
« Last Edit: May 07, 2018, 06:30:26 pm by ulao »

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: best practices sending a non fixed size report?
« Reply #3 on: May 08, 2018, 01:42:01 pm »
1. Input/Output reports are an alternative to Feature reports. With any report type, you can define multiple report IDs, with each report ID defining a report with a different length.

2. Bulk transfers have no guaranteed delivery time. HIDs can't use bulk transfers.

3. Yes, you could, for example, define a 32-byte report with the first byte specifying the sequence number of the report within a larger report and the second byte specifying the number of valid data bytes in the report. The recipient would then need to put the reports together. For example to send a 76-byte report using 32-byte reports:

01h, 1Fh, 30 data bytes
02h, 1Fh ,30 data bytes
03h, 10h, 16 data bytes, 14 pad bytes

Complete "mega-report" is 76 data bytes.

01h... next report begins


This is shoehorning a protocol into a class that was designed for fixed-length reports.