I would like to use USB host on ESP32-S2 in ESP-IDF

[ESP_Dazz]

So are you saying that the software driver does the periodic polling of INTR or the hardware with "repeating thingies" that I read about on hardware spec sheet? I'm asking because I want to know whether the responsibility of the INTR polling lies, with software or hardware.

Once an interrupt transfer (or IRP) is submitted, the hardware will be responsible for repeating each transaction until it gets a non-NAK response (either a >= 0 bytes data or a STALL).

On the software side of things, the IRP is supposed to represent an entire transfer. According to the USB2.0 spec (section 5.7.3):

A device can move data via an interrupt pipe that is larger than wMaxPacketSize. A software client can accept this data via an IRP for the interrupt transfer that requires multiple bus transactions without requiring an IRP-complete notification per transaction. This can be achieved by specifying a buffer that can hold the desired data size. The size of the buffer is a multiple of wMaxPacketSize with some remainder. The endpoint must transfer each transaction except the last as wMaxPacketSize and the last transaction is the remainder. The multiple data transactions are moved over the bus at the period established for the pipe.

This means that when an interrupt IRP is submitted to the HCD:

• The IRP is split down into multiple transactions, each one MPS sized (except for the last))

• The transactions are moved over the established period for the pipe (i.e., the bInterval of the pipe, usually 10ms per transaction for most low speed HID devices)

• If a transaction is NAKd, the hardware will automatically repeat the transaction at the next interval. It will continually be repeated until it receives a 0 length or longer data packet, a STALL, or is actively cancelled from software

• If a short packet is received, the transfer is considered complete (even if there are transactions of the transfer that have yet to be executed). The missing bytes from the unexecuted transactions will be reflected in the actual_num_bytes field of your IRP

The intent of HCD transparently splitting down the IRPs into multiple MPS transactions is that users can double (or N buffer) their interrupt transfers. For example, if I have an low speed HID mouse where:

• Code: Select all

  Endpoint Descriptor:
      bLength             7
      bDescriptorType     5
      bEndpointAddress    0x81  EP 1 IN
      bmAttributes        3
          Transfer Type   Interrupt
          Synch Type      None
          Usage Type      Data
      wMaxPacketSize      0x0004  1x 4 bytes
      bInterval           10
  

• Each IRP (transfer) will collect 10 HID mouse reports (4 MPS transactions)

Then I could allocate two IRPs, each with a buffer size of 10 * 4 (MPS) = 40 bytes. So while one IRP is being executed by the HCD, the other IRP can be parsed by the application

[chegewara]

But for now I would like to know if there is a special reason why you used a Descriptor Index of 1. It's not clear to me what it does.

SET_CONFIGURATION
When the host has got all the information it requires it loads a driver for the device based on the VID/PID combination in the device descriptor, or on the standard class defined there or in an interface descriptor.

The driver may also ask for the same or different information using Get Descriptor requests.

Eventually it will decide to configure the device using the SET_CONFIGURATION request. Usually ( when there is one configuration) the Set Configuration request will have wValue set to 1, which will select the first configuration.

Set Configuration can also be used, with wValue set to 0, to deconfigure the device.

https://www.usbmadesimple.co.uk/ums_4.htm

[tore-espressif]

Hello all,

We updated USB Host code with CDC driver and example, please have look here:
https://github.com/espressif/esp-idf/co ... 6e2ff79cd9

and let me know if it meets your requirements.