Chapter 5 - USBX Device Class Considerations

Device Class Registration
General Considerations For Bulk Transfer

USB Device Classes :

USB Device Storage Class
USB Device CDC-ACM Class
USB Device CDC-ECM Class
USB Device HID Class

device_class_registration

Each device class follows the same principle for registration. A structure containing specific class parameters is passed to the class initialize function.

/* Set the parameters for callback when insertion/extraction of a HID device. */
hid_parameter.ux_slave_class_hid_instance_activate = demo_hid_instance_activate;
hid_parameter.ux_slave_class_hid_instance_deactivate = demo_hid_instance_deactivate;

/* Initialize the hid class parameters for the device. */
hid_parameter.ux_device_class_hid_parameter_report_address = hid_device_report;
hid_parameter.ux_device_class_hid_parameter_report_length = HID_DEVICE_REPORT_LENGTH;
hid_parameter.ux_device_class_hid_parameter_report_id = UX_TRUE;
hid_parameter.ux_device_class_hid_parameter_callback = demo_hid_callback;

/* Initialize the device hid class. The class is connected with interface 0 */
status = ux_device_stack_class_register(_ux_system_slave_class_hid_name, ux_device_class_hid_entry, 1, 0, (VOID *)&hid_parameter);

Each class can register, optionally, a callback function when a instance of the class gets activated. The callback is then called by the device stack to inform the application that an instance was created.

The application would have in its body the 2 functions for activation and deactivation, as shown in the following example.

VOID demo_hid_instance_activate(VOID *hid_instance)
{
    /* Save the HID instance. */
    hid_slave = (UX_SLAVE_CLASS_HID *) hid_instance;
}

VOID demo_hid_instance_deactivate(VOID *hid_instance)
{
    /* Reset the HID instance. */
    hid_slave = UX_NULL;
}

It is not recommended to do anything within these functions but to memorize the instance of the class and synchronize with the rest of the application.

general_considerations_for_bulk_transfer

As per the USB 2.0 specification, an endpoint must always transmit data payloads with a data field less than or equal to the endpoint's reported wMaxPacketSize value. The size of a data packet is limited to bMaxPacketSize. Transfer can be completed with the following cases

The endpoint has transferred exactly the amount of data expected
When a device or host endpoint receives a packet with size less than max packet size(wMaxPacketSize). This short packet indicates that there is no more data packet left and transfer is complete or when the data packets to be transmitted are all equal to wMaxPacketSize, then the end of transfer cannot be determined. In order for transfer completion a Zero Length Packet(ZLP) must be sent Short packets and Zero Length Packets signify the end of a bulk data transfer. The above considerations apply to raw bulk data transfer APIs, e.g., ux_device_class_cdc_acm_read().

usb_device_storage_class

The USB device storage class allows for a storage device embedded in the system to be made visible to a USB host.

Storage Class Initialize
Storage Class Configuration Options
Storage Class Multiple SCSI LUN
Storage Class Write Caching SCSI LUN

The USB device storage class does not by itself provide a storage solution. It merely accepts and interprets SCSI requests coming from the host. When one of these requests is a read or a write command, it will invoke a pre-defined call back to a real storage device handler, such as an ATA device driver or a Flash device driver.

storage_class_initialize

When initializing the device storage class, a pointer structure is given to the class that contains all the information necessary. An example is given below.

UX_SLAVE_CLASS_STORAGE_PARAMETER  storage_parameter;

UCHAR demo_storage_vendor_id[] =      "USBX VID";
UCHAR demo_storage_product_id[] =     "USBX Storage ";
UCHAR demo_storage_product_rev[] =    "1010";
UCHAR demo_storage_product_serial[] = "01234567890123456789";

/* Initialize callbacks.  */
storage_parameter.ux_slave_class_storage_instance_activate = demo_storage_instance_activate;
storage_parameter.ux_slave_class_storage_instance_deactivate = demo_storage_instance_deactivate;

