SILICON LABS USB Device Stack Instruction Manual

The USB device stack by Silicon Labs provides versatile and
easy-to-use USB connectivity for IoT projects, facilitating
communication between network co-processors and hosts.

Caratteristiche

Efficient USB device stack
Ideal for IoT projects
Support for communication between network co-processors and
ospiti

Istruzioni per l'uso del prodotto

USB Device Configuration

Configure the USB device settings according to your project
requirements by referring to the USB Device Configuration section
nella documentazione.

USB Device Programming Guide

Follow the USB Device Programming Guide to understand how to
program and interact with the USB device for various
applicazioni.

USB Device Classes

The USB Device Classes section provides an overview di diverso
classes like CDC ACM, HID, MSC SCSI, and Vendor Class. Choose the
appropriate class based on your device functionality.

USB Device Troubleshooting

If you encounter any issues with the USB device, refer to the
USB Device Troubleshooting section for solutions and debugging
suggerimenti.

Microsoft Windows OS USB Host

If you are using the USB device with a Microsoft Windows OS USB
Host, make sure to follow the guidelines provided in the
documentation for seamless integration.

Domande frequenti

D: Quali sono alcuni esempi comuni?amples of devices I can build using
this USB stack?

A: The USB stack allows you to build devices such as
USB-to-serial adapters, mice or keyboards, removable storage
devices, and custom devices.

Q: Are there any specific software requirements for using this
USB device stack?

A: Compatible software includes Simplicity SDK, Simplicity
Studio, Simplicity Commander, GCC (The GNU Compiler Collection),
IAR Embedded Workbench for ARM, and IAR EWARM.

View Fullscreen

Universal Serial Bus USB

USB Overview Sopraview
Release Notes USB
Specifications and Features Overview
USB Device Configuration Overview
USB Device Programming Guide Overview
USB Device Classes Overview CDC ACM Class Overview HID Class Overview MSC SCSI Class Overview Vendor Class Overview
USB API API Documentation USB Device API USB Device ACM API a sl_usbd_cdc_ cm_line_coding_t sl_usbd_cdc_acm_callbacks_t USB Device CDC API a sl_usbd_cdc_subcl ss_driver_t USB Device Core API
sl_usbd_device_config_t sl_usbd_setup_req_t
a sl_usbd_cl ss_driver_t USB Device HID API
sl_usbd_hid_callbacks_t USB Device MSC API
a sl_usbd_msc_subcl ss_driver_t USB Device MSC SCSI API
sl_usbd_msc_scsi_callbacks_t

1/174

Universal Serial Bus USB
a sl_usbd_msc_scsi_lun_ pi
sl_usbd_msc_scsi_lun_info sl_usbd_msc_scsi_lun
USB Device Vendor API sl_usbd_vendor_callbacks_t
API Documentation USB Device Troubleshooting
Sopraview Microsoft Windows OS USB Host
Sopraview

2/174

Sopraview
Sopraview
Dispositivo USB
USB is one of the most successful communication interfaces in the history of computer systems and is the de facto standard for connecting computer peripherals. Silicon Labs USB Device stack is a USB device module designed specifically for embedded systems. Built from the ground up with Silicon Labs’ quality, scalability, and reliability, it has gone through a rigorous validation process to comply with the USB 2.0 specification. This documentation describes how to initialize, start, and use Silicon Labs USB Device stack. It explains the various configuration values and their uses. It also includes an overview of the technology, types of configuration possibilities, implementation procedures, and examples of typical usage for every available class.
To help you understand the USB concepts quickly, the documentation features many examples of USB with basic functions. These examples will provide you with a framework that allows you to build devices quickly. These exampincludono:
USB-to-serial adapter (Communications Device Class) Mouse or keyboard (Human Interface Device Class) Removable storage device (Mass Storage Class) Custom device (Vendor Class)
Quello che segue è il finitoview of the documentation sections:
Specifications and Features USB Device Configuration USB Device Programming Guide USB Device Classes
CDC ACM Class HID Class MSC SCSI Class Vendor Class USB Device Troubleshooting Microsoft Windows OS USB Host

3/174

USB
USB

USB Version 1.5.1 July 21, 2025 – Release Notes
Simplicity SDK Version 2025.6.1
Silicon Labs’ efficient USB device stack offers versatile, easy-to-use USB connectivity ideal for IoT projects, including communication between network co-processors and hosts. Click here for earlier releases.
Riepilogo della versione
Key Features | API Changes | Bug Fixes | Chip Enablement
Caratteristiche principali
Underlying platform changes only.
Modifiche API
Nessuno.
Correzioni di bug
Nessuno.
Chip Enablement
Nessuno.
Caratteristiche principali
New Features | Enhancements | Removed Features | Deprecated Features
Nuove funzionalità
Nessuno.
Miglioramenti
Underlying platform changes only.
Removed Features
Nessuno.
Funzionalità obsolete
Nessuno.
Modifiche API
New APIs | Modified APIs | Removed APIs | Deprecated APIs
Nuove API

4/174

USB
Nessuno.
Modified APIs
Nessuno.
Removed APIs
Nessuno.
Deprecated APIs
Nessuno.
Correzioni di bug
Nessuno.
Chip Enablement
Nessuno.
Applicazione Example Changes
Nuovo esamples | Modified Examples | Removed Examples | Deprecated Examples
Nuovo esamples
Nessuno.
Ex modificatoamples
Nessuno.
Rimosso esamples
Nessuno.
Deprecated Examples
Nessuno.
Impact of Release Changes
Impact Statements | Migration Guide
Impact Statements
Nessuno.
Guida alla migrazione
Nessuno.
Problemi noti e limitazioni
Nessuno.
Utilizzo di questa versione

5/174

USB

What’s in the Release? | Compatible Software | Installation and Use | Help and Feedback

What’s in the Release?

USB Device Stack Application Examples
Software compatibile

Software
Simplicity SDK Simplicity Studio Simplicity Commander GCC The GNU Compiler Collection) IAR Embedded Workbench for ARM IAR EWARM

Compatible Version or Variant
2025.6.0 5.11.0 1.18.2 (provided with Simplicity Studio) 12.2.1 (provided with Simplicity Studio) 9.40.1 (provided with Simplicity Studio)

Installazione e utilizzo

To kick start your development see our:
USB Device Programming Guide. API Documentation.
For information about Secure Vault Integration, see Secure Vault.
per riview Security and Software Advisory notifications and manage your notification preferences:
ò Go to https://community.silabs.com/. ó Log in with your account credentials. ô Click your profile icon in the upper-right corner of the page.
õ Select Notifications from the dropdown menu. ö In the Notifications section, go to the My Product Notifications tab to review historical Security and Software Advisory
notifiche
÷ To manage your preferences, use the Manage Notifications tab to customize which product updates and advisories you
ricevere.
For recommended configuration settings, see here.
To learn more about the software in this release, dive into our online documentation.
Aiuto e feedback

Contact Silicon Labs Support. To use our Ask AI tool to get answers, see the search field at the top of this page.

Note: Ask AI is experimental.

Get help from our developer community.
Politica di rilascio e manutenzione dell'SDK
See our SDK Release and Maintenance Policy.

6/174

Sopraview
Sopraview
Specifiche
Complies with the “Universal Serial Bus specification revision 2.0” Implements the “Interface Association Descriptor Engineering Change Notice (ECN)” Transfer types
Control Bulk Interrupt USB classes Communication Device Class (CDC) Abstract Control Model (ACM) Human Interface Device (HID) Mass Storage Class (MSC) Vendor-specific class framework
Caratteristiche
Scalable to include only required features to minimize memory footprint Supports Full-speed (12 Mbit/s) Supports composite (multi-function) devices Supports multi-configuration devices Supports USB power-saving functionalities (device suspend and resume) Complete integration of Mass Storage Class into Micrium OS File System module Developed with CMSIS-RTOS2 abstraction layer so that it can work with different OSes. Silicon Labs GSDK comes with FreeRTOS and Micrium OS ports.

7/174

Sopraview
Sopraview

USB Device Configuration

This section discusses how to configure Silicon Labs USB Device. There are three groups of configuration parameters, as follows:
USB Device Core Configuration USB Device Information Configuration USB Device Hardware Configuration
USB Device Core Configuration
Silicon Labs USB Device can be configured at compile time via a set of #defines located in the sl_usbd_core_config.h file. USB Device uses #defines when possible because they allow code and data sizes to be scaled at compile time based on which features are enabled. This allows the read-only memory (ROM) and random-access memory (RAM) footprints of Silicon Labs USB Device to be adjusted based on your application’s requirements.
Recommended: Start the configuration process with the default values (highlighted in bold).
The sections below are organized based on the order in the template configuration file, sl_usbd_core_config.h.
Core Configuration Classes Configuration
Configurazione del core
Table – USB Device Core Configuration Constants

Constant Description

Valore predefinito

SL_USBD_TA SK_STACK_ SIZE

Configures the stack size in bytes of USBD core task

4096

SL_USBD_TA SK_PRIORIT Y

Configures the priority of USBD core task. This is a CMSIS-RTOS2 priority.

osPriorityHigh

SL_USBD_A UTO_START _USB_DEVIC E

If enabled, the USB device will be automatically started once the kernel is started and that 1 USBD core task is scheduled for the first time. If disabled, your application will need to call sl_usbd_core_start_device() when ready to be detected by the USB host.

SL_USBD_C The total number of configurations that will be added via the sl_usbd_add_configuration()

ONFIGURATI function.

ON_QUANTI

8/174

Sopraview

Costante
SL_USBD _INTERF ACE_QU ANTITY
SL_USBD _ALT_INT ERFACE_ QUANTI
TY
SL_USBD _INTERF ACE_GR
OUP_QU
ANTITA
SL_USBD _DESCRI
PTOR_Q
UNITÀ
SL_USBD _STRING _QUANTI
TY
SL_USBD _OPEN_E NDPOIN TS_QUA NTITY

Description The total number of USB interfaces to be added for all your configurations. This greatly depends on the class(es) used. For more information on how many interfaces a class instance requires, refer to the section “Resource Needs from core” of your class(es).
The total number of USB alternate interfaces to be added for all your configurations. This greatly depends on the class(es) used. This value must always be equal or greater than SL_USBD_INTERFACE_QUANTITY . For more information on how many alternate interfaces a class instance requires, refer to the section “Resource Needs from Core” of your class(es).
The total number of USB interface groups that will be added for all your configurations. This greatly depends on the class(es) used. For more information on how many interface groups requires a class instance, refer to the section “Resource Needs from Core” of your class(es).
The total number of Endpoint descriptors that will be added for all your configurations. This greatly depends on the class(es) used. For more information on how many endpoint descriptors a class instance requires, refer to “Number of endpoints” in the section “Resource Needs from Core” of your class(es). Note that the control endpoints don’t need to be considered here. The total number of USB strings. Setting the quantity to zero will disable the feature. Disabling this will cause the device to not store any USB description strings passed from the application. This means the host will be unable to retrieve the description strings (such as manufacturer and product name). The total number of opened endpoints per configuration. A device requires at least two opened endpoints for control transfers, but you must also add the endpoints of the class(es) used. For more information on how many opened endpoints a class instance requires, refer to “Number of endpoints” in the section “Resource Needs from Core” of your class(es).

Valore predefinito
10 10
2
20 30 20

Classes Configuration
Classes have specific compile-time configurations. Refer to USB Device Classes for more information.
USB Device Information Configuration

The sl_usbd_device_config.h configuration file regroups compile-time #define-s to set basic information regarding your device, such as Vendor/Product ID, device strings, etc. The table below describes each information configuration define available in this configuration file.

Table – USB Device Information Configuration Defines

Costante
SL_USBD_DEVIC E_VENDOR_ID
SL_USBD_DEVIC E_PRODUCT_ID

Description Your vendor identification number as delivered by the USB Implementers Forum. For more information on how you can obtain a vendor ID, see http://www.usb.org/developers/vendor/ . Your product identification number.

9/174

Sopraview

Costante

Descrizione

SL_USBD_DEVICE_RELEASE Release number of your device. _NUMBER

SL_USBD_DEVICE_MANUFA String describing the manufacturer of your device. This configuration is ignored when the

CTURER_STRING

configuration SL_USBD_STRING_QUANTITY is set to 0.

SL_USBD_DEVICE_PRODUC String describing your product. This configuration is ignored when the configuration

T_STRING

SL_USBD_STRING_QUANTITY is set to 0.

SL_USBD_DEVICE_SERIAL_N String containing the serial number of your device. This configuration is ignored when the

UMBER_STRING

configuration SL_USBD_STRING_QUANTITY is set to 0.

SL_USBD_DEVICE_LANGUA Identification number of the language of your device’s strings. Possible values are:
GE_ID

– SL_USBD_LANG_ID_ARABIC_SAUDI_ARABIA

– SL_USBD_LANG_ID_CHINESE_TAIWAN

– SL_USBD_LANG_ID_ENGLISH_US

– SL_USBD_LANG_ID_ENGLISH_UK

– SL_USBD_LANG_ID_FRENCH

– SL_USBD_LANG_ID_GERMAN

– SL_USBD_LANG_ID_GREEK

– SL_USBD_LANG_ID_ITALIAN

– SL_USBD_LANG_ID_PORTUGUESE

– SL_USBD_LANG_ID_SANSKRIT

This configuration is ignored when the configuration SL_USBD_STRING_QUANTITY is set to 0.

USB Device Hardware Configuration

Depending on the Silicon Labs device you are using, you will possibly have the GPIO pin and port to configure for USB VBUS Sense signal. The configuration defines are in the sl_usbd_hardware_config.h header file.

Costante
SL_USBD_DRIVER_VBUS_SENSE_PORT SL_USBD_DRIVER_VBUS_SENSE_PIN

Descrizione
GPIO Port for the USB VBUS Sense signal on your board. GPIO Pin for the USB VBUS Sense signal on your board.

10/174

Sopraview
Sopraview
USB Device Programming Guide
This section explains how to use the USB Device module.
Initial Setup of USB Device Module
This section describes the basic steps required to initialize the USB Device module and to add, prepare, and start a device. Initializing the USB Device Module Initializing the USB Device Core Initializing the aCl ss(es) Adding Your USB Device Building Your USB Device Adding Configuration(s) Adding USB Function(s) Starting Your USB Device
Event Hook Functions
Initializing the USB Device Module
Initializing the USB Device Core
a US a Begin by initi lizing the B device module core by c lling the function sl_usbd_core_init() . T a a he ex mple below shows c lling sl_usbd_core_init() .
Example – Calling sl_usbd_core_init()
sl_status_t status; status = sl_usbd_core_init(); if (status ! SL_STATUS_OK) { /* An error occurred. Error handling should be added here. */
}
Initializing the Class(es)
After the USB device module core has been initialized, you must initialize each class you intend to use. See section “Programming Guide” of your acl ss(es) for more information.
Building Your USB Device
Adding Configuration(s)
After you successfully initialize your device, you can start adding the USB functions to it, starting with a new configuration. A device must have at least one configuration. To add a configur tion(s), call the function a a sl_usbd_core_ dd_configur tion() function. This function must be called for each configuration you want to add. The example below shows how to add a Full-speed.
Example – Adding Configuration(s) to Your Device

11/174

Sopraview

sl_status_t status; uint8_t config_nbr_fs;

/* Adding a full-speed configuration to the device. */

status = sl_usbd_core_add_configuration(0,

/* No special attributes to the configuration. */

100u,

/* Max power consumption: 100mA.

SL_USBD_DEVICE_SPEED_FULL,

/* Full-Speed configuration.

“Config Add Example Full-Speed config”,

&config_nbr_fs);

if (status ! SL_STATUS_OK) {

/* An error occurred. Error handling should be added here. */

}

