|
| 1 | +USB Host Driver (USBH) |
| 2 | +====================== |
| 3 | + |
| 4 | +Introduction |
| 5 | +------------ |
| 6 | + |
| 7 | +The USB Host Driver (henceforth referred to as USBH) provides a USB Host software interface which abstracts USB devices. The USBH interface provides APIs to... |
| 8 | + |
| 9 | +- manage the device pool (i.e., adding and removing devices) |
| 10 | +- address and configure a device (i.e., setting device and configuration descriptors) |
| 11 | +- submit transfers to a particular endpoint of a device |
| 12 | + |
| 13 | +Requirements |
| 14 | +------------ |
| 15 | + |
| 16 | +USB Specification Requirements |
| 17 | +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 18 | + |
| 19 | +Chapter 10 of the USB 2.0 specification outlines some requirements of the USBH (referred to as USBD in the specification). The design of the USBH takes into consideration these requirements from the specification. |
| 20 | + |
| 21 | +- Default pipe of a device is owned by the USBH |
| 22 | +- All other pipes are owned and managed by clients of the USBH |
| 23 | +- USBH interface must provide the following services |
| 24 | + |
| 25 | + - Configuration and command mechanism |
| 26 | + - Transfer services via both command and pipe mechanisms |
| 27 | + - Event notification |
| 28 | + - Status reporting and error recovery |
| 29 | + |
| 30 | +Host Stack Requirements |
| 31 | +^^^^^^^^^^^^^^^^^^^^^^^ |
| 32 | + |
| 33 | +In addition to the USB 2.0 specification requirements, the USBH also takes into consideration the requirements set for the overall Host Stack (see :doc:`./usb_host_notes_design`): |
| 34 | + |
| 35 | +- USBH must not instantiate any tasks/threads |
| 36 | +- USBH must be event driven, providing event callbacks and an event processing function |
| 37 | + |
| 38 | +Implementation & Usage |
| 39 | +---------------------- |
| 40 | + |
| 41 | +Events & Processing |
| 42 | +^^^^^^^^^^^^^^^^^^^ |
| 43 | + |
| 44 | +The USBH is completely event driven and all event handling is done via then ``usbh_process()`` function. The ``usbh_config_t.proc_req_cb`` callback provided on USBH installation will be called when processing is required. Typically, ``usbh_process()`` will be called from a dedicated thread/task. |
| 45 | + |
| 46 | +The USBH exposes the following event callbacks: |
| 47 | + |
| 48 | +- ``usbh_event_cb_t`` used to indicate various events regarding a particular device and control transfers to EP0. This callback is called from the context of ``usbh_process()`` |
| 49 | +- ``usbh_ep_cb_t`` used to indicate events for all other endpoints. This callback is not called from the ``usbh_process()`` context (currently called from an HCD interrupt context). |
| 50 | + |
| 51 | +Device Pool |
| 52 | +^^^^^^^^^^^ |
| 53 | + |
| 54 | +The USBH keeps track of all currently connected devices by internally maintaining a device pool (simply a linked list) where each device is represented by a device object. |
| 55 | + |
| 56 | +The USB 2.0 specification "assumes a specialized client of the USBD, called a hub driver, that acts as a clearinghouse for the addition and removal of devices from a particular hub". As a result, the USBH is completely reliant on an external client(s) (typically a Hub Driver) to inform the USBH of device addition and removal. The USBH provides the following APIs for device addition and removal: |
| 57 | + |
| 58 | +- ``usbh_devs_add()`` which will allocate a new device object and add it to the device pool. The newly added device will be unenumerated, meaning the device object will... |
| 59 | + |
| 60 | + - be assigned to address 0 |
| 61 | + - have no device and configuration descriptor |
| 62 | + |
| 63 | +- ``usbh_devs_remove()`` which will indicate to the USBH that a device has been removed (such as due to a disconnection or a port error). |
| 64 | + |
| 65 | + - If the device is not currently opened (i.e., used by one or more clients), the USBH will free the underlying device object immediately. |
| 66 | + - If the device is currently opened, a ``USBH_EVENT_DEV_GONE`` event will be propagated and the device will be flagged for removal. The last client to close the device will free the device object. |
| 67 | + - When a device object is freed, a ``USBH_EVENT_DEV_FREE`` event will be propagated. This event is used to indicate that the device's upstream port can be recycled. |
| 68 | + |
| 69 | +Device Enumeration |
| 70 | +^^^^^^^^^^^^^^^^^^ |
| 71 | + |
| 72 | +Newly added devices will need to be enumerated. The USBH provides various ``usbh_dev_set_...()`` functions to enumerate the device, such as assigning the device's address and setting device/configuration/string descriptors. Given that USBH devices can be shared by multiple clients, attempting to enumerate a device while another client has opened the device can cause issues. |
| 73 | + |
| 74 | +Thus, before calling any ``usbh_dev_set_...()`` enumeration function, a device must be locked for enumeration by calling ``usbh_dev_enum_lock()``. This prevents the device from being opened by any other client but the enumerating client. |
| 75 | + |
| 76 | +After enumeration is complete, the enumerating client can call ``usbh_devs_trigger_new_dev_event()`` to propagate a ``USBH_EVENT_NEW_DEV`` event. |
| 77 | + |
| 78 | +Device Usage |
| 79 | +^^^^^^^^^^^^ |
| 80 | + |
| 81 | +Clients that want to use a device must open the device by calling ``usbh_devs_open()`` and providing the device's address. The device's address can either be obtained from a ``USBH_EVENT_NEW_DEV`` event or by calling ``usbh_devs_addr_list_fill()``. |
| 82 | + |
| 83 | +Opening a device will do the following: |
| 84 | + |
| 85 | +- Return a ``usb_device_handle_t`` device handle which can be used to refer to the device in various USBH functions |
| 86 | +- Increment the device's internal ``open_count`` which indicates how many clients have opened the device. As long as ``open_count > 0``, the underlying device object will not be freed, thus guaranteeing that the device handle refers to a valid device object. |
| 87 | + |
| 88 | +Once a client no longer needs to use a device, the client should call ``usbh_devs_close()`` thus invalidating the device handle. |
| 89 | + |
| 90 | +.. note:: |
| 91 | + |
| 92 | + Most device related APIs accept ``usb_device_handle_t`` as an argument, which means that the calling client must have previously opened the device to obtain the device handle beforehand. This design choice is intentional in order to enforce an "open before use" pattern. |
| 93 | + |
| 94 | + However, a limited set of APIs (e.g., ``usbh_devs_remove()``) refer to devices using a Unique Identifier (``uid``) which is assigned on device addition (see ``usbh_devs_add()``). The use of ``uid`` in these functions allows their callers to refer to a device **without needing to open it** due to the lack of a ``usb_device_handle_t``. |
| 95 | + |
| 96 | + As a result, it is possible that a caller of a ``uid`` function may refer to a device that has already been freed. Thus, callers should account for a fact that these functions may return :c:macro:`ESP_ERR_NOT_FOUND`. |
| 97 | + |
| 98 | +Endpoints & Transfers |
| 99 | +^^^^^^^^^^^^^^^^^^^^^ |
| 100 | + |
| 101 | +USBH supports transfer to default (i.e., EP0) and non-default endpoints. |
| 102 | + |
| 103 | +For non-default endpoints: |
| 104 | + |
| 105 | +- A client must first allocate the endpoint by calling ``usbh_ep_alloc()`` which assigns a ``usbh_ep_cb_t`` callback and returns a ``usbh_ep_handle_t`` endpoint handle so that the endpoint can be referred to. |
| 106 | +- A client can then enqueue a ``urb_t`` transfer to the endpoint by calling ``usbh_ep_enqueue_urb()``. |
| 107 | +- The ``usbh_ep_cb_t`` callback is called to indicate transfer completion |
| 108 | +- The client must then dequeue the transfer using ``usbh_ep_dequeue_urb()`` |
| 109 | + |
| 110 | +Default endpoints are owned and managed by the USBH, thus API for control transfers are different: |
| 111 | + |
| 112 | +- EP0 is always allocated for each device, thus clients do no need to allocate EP0 or provide an endpoint callback. |
| 113 | +- Clients call should call ``usbh_dev_submit_ctrl_urb()`` to submit a control transfer to a device's EP0. |
| 114 | +- A ``USBH_EVENT_CTRL_XFER`` event will be propagated when the transfer is complete |
| 115 | +- Control transfers do not need to be dequeued |
0 commit comments