/* Initialize the storage class parameters to customize vendor strings. */
storage_parameter.ux_slave_class_storage_parameter_vendor_id = demo_storage_vendor_id;
storage_parameter.ux_slave_class_storage_parameter_product_id = demo_storage_product_id;
storage_parameter.ux_slave_class_storage_parameter_product_rev = demo_storage_product_rev;
storage_parameter.ux_slave_class_storage_parameter_product_serial = demo_storage_product_serial;

/* Store the number of LUN in this device storage instance: single LUN. */
storage_parameter.ux_slave_class_storage_parameter_number_lun = 1;

/* Initialize the storage class parameters for reading/writing to the Flash Disk. */
storage_parameter.ux_slave_class_storage_parameter_lun[0].ux_slave_class_storage_media_last_lba = 0x1e6bfe;
storage_parameter.ux_slave_class_storage_parameter_lun[0].ux_slave_class_storage_media_block_length = 512;
storage_parameter.ux_slave_class_storage_parameter_lun[0].ux_slave_class_storage_media_type = 0;
storage_parameter.ux_slave_class_storage_parameter_lun[0].ux_slave_class_storage_media_removable_flag = 0x80;
storage_parameter.ux_slave_class_storage_parameter_lun[0].ux_slave_class_storage_media_read_only_flag = UX_FALSE;
storage_parameter.ux_slave_class_storage_parameter_lun[0].ux_slave_class_storage_media_read = demo_storage_flash_media_read;
storage_parameter.ux_slave_class_storage_parameter_lun[0].ux_slave_class_storage_media_write = demo_storage_flash_media_write;
storage_parameter.ux_slave_class_storage_parameter_lun[0].ux_slave_class_storage_media_status = demo_storage_flash_media_status;
storage_parameter.ux_slave_class_storage_parameter_lun[0].ux_slave_class_storage_media_flush = demo_storage_flash_media_flush;

/* Initialize the device storage class. The class is connected with interface 0 */
status = ux_device_stack_class_register(_ux_system_slave_class_storage_name, ux_device_class_storage_entry, 1, 0, (VOID *)&storage_parameter);

if (status != UX_SUCCESS)
    return;

In this example, the driver storage strings are customized by assigning string pointers to corresponding parameter. If any one of the string pointer is left to UX_NULL, the default ThreadX string is used.

In this example, the drive's last block address or LBA is given as well as the logical sector size. The LBA is the number of sectors available in the media –1. The block length is set to 512 in regular storage media. It can be set to 2048 for optical drives.

The application needs to pass three callback function pointers to allow the storage class to read, write and obtain status for the media.

The prototypes for the read and write functions are shown in the example below.

UINT media_read( 
    VOID *storage,  
    ULONG lun,  
    UCHAR *data_pointer,
    ULONG number_blocks,  
    ULONG lba,  
    ULONG *media_status);

UINT media_write( 
    VOID *storage,  
    ULONG lun,  
    UCHAR *data_pointer,
    ULONG number_blocks,  
    ULONG lba,  
    ULONG *media_status);

Where:

storage is the instance of the storage class.
lun is the LUN the command is directed to.
data_pointer is the address of the buffer to be used for reading or writing.
number_blocks is the number of sectors to read/write.
lba is the sector address to read.
media_status should be filled out exactly like the media status callback return value.

The return value can have either the value UX_SUCCESS or UX_ERROR indicating a successful or unsuccessful operation. These operations do not need to return any other error codes. If there is an error in any operation, the storage class will invoke the status call back function.

This function has the following prototype.

ULONG media_status( 
    VOID *storage,  
    ULONG lun,  
    ULONG media_id,  
    ULONG *media_status);

The calling parameter media_id is not currently used and should always be 0. In the future it may be used to distinguish multiple storage devices or storage devices with multiple SCSI LUNs. This version of the storage class does not support multiple instances of the storage class or storage devices with multiple SCSI LUNs.

The return value is a SCSI error code that can have the following format.