Adding USB Function(s)
After you have successfully added at least one configuration to your device, you can add the interfaces and endpoints to your device. Each USB class has its own needs in terms of interface and endpoints type, quantity, and other parameters. Silicon Labs USB Device adds interfaces and endpoints in the classes it offers.
From your application, you can instantiate a USB class and add it to a configuration. For more information on the concept of USB device class instances, see USB Device Classes. Note that you can instantiate and add many different class instances to a configuration to create a multi-function (composite) device.
L'example below shows how to create a class instance and add it to a configuration.
Example – Adding a Class Instance to Your Device

sl_status_t status; uint8_t class_nbr;
/* Create an instance of the class you want to use.*/ /* Note that depending on the class this function can have more arguments. */ status = sl_usbd_<class>_create_instance(&class_nbr); if (status ! SL_STATUS_OK) { /* An error occurred. Error handling should be added here. */ }
/* Add the class instance to the Full-Speed configuration. */ status = sl_usbd_<class>_add_to_configuration(class_nbr, /* Class number returned by sl_usbd_<class>_create_instance. */
config_nbr_fs); /* Configuration number returned by sl_usbd_core_add_configuration(). */ if (status ! SL_STATUS_OK) { /* An error occurred. Error handling should be added here. */ }
Starting Your USB Device
By default, the device will be started automatically by the USB device core task after the device initialization is completed and the kernel started. To control when the device is started and becomes visible by the USB host, use the configuration define SL_USBD_AUTO_START_USB_DEVICE to disable the auto-start feature. When disabled, after you have built/prepared your device, you can start it and make it visible to the USB host by calling the function sl_usbd_core_start_device() .
L'example below shows how to start your device using the sl_usbd_core_start_device() function.
Example – Starting Your Device

12/174

Sopraview

sl_status_t status;
status = sl_usbd_core_start_device(); if (status ! SL_STATUS_OK) { /* An error occurred. Error handling should be added here. */ }

Event Hook Functions
The USB Device core module offers two weak hook functions that you can re-defined in your application. Their purpose is to notify when bus and configuration events occur.
Table – USB Event Hook Functions

Evento

Descrizione

Autobus

Called when USB Bus event occurs

Configuration Called when USB Configuration event occurs

Function Signature
void sl_usbd_on_bus_event(sl_usbd_bus_event_t event); void sl_usbd_on_config_event(sl_usbd_config_event_t event, uint8_t config_nbr);

Example – Event Hook Functions

void sl_usbd_on_bus_event(sl_usbd_bus_event_t event) { switch (event) { case SL_USBD_EVENT_BUS_CONNECT:
// called when USB cable is inserted in a host controller break;
case SL_USBD_EVENT_BUS_DISCONNECT: // called when USB cable is removed from a host controller break;
case SL_USBD_EVENT_BUS_RESET: // called when the host sends reset command break;
case SL_USBD_EVENT_BUS_SUSPEND: // called when the host sends suspend command break;
case SL_USBD_EVENT_BUS_RESUME: // called when the host sends wake up command break;
default: break; } }
void sl_usbd_on_config_event(sl_usbd_config_event_t event, uint8_t config_nbr) { switch (event) { case SL_USBD_EVENT_CONFIG_SET:
// called when the host sets a configuration break;
case SL_USBD_EVENT_CONFIG_UNSET: // called when a configuration is unset break;
default: break; } }

13/174

Sopraview

14/174

Sopraview
Sopraview

USB Device Classes

The USB classes available in Silicon Labs USB Device share some common characteristics. This section explains these characteristics and their interactions with the core layer.
For more information on a specific class, see the following:
CDC ACM Class HID Class MSC SCSI Class Vendor Class
About Class Instances
The USB classes available in USB Device implement the concept of class instances. A class instance represents one function within a device. The function can be described by one interface or by a group of interfaces and belongs to a specific class.
Each USB class implementation has some configurations and functions in common, based on the concept of class instance. The common configurations and functions are presented in the table below. In the column title ‘Constants or Function’, the placeholder XXXX can be replaced by the name of the class: CDC, HID, MSC, CDC_ACM or VENDOR (Vendor for function names).
Table – Constants and Functions Related to the Concept of Multiple Class Instances

Constant or Function
SL_USBD_XXXX_CL ASS_INS TANCE_QUANTITY
SL_USBD_XXXX_CONFIGUR ATION_QUANTITY
sl_usb d _XXXX_cre ate _insta nce ()
sl_usbd_XXXX_add_to_conf iguration()

Descrizione
Configures the maximum number of class instances.
Configures the maximum number of configurations. During the class initialization, a created class instance will be added to one or more configurations. Creates a new class instance.
Adds an existing class instance to the specified device configuration.

In terms of code implementation, the class will declare a local global variable that contains a class control structure. This class control structure is associated with one class instance and will contain specific information to manage the class instance.
The following figures show several case scenarios. Each figure includes a code example that corresponds to the case scenario.
Figure – Multiple Class Instances – FS Device (1 Configuration with 1 Interface) represents a typical USB device. The device is Full-Speed (FS) and contains a single configuration. The function of the device is described by one interface composed of a pair of endpoints for data communication. One class instance is created and will allow you to manage the entire interface with its associated endpoint.
Figure – Multiple Class Instances – FS Device 1 Configuration with 1 Interface)

15/174

Sopraview

The code corresponding to Figure – Multiple Class Instances – FS Device (1 Configuration with 1 Interface) is shown in the exampqui sotto.
Example – Multiple Class Instances – FS Device 1 Configuration with 1 Interface)

sl_status_t status; uint8_t class_0;

void app_usbd_XXXX_enable(uint8_t class_nbr) { /* Handle Class enable event. */ }

void app_usbd_XXXX_disable(uint8_t class_nbr) { /* Handle Class disable event. */ }

sl_usbd_XXXX_callbacks_t class_callbacks = {

(1)

.enable = app_usbd_XXXX_enable,

.disable = app_usbd_XXXX_disable

};

status = sl_usbd_XXXX_init();

(2)

if (status ! SL_STATUS_OK) {

/* $$$$ Handle the error. */

}

status = sl_usbd_XXXX_create_instance(&class_callbacks,

(3)

&class_0);

if (status ! SL_STATUS_OK) {

/* $$$$ Handle the error. */

}

status = sl_usbd_XXXX_add_to_configuration(class_0, config_0);

(4)

if (status ! SL_STATUS_OK) {

/* $$$$ Handle the error. */

}

(1) Every class offers a set of callback functions for device connect/disconnect events and for class specific events. The callback structure object is passed as argument when creating the class instance with sl_usbd_XXXX_create_instance()
funzione.
(1) Initialize the class. All internal variables, structures, and class ports will be initialized. Note that the Init() function in some classes may take other arguments.

16/174

Sopraview
(2) Create the class instance, which is class_0 . The function sl_usbd_XXXX_create_instance() allocates a class control structure associated with class_0 . Depending on the class, sl_usbd_XXXX_create_instance() may have additional parameters aside from the class number that represent class-specific information stored in the class control structure. a a a (3) Add the cl ss inst nce, class_0 , to the specified configur tion number, config_0 . sl_usbd_XXXX_add_to_configuration() will create the interface 0 and its associated IN and OUT endpoints. As a result, the class instance encompasses the interface 0 and its endpoints. Any communication done on the interface 0 will use the class instance number, class_0 . Figure – Multiple Class Instances – FS Device (2 Configurations and Multiple Interfaces) represents a more complex example. A full-speed device is composed of two configurations. The device has two functions which belong to the same class, but each function is described by two interfaces and has a pair of bidirectional endpoints. In this example, two class instances are created. Each class instance is associated with a group of interfaces as opposed to Figure – Multiple Class Instances – FS Device (1 Configuration with 1 Interface) and Figure – Multiple Class Instances – FS Device (2 Configurations and Multiple Interfaces) where the class instance was associated with a single interface.
Figure – Multiple Class Instances – FS Device 2 Configurations and Multiple Interfaces)

The code corresponding to Figure – Multiple Class Instances – FS Device (2 Configurations and Multiple Interfaces) is shown in the example below. The error handling is omitted for clarity.
Example – Multiple Class Instances – FS Device 2 Configurations and Multiple Interfaces)

17/174

Sopraview

sl_status_t status; uint8_t class_0; uint8_t class_1;
status = sl_usbd_XXXX_init();
status = sl_usbd_XXXX_create_instance(&class_0); status = sl_usbd_XXXX_create_instance(&class_1);
status = sl_usbd_XXXX_add_to_configuration(class_0, cfg_0); status = sl_usbd_XXXX_add_to_configuration(class_1, cfg_0);
status = sl_usbd_XXXX_add_to_configuration(class_0, cfg_1); status = sl_usbd_XXXX_add_to_configuration(class_1, cfg_1);

(1)
(2) (3)
(4) (5)
(6) (6)

(1) Initialize the class. Any internal variables, structures, and class ports will be initialized.
(2) Create the class instance, class_0 . The function sl_usbd_XXXX_create_instance() allocates a class control structure associated with class_0 .
(3) Create the class instance, class_1 . The function sl_usbd_XXXX_create_instance() allocates another class control structure associated with class_1 .
(4) Add the class instance, class_0 , to the configuration, cfg_0 . sl_usbd_XXXX_add_to_configuration() will create the interface 0, interface 1, alternate interfaces, and the associated IN and OUT endpoints. The class instance number, class_0 , will be used for any data communication on interface 0 or interface 1.
(5) Add the class instance, class_1 , to the configuration, cfg_0 . sl_usbd_XXXX_add_to_configuration() will create the interface 2, interface 3 and their associated IN and OUT endpoints. The class instance number, class_1 , will be used for any data communication on interface 2 or interface 3.
(6) Add the same class instances, class_0 and class_1 , to the other configuration, cfg_1 .
Every class defines structure of type sl_usbd_XXXX_callbacks_t . Its purpose is to give every class a set of callback functions to be called when event occurs. Two callback functions are present in each class. They are presented in the table bellow.
Table – Common Class Callback Functions

Fields Description .enable Called when the USB class instance is enabled successfully. .disable Called when the USB class instance is disabled.

Function Signature void app_usbd_XXXX_enable(uint8_t class_nbr); void app_usbd_XXXX_disable(uint8_t class_nbr);

18/174

Sopraview
Sopraview
USB Device CDC ACM Class
USB Device CDC Base Class Overview USB Device CDC ACM Class Resource Needs from Core USB Device CDC ACM Subclass Overview USB Device CDC ACM Class Configuration USB Device CDC ACM Class Programming Guide
This section describes the Communications Device Class (CDC) class and the associated CDC subclass supported by Silicon Labs’ USB Device stack. Silicon Labs USB-Device currently supports the Abstract Control Model (ACM) subclass, which is commonly used for serial emulation.
CDC includes various telecommunication and networking devices. Telecommunication devices encompass analog modems, analog and digital telephones, ISDN terminal adapters, etc. For example, networking devices contain ADSL and cable modems, Ethernet adapters, and hubs. CDC defines a framework to encapsulate existing communication services standards, such as V.250 (for modems over telephone network) and Ethernet (for local area network devices), using a USB link. A communication device is in charge of device management, call management when needed, and data transmission.
CDC defines seven major groups of devices. Each group belongs to a model of communication, which may include several subclasses. Each group of devices has its own specification document besides the CDC base class. The seven groups are:
Public Switched Telephone Network (PSTN), devices including voiceband modems, telephones, and serial emulation devices. Integrated Services Digital Network (ISDN) devices, including terminal adaptors and telephones. Ethernet Control Model (ECM) devices, including devices supporting the IEEE 802 family (ex.: cable and ADSL modems, WiFi adapters). Asynchronous Transfer Mode (ATM) devices, including ADSL modems and other devices connected to ATM networks (workstations, routers, LAN switches). Wireless Mobile Communications (WMC) devices, including multi-function communications handset devices used to manage voice and data communications. Ethernet Emulation Model (EEM) devices which exchange Ethernet-framed data. Network Control Model (NCM) devices, including high-speed network devices (High Speed Packet Access modems, Line Terminal Equipment)
The CDC and the associated subclass implementation complies with the following specifications:
Universal Serial Bus, Class Definitions for Communications Devices, Revision 1.2, November 3 2010. Universal Serial Bus, Communications, Subclass for PSTN Devices, Revision 1.2, February 9 2007.
USB Device CDC Base Class Overview
A CDC device is composed of the following interfaces to implement communication capability:
Communications Class Interface (CCI) is responsible for the device management and optionally the call management. The
device management enables the general configuration and control of the device and the notification of events to the host. The call management enables calls establishment and termination. Call management might be multiplexed through a DCI. A CCI is mandatory for all CDC devices. It identifies the CDC function by specifying the communication model supported by the CDC device. The interface(s) following the CCI can be any defined USB class interface, such as Audio or a vendor-specific interface. The vendor-specific interface is represented specifically by a DCI.
Data Class Interface (DCI) is responsible for data transmission. Data transmitted and/or received do not follow a specific
format. Data could be raw data from a communication line, data following a proprietary format, etc. All the DCIs following the CCI can be seen as subordinate interfaces.
A CDC device must have at least one CCI and zero or more DCIs. One CCI and any subordinate DCI together provide a feature to the host. This capability is also referred to as a function. In a CDC composite device, you could have several

19/174

Sopraview
functions. Therefore, the device would be composed of several sets of CCI and DCI(s) as shown in Figure – CDC Composite Device.
Figure – CDC Composite Device

A CDC device is likely to use the following combination of endpoints:
A pair of control IN and OUT endpoints called the default endpoint. An optional bulk or interrupt IN endpoint. A pair of bulk or isochronous IN and OUT endpoints. Note that Silicon Labs USB device stack does not currently support isochronous endpoints.
The table below shows the usage of the different endpoints and by which interface of the CDC they are used.
Table – CDC Endpoint Usage

Punto finale
Controllo IN
Controllo OUT
Interrupt or bulk IN Bulk or isochronous IN Bulk or isochronous
FUORI

Direzione
Deviceto-host
Host-todevice
Deviceto-host
Deviceto-host
Host-todevice

Utilizzo dell'interfaccia

CCI

Standard requests for enumeration, class-specific requests, device

management, and optionally call management.

CCI

Standard requests for enumeration, class-specific requests, device

management, and optionally call management.

CCI

Events notification, such as ring detect, serial line status, network status.

DCI

Raw or formatted data communication.

DCI

Raw or formatted data communication.

Most communication devices use an interrupt endpoint to notify the host of events. Isochronous endpoints should not be used for data transmission when a proprietary protocol relies on data retransmission in case of USB protocol errors. Isochronous communication can inherently lose data since it has no retry mechanisms.
The seven major models of communication encompass several subclasses. A subclass describes the way the device should use the CCI to handle the device management and call management. The table below shows all the possible subclasses and the communication model they belong to.
Table – CDC Subclasses

Subclass
Direct Line Control Model Abstract Control Model

Communication Model
Linea telefonica pubblica
Linea telefonica pubblica

Example of Devices Using This Subclass
Modem devices directly controlled by the USB host
Serial emulation devices, modem devices controlled through a serial command set

20/174

Sopraview

Subclass

Communication Model

Example of Devices Using This Subclass

Telephone Control Model

Linea telefonica pubblica

Multi-Channel Control ISDN Model

CAPI Control Model ISDN

Ethernet Networking ECM Control Model

ATM Networking

ATM

Modello di controllo

Wireless Handset Control Model

WMC

Device Management WMC

Mobile Direct Line Model

WMC

OBEX

WMC

Ethernet Emulation EEM Model

Modello di controllo della rete

NCM

