Author Topic: making Bulk transfer to work  (Read 141 times)

danwaqar

  • Member
  • ***
  • Posts: 4
making Bulk transfer to work
« on: January 06, 2021, 10:43:31 pm »
hi

i have a custom hardware based on arm processors. the sdk has native support for usb.
The device is built and working is a speaker based on usb hid.
the communication to send high load packets such as FW upgrade take a lot of time because all communication is based on HID interrupt packets.
i wanted to switch it to bulk transfer. but i read that HID dont support bulk. can you please tell is there anyway forward to get this functionality here in that same hardware and FW with both HID and bulk working side by side.

Thanks
Dan

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 2959
    • Lakeview Research
Re: making Bulk transfer to work
« Reply #1 on: January 07, 2021, 12:05:50 am »
To support bulk transfers, the device will need to add an interface for a USB class or vendor-defined driver that supports bulk transfers, for example, cdc virtual COM port, mass storage, or WinUSB. The host software would communicate with the driver for the new interface.

There is a defined USB device firmware upgrade class, bit you would need to provide a driver for it.

The HID interface can coexist with a second interface.

danwaqar

  • Member
  • ***
  • Posts: 4
Re: making Bulk transfer to work
« Reply #2 on: January 07, 2021, 02:26:14 pm »
Jan

Thanks alot for your reply.
i have a endpoint (6) defined for bulk transfer in the FW. also the size of Bulk transfer max packet size is set as 512. number of bulk interface is set as 1.
still the device is failing to enumerate. but when i remove these values from FW, the hid device works fine. what bulk setting am i missing?

Renate

  • Frequent Contributor
  • ****
  • Posts: 56
Re: making Bulk transfer to work
« Reply #3 on: January 08, 2021, 08:47:19 am »
Does dmesg tell you anything (this is Linux, right?)
You are defining this as two interfaces?
Your first chore is to add this second interface without breaking the HID.
The second is to get the audio interface working.

Is the HID pushbuttons/volume whatever for the speaker?
Are you implementing all those audio descriptors?
If it's a normal audio you might need three interfaces total.

I've never done regular audio, but audio MIDI requires an audio interface (without any endpoints) and a MIDI interface (with one or two endpoints).

Edit:

I missed some things on the first reading.
You're talking about three things, HID, speaker, firmware upgrade?
Are you feeding audio data down HID to a speaker?
Wouldn't you want a regular audio isochronous interface?
« Last Edit: January 09, 2021, 07:22:00 am by Renate »

danwaqar

  • Member
  • ***
  • Posts: 4
Re: making Bulk transfer to work
« Reply #4 on: January 10, 2021, 05:55:06 pm »
Thank you for the email


the device is already fully functional
hid based speaker, isochronous endpoint working
yes the audio pushbutton stuff is done by hid command and the audio endpoints/descriptors and interfaces are there and working
right now the fw upgrade data is also sent using isochronous packets
i only want to increase the speed of this fw upgrade transfer with minimum changes that is why looking to send that data over bulk interface.
the host is windows
« Last Edit: January 10, 2021, 10:12:25 pm by danwaqar »

Renate

  • Frequent Contributor
  • ****
  • Posts: 56
Re: making Bulk transfer to work
« Reply #5 on: January 11, 2021, 01:34:22 pm »
The fw upgrade data is also sent using isochronous packets
Is the FW upgraded so often that anybody cares how long it takes? How big is the upgrade?
Are you using a custom Windows driver for all this?

WinUsb and a pair of bulk endpoints is the "greatest common denominator" for custom interfaces in the Windows world.

You could also just use Vendor-specific control transfers for the upgrade stuff.
This might be slower, but it means you don't need any other endpoints or descriptors.
The problem is, as far as I know, without a custom driver you only have WinUsb_ControlTransfer to send arbitrary control transfers.

Hmm, I've never tried, I wonder if you could bind a WinUsb driver to an interface without any endpoints?
I'll have to try that.