Bits 0-7 Sense_key
Bits 8-15 Additional Sense Code
Bits 16-23 Additional Sense Code Qualifier

The following table provides the possible Sense/ASC/ASCQ combinations.

Sense Key	ASC	ASCQ	Description
00	00	00	NO SENSE
01	17	01	RECOVERED DATA WITH RETRIES
01	18	00	RECOVERED DATA WITH ECC
02	04	01	LOGICAL DRIVE NOT READY - BECOMING READY
02	04	02	LOGICAL DRIVE NOT READY - INITIALIZATION REQUIRED
02	04	04	LOGICAL UNIT NOT READY - FORMAT IN PROGRESS
02	04	FF	LOGICAL DRIVE NOT READY - DEVICE IS BUSY
02	06	00	NO REFERENCE POSITION FOUND
02	08	00	LOGICAL UNIT COMMUNICATION FAILURE
02	08	01	LOGICAL UNIT COMMUNICATION TIME-OUT
02	08	80	LOGICAL UNIT COMMUNICATION OVERRUN
02	3A	00	MEDIUM NOT PRESENT
02	54	00	USB TO HOST SYSTEM INTERFACE FAILURE
02	80	00	INSUFFICIENT RESOURCES
02	FF	FF	UNKNOWN ERROR
03	02	00	NO SEEK COMPLETE
03	03	00	WRITE FAULT
03	10	00	ID CRC ERROR
03	11	00	UNRECOVERED READ ERROR
03	12	00	ADDRESS MARK NOT FOUND FOR ID FIELD
03	13	00	ADDRESS MARK NOT FOUND FOR DATA FIELD
03	14	00	RECORDED ENTITY NOT FOUND
03	30	01	CANNOT READ MEDIUM - UNKNOWN FORMAT
03	31	01	FORMAT COMMAND FAILED
04	40	NN	DIAGNOSTIC FAILURE ON COMPONENT NN (80H-FFH)
05	1A	00	PARAMETER LIST LENGTH ERROR
05	20	00	INVALID COMMAND OPERATION CODE
05	21	00	LOGICAL BLOCK ADDRESS OUT OF RANGE
05	24	00	INVALID FIELD IN COMMAND PACKET
05	25	00	LOGICAL UNIT NOT SUPPORTED
05	26	00	INVALID FIELD IN PARAMETER LIST
05	26	01	PARAMETER NOT SUPPORTED
05	26	02	PARAMETER VALUE INVALID
05	39	00	SAVING PARAMETERS NOT SUPPORT
06	28	00	NOT READY TO READY TRANSITION – MEDIA CHANGED
06	29	00	POWER ON RESET OR BUS DEVICE RESET OCCURRED
06	2F	00	COMMANDS CLEARED BY ANOTHER INITIATOR
07	27	00	WRITE PROTECTED MEDIA
0B	4E	00	OVERLAPPED COMMAND ATTEMPTED

There are two additional, optional callbacks the application may implement; one is for responding to a GET_STATUS_NOTIFICATION command and the other is for responding to the SYNCHRONIZE_CACHE command.

If the application would like to handle the GET_STATUS_NOTIFICATION command from the host, it should implement a callback with the following prototype.

UINT ux_slave_class_storage_media_notification( 
    VOID *storage,  
    ULONG lun,
    ULONG media_id,  
    ULONG notification_class,
    UCHAR **media_notification,  
    ULONG *media_notification_length);

Where:

storage: is the instance of the storage class.
media_id: is not currently used. notification_class specifies the class of notification.
media_notification: should be set by the application to the buffer containing the response for the notification.
media_notification_length: should be set by the application to contain the length of the response buffer.

The return value indicates whether or not the command succeeded – should be either UX_SUCCESS or UX_ERROR.

If the application does not implement this callback, then upon receiving the GET_STATUS_NOTIFICATION command, USBX will notify the host that the command is not implemented.