Voice telephony devices
Basic rate terminal adaptors, primary rate terminal adaptors, telephones
Basic rate terminal adaptors, primary rate terminal adaptors, telephones DOC-SIS cable modems, ADSL modems that support PPPoE emulation, Wi-Fi adaptors (IEEE 802.11-family), IEEE 802.3 adaptors ADSL modems
Mobile terminal equipment connecting to wireless devices
Mobile terminal equipment connecting to wireless devices Mobile terminal equipment connecting to wireless devices
Mobile terminal equipment connecting to wireless devices Devices using Ethernet frames as the next layer of transport. Not intended for routing and Internet connectivity devices IEEE 802.3 adaptors carrying high-speed data bandwidth on network

USB Device CDC ACM Class Resource Needs from Core

Each time you add a CDC ACM class instance to a USB configuration via a call to the function sl_usbd_cdc_acm_add_to_configuration() , the following resources will be allocated from the core.

Risorsa
Interfaces Alternate interfaces Endpoints Interface groups

Quantità
2 2 3 1

Note that those numbers are per configuration. When setting up your SL_USBD_INTERFACE_QUANTITY , SL_USBD_ALT_INTERFACE_QUANTITY , SL_USBD_INTERFACE_GROUP_QUANTITY and SL_USBD_DESCRIPTOR_QUANTITY configuration values, don’t forget to take into account on how many configurations the class will be added. For the SL_USBD_OPEN_ENDPOINTS_QUANTITY configuration value, since endpoints are opened only when a configuration is set by the host, you just need to take into account the number of needed endpoints for a class instance.
USB Device CDC ACM Subclass Overview

The CDC base class is composed of a Communications Class Interface (CCI) and Data Class Interface (DCI), which is discussed in detail in USB Device CDC Base Class Overview . This section discusses a CCI of type ACM. It consists of a default endpoint for the management element and an interrupt endpoint for the notification element. A pair of bulk endpoints is used to carry unspecified data over the DCI.
The ACM subclass is used by two types of communication devices:
Devices supporting AT commands (for instance, voiceband modems). Serial emulation devices which are also called Virtual COM port devices.
There are several subclass-specific requests for the ACM subclass. They allow you to control and configure the device. The complete list and description of all ACM requests can be found in the specification <Universal Serial Bus, Communications,

21/174

Sopraview Subclass for PSTN Devices, revision 1.2, February 9, 2007=, section 6.2.2.
From this list, Silicon Labs9 ACM subclass supports the following:
Table – ACM Requests Supported by Silicon Labs

Subclass Request Description

SetCommFeature GetCommFeature ClearCommFeature

The host sends this request to control the settings for a given communications feature. Not used for serial emulation.
The host sends this request to get the current settings for a given communications feature. Not used for serial emulation.
The host sends this request to clear the settings for a given communications feature. Not used for serial emulation.

SetLineCoding

The host sends this request to configure the ACM device settings: baud rate, number of stop bits, parity type and number of data bits. For a serial emulation, this request is sent automatically by a serial terminal each time you configure the serial settings for an open virtual COM port.

GetLineCoding

The host sends this request to get the current ACM settings (baud rate, stop bits, parity, data bits). For a serial emulation, serial terminals send this request automatically during virtual COM port opening.

SetControlLineState The host sends this request to control the carrier for half-duplex modems and indicate that Data Terminal Equipment (DTE) is ready or not. In the serial emulation case, the DTE is a serial terminal. For a serial emulation, certain serial terminals allow you to send this request with the controls set.

SetBreak

The host sends this request to generate an RS-232 style break. For a serial emulation, certain serial terminals allow you to send this request.

Silicon Labs9 ACM subclass uses the interrupt IN endpoint to notify the host about the current serial line state. The serial
line state is a bitmap informing the host about:

Data discarded because of overrun Parity error Framing error State of the ring signal detection State of break detection mechanism State of transmission carrier State of receiver carrier detection

Silicon Labs9 ACM subclass implementation complies with the following specification:
Universal Serial Bus, Communications, Subclass for PSTN Devices, revision 1.2, February 9, 2007.
USB Device CDC ACM Class Configuration

This section discusses how to configure the CDC ACM Class (Communication Device Class, Abstract Control Model). There are two groups of configuration parameters:
USB Device CDC ACM Class Application Specific Configurations USB Device CDC ACM Class Instance Configurations
USB Device CDC ACM Class Application Specific Configurations

CDC Base Class ACM Subclass
CDC Base Class

First, to use the Silicon Labs USB device CDC class module, you will need to adjust the CDC compile-time configuration #define-s according to your application needs. They are regrouped inside the sl_usbd_core_config.h header file under the CDC section. Their purpose is to inform the USB device module about how many USB CDC objects to allocate.

22/174

Sopraview

The table below describes each configuration field available in this configuration structure.
Table – USB Device CDC Configuration Defines

Nome configurazione
SL_USBD_CDC_CL AS S_INSTANCE_QUANT ITY
SL_USBD_CDC_CONF IGURATION_QUANTI
TY
SL_USBD_CDC_DATA _INTERFACE_QUANTI
TY

Descrizione
Number of class instances you will allocate via a call to the function
sl_usbd_cdc_acm_create_instance() .
Number of configurations. ACM class instances can be added to one or more a a a a configur tions vi c ll to the sl_usbd_cdc_acm_add_to_configuration() .
Total number of data interfaces (DCI) for all the CDC functions. Each CDC ACM function a a a a a a a a a dded vi c ll to the function sl_usbd_cdc_acm_create_instance() will dd d t interf ce.

Valore predefinito
2
1
2

ACM Subclass
The ACM subclass has one compile-time configuration shown in the table below.
Table – USB Device CDC ACM Configuration Define

Nome configurazione
SL_USBD_CDC_ACM_SUBCL ASS_I NSTANCE_QUANTITY

Descrizione
Configures the number of subclass instances you will allocate via a call to the
function sl_usbd_cdc_acm_create_instance() .

Valore predefinito
2

USB Device CDC ACM Class Instance Configurations

This section defines the configurations related to the CDC ACM serial class instances. Class Instance Creation line state interval call mgmt capabilities p_acm_callbacks
Class Instance Creation

To create a CDC ACM serial class instance, call the function T a sl_usbd_cdc_acm_create_instance() . his function t kes three configuration arguments, as described here.

line_state_interval
This is the interval (in milliseconds) that your CDC ACM serial class instance will report the line state notifications to the T a a host. his v lue must be power of two (1, 2, 4, 8, 16, etc).

call_mgmt_capabilities
Call Management Capabilities bitmap. Possible values of the bitmap are as follows:

Value (bit)
SL_USBD_ACM_SERIAL_CALL_MGMT_DEV
SL_USBD_ACM_SERIAL_CALL_MGMT_DATA_CCI _DCI

Descrizione
Device handles call management itself. Device can send/receive call management information over a Data Class interface.

p_acm_callbacks

23/174

Sopraview

a a M a a p_acm_callbacks is pointer to structure of type sl_usbd_cdc_acm_callbacks_t . Its purpose is to give the CDC AC Cl ss set of callback functions to be called when a CDC ACM event occurs. Not all callbacks are mandatory and a null pointer ( NULL ) can be passed in the callbacks structure variable when the callback is not needed. The table below describes each configuration field available in this configuration structure.
Table – sl_usbd_cdc_acm _callbacks_t Configuration Structure

Campi

Descrizione

.enable

Called when the USB class instance is enabled

con successo.

.disable

Called when the USB class instance is disabled.

.line_control_changed Called when a line control change is received.

line_coding_changed Called when a line coding change is received.

