USB Host Device Resource Needs#
Configuring the USB Host module can be a challenge, as the configuration depends on the specifics of your application and the different devices you plan to connect. This guide is meant to help simplify the process of configuring the resources you need to allocate.
Run-Time Configurations#
Reference: USB Host Run-Time Application Specific Configurations .
General Configurations#
Below is an estimate of the length, in octets, needed for each device type for the configuration descriptor. If you plan to support more than one device type, use the largest size.
Optimize Speed Configurations#
These configurations are needed only if you set the configuration USBH_CFG_OPTIMIZE_SPD_EN to DEF_ENABLED. |
|---|
If you plan to support more than one device type, use the largest size.
Allocation at Initialization Configurations#
These configurations are needed only if you set the configuration USBH_CFG_INIT_ALLOC_EN to DEF_ENABLED. |
|---|
This is per device of each type. You must use the sum of all the devices.
*The control endpoints must also be taken into consideration and represent 1 endpoint per device.
A Note on Each Device Type#
Android Device#
In accessory mode, an Android device is composed of a single interface with two bulk endpoints. These resources must be taken into consideration when configuring the USB host core module.
Also note that, when switching to the accessory mode, the Android device may switch into debug mode. The debug interface will show up only if the debugging mode has been enabled on the Android device. Since the USB host module does not offer a class driver for the debug interface, the host core module will not attempt to open the endpoints or allocate class a function. However, the core module will have to allocate the resources to represent this functionality.
So, if your plan is to support any kind of Android devices, you have to take into considerations the case where a device will present the debug functionality when configuring the core module.
CDC ACM#
CDC ACM devices are special devices that use more than one interface per USB function. They are composed of one Communication Control Interface (CCI) and one or more (but generally only one) Data Control Interfaces. The CCI generally implements an interrupt endpoint and each DCI a pair of bulk endpoints.
HID#
A typical HID device (such as a mouse or keyboard) has only one interface/function, which implements only one interrupt endpoint. However, some HID device manufacturers use the same firmware for all their HID device types and present three different functionalities to the host: Mouse, keyboard, and vendor-specific interface. Even though only one function is useful, they must all be allocated. The numbers given in the table take those exceptions into consideration. If you plan on supporting only a limited set of HID devices and you know they don't use such generic firmware, you can reduce the numbers accordingly.
MSC#
MSC devices generally have very simple setups where only one function/interface and two bulk endpoints are declared. However, some MSC devices will declare an interrupt endpoint even though it is not used. This endpoint must be taken into consideration when configuring the value .EP_QtyTot.
USB-To-Serial#
The USB-To-Serial class driver supports USB-to-serial adapters that do not follow any standard approved by the USB Implementers Forum. Hence, each device manufacturers use different protocols and configurations. Hence, each type of adapters may have different needs. While adapters from FTDI and Silicon Laboratories have similar setups where there is one function/interface with two bulk endpoints per serial port on the device, the adapters from Prolific Technology use an extra interrupt endpoint for notifications.
External Hubs#
External hubs generally use only one function/interface per device with one interrupt endpoint. However, be aware that most external hubs that have more than 4 ports use multiple hubs. Hence, that must be taken into consideration when computing the needs in resources.
A Note on Composite Devices#
A composite device (multi-function device) is composed of several functionalities. When computing the device needs, each function should be treated as a different device, except for the .MaxDescLen, for which you should use the sum of all the functions.
A Note on Compound Devices#
Some common devices such as keyboards or media card readers embed a hub as well. They are called compound devices, as they are simply a hub with a permanently connected device (keyboard or MSC). That should be taken into consideration if you want to support any kind of devices.