The SYNCHRONIZE_CACHE command should be handled if the application is utilizing a cache for writes from the host. A host may send this command if it knows the storage device is about to be disconnected, for example, in Windows, if you right click a flash drive icon in the toolbar and select "Eject [storage device name]", Windows will issue the SYNCHRONIZE_CACHE command to that device.

If the application would like to handle the SYNCHRONIZE_CACHE command from the host, it should implement a callback with the following prototype.

UINT ux_slave_class_storage_media_flush(
    VOID *storage, 
    ULONG lun,
    ULONG number_blocks, 
    ULONG lba, 
    ULONG *media_status);

Where:

storage: is the instance of the storage class.
lun: parameter specifies which LUN the command is directed to.
number_blocks: specifies the number of blocks to synchronize.
lba: is the sector address of the first block to synchronize.
media_status: should be filled out exactly like the media status callback return value.

The return value indicates whether or not the command succeeded – should be either UX_SUCCESS or UX_ERROR.

storage_class_configuration_options

There are several configuration options for building USB Device Storage Class. All options are located in the ux_user.h.

The list below details each configuration option.

Configuration Option	Description
UX_MAX_SLAVE_LUN	This value represents the current number of SCSI logical units represented in the device storage class driver.
UX_SLAVE_CLASS_STORAGE_INCLUDE_MMC	This value includes code to handle storage Multi-Media Commands (MMC). E.g., DVD-ROM.

storage_class_multiple_scsi_lun

The USBX device storage class supports multiple LUNs. It is therefore possible to create a storage device that acts as a CD-ROM and a Flash disk at the same time. In such a case, the initialization would be slightly different. Here is an example for a Flash Disk and CD-ROM:

UX_SLAVE_CLASS_STORAGE_PARAMETER  storage_parameter;

/* Store the number of LUN in this device storage instance. */
storage_parameter.ux_slave_class_storage_parameter_number_lun = 2;

/* Initialize the storage class parameters for reading/writing to the Flash Disk. */
storage_parameter.ux_slave_class_storage_parameter_lun[0].ux_slave_class_storage_media_last_lba = 0x7bbff;
storage_parameter.ux_slave_class_storage_parameter_lun[0].ux_slave_class_storage_media_block_length = 512;
storage_parameter.ux_slave_class_storage_parameter_lun[0].ux_slave_class_storage_media_type = 0;
storage_parameter.ux_slave_class_storage_parameter_lun[0].ux_slave_class_storage_media_removable_flag = 0x80;
storage_parameter.ux_slave_class_storage_parameter_lun[0].ux_slave_class_storage_media_read = demo_storage_flash_media_read;
storage_parameter.ux_slave_class_storage_parameter_lun[0].ux_slave_class_storage_media_write = demo_storage_flash_media_write;
storage_parameter.ux_slave_class_storage_parameter_lun[0].ux_slave_class_storage_media_status = demo_storage_flash_media_status;

/* Initialize the storage class LUN parameters for reading/writing to the CD-ROM. */
storage_parameter.ux_slave_class_storage_parameter_lun[1].ux_slave_class_storage_media_last_lba = 0x04caaf;
storage_parameter.ux_slave_class_storage_parameter_lun[1].ux_slave_class_storage_media_block_length = 2048;
storage_parameter.ux_slave_class_storage_parameter_lun[1].ux_slave_class_storage_media_type = 5;
storage_parameter.ux_slave_class_storage_parameter_lun[1].ux_slave_class_storage_media_removable_flag = 0x80;
storage_parameter.ux_slave_class_storage_parameter_lun[1].ux_slave_class_storage_media_read = demo_storage_cdrom_media_read;
storage_parameter.ux_slave_class_storage_parameter_lun[1].ux_slave_class_storage_media_write = demo_storage_cdrom_media_write;
storage_parameter.ux_slave_class_storage_parameter_lun[1].ux_slave_class_storage_media_status = demo_storage_cdrom_media_status;