Function Signature
void app_usbd_cdc_acm_enable(uint8_t subclass_nbr);
void app_usbd_cdc_acm_disable(uint8_t subclass_nbr);
void app_usbd_cdc_acm_line_control_changed(uint8_t subclass_nbr, uint8_t event, uint8_t event_chngd); bool app_usbd_cdc_acm_line_coding_changed(uint8_t subclass_nbr, subclass_nbr, sl_usbd_cdc_acm_line_coding_t
*p_line_coding

See section Registering Event Notification Callbacks for callback functions examplui.
USB Device CDC ACM Class Programming Guide

This section explains how to use the CDC Abstract Control Model class. Initializing the USB Device CDC ACM Class Adding a USB Device CDC ACM Class Instance to Your Device Communicating Using the CDC ACM Class
Initializing the USB Device CDC ACM Class

To add CDC ACM class functionality to your device, you must first initialize the CDC base class and the ACM subclass by a a c lling the functions sl_usbd_cdc_init() nd sl_usbd_cdc_acm_init() . T a a a a a he ex mple below shows how to c ll sl_usbd_cdc_init() nd sl_usbd_cdc_acm_init() using def ult rguments.

Example – Initialization of CDC ACM Class

sl_status_t status;
status = sl_usbd_cdc_init(); if (status ! SL_STATUS_OK) { /* An error occurred. Error handling should be added here. */
}
status = sl_usbd_cdc_acm_init(); if (status ! SL_STATUS_OK) { /* An error occurred. Error handling should be added here. */
}
Adding a USB Device CDC ACM Class Instance to Your Device
To add CDC ACM class functionality to your device, you must create an instance, then add it to your device’s configuration(s).
Creating a CDC ACM Class Instance

24/174

Sopraview
Adding the CDC ACM Class Instance to Your Device’s Configuration(s) Registering Event Notification Callbacks
Creating a CDC ACM Class Instance
a a M a a a Cre te CDC AC cl ss inst nce by c lling the function sl_usbd_cdc_acm_create_instance() . T a a a M a a a he ex mple below shows how to cre te CDC AC cl ss inst nce vi sl_usbd_cdc_acm_create_instance() .
Example – Creating a CDC ACM Function via sl_usbd_cdc_acm_create_instance()

uint8_t subclass_nbr; sl_status_t status;
status = sl_usbd_cdc_acm_create_instance(64u, SL_USBD_ACM_SERIAL_CALL_MGMT_DATA_CCI_DCI | SL_USBD_ACM_SERIAL_CALL_MGMT_DEV, NULL, &subclass_nbr);
if (status ! SL_STATUS_OK) { /* An error occurred. Error handling should be added here. */
}
Adding the CDC ACM Class Instance to Your Device’s Configuration(s)
After you have created a CDC ACM class instance, you can add it to a configuration by calling the function
sl_usbd_cdc_acm_add_to_configuration() .
T a a he ex mple below shows how to c ll sl_usbd_cdc_acm_add_to_configuration() .
Example – Call to USBD ACM sl_usbd_cdc_acm_add_to_configuration()

sl_status_t status;

status = sl_usbd_cdc_acm_add_to_configuration(subclass_nbr,

(1)

config_nbr_fs);

(2)

if (status ! SL_STATUS_OK) {

/* An error occurred. Error handling should be added here. */

}

a a a (1) Cl ss number to dd to the configur tion returned by sl_usbd_cdc_acm_create_instance() . (2) Configuration number (here adding it to a Full-Speed configuration).
Registering Event Notification Callbacks
The CDC ACM Serial class can notify your application of any changes in line control or coding via notification callback functions. A callback functions structure can be passed as argument during the ACM instance creation. Note that those callbacks are optional. Example – CDC ACM Callbacks Registration illustrates the use of the callback registration functions. Example – CDC ACM Callbacks Implementation shows an example of implementation of the callback functions.
Example – CDC ACM Callbacks Registration

25/174

Sopraview

uint8_t subclass_nbr; sl_status_t status;
sl_usbd_cdc_acm_callbacks_t sli_usbd_cdc_acm_callbacks = { app_usbd_cdc_acm_connect, app_usbd_cdc_acm_disconnect, app_usbd_cdc_acm_line_control_changed, app_usbd_cdc_acm_line_coding_changed, };
status = sl_usbd_cdc_acm_create_instance(64u, SL_USBD_ACM_SERIAL_CALL_MGMT_DATA_CCI_DCI | SL_USBD_ACM_SERIAL_CALL_MGMT_DEV, &sli_usbd_cdc_acm_callbacks, &subclass_nbr);
if (status ! SL_STATUS_OK) { /* An error occurred. Error handling should be added here. */ }
Example – CDC ACM Callbacks Implementation

bool app_usbd_cdc_acm_line_coding_changed (uint8_t

subclass_nbr,

sl_usbd_cdc_acm_line_coding_t *p_line_coding)

{

uint32_t baudrate_new;

uint8_t parity_new;

uint8_t stop_bits_new;

uint8_t data_bits_new;

/* TODO Apply new line coding.*/ baudrate_new = p_line_coding->BaudRate; parity_new = p_line_coding->Parity; stop_bits_new = p_line_coding->StopBits; data_bits_new = p_line_coding->DataBits;

return (true);

(1)

}

void app_usbd_cdc_acm_line_control_changed (uint8_t subclass_nbr, uint8_t event, uint8_t event_changed)
{ bool rts_state; bool rts_state_changed; bool dtr_state; bool dtr_state_changed; bool brk_state; bool brk_state_changed;

/* TODO Apply new line control. */ rts_state = ((event & SL_USBD_CDC_ACM_CTRL_RTS) ! 0) ? true : false; rts_state_changed = ((event_changed & SL_USBD_CDC_ACM_CTRL_RTS) ! 0) ? true : false; dtr_state = ((event & SL_USBD_CDC_ACM_CTRL_DTR) ! 0) ? true : false; dtr_state_changed = ((event_changed & SL_USBD_CDC_ACM_CTRL_DTR) ! 0) ? true : false; brk_state = ((event & SL_USBD_CDC_ACM_CTRL_BREAK) ! 0) ? true : false; brk_state_changed = ((event_changed & SL_USBD_CDC_ACM_CTRL_BREAK) ! 0) ? true : false;
}

(1) It is important to return false to this function if the line coding applying failed. Otherwise, return true.
Communicating Using the CDC ACM Class
Serial Status
Line Coding Line Control

26/174

Sopraview

Line State Subclass Instance Communication
Serial Status
Line Coding
The USB host controls the line coding (baud rate, parity, etc) of the CDC ACM device. When necessary, the application is responsible for setting the line coding. There are two functions provided to retrieve and set the current line coding, as described in the table below.
Table – CDC ACM Line Coding Functions

Funzione
sl_usbd_cdc_acm_g e t_line _co d ing ()
sl_usbd_cdc_acm_s e t_line _co d ing ()

Descrizione
Your application can get the current line coding settings set either from the host with SetLineCoding requests or with the function sl_usbd_cdc_acm_set_line_coding() .
Your application can set the line coding. The host can retrieve the settings with the GetLineCoding request.

Controllo di linea
The USB host controls the line control (RTS and DTR pins, break signal, and so on) of the CDC ACM device. When necessary, your application is responsible for applying the line controls. A function is provided to retrieve and set the current line controls, as are described in the table below.
Table – CDC ACM Line Control Functions

Funzione
sl_usb d _cd c_acm_g e t_line _co ntr o l_state ()

Your application can get the current control line state set by the host with the SetControlLineState request.

Stato della linea
The USB host retrieves the line state at a regular interval. Your application must update the line state each time it changes. When necessary, your application is responsible for setting the line state. Two functions are provided to retrieve and set the current line controls, as described in the table below.
Table – CDC ACM Line S tate Functions

Funzione
sl_usb d _cd c_acm_se t _line _state _e v e nt()
sl_usbd_cdc_acm_cle ar_line _state _e v e nt()

Your application can set any line state event(s). While setting the line state, an interrupt IN transfer is sent to the host to inform about it a change in the serial line state.
Application can clear two events of the line state: transmission carrier and receiver carrier detection. All the other events are self-cleared by the ACM serial emulation subclass.

Subclass Instance Communication

Silicon Labs’ ACM subclass offers the following functions to communicate with the host. For more details about the functions9 parameters, see the CDC ACM Subclass Functions reference.

Nome della funzione
sl_usb d _cd c_acm_ re ad () sl_usb d _cd c_acm_write ()

Operazione
Receives data from host through a bulk OUT endpoint. This function is blocking. Sends data to host through a bulk IN endpoint. This function is blocking.

27/174

Sopraview

Table – CDC ACM Communication API Summary a a a a a sl_usbd_cdc_acm_read() nd sl_usbd_cdc_acm_write() provide synchronous communic tion, which me ns th t the tr nsfer is blocking. In other words, upon calling the function, the application blocks until the transfer is complete with or without an error. A timeout can be specified to avoid waiting forever. The example below shows a read and write example that receives data from the host using the bulk OUT endpoint and sends data to the host using the bulk IN endpoint.
Listing – Serial Read and Write Example

__ALIGNED(4) uint8_t rx_buf[2];

__ALIGNED(4) uint8_t tx_buf[2];

uint32_t

xfer_len;

sl_status_t

status;

status = sl_usbd_cdc_acm_read(subclass_nbr,

(1)

rx_buf,

(2)

2u,

0u,

(3)

&xfer_len);

if (status ! SL_STATUS_OK) {

/* An error occurred. Error handling should be added here. */

}

status = sl_usbd_cdc_acm_write(subclass_nbr,

(1)

tx_buf,

(4)

2u,

0u,

(3)

&xfer_len);

if (status ! SL_STATUS_OK) {

/* An error occurred. Error handling should be added here. */

}

T a a a a a M (1) he cl ss inst nce number cre ted with sl_usbd_cdc_acm_create_instance() provides n intern l reference to the AC subclass to route the transfer to the proper bulk OUT or IN endpoint. (2) Your application must ensure that the buffer provided to the function is large enough to accommodate all the data. Otherwise, synchronization issues might happen. (3) To avoid an infinite blocking situation, specify a timeout expressed in milliseconds. A value of 809 makes the application task wait forever. (4) The application provides the initialized transmit buffer.

28/174

Sopraview
Sopraview

USB Device HID Class

USB Device HID Class Overview USB Device HID Class Resource Needs from Core USB Device HID Class Configuration USB Device HID Class Programming Guide HID Periodic Input Reports Task
This section describes the Human Interface Device (HID) class supported by Silicon Labs USB Device.
The HID class encompasses devices used by humans to control computer operations, such as keyboards, mice, pointing devices, and game devices.
The HID class can also be used in a composite device that contains controls such as knobs, switches, buttons, and sliders. For example, mute and volume controls in an audio headset are controlled by the HID function of the headset. HID class can exchange data for any purpose using only control and interrupt transfers.
The HID class is one of the oldest and most widely-used USB classes. All the major host operating systems provide a native driver to manage HID devices, which is why a variety of vendor-specific devices work with the HID class. This class also includes various types of output items such as LEDs, audio, tactile feedback, etc.
The HID implementation complies with the following specifications:
Device Class Definition for Human Interface Devices (HID), 6/27/01, Version 1.11. Universal Serial Bus HID Usage Tables, 10/28/2004, Version 1.12.
USB Device HID Class Overview
Sopraview
A HID device is composed of the following endpoints:
A pair of control IN and OUT endpoints called the default endpoint An interrupt IN endpoint An optional interrupt OUT endpoint
The table below describes the usage of the different endpoints:
Table – HID Class Endpoints Usage

Endpoint Direction Usage

Controllo IN
Controllare
FUORI
Interrupt IN
Interrompere
FUORI

Deviceto-host
Host-todevice
Deviceto-host
Host-todevice

Standard requests for enumeration, class-specific requests, and data communication (Input, Feature reports sent to the host with GET_REPORT request). Standard requests for enumeration, class-specific requests and data communication (Output, Feature reports received from the host with SET_REPORT request). Data communication (Input and Feature reports).
Data communication (Output and Feature reports).

Rapporto

29/174

Sopraview

A host and a HID device exchange data using reports. A report contains formatted data giving information about controls and other physical entities of the HID device. A control is manipulable by the user and operates an aspect of the device. For example, a control can be a button on a mouse or a keyboard, a switch, etc. Other entities inform the user about the state of certain device9s features. For example, LEDs on a keyboard notify the user about the caps lock on, the numeric keypad active, etc.
The format and the use of a report data is understood by the host by analyzing the content of a Report descriptor. Analyzing the content is done by a parser. The Report descriptor describes data provided by each control in a device. It is composed of items which are pieces of information about the device and consist of a 1-byte prefix and variable-length
data. For more details about the item format, refer to <Device Class Definition for Human Interface Devices (HID) Version
1.11=, section 5.6 and 6.2.2.
There are three principal types of items:
Main item defines or groups certain types of data fields.
Global item describes data characteristics of a control.
Local item describes data characteristics of a control.
Each item type is defined by different functions. An item function can also be called a tag. An item function can be seen as a sub-item that belongs to one of the three principal item types. The table below provides a brief overview of the item9s functions in each item type. For a complete description of the items in each category, see <Device Class Definition for Human Interface Devices (HID) Version 1.11=, section 6.2.2.
Table – Item’s Function Description for Each Item Type

Item Item Type Function

Descrizione

Ingresso principale

Describes information about the data provided by one or more physical controls.

Main Output Describes data sent to the device.

Caratteristica principale

Describes device configuration information sent to or received from the device which influences the overall behavior of the device or one of its components.

Main Collection Group related items (Input, Output or Feature).

Main End of Closes a collection. Collection

30/174

Sopraview

Item Item Type Function

Descrizione

Global Usage Page

Identifies a function available within the device.

Global Logical Defines the lower limit of the reported values in logical units. Minimum

Global Logical Defines the upper limit of the reported values in logical units. Maximum

Global Physical Defines the lower limit of the reported values in physical units, that is the Logical Minimum Minimum expressed in physical units.

Global Physical Defines the upper limit of the reported values in physical units, that is the Logical Maximum Maximum expressed in physical units.

Global Unit

Indicates the unit exponent in base 10. The exponent ranges from -8 to +7.

Esponente

Global Unit

Indicates the unit of the reported values. For instance, length, mass, temperature units, etc.

Global Report Size

Indicates the size of the report fields in bits.

Global Report ID Indicates the prefix added to a particular report.

Global Report Count

Indicates the number of data fields for an item.

Global Push

Places a copy of the global item state table on the CPU stack.

Global Pop

Replaces the item state table with the last structure from the stack.

Local Usage

Represents an index to designate a specific Usage within a Usage Page. It indicates the vendor9s suggested use for a specific control or group of controls. A usage supplies information to an application developer about what a control is actually measuring.

Local Usage

Defines the starting usage associated with an array or bitmap.

Minimo

Local Usage

Defines the ending usage associated with an array or bitmap.

Massimo

Local Designator Determines the body part used for a control. Index points to a designator in the Physical

Indice

descrittore.

Local Designator Defines the index of the starting designator associated with an array or bitmap. Minimum

Local Designator Defines the index of the ending designator associated with an array or bitmap. Maximum

Local String Index

String index for a String descriptor. It allows a string to be associated with a particular item or control.

Local String

Specifies the first string index when assigning a group of sequential strings to controls in an array

Minimum or bitmap.

Local Local

String Maximum
Delimitatore

Specifies the last string index when assigning a group of sequential strings to controls in an array or bitmap.
Defines the beginning or end of a set of local items.

A control9s data must define at least the following items:
Input, Output or Feature Main items Usage Local item Usage Page Global item Logical Minimum Global item Logical Maximum Global item Report Size Global item

31/174

Sopraview
Report Count Global item The table below shows the representation of a Mouse Report descriptor content from a host HID parser perspective. The mouse has three buttons (left, right, and wheel). The code presented in the example below is a code implementation corresponding to this mouse Report descriptor representation.
Figure – Report Descriptor Content from a Host HID Parser View

(1) The Usage Page item function specifies the general function of the device. In this example, the HID device belongs to a
generic desktop control.
(2) The Collection Application groups Main items that have a common purpose and may be familiar to applications. In the diagram, the group is composed of three Input Main items. For this collection, the suggested use for the controls is a mouse as indicated by the Usage item. (3) Nested collections may be used to give more details about the use of a single control or group of controls to applications. In this example, the Collection Physical, nested into the Collection Application, is composed of the same three Input items forming the Collection Application. The Collection Physical is used for a set of data items that represent data points collected at one geometric point. In the example, the suggested use is a pointer as indicated by the Usage item. Here the pointer usage refers to the mouse position coordinates and the system software will translate the mouse coordinates in movement of the screen cursor. (4) Nested usage pages are also possible and give more details about a certain aspect within the general function of the device. In this case, two Inputs items are grouped and correspond to the buttons of the mouse. One Input item defines the three buttons of the mouse (right, left and wheel) in terms of number of data fields for the item (Report Count item), size of a data field (Report Size item) and possible values for each data field (Usage Minimum and Maximum, Logical Minimum and Maximum items). The other Input item is a 13-bit constant allowing the Input report data to be aligned on a byte boundary. This Input item is used only for padding purpose. (5) Another nested usage page referring to a generic desktop control is defined for the mouse position coordinates. For this usage page, the Input item describes the data fields corresponding to the x- and y-axis as specified by the two Usage
elementi.
After analyzing the previous mouse Report descriptor content, the host9s HID parser is able to interpret the Input report data sent by the device with an interrupt IN transfer or in response to a GET_REPORT request. The Input report data corresponding to the mouse Report descriptor shown in Figure – Report Descriptor Content from a Host HID Parser View is

32/174

Sopraview

shown in the table below. The total size of the report data is 4 bytes. Different types of reports may be sent over the same endpoint. For the purpose of distinguishing the different types of reports, a 1-byte report ID prefix is added to the data report. If a report ID was used in the example of the mouse report, the total size of the report data would be 5 bytes.
Table – Input Report Sent to Host and Corresponding to the State of a 3 Buttons Mouse

Offset bit
0 1 2 3 16 24

Bit Count 1 1 1 13 8 8

Description Button 1 (left button). Button 2 (right button). Button 3 (wheel button). Not used. Position on axis X. Position on axis Y.

A Physical descriptor indicates the part or parts of the body intended to activate a control or controls. An application may use this information to assign a functionality to the control of a device. A Physical descriptor is an optional class-specific descriptor and most devices have little gain for using it. Refer to <Device Class Definition for Human Interface Devices (HID) Version 1.11= section 6.2.3 for more details about this descriptor.
USB Device HID Class Resource Needs from Core

Each time you add a HID class instance to a USB configuration via a call to the function sl_usbd_hid_add_to_configuration() , the following resources will be allocated from the core.

Risorsa
Interfaces Alternate interfaces Endpoints Interface groups

Quantità
1 1 1 (2 if interrupt OUT endpoint is enabled) 0

Two groups of configuration parameters are used to configure the HID class:
USB Device HID Class Application-Specific Configurations USB Device HID Class Instance Configurations
USB Device HID Class Application-Specific Configurations

First, to use the Silicon Labs USB device HID class module, adjust the HID compile-time configuration defines according to your application needs. They are regrouped inside the sl_usbd_core_config.h header file under the HID section. They can be divided into two sections, the quantity configurations and the HID task configurations. The quantity configurations purpose is to inform the USB device module about how many USB HID objects to allocate.
The table below describes each configuration define.
Table – USB Device HID Configuration Defines

33/174

Sopraview

Nome configurazione
SL_USBD_HID_CL ASS_I NSTANCE_QUANTITY
SL_USBD_HID_CONFIG URATION_QUANTITY
SL_USBD_HID_REPORT_ ID_QUANTITY
SL_USBD_HID_PUSH_P OP_ITEM_QUANTITY
SL_USBD_HID_TIMER_T ASK_STACK_SIZE
SL_USBD_HID_TIMER_T ASK_PRIORITY

Descrizione
Number of class instances you will allocate via a call to the function
sl_usbd_hid_create_instance() .
Number of configurations. HID class instances can be added to one or more a a a a configur tions vi c ll to the function sl_usbd_hid_add_to_configuration() . Configures the total number of report IDs to allocate.
Configures the total number of Push/Pop items to allocate.
The timer task handles all the timer-based HID operations. This configuration allows you to set the stack size (in number of bytes). Priority of HID task. his is a CMSIS-RTOS2 priority.

Valore predefinito
2 1 2 0 2048
osPriorityHigh

USB Device HID Class Instance Configurations Class Instance Creation subclass
protocol country_code
interval_in and interval_out p_hid_callback HID Class Report Descriptor Example This section defines the configurations related to the HID class instances.
Class Instance Creation
Creating a HID class instance is done by calling the function a a a sl_usbd_hid_create_instance() , which t kes sever l configur tion arguments that are described below.
subclass
Code of the HID subclass. Possible values are:
SL_USBD_HID_SUBCL ASS_NONE SL_USBD_HID_SUBCL ASS_BOOT
A HID device that uses the boot subclass must use standard report formats. For more information on the subclass codes, see section 4.2 of HID specification revision 1.11.
protocollo
Protocol used by the HID device. Possible values are:
SL_USBD_HID_PROTOCOL_NONE SL_USBD_HID_PROTOCOL_KBD SL_USBD_HID_PROTOCOL_MOUSE
If your HID function is a mouse, the protocol should be set to a a SL_USBD_HID_PROTOCOL_MOUSE . If it is keybo rd, it should O be set to SL_USBD_HID_PROTOCOL_KBD . therwise, the protocol should be set to SL_USBD_HID_PROTOCOL_NONE . For more information on the subclass codes, see section 4.3 of HID specification revision 1.11.
country_code
ID of the country code. Possible values are:
SL_USBD_HID_COUNTRY_CODE_NOT_SUPPORTED

34/174

Sopraview
SL_USBD_HID_COUNTRY_CODE_ARABIC SL_USBD_HID_COUNTRY_CODE_BELGIAN SL_USBD_HID_COUNTRY_CODE_CANADIAN_BILINGUAL SL_USBD_HID_COUNTRY_CODE_CANADIAN_FRENCH SL_USBD_HID_COUNTRY_CODE_CZECH_REPUBLIC SL_USBD_HID_COUNTRY_CODE_DANISH SL_USBD_HID_COUNTRY_CODE_FINNISH SL_USBD_HID_COUNTRY_CODE_FRENCH SL_USBD_HID_COUNTRY_CODE_GERMAN SL_USBD_HID_COUNTRY_CODE_GREEK SL_USBD_HID_COUNTRY_CODE_HEBREW SL_USBD_HID_COUNTRY_CODE_HUNGARY SL_USBD_HID_COUNTRY_CODE_INTERNATIONAL SL_USBD_HID_COUNTRY_CODE_ITALIAN SL_USBD_HID_COUNTRY_CODE_JAPAN_KATAKANA SL_USBD_HID_COUNTRY_CODE_KOREAN SL_USBD_HID_COUNTRY_CODE_L ATIN_AMERICAN SL_USBD_HID_COUNTRY_CODE_NETHERL ANDS_DUTCH SL_USBD_HID_COUNTRY_CODE_NORWEGIAN SL_USBD_HID_COUNTRY_CODE_PERSIAN_FARSI SL_USBD_HID_COUNTRY_CODE_POL AND SL_USBD_HID_COUNTRY_CODE_PORTUGUESE SL_USBD_HID_COUNTRY_CODE_RUSSIA SL_USBD_HID_COUNTRY_CODE_SLOVAKIA SL_USBD_HID_COUNTRY_CODE_SPANISH SL_USBD_HID_COUNTRY_CODE_SWEDISH SL_USBD_HID_COUNTRY_CODE_SWISS_FRENCH SL_USBD_HID_COUNTRY_CODE_SWISS_GERMAN SL_USBD_HID_COUNTRY_CODE_SWITZERL AND SL_USBD_HID_COUNTRY_CODE_TAIWAN SL_USBD_HID_COUNTRY_CODE_TURKISH_Q SL_USBD_HID_COUNTRY_CODE_UK SL_USBD_HID_COUNTRY_CODE_US SL_USBD_HID_COUNTRY_CODE_YUG OSL AVIA SL_USBD_HID_COUNTRY_CODE_TURKISH_F
The country code identifies which country the hardware is localized for. Most hardware is not localized and therefore this a a a a v lue would be SL_USBD_HID_COUNTRY_CODE_NOT_SUPPORTED (0). However, keybo rds m y use the field to indic te the language of the key caps.
For more information on the country codes, see section 6.2.1 of HID specification revision 1.11.
interval_in and interval_out
interval_in and interval_out represent the polling interval of the IN interrupt endpoint and the OUT interrupt endpoint.
This represents the polling interval of the endpoint, in milliseconds. Setting this value depends on how frequently your device is susceptible to generate a new report for the host. For instance, if a report is generated every 16 milliseconds, the interval should be 16 or less.
The value must be a power of 2 (1, 2, 4, 8, 16, etc.).
a interval_out v lue is ignored if ctrl_rd_en is set to true.
p_hid_callback
a a a a p_hid_callback is pointer to structure of type sl_usbd_hid_callbacks_t . Its purpose is to give the HID Cl ss set of callback functions to be called when a HID event occurs.

35/174

Sopraview

Not all callbacks are mandatory and a null pointer ( NULL ) can be passed in the callbacks structure variable when the callback is not needed. The table below describes each configuration field available in this configuration structure.
Table – sl_usbd_hid_callbacks_t Configuration Structure

Campi

Descrizione

Function Signature

.enable .disable .get_report_desc
.get_phy_desc
.set_output_report .get_feature_report .set_feature_report

Called when the USB class instance is enabled successfully. Called when the USB class instance is disabled.
Called during the HID Instance creation to pass your report descriptor. For each of your HID functions, you must provide a report descriptor. The report descriptor indicates to the host how the periodic report that will be sent by the device should be parsed. Writing your own report descriptor can be challenging, and that is why there are some resources to help. This is the only mandatory callback function. Called during the HID Instance creation to pass your physical descriptor. The physical descriptor is a descriptor that provides information about the specific part or parts of the human body that are activating a control or controls. For more information on physical descriptors, see section 6.2.3 of HID specification revision 1.11. The physical descriptor is optional and most of the time ignored. The buffer passed here can be set to NULL and the length set to 0. Called when the host sets a report as described in your report descriptor (when it sends a report).
Called when the host requests a feature report as described in your report descriptor.
Called when the host sets a feature report as described in your report descriptor.

void app_usbd_hid_enable(uint8_t class_nbr); void app_usbd_hid_disable(uint8_t class_nbr); void app_usbd_hid_get_report_desc(uint8_t class_nbr, const uint8_t *p_report_ptr, uint16_tp_report_len);
void app_usbd_hid_get_phy_desc(uint8_t class_nbr, const uint8_t *p_report_ptr, uint16_tp_report_len);
void app_usbd_hid_set_output_report(uint8_t class_nbr, uint8_t report_id, uint8_t *p_report_buf, uint16_t report_len); void app_usbd_hid_get_feature_report(uint8_t class_nbr, uint8_t report_id, uint8_t *p_report_buf, uint16_t report_len); void app_usbd_hid_set_feature_report(uint8_t class_nbr, uint8_t report_id, uint8_t *p_report_buf, uint16_t report_len);

.get_protocol

Retrieves current active protocol.

void app_usbd_hid_get_protocol(uint8_t class_nbr, uint8_t *p_protocol);

.set_protocol

Sets current active protocol.

void app_usbd_hid_set_protocol(uint8_t class_nbr, uint8_t protocol);

HID Class Report Descriptor Example

Silicon Labs’ HID class sample application provides an example of a report descriptor for a simple mouse. The example below shows a mouse report descriptor.
Example – Mouse Report Descriptor

static uint8_t app_usbd_hid_report_desc[] = {

(1) (2)

SL_USBD_HID_GLOBAL_USAGE_PAGE + 1, SL_USBD_HID_USAGE_PAGE_GENERIC_DESKTOP_CONTROLS,

SL_USBD_HID_LOCAL_USAGE + 1, SL_USBD_HID_CA_MOUSE,

(3)

36/174

Sopraview

SL_USBD_HID_MAIN_COLLECTION +1, SL_USBD_HID_COLLECTION_APPLICATION,(4)

SL_USBD_HID_LOCAL_USAGE +1, SL_USBD_HID_CP_POINTER,(5)

SL_USBD_HID_MAIN_COLLECTION +1, SL_USBD_HID_COLLECTION_PHYSICAL,(6)

SL_USBD_HID_GLOBAL_USAGE_PAGE +1, SL_USBD_HID_USAGE_PAGE_BUTTON,(7)

SL_USBD_HID_LOCAL_USAGE_MIN +1,0 01,

SL_USBD_HID_LOCAL_USAGE_MAX +1,0 03,

SL_USBD_HID_GLOBAL_LOG_MIN +1,0 00,

SL_USBD_HID_GLOBAL_LOG_MAX +1,0 01,

SL_USBD_HID_GLOBAL_REPORT_COUNT +1,0 03,

SL_USBD_HID_GLOBAL_REPORT_SIZE +1,0 01,

SL_USBD_HID_MAIN_INPUT +1, SL_USBD_HID_MAIN_DATA |

SL_USBD_HID_MAIN_VARIABLE |

SL_USBD_HID_MAIN_ABSOLUTE,

SL_USBD_HID_GLOBAL_REPORT_COUNT +1,0 01,(8)

SL_USBD_HID_GLOBAL_REPORT_SIZE +1,0 0D,

SL_USBD_HID_MAIN_INPUT +1, SL_USBD_HID_MAIN_CONSTANT,(9)

SL_USBD_HID_GLOBAL_USAGE_PAGE +1, SL_USBD_HID_USAGE_PAGE_GENERIC_DESKTOP_CONTROLS,

SL_USBD_HID_LOCAL_USAGE +1, SL_USBD_HID_DV_X,

SL_USBD_HID_LOCAL_USAGE +1, SL_USBD_HID_DV_Y,

SL_USBD_HID_GLOBAL_LOG_MIN +1,0 81,

SL_USBD_HID_GLOBAL_LOG_MAX +1,0 7F,

SL_USBD_HID_GLOBAL_REPORT_SIZE +1,0 08,

SL_USBD_HID_GLOBAL_REPORT_COUNT +1,0 02,

SL_USBD_HID_MAIN_INPUT +1, SL_USBD_HID_MAIN_DATA |

SL_USBD_HID_MAIN_VARIABLE |

SL_USBD_HID_MAIN_RELATIVE,

SL_USBD_HID_MAIN_ENDCOLLECTION,(10)

SL_USBD_HID_MAIN_ENDCOLLECTION

(11)};

(1) The table representing a mouse report descriptor is initialized in such way that each line corresponds to a short item. The latter is formed from a 1-byte prefix and a 1-byte data. Refer to <Device Class Definition for Human Interface Devices (HID) Version 1.11=, sections 5.3 and 6.2.2.2 for more details about short items format. This table content corresponds to the mouse report descriptor content viewed by a host HID parser in Figure – Report Descriptor Content from a Host HID Parser View.
(2) The Generic Desktop Usage Page is used.
(3) Within the Generic Desktop Usage Page, the usage tag suggests that the group of controls is for controlling a mouse. A mouse collection typically consists of two axes (X and Y) and one, two, or three buttons.
(4) The mouse collection is started.
(5) Within the mouse collection, a usage tag suggests more specifically that the mouse controls belong to the pointer collection. A pointer collection is a collection of axes that generates a value to direct, indicate, or point user intentions to an application.
(6) The pointer collection is started.
(7) The Buttons Usage Page defines an Input item composed of three 1-bit fields. Each 1-bit field represents the mouse9s button 1, 2 and 3 respectively and can return a value of 0 or 1.
(8) The Input Item for the Buttons Usage Page is padded with 13 other bits.
(9) Another Generic Desktop Usage Page is indicated for describing the mouse position with the axes X and Y. The Input item is composed of two 8-bit fields whose value can be between -127 and 127.
(10) The pointer collection is closed.
(11) The mouse collection is closed.
USB.org HID Page

37/174

Sopraview
The USB Implementers Forum (USB-IF) provides a tool called “HID Descriptor Tool” along with other information on the report descriptor format. Seehttp://www.usb.org/developers/hidpage/ for more information.
USB Device HID Class Programming Guide
This section explains how to use the HID class. Initializing the USB Device HID Class Adding a USB Device HID Class Instance to your Device Communicating using the USB Device HID Class
Initializing the USB Device HID Class
To add HID Class functionality to your device, you must first initialize the class by calling the function sl_usbd_hid_init() . The example below shows how to call sl_usbd_hid_init() using default arguments. For more information on the configuration arguments to pass to sl_usbd_hid_init() , see USB Device HID Class Application Specific Configurations .
Example – Calling sl_usbd_hid_init()
sl_status_t status;
status = sl_usbd_hid_init(); if (status ! SL_STATUS_OK) { /* An error occurred. Error handling should be added here. */
}
Adding a USB Device HID Class Instance to Your Device
To add HID class functionality to your device, you must create an instance, then add it to your device’s configuration(s).
Creating a HID Class Instance
Create a HID class instance by calling the function sl_usbd_hid_create_instance() . The example below shows how to create a simple mouse function via sl_usbd_hid_create_instance() using default arguments. For more information on the configuration arguments to pass to sl_usbd_hid_create_instance() , see USB Device HID Class Instance Configurations .
Example – Adding a Mouse Function via sl_usbd_hid_create_instance()

38/174

Sopraview
/* Global constants. */ static const uint8_t app_usbd_hid_mouse_report_desc[] = {
SL_USBD_HID_GLOBAL_USAGE_PAGE + 1, SL_USBD_HID_USAGE_PAGE_GENERIC_DESKTOP_CONTROLS, SL_USBD_HID_LOCAL_USAGE + 1, SL_USBD_HID_CA_MOUSE, SL_USBD_HID_MAIN_COLLECTION + 1, SL_USBD_HID_COLLECTION_APPLICATION, SL_USBD_HID_LOCAL_USAGE + 1, SL_USBD_HID_CP_POINTER, SL_USBD_HID_MAIN_COLLECTION + 1, SL_USBD_HID_COLLECTION_PHYSICAL, SL_USBD_HID_GLOBAL_USAGE_PAGE + 1, SL_USBD_HID_USAGE_PAGE_BUTTON, SL_USBD_HID_LOCAL_USAGE_MIN + 1, 0 01, SL_USBD_HID_LOCAL_USAGE_MAX + 1, 0 03, SL_USBD_HID_GLOBAL_LOG_MIN + 1, 0 00, SL_USBD_HID_GLOBAL_LOG_MAX + 1, 0 01, SL_USBD_HID_GLOBAL_REPORT_COUNT + 1, 0 03, SL_USBD_HID_GLOBAL_REPORT_SIZE + 1, 0 01, SL_USBD_HID_MAIN_INPUT + 1, SL_USBD_HID_MAIN_DATA | SL_USBD_HID_MAIN_VARIABLE | SL_USBD_HID_MAIN_ABSOLUTE, SL_USBD_HID_GLOBAL_REPORT_COUNT + 1, 0 01, SL_USBD_HID_GLOBAL_REPORT_SIZE + 1, 0 0D, SL_USBD_HID_MAIN_INPUT + 1, SL_USBD_HID_MAIN_CONSTANT, SL_USBD_HID_GLOBAL_USAGE_PAGE + 1, SL_USBD_HID_USAGE_PAGE_GENERIC_DESKTOP_CONTROLS, SL_USBD_HID_LOCAL_USAGE + 1, SL_USBD_HID_DV_X, SL_USBD_HID_LOCAL_USAGE + 1, SL_USBD_HID_DV_Y, SL_USBD_HID_GLOBAL_LOG_MIN + 1, 0 81, SL_USBD_HID_GLOBAL_LOG_MAX + 1, 0 7F, SL_USBD_HID_GLOBAL_REPORT_SIZE + 1, 0 08, SL_USBD_HID_GLOBAL_REPORT_COUNT + 1, 0 02, SL_USBD_HID_MAIN_INPUT + 1, SL_USBD_HID_MAIN_DATA | SL_USBD_HID_MAIN_VARIABLE | SL_USBD_HID_MAIN_RELATIVE, SL_USBD_HID_MAIN_ENDCOLLECTION, SL_USBD_HID_MAIN_ENDCOLLECTION };
/* Local variables.*/ uint8_t class_nbr; sl_status_t status;
sl_usbd_hid_callbacks_t app_usbd_hid_callbacks = { NULL, NULL, app_usbd_hid_get_report_desc, NULL, NULL, NULL, NULL, NULL, NULL };
void app_usbd_hid_get_report_desc(uint8_t class_nbr, const uint8_t **p_report_ptr, uint16_t *p_report_len)
{ (void)class_nbr;
*p_report_ptr = app_usbd_hid_mouse_report_desc; *p_report_len = sizeof(app_usbd_hid_mouse_report_desc); }
status = sl_usbd_hid_create_instance(SL_USBD_HID_SUBCLASS_BOOT, SL_USBD_HID_PROTOCOL_MOUSE, SL_USBD_HID_COUNTRY_CODE_NOT_SUPPORTED, Ex_USBD_HID_Mouse_ReportDesc, sizeof(Ex_USBD_HID_Mouse_ReportDesc), 2u, 2u, true, &app_usbd_hid_callbacks, &class_nbr);
Copyright © 2025 Laboratori di silicio. Tutti i diritti riservati.

39/174

Sopraview
/* An error occurred. Error handling should be added here. */}
Adding the HID Class Instance to Your Device’s Configuration(s) After you have created a HID class instance, you can add it to a configuration by calling the function
sl_usbd_hid_add_to_configuration() .
L'example below shows how to call sl_usbd_hid_add_to_configuration() .
Example – Calling sl_usbd_hid_add_to_configuration()

