| Table of Contents |
|---|
| maxLevel | 3 |
|---|
| minLevel | 2 |
|---|
| indent | 20px |
|---|
|
...
The use of these constants defined usually in app_cfg.h or app_usbd_cfg.h allows you to use the vendor demo application.
| Anchor |
|---|
| Table - Device Application Constants Configuration |
|---|
| Table - Device Application Constants Configuration |
|---|
|
| Panel |
|---|
| borderWidth | 0 |
|---|
| title | Table - Device Application Constants Configuration |
|---|
|
| Constant | Description | File |
|---|
APP_CFG_USBD_VENDOR_EN | General constant to enable the Vendor class demo application. Must be set to DEF_ENABLED. | app_usbd_cfg.h | APP_CFG_USBD_VENDOR_ECHO_SYNC_EN | Enables or disables the Echo Sync demo. The possible values are DEF_ENABLED or DEF_DISABLED. | app_usbd_cfg.h | APP_CFG_USBD_VENDOR_ECHO_ASYNC_EN | Enables or disables the Echo Async demo. The possible values are DEF_ENABLED or DEF_DISABLED. | app_usbd_cfg.h | APP_CFG_USBD_VENDOR_ECHO_SYNC_TASK_PRIO | Priority of the task used by the Echo Sync demo. | app_cfg.h | APP_CFG_USBD_VENDOR_ECHO_ASYNC_TASK_PRIO | Priority of the task used by the Echo Async demo. | app_cfg.h | APP_CFG_USBD_VENDOR_TASK_STK_SIZE | Stack size of the tasks used by Echo Sync and Async demos. A default value can be 256. | app_cfg.h |
|
APP_CFG_USBD_VENDOR_ECHO_SYNC_EN and APP_CFG_USBD_VENDOR_ECHO_ASYNC_EN can be set to DEF_ENABLED at the same time. The vendor device created will be a composite device formed with two vendor interfaces. One will represent the Echo Sync demo and the other the Echo Async demo.
...
app_vendor_echo.c contains some constants to customize the demo.
| Anchor |
|---|
| Table - Windows Application Constants Configuration |
|---|
| Table - Windows Application Constants Configuration |
|---|
|
| Panel |
|---|
| borderWidth | 0 |
|---|
| title | Table - Windows Application Constants Configuration |
|---|
|
| Constant | Description |
|---|
APP_CFG_RX_ASYNC_EN | Enables or disables the use of the asynchronous API for IN pipe. The possible values are TRUE or FALSE. | APP_MAX_NBR_VENDOR_DEV | Defines the maximum number of connected vendor devices supported by the demo. |
|
The constants configuration for the Windows application are independent from the device application constants configuration presented in Table - Windows Application Constants Configuration.
Editing an INF File
An INF file contains directives telling to Windows how to install one or several drivers for one or more devices. Refer to the About INF Files section for more details about INF file use and format. The Vendor class includes two INF files located in \Micrium\Software\uC-USB-Device-V4\App\Host\OS\Windows\Vendor\INF:
...
In the case of a composite device formed of several vendor interfaces, in order to load WinUSB.sys for each vendor interface, the manufacturer section in WinUSB_composite.inf can be modified as shown in Listing - INF File Example for Composite Device Formed of Several Vendor Interfaces. Let’s assume a device with two vendor interfaces.
| Anchor |
|---|
| Listing - INF File Example for Composite Device Formed of Several Vendor Interfaces |
|---|
| Listing - INF File Example for Composite Device Formed of Several Vendor Interfaces |
|---|
|
| Code Block |
|---|
| language | cpp |
|---|
| title | Listing - INF File Example for Composite Device Formed of Several Vendor Interfaces |
|---|
| linenumbers | true |
|---|
|
[MyDevice_WinUSB.NTx86]
%USB\MyDevice.DeviceDesc% =USB_Install, USB\VID_FFFE&PID_1001&MI_00
%USB\MyDevice.DeviceDesc% =USB_Install, USB\VID_FFFE&PID_1001&MI_01
[MyDevice_WinUSB.NTamd64]
%USB\MyDevice.DeviceDesc% =USB_Install, USB\VID_FFFE&PID_1001&MI_00
%USB\MyDevice.DeviceDesc% =USB_Install, USB\VID_FFFE&PID_1001&MI_01
[MyDevice_WinUSB.NTia64]
%USB\MyDevice.DeviceDesc% =USB_Install, USB\VID_FFFE&PID_1001&MI_00
%USB\MyDevice.DeviceDesc% =USB_Install, USB\VID_FFFE&PID_1001&MI_01 |
You can also modify the [Strings] section of the INF file in order to add the strings that best describe your device. shows Listing - Editable Strings in the INF File to Describe the Vendor Device shows the editable [Strings] section common to WinUSB_single.inf and WinUSB_composite.inf.
| Anchor |
|---|
| Listing - Editable Strings in the INF File to Describe the Vendor Device |
|---|
| Listing - Editable Strings in the INF File to Describe the Vendor Device |
|---|
|
| Code Block |
|---|
| language | cpp |
|---|
| title | Listing - Editable Strings in the INF File to Describe the Vendor Device |
|---|
| linenumbers | true |
|---|
|
[Strings]
ProviderName ="Micrium" (1)
USB\MyDevice.DeviceDesc ="Micrium Vendor Specific Device" (2)
ClassName ="USB Sample Class" (3) |
| Panel |
|---|
|
(1) Specify the name of your company as the driver provider. (2) Write the name of your device. (3) You can modify this string to give a new name to the device group in which your device will appear under Device Manager. In this example, “Micrium Vendor Specific Device” will appear under the “USB Sample Class” group. Refer to Figure - Windows Device Manager Example for a CDC Device for an illustration of the strings used by Windows. |
Running the Vendor Class Demo Application
illustrates Figure - Echo Demo illustrates the Echo demo with host and device interactions:
| Anchor |
|---|
| Figure - Echo Demo |
|---|
| Figure - Echo Demo |
|---|
|
| Panel |
|---|
| borderWidth | 0 |
|---|
| title | Figure - Echo Demo |
|---|
|
 Image Added