/* Initialize the device storage class for a Flash disk and CD-ROM. The class is connected with interface 0 */
status = ux_device_stack_class_register(_ux_system_slave_class_storage_name, ux_device_class_storage_entry, 1, 0, (VOID *)&storage_parameter);

if (status != UX_SUCCESS)
    return;

Note: In case multiple LUNs UX_MAX_SLAVE_LUN should be defined in ux_user.h with numbers of supported lun.

storage_class_write_caching_scsi_lun

The USBX device storage class supports write caching on LUNs.

The application needs to pass a callback function pointer to allow the storage class to report write caching enable to host and do flushing on host request.

The flush callback function has the following prototype:

UINT media_flush(VOID *storage, ULONG lun, ULONG number_blocks, ULONG lba, ULONG *media_status);

The calling parameter number_blocks and lba specifies the area on LUN that needs flush.

Note: when the callback is not assigned, host is not notified for write caching support, so there is no option for it. When the callback is assigned, host is notified for write caching enabled, but not allowed to change this setting.

usb_device_cdc_acm_class

The USB device CDC-ACM class allows for a USB host system to communicate with the device as a serial device. This class is based on the USB standard and is a subset of the CDC standard.

CDC-ACM Class Initialize
CDC-ACM Class Configuration Options
CDC-ACM Class APIs

cdc_acm_class_initialize

A CDC-ACM compliant device framework needs to be declared by the device stack. An example is found here below.

unsigned char device_framework_full_speed[] = {

    /*
    Device descriptor 18 bytes
    0x02 bDeviceClass: CDC class code
    0x00 bDeviceSubclass: CDC class sub code 0x00 bDeviceProtocol: CDC Device protocol
    idVendor & idProduct - https://www.linux-usb.org/usb.ids
    */

    0x12, 0x01, 0x10, 0x01,
    0xEF, 0x02, 0x01, 0x08,
    0x84, 0x84, 0x00, 0x00,
    0x00, 0x01, 0x01, 0x02,
    0x03, 0x01,

    /* Configuration 1 descriptor 9 bytes */
    0x09, 0x02, 0x4b, 0x00, 0x02, 0x01, 0x00,0x40, 0x00,

    /* Interface association descriptor. 8 bytes. */
    0x08, 0x0b, 0x00,
    0x02, 0x02, 0x02, 0x00, 0x00,

    /* Communication Class Interface Descriptor Requirement. 9 bytes. */
    0x09, 0x04, 0x00, 0x00,0x01,0x02, 0x02, 0x01, 0x00,

    /* Header Functional Descriptor 5 bytes */
    0x05, 0x24, 0x00,0x10, 0x01,

    /* ACM Functional Descriptor 4 bytes */
    0x04, 0x24, 0x02,0x0f,

    /* Union Functional Descriptor 5 bytes */
    0x05, 0x24, 0x06, 0x00,

    /* Master interface */
    0x01, /* Slave interface */

    /* Call Management Functional Descriptor 5 bytes */
    0x05, 0x24, 0x01,0x03, 0x01, /* Data interface */

    /* Endpoint 1 descriptor 7 bytes */
    0x07, 0x05, 0x83, 0x03,0x08, 0x00, 0xFF,

    /* Data Class Interface Descriptor Requirement 9 bytes */
    0x09, 0x04, 0x01, 0x00, 0x02,0x0A, 0x00, 0x00, 0x00,

    /* First alternate setting Endpoint 1 descriptor 7 bytes*/
    0x07, 0x05, 0x02,0x02,0x40, 0x00,0x00,

    /* Endpoint 2 descriptor 7 bytes */
    0x07, 0x05, 0x81,0x02,0x40, 0x00, 0x00,

};

The CDC-ACM class uses a composite device framework to group interfaces (control and data). As a result care should be taken when defining the device descriptor. USBX relies on the interface association descriptor (IAD) to know internally how to bind interfaces. The IAD descriptor should be declared before the interfaces and contain the first interface of the CDC-ACM class and how many interfaces are attached.