sl_status_t status;

sl_usbd_hid_add_to_configuration(class_nbr,

(1)

config_nbr_fs); (2)

if (status ! SL_STATUS_OK) {

/* An error occurred. Error handling should be added here. */

}

(1) Class number to add to the configuration returned by sl_usbd_hid_create_instance(). (2) Configuration number (here adding it to a Full-Speed configuration).
Communicating Using the USB Device HID Class
Class Instance Communication Synchronous Communication Class Instance Communication The HID class offers the following functions to communicate with the host.
Table – HID Communication API Summary

Nome della funzione
sl_usb d _hid _ re ad _sy nc() sl_usb d _hid _write _sy nc()

Operation Receives data from the host through interrupt OUT endpoint. This function is blocking. Sends data to the host through interrupt IN endpoint. This function is blocking.

Synchronous Communication Synchronous communication means that the transfer is blocking. Upon the function call, the applications blocks until the transfer is completed with or without an error. A timeout can be specified to avoid waiting forever. The example below shows a read and write that receives data from the host using the interrupt OUT endpoint and sends data to the host using the interrupt IN endpoint.
Example – Synchronous HID Read and Write

__ALIGNED(4) uint8_t rx_buf[2];

__ALIGNED(4) uint8_t tx_buf[2];

uint32_t

xfer_len;

sl_status_t

status;

status = sl_usbd_hid_read_sync(class_nbr,

(1)

(void *)rx_buf,

(2)

2u,

0u,

(3)

&xfer_len);

if (status ! SL_STATUS_OK) {

/* An error occurred. Error handling should be added here. */

}

40/174

