Reply
Posts: 32
Registered: ‎05-24-2017

USB Device with Multiple Configuration Descriptors

Hello,

 

I am investigating whether the HG will meet our application requirements and I do not see how the current USB stack would support a device that has multiple configurations. I also do not see how it would support interfaces with multiple alternate settings that reuse endpoints. So I come here with a few questions:

 

1. Does the current USB stack support more than on configuration?

2. Does the current USB stack support the reuse of endpoints across alternate settings of a particular interface?

3. Is there any documentation that states how much of the USB spec is supported? On examining the source it seems that only a limited subset is supported.

Posts: 194
Registered: ‎07-12-2016

Re: USB Device with Multiple Configuration Descriptors

hi @StevenEckhoff,

 

In fact, the configuration descriptor should be understood as part of the application code but not the USB stack. User can just modify the configuration/interface/endpoint descriptor depend on their requirement.
User can define more than one configuration in the descriptors.c, and select the correct one depend on their requirement. Currently, a lot of usb example code be provided in Simplicity Studio, for some special subset still need the user implement it by themselves.

 

My views are my own and do not necessarily represent the views of Silicon Labs

 

Thanks

Posts: 32
Registered: ‎05-24-2017

Re: USB Device with Multiple Configuration Descriptors

Assuming that the USB stack will support multiple configurations, then which calls from the API support it? The following is the only viable call that I see:

 

int USBD_Init( const USBD_Init_TypeDef *p )

This takes the argument:

 

typedef struct
{
  const USB_DeviceDescriptor_TypeDef      *deviceDescriptor;      /**< Pointer to a device descriptor.                */
  const uint8_t                           *configDescriptor;      /**< Pointer to a configuration descriptor.         */
  const void * const                      *stringDescriptors;     /**< Pointer to an array of string descriptor pointers.*/
  const uint8_t                           numberOfStrings;        /**< Number of strings in string descriptor array.  */
  const uint8_t                           *bufferingMultiplier;   /**< Pointer to an array defining the size of the
                                                                       endpoint buffers. The size is given in
                                                                       multiples of endpoint size. Generally a value
                                                                       of 1 (single) or 2 (double) buffering should be
                                                                       used.                                          */
  USBD_Callbacks_TypeDef_Pointer          callbacks;              /**< Pointer to struct with callbacks
                                                                       (@ref USBD_Callbacks_TypeDef). These callbacks
                                                                       are used by the device stack to signal events
                                                                       to or query the application.                   */
  const uint32_t                          reserved;               /**< Reserved for future use.                       */
} USBD_Init_TypeDef;

This only takes one configuration, so I assume that on receiving a SET_CONFIGURATION, that I would need to call USBD_Init() again with the desired configuration. 

 

Questions:

 

1. On receiving SET_CONFIGURATION is the USBD_Init() call sufficient for altering the devices configuration consistent with the USB spec?

2. Does the current USB stack support the reuse of endpoints across alternate settings of a particular interface? I implemented an interface in descriptors.c that had several alternate settings to support multiple sample rates and bit depths and the USB stack would just throw errors. On studying the errors I was able to modify the USB stack to allow initialization to go through. After this I was able to switch between alternate settings and play audio at several different rates. This was a hack and not suitable for production code, so I need clear statement about the stack's support or lack of support for sharing endpoints across alternated settings within one particular interface, which is supported by the spec. I am about to start investigating this issue deeper and it may warrant a thread of its own so I can document the entire issue clearly. Can you provide any more info on this?

3. Is there any documentation that states how much of the USB spec is supported? On examining the source it seems that only a limited subset is supported. I need something explicit that I can show my boss so he can decide to continue with this part or invest time in looking for an alternative.

Posts: 194
Registered: ‎07-12-2016

Re: USB Device with Multiple Configuration Descriptors

hi @StevenEckhoff,

 

Cool, did you modified the source code (em_usbdch9.c) of USB stack to support alternate interface settings ?
Currently, there is no support for alternate interface settings in the stack, however, user can just implement it by themselves.

Regard to the subset of usb devices, all of the example code be listed in the sdk of Simplicity Studio. And what's kind of subset you want to implement ?

 

My views are my own and do not necessarily represent the views of Silicon Labs

 

Thanks

Posts: 32
Registered: ‎05-24-2017

Re: USB Device with Multiple Configuration Descriptors

We may be talking about the same thing on the alternate settings. From my view the alternate settings work just fine with the current stack, but problems arise when you reuse the endpoints, which is mentioned in the spec. I have had to modify quite a lot to get the following to work:

 

1. Alternate settings to handle multiple audio parameters (sample rate and sample depth).

2. Asynchronous isochronous endpoints to support the host matching its rate to the codec rate.

 

Things left to do:

 

3. Handling set configuration commands, so endpoints can be reconfigured for different functions.

 

From my experience the USB stack does not support this out of the box, which has required me to dive in and modify code in the SDK.

 

I believe I have my answers.

 

Thank you for the help!