The CDC-ACM class also uses a union functional descriptor which performs the same function as the newer IAD descriptor. Although a Union Functional descriptor must be declared for historical reasons and compatibility with the host side, it is not used by USBX.

The initialization of the CDC-ACM class expects the following parameters.

UX_SLAVE_CLASS_CDC_ACM_PARAMETER cdc_acm_parameter;

/* Set the parameters for callback when insertion/extraction of a CDC device. */
cdc_acm_parameter.ux_slave_class_cdc_acm_instance_activate = demo_cdc_instance_activate;
cdc_acm_parameter.ux_slave_class_cdc_acm_instance_deactivate = demo_cdc_instance_deactivate;
cdc_acm_parameter.ux_slave_class_cdc_acm_parameter_change = demo_cdc_instance_parameter_change;

/* Initialize the device cdc class. This class owns both interfaces starting with 0. */
status = ux_device_stack_class_register(_ux_system_slave_class_cdc_acm_name, ux_device_class_cdc_acm_entry, 1, 0, (VOID *)&cdc_acm_parameter);

if (status != UX_SUCCESS)
    return;

The 2 parameters defined are callback pointers into the user applications that will be called when the stack activates or deactivate this class.

The third parameter defined is a callback pointer to the user application that will be called when there is line coding or line states parameter change. E.g., when there is request from host to change DTR state to TRUE, the callback is invoked, in it user application can check line states through IOCTL function to kow host is ready for communication.

The CDC-ACM is based on a USB-IF standard and is automatically recognized by MACOs and Linux operating systems. On Windows platforms, this class requires a .inf file for Windows version prior to 10. Windows 10 does not require any .inf files. We supply a template for the CDC-ACM class and it can be found in the usbx_windows_host_files directory. For more recent version of Windows the file CDC_ACM_Template_Win7_64bit.inf should be used (except Win10). This file needs to be modified to reflect the PID/VID used by the device. The PID/VID will be specific to the final customer when the company and the product are registered with the USB-IF. In the inf file, the fields to modify are located here.

[DeviceList]
%DESCRIPTION%=DriverInstall, USB\VID_8484&PID_0000

[DeviceList.NTamd64]
%DESCRIPTION%=DriverInstall, USB\VID_8484&PID_0000

In the device framework of the CDC-ACM device, the PID/VID are stored in the device descriptor (see the device descriptor declared above).

When a USB host systems discovers the USB CDC-ACM device, it will mount a serial class and the device can be used with any serial terminal program. See the host Operating System for reference.

cdc_acm_class_configuration_options

There are several configuration options for building USB Device CDC-ACM Class. All options are located in the ux_user.h.

Configuration Option	Description
UX_DEVICE_CLASS_CDC_ACM_TRANSMISSION_DISABLE	This macro disables CDC ACM non-blocking transmission support.
UX_DEVICE_CLASS_CDC_ACM_WRITE_AUTO_ZLP	class _write is pending ZLP automatically (complete transfer) after buffer is sent.
UX_DEVICE_CLASS_CDC_ACM_ZERO_COPY	This macro enables device CDC ACM zero copy for bulk in/out endpoints (write/read). Enabled, the endpoint buffer is not allocated in class, application must provide the buffer for read/write, and the buffer must meet device controller driver (DCD) buffer requirements (e.g., aligned and cache safe). It only works if UX_DEVICE_ENDPOINT_BUFFER_OWNER is 1 (endpoint buffer managed by class).

cdc_acm_class_apis

The CDC-ACM class API functions are defined below.

ux_device_class_cdc_acm_ioctl
ux_device_class_cdc_acm_read
ux_device_class_cdc_acm_read_run
ux_device_class_cdc_acm_write
ux_device_class_cdc_acm_write_run
ux_device_class_cdc_acm_write_with_callback

ux_device_class_cdc_acm_ioctl

Perform IOCTL on the CDC-ACM interface