Sopraview
status =sl_usbd_hid_read_sync(class_nbr,(1)(void *)rx_buf,(2)2u,0u,(3)&xfer_len);if(status ! SL_STATUS_OK){/* An error occurred. Error handling should be added here. */}
status =sl_usbd_hid_write_sync(class_nbr,(1)(void *)tx_buf,(4)2u,0u,(3)&xfer_len);if(status ! SL_STATUS_OK){/* An error occurred. Error handling should be added here. */}
(1) The class instance number created from sl_usbd_hid_create_instance() provides an internal reference for the HID class to route the transfer to the proper interrupt OUT or IN endpoint.
(2) The application must ensure that the buffer provided to the function is large enough to accommodate all the data. Otherwise, synchronization issues might happen. Internally, the read operation is done either with the control endpoint or with the interrupt endpoint, depending on the control read flag set when calling sl_usbd_hid_create_instance() .
(3) To avoid an infinite blocking situation, a timeout expressed in milliseconds can be specified. A value of 809 makes the application task wait forever.
(4) The application provides the initialized transmit buffer.
HID Periodic Input Reports Task
To save bandwidth, the host has the ability to silence reports from an interrupt IN endpoint by limiting the reporting frequency. To do so, the host must send the SET_IDLE request. The HID class implemented by Silicon Labs contains an internal task that respects the reporting frequency limitation that you can apply to one or several input reports. Figure Periodic Input Reports Task shows the functioning of the periodic input reports tasks.
Figure – Periodic Input Reports Task

(1) The device receives a SET_IDLE request. This request specifies an idle duration for a given report ID. For more details about the SET_IDLE request, see <Device Class Definition for Human Interface Devices (HID) Version 1.11=, section 7.2.4. A report ID allows you to distinguish among the different types of reports sent from the same endpoint.
(2) A report ID structure (allocated during the HID class initialization phase) is updated with the idle duration. An idle duration counter is initialized with the idle duration value. The report ID structure is inserted at the end of a linked list containing input reports ID structures. The idle duration value is expressed in 4-ms unit which gives a range of 4 to 1020 ms.

41/174

Sopraview
If the idle duration is less than the polling interval of the interrupt IN endpoint, the reports are generated at the polling interval.
(3) Every 4 ms, the periodic input report task browses the input reports ID list. For each input report ID, the task performs one of two possible operations. The duration of the task period matches the 4-ms unit used for the idle duration. If no SET_IDLE requests have been sent by the host, the input reports ID list is empty and the task has nothing to process. The task processes only report IDs that are different from 0 and with an idle duration greater than 0.
(4) For a given input report ID, the task verifies if the idle duration has elapsed. If the idle duration has not elapsed, the counter is decremented and no input report is sent to the host.
(5) If the idle duration has elapsed (that is, the idle duration counter has reached zero), an input report is sent to the host by calling the sl_usbd_hid_write_sync() function via the interrupt IN endpoint.
(6) The input report data sent by the task comes from an internal data buffer allocated for each input report described in the Report descriptor. An application task can call the sl_usbd_hid_write_sync() function to send an input report. After sending the input report data, sl_usbd_hid_write_sync() updates the internal buffer associated to an input report ID with the data just sent. Then, the periodic input reports task always sends the same input report data after each idle duration elapsed and until the application task updates the data in the internal buffer. There is some locking mechanism to avoid corruption of the input report ID data in the event of a modification happening at the exact time of transmission done by the periodic input report task.

42/174

Sopraview
Sopraview
USB Device MSC Class
USB Device MSC Class Overview USB Device MSC Class Resource Needs from Core USB Device MSC Class Configuration USB Device MSC Class Programming Guide USB Device MSC Class Storage Drivers
This section describes the mass storage device class (MSC) supported by Silicon Labs USB Device. MSC is a protocol that enables the transfer of information between a USB device and a host. The information being transferred is anything that can be stored electronically, such as executable programs, source code, documents, images, configuration data, or other text or numeric data. The USB device appears as an external storage medium to the host, enabling the transfer of files via drag and drop.
A file system defines how the files are organized in the storage media. The USB mass storage class specification does not require any particular file system to be used on conforming devices. Instead, it provides a simple interface to read and write sectors of data using the Small Computer System Interface (SCSI) transparent command set. As such, operating systems may treat the USB drive like a hard drive, and can format it with any file system they like.
The USB mass storage device class supports two transport protocols, as follows:
Bulk-Only Transport (BOT) Control/Bulk/Interrupt (CBI) Transport (used only for floppy disk drives)
The mass storage device class implements the SCSI transparent command set using the BOT protocol only, which signifies that only bulk endpoints will be used to transmit data and status information. The MSC implementation supports multiple logical units.
The MSC implementation is in compliance with the following specifications:
Universal Serial Bus Mass Storage Class Specification Overview, Revision 1.3 Sept. 5, 2008. Universal Serial Bus Mass Storage Class Bulk-Only Transport, Revision 1.0 Sept. 31, 1999.
USB Device MSC aCl ss Overview
Protocol Endpoints Class Requests Small Computer System Interface (SCSI)
Protocollo
In this section, we will discuss the Bulk-Only Transport (BOT) protocol of the Mass Storage Class. The Bulk-Only Transport protocol has three stages:
The Command Transport The Data Transport The Status Transport
Mass storage commands are sent by the host through a structure called the Command Block Wrapper (CBW). For commands requiring a data transport stage, the host will attempt to send or receive the exact number of bytes from the device as specified by the length and flag fields of the CBW. After the data transport stage, the host attempts to receive a Command Status Wrapper (CSW) from the device that details the status of the command as well as any data residue (if

43/174

Sopraview
any). For commands that do not include a data transport stage, the host attempts to receive the CSW directly after CBW is sent. The protocol is detailed in Figure – MSC Protocol.
Figure – MSC Protocol

endpoint
On the device side, in compliance with the BOT specification, the MSC is composed of the following endpoints: A pair of control IN and OUT endpoints called default endpoint. A pair of bulk IN and OUT endpoints.
The table below indicates the different usages of the endpoints.
Table – MSC Endpoint Usage

Punto finale
Control IN Control OUT Bulk IN Bulk OUT

Direzione
Device to Host Host to Device Device to Host Host to Device

Utilizzo
Enumeration and MSC class-specific requests Enumeration and MSC class-specific requests Send CSW and data Receive CBW and data

Class Requests
There are two defined control requests for the MSC BOT protocol. These requests and their descriptions are detailed in the table below.

Table – Mass Storage Class Requests

Class Requests
Bulk-Only Mass Storage Reset

Descrizione
This request is used to reset the mass storage device and its associated interface. This request readies the device to receive the next command block.

44/174

Sopraview

Class Requests

Descrizione

Get Max This request is used to return the highest logical unit number (LUN) supported by the device. For example, a

LUN

device with LUN 0 and LUN 1 will return a value of 1. A device with a single logical unit will return 0 or stall the

request. The maximum value that can be returned is 15.

Small Computer System Interface SCSI

At the programming interface level, the MSC device implements one of the standard storage-media communication protocols, like SCSI and SFF-8020i (ATAPI). The “Programming Interface” specifies which protocol is implemented, and helps the host operating system to load the suitable device driver for communicating with the USB storage device. SCSI is the most common protocol used with USB MSC storage devices. We provide an implementation for MSC SCSI subclass that our GSDK users can use out of the box.
SCSI is a set of standards for handling communication between computers and peripheral devices. These standards include commands, protocols, electrical interfaces and optical interfaces. Storage devices that use other hardware interfaces, such as USB, use SCSI commands for obtaining device/host information and controlling the device’s operation and transferring blocks of data in the storage media.
SCSI commands cover a vast range of device types and functions and as such, devices need a subset of these commands. In general, the following commands are necessary for basic communication:
INQUIRY READ CAPACITY(10) READ(10) REQUEST SENSE TEST UNIT READY WRITE(10)
USB Device MSC Class Resource Needs from Core

Each time you add an MSC class instance to a USB configuration via the function sl_usbd_msc_add_to_configuration() , the following resources will be allocated from the core.

Risorsa
Interfaces Alternate interfaces Endpoints Interface groups

Quantità
1 1 2 0

Two groups of configuration parameters are used to configure the MSC class:
USB Device MSC Class Application-Specific Configurations USB Device MSC Class Logical Unit Configuration
USB Device MSC Class Application-Specific Configurations

Class Compile-Time Configurations Class Instance Creation

45/174

Sopraview

Class Compile-Time Configurations
Silicon Labs USB Device MSC class and SCSI subclass are configurable at compile time via #defines located in the sl_usbd_core_config.h file.
Table – Generic Configuration Constants

Nome configurazione

Descrizione

SL_USBD_MSC_CLASS_INST Number of class instances you will allocate via a call to the function

ANCE_QUANTITY

sl_usbd_msc_scsi_create_instance() .

SL_USBD_MSC_CONFIGURA Number of configuration to which a class instance can be added via a call to the

TION_QUANTITY

function sl_usbd_msc_scsi_add_to_configuration() .

SL_USBD_MSC_LUN_QUANT Number of logical units per class instance that you will add via a call to the

ITTÀ

function sl_usbd_msc_scsi_lun_add() .

SL_USBD_MSC_SCSI_64_BIT Enables or disables support for Logical Block Address (LBA) of 64 bits.
_LBA_EN

SL_USBD_MSC_DATA_BUFF Size of data buffer per class instance in bytes ER_SIZE

Valore predefinito
2
1
2
0
512

Class Instance Creation
Creating a USB Device MSC SCSI class instance is done by calling the sl_usbd_msc_scsi_create_instance() function. This function takes one configuration argument that is described below.
p_scsi_callbacks
p_scsi_callbacks is a pointer to a configuration structure of type sl_usbd_msc_scsi_callbacks_t . In addition to the common usb device class callbacks connect/disconnect, it provides the MSC class with a set of optional callback functions that are called when an event occurs on the logical unit. A null pointer ( NULL ) can be passed to this argument if no callbacks are needed.
The table below describes each configuration field available in this configuration structure.
Table – sl_usbd_msc_scsi_callbacks_t Configuration Structure

Campi

Descrizione

.enable

Called when the USB class instance is enabled successfully.

.disable Called when the USB class instance is disabled.

.host_eject Function called when a logical unit is ejected from the host.

Function Signature
void app_usbd_msc_scsi_enable(uint8_t class_nbr);
void app_usbd_msc_scsi_disable(uint8_t class_nbr); void app_usbd_msc_scsi_host_eject(uint8_t class_nbr, uint8_t lu_nbr);

USB Device MSC Class Logical Unit Configuration

Adding a logical unit to an MSC class instance is done by calling the function sl_usbd_msc_lun_add() . This function takes one configuration argument that is described below.

p_lu_info

p_lu_info is a pointer to a structure of type sl_usbd_msc_scsi_lun_info_t . Its purpose is to provide the information on the logical unit to the MSC class.
The table below describes each configuration field available in this configuration structure.

Table – sl_usbd_msc_scsi_lun_info_t Configuration Structure

46/174

Sopraview

Campo

Descrizione

Campo
.scsi_lun_api_p tr

Descrizione
Pointer to the media driver API that will handle this logical unit. See USB Device MSC Class Storage Drivers for more information on storage drivers.

.v e nd o r_id _ p tr
.product_id_ptr
.p ro d uct_ re v isi on_level .is_ re ad _o nly

Pointer to a string that contains the vendor identification of the logical unit. The maximum length of the string is 8 characters. Pointer to a string that contains the product identification of the logical unit. The maximum length of the string is 16 characters. Product revision level.
Flag that indicates if the logical unit should be seen as read only from the point of view of the host ( true ) or not ( false ).

USB Device MSC Class Programming Guide

This section explains how to use the MSC class.
Initializing the USB Device MSC Class Adding a USB Device MSC SCSI Class Instance to Your Device USB Device MSC Class Logical Unit Handling
Initializing the USB Device MSC Class

To add MSC SCSI class functionality to your device, first initialize the MSC base class and the SCSI subclass by calling the function sl_usbd_msc_init() and sl_usbd_msc_scsi_init() .
L'example below shows how to call sl_usbd_msc_init() and sl_usbd_msc_scsi_init() .

Example – Calling sl_usbd_msc_init() and sl_usbd_msc_scsi_init()

sl_status_t status;
status = sl_usbd_msc_init(); if (status ! SL_STATUS_OK) { /* An error occurred. Error handling should be added here. */
}
status = sl_usbd_msc_scsi_init(); if (status ! SL_STATUS_OK) { /* An error occurred. Error handling should be added here. */
}
Adding a USB Device MSC SCSI Class Instance to Your Device
To add MSC SCSI class functionality to your device, first create an instance, then add it to your device’s configuration(s). You must add at least one logical unit to your instance.
Creating an MSC SCSI Class Instance
Create a MSC SCSI class instance by calling the function sl_usbd_msc_scsi_create_instance() .
L'example below shows how to call sl_usbd_msc_scsi_create_instance() using default arguments. For more information on the configuration arguments to pass to sl_usbd_msc_scsi_create_instance() , see USB Device MSC Class Application Specific Configurations .
Example – Calling sl_usbd_ msc_scsi_create_instance()

47/174

Sopraview

uint8_t class_nbr; sl_status_t status;
sl_usbd_msc_scsi_callbacks_t app_usbd_msc_scsi_callbacks = { .enable = NULL, .disable = NULL, .host_eject = NULL };
status = sl_usbd_msc_scsi_create_instance(&app_usbd_msc_scsi_callbacks,0 &class_nbr);
if (status ! SL_STATUS_OK) { /* An error occurred. Error handling should be added here. */ }
Adding the MSC Class Instance to Your Device’s Configuration(s)
After you have created an MSC class instance, you can add it to a configuration by calling the function
sl_usbd_msc_add_to_configuration() .
L'example below show how to call sl_usbd_msc_scsi_add_to_configuration() using default arguments.
Example – Calling sl_usbd_ msc_scsi_add_to_configuration()

sl_status_t status;

status = sl_usbd_msc_scsi_add_to_configuration(class_nbr,

(1)

config_nbr_fs);

(2)

if (status ! SL_STATUS_OK) {

/* An error occurred. Error handling should be added here. */

}

(1) Class number to add to the configuration returned by sl_usbd_msc_scsi_create_instance() . (32) Configuration number (here adding it to a Full-Speed configuration).
USB Device MSC Class Logical Unit Handling
Adding a Logical Unit Attaching/Detaching a Storage Medium
Adding a Logical Unit
When adding a logical unit to your MSC SCSI class instance, it must be bound to a storage medium (RAMDisk, SD card, flash memory, etc). The MSC class uses a storage driver to communicate with storage media. This driver will need to be supply when adding the logical unit.
L'example below shows how to add a logical unit via sl_usbd_msc_scsi_lun_add() .
Example – Adding a Logical Unit via sl_usbd_msc_scsi_lun_add()

48/174

Sopraview

sl_usbd_msc_scsi_lun_t *lu_object_ptr = NULL;

sl_usbd_msc_scsi_lun_info_t lu_info;

sl_status_t

status;

lu_info.sl_usbd_msc_scsi_lun_api_t = &app_usbd_scsi_storage_block_device_api;

lu_info.vendor_id_ptr

= “Silicon Labs”;

lu_info.product_id_ptr

= “block device example”;

lu_info.product_revision_level = 0x1000u;

lu_info.is_read_only

= false;

status = sl_usbd_msc_scsi_lun_add(class_nbr, &lu_info, &lu_object_ptr);
if (status ! SL_STATUS_OK) { /* An error occurred. Error handling should be added here. */ }

Attaching/Detaching a Storage Medium
After the logical unit has been added, a storage medium must be attached to be available from the host side. The MSC class offers two functions to control the storage media association to the logical unit: sl_usbd_msc_scsi_lun_attach() and sl_usbd_msc_scsi_lun_detach() . These functions allow you to emulate the removal of a storage device in order to re-gain access from the embedded application if necessary.
L'example below shows how to use the function sl_usbd_msc_scsi_lun_attach() and sl_usbd_msc_scsi_lun_detach() .
Example – Media Attach/Detach

