OverView ¶
USBX is the USB middleware component of the Eclipse ThreadX RTOS family. It provides a comprehensive, high-performance, and portable USB host/device stack specifically optimized for resource-constrained embedded systems.
USBX supports a wide range of standard USB device and host classes (for example: MSC, CDC, HID, Audio, Video, Printer, and others), multiple endpoints, and all USB transfer types (control, bulk, interrupt, isochronous). The stack is written in ANSI C and is designed for straightforward porting across different 32-bit microcontroller architectures.
USBX on STM32 Microcontrollers
On STM32 microcontrollers, USBX offers:
Seamless integration with the STM32Cube ecosystem
Support for all STM32 USB peripherals:
DRD Full-Speed (FS)
OTG Full-Speed (FS)
OTG High-Speed (HS)
Flexible operation with or without an RTOS:
Integrated with RTOS for fully multithreaded applications.
Usable in standalone bare-metal configurations (no RTOS).
Layered Architecture
The USBX architecture on STM32 is cleanly layered to improve clarity, reuse, and maintainability:
Application Layer User application code, high-level class behavior, data handling, and protocol logic specific to the end product.
USBX Core and Class Drivers USB protocol engine and standard class implementations (CDC, MSC, HID, etc.). This layer is independent from any specific STM32 device.
Low-Level Driver Layer STM32 USB drivers and board-support code that interface the USBX core with the underlying USB hardware peripheral.
This layered design simplifies USB application development, promotes portability across STM32 device families, and enables efficient reuse of existing USB solutions in new products.
Overall architecture ¶
The high-level USBX architecture on STM32 can be summarized as:
Application code using USB class APIs (MSC, CDC, HID, etc.).
USBX core and class drivers managing enumeration, endpoints, and data transfers.
USBX overall block diagram ¶
The reworked USBX middleware architecture preserves the same high-level software layering as the original implementation:
Controller Layer Interfaces directly with the hardware USB peripheral (device/host controllers, PHY, low-level drivers).
Core Processing Layer Manages core USB protocol operations such as enumeration, endpoint handling, transfers, and protocol state machines.
Class and Application Interface Layer Implements USB device and host classes (CDC, MSC, HID, etc.) and exposes interfaces used by the application layer.
Utility Layer for OS Portability Provides OS abstraction and common utilities to ensure portability of the USBX stack across different runtime environments (RTOS or bare metal).
USBX middleware folder structure ¶
USBX folder structure ¶
USBX root
Contains all USBX middleware files and subfolders.
Common ¶
core - USB protocol core, state machines, utilities, macros, error codes.
usbx_device_class - device class implementations.
usbx_host_class - host class implementations.
usbx_host_controllers - generic EHCI/OHCI HCD drivers (not used on STM32 MCU).
usbx_pictbridge - PictBridge standard driver.
Ports ¶
Platform-specific adaptation layer (FreeRTOS, other RTOSes, bare-metal).
Interfaces (STM32) ¶
usbx_stm32_device_controllers - interface with STM32Cube USB PCD HAL.
usbx_stm32_host_controllers - interface with STM32Cube USB HCD HAL.
usbx_stm32_device_descriptors - runtime USB device descriptor builder.
Templates ¶
Example USBX applications for different classes and modes.
Docs ¶
Additional USBX documentation, revision history, features and dependencies.
USBX middleware architecture ¶
Originally, the utility layer supported
only ThreadX RTOS
, and its
OS-specific utility files were located under the
common/core
folder.
Eclipse ThreadX USBX middleware utility ¶
The main rework consists of making this utility layer RTOS-agnostic , ensuring portability of USBX across different operating systems, especially FreeRTOS .
The new OS-agnostic utility layer:
Provides the essential services and abstractions required by USBX (threads, synchronization, memory, timing, etc.).
Allows integration with various RTOS environments.
Preserves compatibility with bare metal (no RTOS) configurations.
The RTOS-agnostic utility files are now organized under a
ports
directory, with a dedicated subfolder for each supported
operating system or execution environment. For example:
ports/FreeRTOS- utilities and OS abstraction for FreeRTOS.ports/generic- generic / bare-metal configuration (no RTOS).