Function	Value
UX_SLAVE_CLASS_CDC_ACM_IOCTL_SET_LINE_CODING	1
UX_SLAVE_CLASS_CDC_ACM_IOCTL_GET_LINE_CODING	2
UX_SLAVE_CLASS_CDC_ACM_IOCTL_GET_LINE_STATE	3
UX_SLAVE_CLASS_CDC_ACM_IOCTL_ABORT_PIPE	4
UX_SLAVE_CLASS_CDC_ACM_IOCTL_SET_LINE_STATE	5
UX_SLAVE_CLASS_CDC_ACM_IOCTL_TRANSMISSION_START	6
UX_SLAVE_CLASS_CDC_ACM_IOCTL_TRANSMISSION_STOP	7
UX_SLAVE_CLASS_CDC_ACM_IOCTL_SET_READ_TIMEOUT	8
UX_SLAVE_CLASS_CDC_ACM_IOCTL_SET_WRITE_TIMEOUT	9

Configuration Option	Description
UX_DEVICE_CLASS_CDC_ECM_NX_PKPOOL_ENTRIES	This value represents the number of packets in the CDC_ECM device class. The default is 16.
UX_DEVICE_CLASS_CDC_ECM_PACKET_POOL_WAIT	This value represents the number of milliseconds to wait for packet allocation until invoking the application's error callback and retrying.
UX_DEVICE_CLASS_CDC_ECM_ZERO_COPY	This marco enables device CDC_ECM zero copy support (works if CDC_ECM owns endpoint buffer). Enabled, it requires that the NX IP default packet pool is in cache safe area, and buffer max size is larger than UX_DEVICE_CLASS_CDC_ECM_ETHERNET_PACKET_SIZE (1536).

Command name	Value	Description
UX_DEVICE_CLASS_HID_COMMAND_GET_REPORT	0x01	Get a report from the device, callback is invoked to let application fill event
UX_DEVICE_CLASS_HID_COMMAND_GET_IDLE	0x02	Get the idle frequency of the interrupt endpoint
UX_DEVICE_CLASS_HID_COMMAND_GET_PROTOCOL	0x03	Get the protocol running on the device
UX_DEVICE_CLASS_HID_COMMAND_SET_REPORT	0x09	Set a report to the device, callback is invoked to notify application
UX_DEVICE_CLASS_HID_COMMAND_SET_IDLE	0x0a	Set the idle frequency of the interrupt endpoint
UX_DEVICE_CLASS_HID_COMMAND_SET_PROTOCOL	0x0b	Get the protocol running on the device

Configuration Option	Description
UX_DEVICE_CLASS_HID_EVENT_BUFFER_LENGTH	This value represents the the maximum length of HID reports on the device.
UX_DEVICE_CLASS_HID_MAX_EVENTS_QUEUE	This value represents the the maximum number of HID events/reports that can be queued at once.
UX_DEVICE_CLASS_HID_INTERRUPT_OUT_SUPPORT	This macro enables device HID interrupt OUT transfer is supported.
UX_DEVICE_CLASS_HID_ZERO_COPY	This macro enables device HID zero copy and flexible queue support (works if HID owns endpoint buffer). Enabled, the internal queue buffer is directly used for transfer, the APIs are kept to keep backword compatibility, to AVOID KEEPING BUFFERS IN APPLICATION. Flexible queue introduces initialization parameter _event_max_number and _event_max_length, so each HID function could have different queue settings. _event_max_number could be 2 ~ UX_DEVICE_CLASS_HID_MAX_EVENTS_QUEUE. Max of _event_max_length could be UX_DEVICE_CLASS_HID_EVENT_BUFFER_LENGTH. If the initialization parameters are invalid (are 0s or exceed upper mentioned definition), UX_DEVICE_CLASS_HID_MAX_EVENTS_QUEUE and UX_DEVICE_CLASS_HID_EVENT_BUFFER_LENGTH are used to calculate and allocate the queue.