sl_status_t status;

status = sl_usbd_msc_scsi_lun_attach(lu_object_ptr); if (status ! SL_STATUS_OK) { /* An error occurred. Error handling should be added here. */
}

…

(1)

status = sl_usbd_msc_scsi_lun_detach(lu_object_ptr); if (status ! SL_STATUS_OK) {
/* An error occurred. Error handling should be added here. */
}

…

(2)

status = sl_usbd_msc_scsi_lun_attach(lu_object_ptr) if (status ! SL_STATUS_OK) {
/* An error occurred. Error handling should be added here. */
}

…

(3)

(1) From this moment, if the MSC device is connected to a host, the storage media is accessible.
(2) If the MSC device is connected to a host, the media will now appear as unavailable. At this moment, operations can be performed on the media from the embedded application.
(3) Again, if the MSC device is connected to the host, the storage media will appear as connected.
USB Device MSC Class Storage Drivers
The USB Device MSC Class needs a storage driver to communicate with a storage medium. For the moment, Silicon Labs doesn’t offer drivers.

49/174

Sopraview
T P Y a a he driver A I is defined by typedef sl_usbd_msc_scsi_lun_api_t . our sl_usbd_msc_scsi_lun_api_t v ri ble must be included to a a a a a a a a your sl_usbd_msc_scsi_lun_info_t v ri ble, p ssed s rgument when you dd logic l unit with sl_usbd_msc_scsi_lun_add() . See section USB Device MSC SCSI API for more details on the structures. The storage driver implementation can be as simple as an array of sectors in RAM. Typical sector size (i.e., block size) is 512 for mass storage devices, and 2048 for CD-ROMs.

50/174

Sopraview
Sopraview
USB Device Vendor Class
USB Device Vendor Class Overview USB Device Vendor Class Resource Needs from Core USB Device Vendor Class Configuration USB Device Vendor Class Programming Guide The Vendor class allows you to build vendor-specific devices that can implement a proprietary protocol. It relies on a pair of bulk endpoints to transfer data between the host and the device. Bulk transfers are convenient for transferring large amounts of unstructured data and provide a reliable exchange of data by using an error detection and retry mechanism. In addition to bulk endpoints, the Vendor class can also use an optional pair of interrupt endpoints. Any operating system (OS) can work with the Vendor class provided that the OS has a driver to handle the Vendor class. Depending on the OS, the driver can be native or vendor-specific. For instance, under Microsoft Windows®, your application interacts with the WinUSB driver provided by Microsoft to communicate with the vendor device.
USB Device Vendor Class Overview
Figure – General Architecture Between Windows Host and Vendor Class shows the general architecture between the host and the device using the Vendor class. In this example, the host operating system is MS Windows.
Figure – General Architecture Between MS Windows Host and Vendor Class

On the MS Windows side, the application communicates with the vendor device by interacting with a USB library. Libraries, like libusb, offer an API to manage a device and its associated pipes, and to communicate with the device through control, bulk and interrupt endpoints.
On the device side, the Vendor class is composed of the following endpoints:
A pair of control IN and OUT endpoints called the default endpoint. A pair of bulk IN and OUT endpoints.

51/174

Sopraview

A pair of interrupt IN and OUT endpoints. This pair is optional. The table below indicates the usage of the different endpoints:
Table – Vendor Class Endpoints Usage

Endpoint Direction

Controllo IN
Controllare
FUORI
Bulk IN

Device-tohost
>Host-todevice
Device-tohost

Bulk OUT
Interrupt IN
Interrompere
FUORI

Host-todevice
Device-tohost
Host-todevice

Utilizzo
Standard requests for enumeration and vendor-specific requests.
Standard requests for enumeration and vendor-specific requests.
Raw data communication. Data can be structured according to a proprietary protocol.
Raw data communication. Data can be structured according to a proprietary protocol.
Raw data communication or notification. Data can be structured according to a proprietary protocol. Raw data communication or notification. Data can be structured according to a proprietary protocol.

The device application can use bulk and interrupt endpoints to send or receive data to or from the host. It can only use the default endpoint to decode vendor-specific requests sent by the host. The standard requests are managed internally by the Core layer of Silicon Labs USB Device.
USB Device Vendor Class Resource Needs from Core

Each time you add a vendor class instance to a configuration via the function sl_usbd_vendor_add_to_configuration() , the following resources will be allocated from the core.

Risorsa
Interfaces Alternate interfaces Endpoints Interface groups

Quantità
1 1 2 (4 if you enabled interrupt endpoints) 0

Two groups of configuration parameters are used to configure the Vendor class:
USB Device Vendor Class Application-Specific Configurations USB Device Vendor Class Instance Configurations
USB Device Vendor Class Application-Specific Configurations
First, to use the Silicon Labs USB device Vendor class module, adjust the Vendor compile-time configuration defines according to your application needs. They are regrouped inside the sl_usbd_core_config.h header file under the Vendor section. The quantity configurations purpose is to inform the USB device module about how many USB Vendor objects to allocate.
The table below describes each configuration define.

52/174

Sopraview

Table – USB Device Vendor Configuration Defines

Nome configurazione

Descrizione

Valore predefinito

SL_USBD_VENDOR_CLASS_INSTANCE_QUANTITY Number of class instances you will allocate via a call to the 2 function sl_usbd_vendor_create_instance() .

SL_USBD_VENDOR_CONFIGURATION_QUANTITY Number of configurations. Vendor class instances can be 1 added to one or more configurations via a call to the function sl_usbd_vendor_add_to_configuration() .

USB Device Vendor Class Instance Configurations

This section defines the configurations related to the Vendor class instances.
Class Instance Creation intr_en interval p_vendor_callbacks
Class Instance Creation

Creating a Vendor class instance is done by calling the function sl_usbd_vendor_create_instance() , which takes three configuration arguments that are described below.

intr_en
Boolean that indicates if a pair of interrupt endpoints should be added or not.

Valore
vero falso

Descrizione
A pair of IN/OUT endpoints will be added and made available to the embedded application. No interrupt endpoint will be added. Only a pair of Bulk IN/OUT endpoint will be available.

intervallo
If you set intr_en to true , you can specify the interrupt endpoints polling interval (in milliseconds). If you set intr_en to false , you can set interval to 0 as it will be ignored by the class.
p_vendor_callbacks
p_vendor_callbacks is a pointer to a callback functions structure variable. that you can specify to handle the class specific control requests. If you don’t use any class specific requests or needs enable/disable notification, you can set this to NULL .
L'example below provides the expected signature of your class specific requests handler.
Example – Signature of Class-Specific Request Function

void app_usbd_vendor_req_handle(uint8_t

class_nbr, (1)

const sl_usbd_setup_req_t *p_setup_req); (2)

sl_usbd_vendor_callbacks_t app_usbd_vendor_callback_functions =
{
.enable = NULL, .disable = NULL, .setup_req = app_usbd_vendor_req_handle,
};

(1) Vendor class instance number.

53/174

Sopraview

(2) Pointer to a received setup request from host.
USB Device Vendor Class Programming Guide
This section explains how to use the Vendor class. Initializing the USB Device Vendor Class Adding a USB Device Vendor Class Instance to your Device Communicating using the USB Device Vendor Class
Initializing the USB Device Vendor Class
To add a Vendor Class functionality to your device, first initialize the class by calling the function USBD_Vendor_Init(). The example below shows how to call sl_usbd_vendor_init() .
Example – Calling sl_usbd_vendor_init()

sl_status_t status;
status = sl_usbd_vendor_init(); if (status ! SL_STATUS_OK) { /* An error occurred. Error handling should be added here. */ }
Adding a USB Device Vendor Class Instance to your Device
To add vendor class functionality to your device, you must first create an instance, then add it to your device’s configuration(s).
Creating a Vendor Class Instance Adding the Vendor Class Instance to Your Device’s Configuration(s)
Creating a Vendor Class Instance
Create a Vendor class instance by calling the function sl_usbd_vendor_create_instance() . The example below shows how to call sl_usbd_vendor_create_instance() using default arguments. For more information about the configuration arguments to pass to sl_usbd_vendor_create_instance() , see USB Device Vendor Class Instance Configurations .
Example – Calling sl_usbd_vendor_create_instance()

uint8_t class_nbr; sl_status_t status;

status = sl_usbd_vendor_create_instance(false,

(1)

0u,

(2)

app_usbd_vendor_callback_functions, (3)

&class_nbr);

if (status ! SL_STATUS_OK) {

/* An error occurred. Error handling should be added here. */

}

(1) No Interrupt endpoints with this class instance. (2) Interval is ignored since Interrupt endpoints are disabled.

54/174

Sopraview

(3) Callback function that is part of your application that handles vendor-specific class requests. See Communicating using the USB Device Vendor Class for more information. Adding the Vendor Class Instance to Your Device’s Configuration(s) After you have created a vendor class instance, you can add it to a configuration by calling the function USBD_Vendor_ConfigAdd(). The example below shows how to call sl_usbd_vendor_add_to_configuration() using default arguments.
Example – Calling sl_usbd_vendor_add_to_configuration()

sl_status_t status;

status = sl_usbd_vendor_add_to_configuration(class_nbr,

(1)

config_nbr_fs);

(2)

if (status ! SL_STATUS_OK) {

/* An error occurred. Error handling should be added here. */

}

(1) Class number to add to the configuration returned by sl_usbd_vendor_create_instance() . (2) Configuration number (here adding it to a Full-Speed configuration).
Communicating Using the USB Device Vendor Class
General Synchronous Communication Asynchronous Communication Vendor Request General The Vendor class offers the following functions to communicate with the host. For more details about the parameters of the function, see USB Device Vendor API.
Table – Vendor Communication API Summary

Nome della funzione
sl_usb d _v e nd o r_ re ad _b ulk_sy nc() sl_usb d _v e nd o r_write _b ulk_sy nc() sl_usb d _v e nd o r_ re ad _b ulk_asy nc() sl_usb d _v e nd o r_write _b ulk_asy nc() sl_usb d _v e nd o r_ re ad _inte rrup t_sy nc() sl_usb d _v e nd o r_write _inte rrup t_sy nc() sl_usb d _v e nd o r_ re ad _inte rrup t_asy nc
()
sl_usb d _v e nd o r_write _inte rrup t_asy nc
()

Operation Receives data from host through bulk OUT endpoint. This function is blocking. Sends data to host through bulk IN endpoint. This function is blocking. Receives data from host through bulk OUT endpoint. This function is non-blocking. Sends data to host through bulk IN endpoint. This function is non-blocking. Receives data from host through interrupt OUT endpoint. This function is blocking. Sends data to host through interrupt IN endpoint. This function is blocking. Receives data from host through interrupt OUT endpoint. This function is non-
bloccando.
Sends data to host through interrupt IN endpoint. This function is non-blocking.

The vendor requests are also another way to communicate with the host. When managing vendor requests sent by the host, the application can receive or send data from or to the host using the control endpoint; you will need to provide an application callback passed as a parameter of sl_usbd_vendor_create_instance() . Synchronous Communication

55/174

Sopraview

Synchronous communication means that the transfer is blocking. When a function is called, the application blocks until the transfer completes with or without an error. A timeout can be specified to avoid waiting forever. The example below shows a read and write that receives data from the host using the bulk OUT endpoint and sends data to the host using the bulk IN endpoint.
Example – Synchronous Bulk Read and Write

__ALIGNED(4) uint8_t rx_buf[2];

__ALIGNED(4) uint8_t tx_buf[2];

uint32_t

xfer_len;

sl_status_t

status;

status = sl_usbd_vendor_read_bulk_sync(class_nbr,

(1)

(void *)&rx_buf[0],

(2)

2u,

0u,

(3)

&xfer_len);

if (status ! SL_STATUS_OK) {

/* $$$$ Handle the error. */

}

status = sl_usbd_vendor_write_bulk_sync( class_nbr,

(1)

(void *)&tx_buf[0],

(4)

2u,

0u,

(3)

false,

(5)

&xfer_len);

if (status ! SL_STATUS_OK) {

/* $$$$ Handle the error. */

}

(1) The class instance number created with sl_usbd_vendor_create_instance() provides an internal reference to the Vendor class to route the transfer to the proper bulk OUT or IN endpoint.
(2) The application must ensure that the buffer provided to the function is large enough to accommodate all the data. Otherwise, synchronization issues might happen.
(3) In order to avoid an infinite blocking situation, a timeout expressed in milliseconds can be specified. A value of 809 makes the application task wait forever.
(4) The application provides the initialized transmit buffer.
(5) If this flag is set to true , and the transfer length is multiple of the endpoint maximum packet size, the device stack will send a zero-length packet to the host to signal the end of the transfer.
The use of interrupt endpoint communication functions, sl_usbd_vendor_read_interrupt_sync() and sl_usbd_vendor_write_interrupt_sync() , is similar to bulk endpoint communication functions presented in Example – Synchronous Bulk Read and Write.
Comunicazione asincrona
Asynchronous communication means that the transfer is non-blocking. When a function is called, the application passes the transfer information to the device stack and does not block. Other application processing can be done while the transfer is in progress over the USB bus. Once the transfer has completed, a callback function is called by the device stack to inform the application about the transfer completion. The example below shows asynchronous read and write.
Example – Asynchronous Bulk Read and Write

56/174

Sopraview

void app_usbd_vendor_comm (uint8_t class_nbr)

