Your application layer needs to provide configuration information to µC/USB-Device in the form of several C files: app_cfg.h, app_usbd_cfg.h, usbd_cfg.h, usbd_dev_cfg.c, usbd_dev_cfg.h and optionnaly usbd_audio_dev_cfg.c and usbd_audio_dev_cfg.h:
app_cfg.h is an application-specific configuration file. It contains #defines to specify task priorities and the stack size of each of the task within the application and the task(s) required by µC/USB-Device.app_usbd_cfg.h is a configuration file for the sample µC/USB-Device applications. It contains #defines to enable or disable each sample application and set various parameters for the different applications. For example, set the waveform used in the audio application, enable the mouse application for the HID class or set the type of Vendor sample application.usbd_cfg.h consists of specifying the number of devices supported in the stack, the maximum number of configurations, the maximum number of interfaces and alternate interfaces, maximum number of opened endpoints per device, class-specific configuration parameters and more. In all, there are approximately 20 #defines to set.usbd_dev_cfg.c/.h consists of device-specific configuration requirements such as vendor ID, product ID, device release number and its respective strings. It also contains device controller specific configurations such as base address, dedicated memory base address and size, and endpoint management table.usbd_audio_dev_cfg.c/.h, are audio-specific configuration files and are only needed if the audio class is used. These files defines the audio device topography, allowing the user to build the exact type of audio device needed. Refer to the Audio Topology Configuration page for more details.Refer to the Configuration page for more information on how to configure µC/USB-Device.
Given that µC/USB-Device is designed to be used in safety critical applications, some of the “standard” library functions such as strcpy(), memset(), etc. have been rewritten to conform to the same quality standards as the rest of the USB device stack. All these standard functions are part of a separate Micrium product called µC/LIB. µC/USB-Device depends on this product. In addition, some data objects in USB controller drivers are created at run-time which implies the use of memory allocation from the heap function Mem_HeapAlloc().
Your application will interface with µC/USB-Device using the class layer API. In this layer, four classes defined by the USB-IF are implemented. In case you need to implement a vendor-specific class, a fifth class, the “vendor” class, is available. This class provides functions for simple communication via endpoints. The classes that µC/USB-Device currently supports are the following:
You can also create other classes defined by the USB-IF. Refer to the USB Classes page for more information on how a USB class interacts with the core layer.
USB core layer is responsible for creating and maintaining the logical structure of a USB device. The core layer manages the USB configurations, interfaces, alternate interfaces and allocation of endpoints based on the application or USB classes requirements and the USB controller endpoints available. Standard requests, bus events (reset, suspend, connect and disconnect) and enumeration process are also handled by the Core layer.
The endpoint management layer is responsible for sending and receiving data using endpoints. Control, interrupt, bulk and isochronous transfers are implemented in this layer. This layer provides synchronous API for control, bulk and interrupt I/O operations and asynchronous API for bulk, interrupt and isochronous I/O operations.
µC/USB-Device assumes the presence of an RTOS, and an RTOS abstraction layer allows µC/USB-Device to be independent of a specific RTOS. The RTOS abstraction layer is composed of several RTOS ports, a core layer port and some class layer ports.
At the very least, the RTOS for the core layer:
µC/USB-Device is provided with ports for µC/OS-II and µC/OS-III. If a different RTOS is used, you can use the files for µC/OS-II or µC/OS-III as a template to interface to the RTOS of your choice. For more information on how to port µC/USB-Device to an RTOS, see the Porting uC-USB-Device to your RTOS page.
Some USB classes require an RTOS port (i.e. Audio, HID, MSC and PHDC). Refer to for a list of sections containing more information on the RTOS port of each of these classes.
µC/USB-Device works with nearly any USB device controller. This layer handles the specifics of the hardware, e.g., how to initialize the device, how to open and configure endpoints, how to start reception and transmission of USB packets, how to read and write USB packets and how to report USB events to the core, among others. The USB device driver controller functions are encapsulated and implemented in the usbd_drv_<controller>.c file.
In order to have independent configuration for clock gating, interrupt controller and general purpose I/O, a USB device controller driver needs an additional file. This file is called a Board Support Package (BSP). The name of this file is usbd_bsp_<controller>.c. This file contains all the details that are closely related to the hardware on which the product is used. This file also defines the endpoints information table. This table is used by the core layer to allocate endpoints according to the hardware capabilities.
µC/USB-Device can work with either an 8, 16, 32 or even 64-bit CPU, but it must have information about the CPU used. The CPU layer defines such information as the C data type corresponding to 16-bit and 32-bit variables, whether the CPU has little or big endian memory organization, and how interrupts are disabled and enabled on the CPU.
CPU-specific files are found in the \uC-CPU directory and are used to adapt µC/USB-Device to a different CPU.