|
| Panel |
|---|
|
(1) The Windows application executes a simple protocol consisting of sending a header indicating the total payload size, sending the data payload to the device and receiving the same data payload from the device. The entire transfer for data payload is split into small chunks of write and read operations of 512 bytes. The write operation is done using a bulk OUT endpoint and the read uses a bulk IN endpoint. (2) On the device side, the Echo Sync uses a task that complements the Windows application execution. Each step is done synchronously. The read and write operation is the opposite of the host side in terms of USB transfer direction. Read operation implies a bulk OUT endpoint while a write implies a bulk IN endpoint. (3) If the Echo Async is enabled, the same steps done by the Sync task are replicated but using the asynchronous API. A task is responsible to start the first asynchronous OUT transfer to receive the header. The task is also used in case of error during the protocol communication. The callback associated to the header reception is called by the device stack. It prepares the next asynchronous OUT transfer to receive the payload. The read payload callback sends back the payload to the host via an asynchronous IN transfer. The write payload callback is called and either prepares the next header reception if the entire payload has been sent to the host, or prepares a next OUT transfer to receive a new chunk of data payload. |
Upon the first connection of the vendor device, Windows enumerates the device by retrieving the standard descriptors. Since Microsoft does not provide any specific driver for the Vendor class, you have to indicate to Windows which driver to load using an INF file (refer to the About INF Files section for more details about INF). The INF file tells Windows to load the WinUSB generic driver (provided by Microsoft). Indicating the INF file to Windows has to be done only once. Windows will then automatically recognize the vendor device and load the proper driver for any new connection. The process of indicating the INF file may vary according to the Windows operating system version:
...
The Echo Sync or Async demo will first determine the number of vendor devices connected to the PC. For each detected device, the demo will open a bulk IN and a bulk OUT pipe. Then the demo is ready to send/receive data to/from the device. You will have to enter the maximum number of transfers you want as shown by Figure - Demo Application at Startup.
| Anchor |
|---|
| Figure - Demo Application at Startup |
|---|
| Figure - Demo Application at Startup |
|---|
|
| Panel |
|---|
| borderWidth | 0 |
|---|
| title | Figure - Demo Application at Startup |
|---|
|
 Image Added
|
In the example of Figure - Demo Application at Startup, the demo will handle 10 transfers. Each transfer is sent after the header following the simple protocol described in Figure - Echo Demo. The first transfer will have a data payload of 1 byte. Then, subsequent transfers will have their size incremented by 1 byte until the last transfer. In our example, the last transfer will have 10 bytes. Figure - Demo Application Execution (Single Device) presents the execution.
| Anchor |
|---|
| Figure - Demo Application Execution (Single Device) |
|---|
| Figure - Demo Application Execution (Single Device) |
|---|
|
| Panel |
|---|
| borderWidth | 0 |
|---|
| title | Figure - Demo Application Execution (Single Device) |
|---|
|
 Image Added
|
The demo will propose to do a new execution. shows Figure - Demo Application Execution (Single Device) shows the example of a single device with 1 vendor interface. The demo is able to communicate with each vendor interface in the case of a composite device. In that case, the demo will open bulk IN and OUT pipes for each interface. You will be asked the maximum number of transfers for each interface composing the device. Figure - Demo Application Execution (Composite Device) shows an example of a composite device.
| Anchor |
|---|
| Figure - Demo Application Execution (Composite Device) |
|---|
| Figure - Demo Application Execution (Composite Device) |
|---|
|
| Panel |
|---|
| borderWidth | 0 |
|---|
| title | Figure - Demo Application Execution (Composite Device) |
|---|
|
 Image Added
|
GUID
A Globally Unique IDentifier (GUID) is a 128-bit value that uniquely identifies a class or other entity. Windows uses GUIDs for identifying two types of devices classes:
...