{

__ALIGNED(4) uint8_t rx_buf[2];

__ALIGNED(4) uint8_t tx_buf[2];

sl_status_t

status;

status = sl_usbd_vendor_read_bulk_async(class_nbr,

(void *)&rx_buf[0],

(2)

2u,

app_usbd_vendor_rx_completed,

NULL);

(4)

if (status ! SL_STATUS_OK) {

/* $$$$ Handle the error. */

}

status = sl_usbd_vendor_write_bulk_async(class_nbr,

(void *)&tx_buf[0],

(5)

2u,

app_usbd_vendor_tx_completed,

NULL,

(4)

false);

(6)

if (status ! SL_STATUS_OK) {

/* $$$$ Handle the error. */

}

(1) (3)
(1) (3)

static void app_usbd_vendor_rx_completed(uint8_t class_nbr,

(3)

void *p_buf,

uint32_t buf_len,

uint32_t xfer_len,

void *p_callback_arg,

sl_status_t status)

{

if (status ! SL_STATUS_OK) {

/* $$$$ Do some processing. */

} altro {

/* $$$$ Handle the error. */

}

static void app_usbd_vendor_tx_completed(uint8_t class_nbr,

(3)

void *p_buf,

uint32_t buf_len,

uint32_t xfer_len,

void *p_callback_arg,

sl_status_t status)

{

if (status ! SL_STATUS_OK) {

/* $$$$ Do some processing. */

} altro {

/* $$$$ Handle the error. */

}

(1) The class instance number provides an internal reference to the Vendor class to route the transfer to the proper bulk OUT or IN endpoint. (2) The application must ensure that the buffer provided is large enough to accommodate all the data. Otherwise, there may be synchronization issues. (3) The application provides a callback function pointer passed as a parameter. Upon completion of the transfer, the device stack calls this callback function so that the application can finalize the transfer by analyzing the transfer result. For instance, on completion of a read operation, the application might perform processing on the received data. Upon write completion, the application can indicate if the write was successful and how many bytes were sent.

57/174

Sopraview
(4) An argument associated with the callback can be also passed. Then in the callback context, some private information can be retrieved. (5) The application provides the initialized transmit buffer. (6) If this flag is set to true , and the transfer length is a multiple of the endpoint maximum packet size, the device stack will send a zero-length packet to the host to signal the end of transfer. The use of interrupt endpoint communication functions, sl_usbd_vendor_read_interrupt_async() and sl_usbd_vendor_write_interrupt_async() , is similar to the bulk endpoint communication functions presented in Example Asynchronous Bulk Read and Write.
Vendor Request
The USB 2.0 specification defines three types of requests: standard, class, and vendor. All standard requests are handled directly by the core layer, while class requests are managed by the proper associated class. Vendor requests can be processed by the vendor class. To process vendor requests, you must provide an application callback as a parameter of sl_usbd_vendor_create_instance() . After a vendor request is received by the USB device, it must be decoded properly. The example below shows vendor request decoding. Certain requests may be required to receive from or send to the host during the data stage of a control transfer. If no data stage is present, you only have to decode the Setup packet. This example shows the three types of data stage management: no data, data OUT and data IN.
Example – Vendor Request Decoding

58/174

Sopraview

#define APP_VENDOR_REQ_NO_DATA

0x01u

#define APP_VENDOR_REQ_RECEIVE_DATA_FROM_HOST 0x02u

#define APP_VENDOR_REQ_SEND_DATA_TO_HOST 0x03u

#define APP_VENDOR_REQ_DATA_BUF_SIZE

50u

static uint8_t app_vendor_req_buf[APP_VENDOR_REQ_DATA_BUF_SIZE];

static bool app_usbd_vendor_req (uint8_t

class_nbr,

const sl_usbd_setup_req_t *p_setup_req)

(1)

{

bool valid;

sl_status_t status;

uint16_t req_len;

uint32_t xfer_len;

(void)class_nbr;

switch(p_setup_req->bRequest) { case APP_VENDOR_REQ_NO_DATA: valid = true; break;

(2) (3)

case APP_VENDOR_REQ_RECEIVE_DATA_FROM_HOST:

(4)

req_len = p_setup_req->wLength;

if (req_len > APP_VENDOR_REQ_DATA_BUF_SIZE) {

// Not enough room to receive data.

return (false);

}

// Receive data via Control OUT EP. // Wait transfer completion forever. status = sl_usbd_core_read_control_sync((void *)&app_vendor_req_buf[0u],
req_len, 0u, &xfer_len); if (status ! SL_STATUS_OK) { valid = false; } else { valid = true; } break;

case APP_VENDOR_REQ_SEND_DATA_TO_HOST:

(5)

req_len = APP_VENDOR_REQ_DATA_BUF_SIZE;

// Fill buf with a pattern. Mem_Set((void *)&AppVendorReqBuf[0u],
'UN',
req_len);

// Send data via Control IN EP. // Wait transfer completion forever. status = sl_usbd_core_write_control_sync((void *)&app_vendor_req_buf[0u],
req_len, 0u, false, &xfer_len); if (status ! SL_STATUS_OK) { valid = DEF_FAIL; } else { valid = DEF_OK; } break;

predefinito:

(6)

// Request is not supported.

59/174

Sopraview

valid =true;break;
case APP_VENDOR_REQ_RECEIVE_DATA_FROM_HOST:(4) req_len = p_setup_req->wLength;if(req_len > APP_VENDOR_REQ_DATA_BUF_SIZE){// Not enough room to receive data.return(false);}// Receive data via Control OUT EP.// Wait transfer completion forever. status =sl_usbd_core_read_control_sync((void *)&app_vendor_req_buf[0u],
req_len,0u,&xfer_len);if(status ! SL_STATUS_OK){ valid =false;}else{ valid =true;}break;
case APP_VENDOR_REQ_SEND_DATA_TO_HOST:(5) req_len = APP_VENDOR_REQ_DATA_BUF_SIZE;// Fill buf with a pattern.Mem_Set((void *)&AppVendorReqBuf[0u],’A’,
req_len);// Send data via Control IN EP.// Wait transfer completion forever. status =sl_usbd_core_write_control_sync((void *)&app_vendor_req_buf[0u],
req_len,0u,false,&xfer_len);if(status ! SL_STATUS_OK){ valid = DEF_FAIL;}else{ valid = DEF_OK;}break;
default:(6)// Request is not supported. valid = DEF_FAIL;break;}return(valid);}

(1) The core will pass the Setup packet content to your application. The structure sl_usbd_setup_req_t contains the same fields as defined by the USB 2.0 specification (refer to section “9.3 USB Device Requests” of the specification for more details):

tipodef struttura {

uint8_t bmRequestType; /* Characteristics of request.

uint8_t bRequest; /* Specific request.

uint16_t wValue; /* Varies according to request.

uint16_t wIndex; /* Varies according to request; typically used as index.*/

uint16_t wLength; /* Transfer length if data stage presente.

} sl_usbd_setup_req_t;

(2) Determine the request. You may use a switch statement if you are using different requests. In this example, there are three different requests corresponding to the three types of the data stage: APP_VENDOR_REQ_NO_DATA, APP_VENDOR_REQ_RECEIVE_DATA_FROM_HOST, and APP_VENDOR_REQ_SEND_DATA_TO_HOST.
(3) If no data stage is present, you only need to decode the other fields. The presence of a data stage or not is indicated by the field wLength being non-null or null.
(4) If the host sends data to the device, you must call the function sl_usbd_core_read_control_sync() . The buffer provided should be able to contain up to wLength bytes. If any error occurs, return false to the core that will stall the status stage of the control transfer, indicating to the host that the request cannot be processed. true is returned in case of success.
(5) If the host receives data from the device, you must call the function sl_usbd_core_write_control_sync() . If any error occurs, return false to the core that will stall the status stage of the control transfer, indicating to the host that the request cannot be processed. true is returned in case of success.
(6) In this example, all requests not recognized are marked by returning false to the core. This one will stall the data or status stage of the control transfer indicating to the host that the request is not supported.
The host sends vendor requests through a host vendor application. USb libraries, such as libusb, can be used to help you develop your custom host vendor application.

60/174

Documentazione API
Documentazione API
Documentazione API
Elenco dei moduli
USB Device API USB Device ACM API USB Device CDC API USB Device Core API USB Device HID API USB Device MSC API USB Device MSC SCSI API USB Device Vendor API

Descrizione
USB Device API USB Device ACM API USB Device CDC API USB Device Core API USB Device HID API USB Device MSC API USB Device MSC SCSI API USB Device Vendor API

61/174

USB Device API
USB Device API
USB Device API
USB Device API.
Moduli
USB Device ACM API USB Device CDC API USB Device Core API USB Device HID API USB Device MSC API USB Device MSC SCSI API USB Device Vendor API

62/174

USB Device ACM API

USB Device CDC ACM API.
Moduli
a sl_usbd_cdc_ cm_line_coding_t sl_usbd_cdc_acm_callbacks_t
Funzioni

sl_status_t sl_status_t
sl_status_t sl_status_t sl_status_t
sl_status_t
sl_status_t
sl_status_t
sl_status_t sl_status_t sl_status_t sl_status_t sl_status_t

a sl_usbd_cdc_ cm_init(void)
GLOBAL VARIABLES.
ssll__uussbbdd__ccddcc__aaccmm__ccraellabtaec_kins_stta*npc_ea(cumin_tc1a6l_lbtalicnkes_,sutaintte8__int t*eprv_saul,bucinlats1s6__nt bcra)ll_mgmt_capabilities,
Add a new instance of the CDC ACM serial emulation subclass.
a a a a sl_usbd_cdc_ cm_ dd_to_configur tion(uint8_t subcl ss_nbr, uint8_t config_nbr)
Add a CDC ACM subclass class instance into USB device configuration.
a a sl_usbd_cdc_ cm_is_en bled(uint8_t subclass_nbr, bool *p_enabled)
Get the CDC ACM serial emulation subclass enable state.
a a a sl_usbd_cdc_ cm_re d(uint8_t subcl ss_nbr, uint8_t *p_buf, uint32_t buf_len, uint16_t timeout, uint32_t
*p_xfer_len) Receive data on the CDC ACM serial emulation subclass.
a a a a sl_usbd_cdc_ cm_re d_ sync(uint8_t subcl ss_nbr, uint8_t *p_buf, uint32_t buf_len, a a a a sl_usbd_cdc_ sync_function_t sync_fnct, void *p_ sync_ rg)
Receive data on the CDC ACM serial emulation subclass asynchronously.
a a sl_usbd_cdc_ cm_write(uint8_t subcl ss_nbr, uint8_t *p_buf, uint32_t buf_len, uint16_t timeout, uint32_t
*p_xfer_len) Send data on the CDC ACM serial emulation subclass.
a a a sl_usbd_cdc_ cm_write_ sync(uint8_t subcl ss_nbr, uint8_t *p_buf, uint32_t buf_len, a a a a sl_usbd_cdc_ sync_function_t sync_fnct, void *p_ sync_ rg)
Send data on the CDC ACM serial emulation subclass asynchronously.
a a a sl_usbd_cdc_ cm_get_line_control_st te(uint8_t subcl ss_nbr, uint8_t *p_line_ctrl)
Return the state of control lines.
a a a sl_usbd_cdc_ cm_get_line_coding(uint8_t subcl ss_nbr, sl_usbd_cdc_ cm_line_coding_t *p_line_coding)
Get the current state of the line coding.
a a a sl_usbd_cdc_ cm_set_line_coding(uint8_t subcl ss_nbr, sl_usbd_cdc_ cm_line_coding_t *p_line_coding)
Set a new line coding.
a a a sl_usbd_cdc_ cm_set_line_st te_event(uint8_t subcl ss_nbr, uint8_t events)
Set a line state event(s).
a a a a sl_usbd_cdc_ cm_cle r_line_st te_event(uint8_t subcl ss_nbr, uint8_t events)
Clear a line state event(s).

63/174

USB Device ACM API
Macro
#define SL_USBD_CDC_ACM_NBR_NONE 255u
MODULO.
#define SL_USBD_CDC_ACM_PARITY_NONE 0u
PORT SETTINGS DEFINES.
#define SL_USBD_CDC_ACM_PARITY_ODD 1u #define SL_USBD_CDC_ACM_PARITY_EVEN 2u #define SL_USBD_CDC_ACM_PARITY_MARK 3u #define SL_USBD_CDC_ACM_PARITY_SPACE 4u #define SL_USBD_CDC_ACM_STOP_BIT_1 0u #define SL_USBD_CDC_ACM_STOP_BIT_1_5 1u #define SL_USBD_CDC_ACM_STOP_BIT_2 2u #define SL_USBD_CDC_ACM_CTRL_BREAK 0 01u
LINE EVENTS FLAGS DEFINES.
#define SL_USBD_CDC_ACM_CTRL_RTS 0 02u #define SL_USBD_CDC_ACM_CTRL_DTR 0 04u #define SL_USBD_CDC_ACM_STATE_DCD 0 01u #define SL_USBD_CDC_ACM_STATE_DSR 0 02u #define SL_USBD_CDC_ACM_STATE_BREAK 0 04u #define SL_USBD_CDC_ACM_STATE_RING 0 08u #define SL_USBD_CDC_ACM_STATE_FRAMING 0 10u #define SL_USBD_CDC_ACM_STATE_PARITY 0 20u #define SL_USBD_CDC_ACM_STATE_OVERUN 0 40u #define SL_USBD_CDC_ACM_CALL_MGMT_DEV 0 01u
CALL MANAGEMENT CAPABILITIES.
#define SL_USBD_CDC_ACM_CALL_MGMT_DATA_CCI_DCI 0 02u #define SL_USBD_CDC_ACM_CALL_MGMT_DATA_OVER_DCI 0 02u | 0 01u)
Function Documentation
sl_usbd_cdc_acm_init
sl_status_t sl_usbd_cdc_acm_init (void )
GLOBAL VARIABLES. Parameters
Copyright © 2025 Laboratori di silicio. Tutti i diritti riservati.

64/174

USB Device ACM API

Tipo
vuoto

Direction N/A

Argument Name

MACROS GLOBAL CONSTANTS FUNCTION PROTOTYPES CDC ACM FUNCTIONS

Initialize the CDC ACM serial emulation subclass.
Resi

Returns SL_STATUS_OK on success or another SL_STATUS code on failure.

Descrizione

sl_usbd_cdc_acm_create_instance

sl_status_t sl_usbd_cdc_acm_create_instance (uint16_t line_state_interval, uint16_t call_mgmt_capabilities, sl_usbd_cdc_acm_callbacks_t * p_acm_callbacks, uint8_t * p_subclass_nbr)

Add a new instance of the CDC ACM serial emulation subclass.
Parametri

Tipo
uint16_t
uint16_t

Direction Argument Name

Descrizione

N / A

line_state_interval Line state notification interval in milliseconds (value must

be a power of 2).

N / A

call_mgmt_capabilities Call Management Capabilities bitmap. OR’ed of the

following flags:

SL_USBD_CDC_ACM_CALL_MGMT_DEV Device handles call management itself. SL_USBD_CDC_ACM_CALL_MGMT_DATA_CCI_DCI Device can send/receive call management information over a Data Class interface.

sl_usbd_cdc_acm_callbacks_t N/A
*

uint8_t *

N / A

p_acm_callbacks p_subclass_nbr

Optional pointers to callback functions to be called on various events.
Param to variable that will receive CDC ACM serial emulation subclass instance number.

Resi

Return SL_STATUS_OK on success or another SL_STATUS code on failure.

sl_usbd_cdc_acm_add_to_configuration

sl_status_t sl_usbd_cdc_acm_add_to_configuration (uint8_t subclass_nbr, uint8_t config_nbr)

Add a CDC ACM subclass class instance into USB device configuration.
Parametri

Tipo
uint8_t uint8_t

Direction N/A N/A

Argument Name
subclass_nbr config_nbr

Description CDC ACM serial emulation subclass instance number. Configuration index to add new test class interface to.

Resi

65/174

USB Device ACM API
Returns SL_STATUS_OK on success or another SL_STATUS code on failure.

sl_usbd_cdc_acm_is_enabled

sl_status_t sl_usbd_cdc_acm_is_enabled (uint8_t subclass_nbr, bool * p_enabled)

Get the CDC ACM serial emulation subclass enable state.
Parametri

Tipo

Direzione

Argument Name

Descrizione

uint8_t N/A

subclass_nbr CDC ACM serial emulation subclass instance number.

bool * N/A

p_enabled

Boolean to a variable that will receive enable status. The variable is set to true, CDC ACM serial emulation is enabled. The va

Documenti / Risorse

SILICON LABS USB Device Stack [pdf] Manuale di istruzioni
USB Device Stack, Device Stack, Stack

Riferimenti

Manuale d'uso

SILICON LABS USB Device Stack Instruction Manual

Stack di dispositivi USB

Specifiche

Prodotto finitoview

Caratteristiche

Istruzioni per l'uso del prodotto

USB Device Configuration

USB Device Programming Guide

USB Device Classes

USB Device Troubleshooting

Microsoft Windows OS USB Host

Domande frequenti

D: Quali sono alcuni esempi comuni?amples of devices I can build using
this USB stack?

Q: Are there any specific software requirements for using this
USB device stack?

Documenti / Risorse

Riferimenti

Lascia un commento

Annulla risposta

Stack di dispositivi USB

Specifiche

Prodotto finitoview

Caratteristiche

Istruzioni per l'uso del prodotto

USB Device Configuration

USB Device Programming Guide

USB Device Classes

USB Device Troubleshooting

Microsoft Windows OS USB Host

Domande frequenti

D: Quali sono alcuni esempi comuni?amples of devices I can build usingthis USB stack?

Q: Are there any specific software requirements for using thisUSB device stack?

Documenti / Risorse

Riferimenti

Lascia un commento

Annulla risposta

D: Quali sono alcuni esempi comuni?amples of devices I can build using
this USB stack?

Q: Are there any specific software requirements for using this
USB device stack?