diff options
Diffstat (limited to 'docs/reference')
| -rw-r--r-- | docs/reference/architecture.rst | 282 | ||||
| -rw-r--r-- | docs/reference/boards.rst | 42 | ||||
| -rw-r--r-- | docs/reference/concurrency.rst | 10 | ||||
| -rw-r--r-- | docs/reference/dependencies.rst | 16 | ||||
| -rw-r--r-- | docs/reference/getting_started.rst | 269 | ||||
| -rw-r--r-- | docs/reference/glossary.rst | 98 | ||||
| -rw-r--r-- | docs/reference/index.rst | 11 | ||||
| -rw-r--r-- | docs/reference/usb_concepts.rst | 428 |
8 files changed, 852 insertions, 304 deletions
diff --git a/docs/reference/architecture.rst b/docs/reference/architecture.rst new file mode 100644 index 000000000..70ea17ed4 --- /dev/null +++ b/docs/reference/architecture.rst @@ -0,0 +1,282 @@ +************ +Architecture +************ + +This document explains TinyUSB's internal architecture, design principles, and how different components work together. + +Design Principles +================= + +Memory Safety +------------- + +TinyUSB is designed for resource-constrained embedded systems with strict memory requirements: + +TinyUSB uses **no dynamic allocation** - all memory is statically allocated at compile time for predictability. All buffers have bounded, compile-time defined sizes to prevent overflow issues. The TinyUSB core avoids heap allocation, resulting in **predictable memory usage** where consumption is fully deterministic. + +Thread Safety +------------- + +TinyUSB achieves thread safety through a deferred interrupt model: + +- **ISR deferral**: USB interrupts are captured and deferred to task context +- **Single-threaded processing**: All USB protocol handling occurs in task context +- **Queue-based design**: Events are queued from ISR and processed in ``tud_task()`` +- **RTOS integration**: Proper semaphore/mutex usage for shared resources + +Portability +----------- + +The stack is designed to work across diverse microcontroller families: + +- **Hardware abstraction**: MCU-specific code isolated in portable drivers +- **OS abstraction**: RTOS dependencies isolated in OSAL layer +- **Modular design**: Features can be enabled/disabled at compile time +- **Standard compliance**: Strict adherence to USB specifications + +Core Architecture +================= + +Layer Structure +--------------- + +TinyUSB follows a layered architecture from hardware to application: + +.. figure:: ../assets/stack.svg + :width: 500px + :align: left + :alt: stackup + +.. raw:: html + + <div class="clear-both"></div> + +Component Overview +------------------ + +- **Application Layer**: Your main application code that uses TinyUSB APIs. +- **Class Drivers**: Implement specific USB device classes (CDC, HID, MSC, etc.) and handle class-specific requests. +- **Device/Host Core**: Implements USB protocol state machines, endpoint management, and core USB functionality. +- **OS Abstraction**: Provides threading primitives and synchronization for different RTOS environments. +- **Device/Host Controller Driver**: drivers that interface with MCU USB peripherals. Several MCUs may share a common driver. + +Device Stack Architecture +========================= + +This section is concerned with the **Device Stack**, i.e., the component of TinyUSB used in USB devices (that talk to a USB host). + +Core Components +--------------- + +**Device Controller Driver (DCD)**: +- MCU-specific USB device peripheral driver +- Handles endpoint configuration and data transfers +- Abstracts hardware differences between MCU families +- Located in ``src/portable/VENDOR/USBIP/`` + +**USB Device Core (USBD)**: +- Implements USB device state machine +- Handles standard USB requests (Chapter 9) +- Manages device configuration and enumeration +- Located in ``src/device/`` + +**Class Drivers**: +- Implement USB class specifications +- Handle class-specific requests and data transfer +- Provide application APIs +- Located in ``src/class/*/`` + +Data Flow +--------- + +**Control Transfers (Setup Requests)**: + +.. code-block:: none + + USB Bus → DCD → USBD Core → Class Driver → Application + ↓ + Standard requests handled in core + ↓ + Class-specific requests → Class Driver + +**Data Transfers**: + +.. code-block:: none + + Application → Class Driver → USBD Core → DCD → USB Bus + USB Bus → DCD → USBD Core → Class Driver → Application + +Event Processing +---------------- + +TinyUSB uses a deferred interrupt model for thread safety: + +1. **Interrupt Occurs**: USB hardware generates interrupt +2. **ISR Handler**: ``dcd_int_handler()`` captures event, minimal processing +3. **Event Queuing**: Events queued for later processing +4. **Task Processing**: ``tud_task()`` (called by application code) processes queued events +5. **Callback Execution**: Application callbacks executed in task context + +.. code-block:: none + + USB IRQ → ISR → Event Queue → tud_task() → Class Callbacks → Application + +Host Stack Architecture +======================= + +This section is concerned with the **Host Stack**, i.e., the component of TinyUSB used in USB hosts, managing connected USB devices. + +Core Components +--------------- + +**Host Controller Driver (HCD)**: +- MCU-specific USB host peripheral driver +- Manages USB pipes and data transfers +- Handles host controller hardware +- Located in ``src/portable/VENDOR/FAMILY/`` + +**USB Host Core (USBH)**: +- Implements USB host functionality +- Manages device enumeration and configuration +- Handles pipe management and scheduling +- Located in ``src/host/`` + +**Hub Driver**: +- Manages USB hub devices +- Handles port management and device detection +- Supports multi-level hub topologies +- Located in ``src/host/`` + +Device Enumeration +------------------ + +The host stack follows USB enumeration process: + +1. **Device Detection**: Hub or root hub detects device connection +2. **Reset and Address**: Reset device, assign unique address +3. **Descriptor Retrieval**: Get device, configuration, and class descriptors +4. **Driver Matching**: Find appropriate class driver for device +5. **Configuration**: Configure device and start communication +6. **Class Operation**: Normal class-specific communication + +.. code-block:: none + + Device Connect → Reset → Get Descriptors → Load Driver → Configure → Operate + +Class Architecture +================== + +Common Class Structure +---------------------- + +All USB classes follow a similar architecture: + +**Device Classes**: +- ``*_device.c``: Device-side implementation +- ``*_device.h``: Device API definitions +- Implement class-specific descriptors +- Handle class requests and data transfer + +**Host Classes**: +- ``*_host.c``: Host-side implementation +- ``*_host.h``: Host API definitions +- Manage connected devices of this class +- Provide application interface + +Class Driver Interface +---------------------- + +See ``usbd.c``. + +**Required Functions**: +- ``init()``: Initialize class driver +- ``reset()``: Reset class state +- ``open()``: Configure class endpoints +- ``control_xfer_cb()``: Handle control requests +- ``xfer_cb()``: Handle data transfer completion + +**Optional Functions**: +- ``close()``: Clean up class resources +- ``deinit()``: Deinitialize class driver +- ``sof()``: Start-of-frame processing +- ``xfer_isr()``: Called from USB ISR context on transfer completion. Data will get queued for ``xfer_cb()`` only if this returns ``false``. + +Descriptor Management +--------------------- + +Each class is responsible for: +- **Interface Descriptors**: Define class type and endpoints +- **Class-Specific Descriptors**: Additional class requirements +- **Endpoint Descriptors**: Define data transfer characteristics + +Memory Management +================= + +Static Allocation Model +----------------------- + +TinyUSB uses only static memory allocation; it allocates fixed-size endpoint buffers for each configured endpoint, static buffers for class-specific data handling, a fixed buffer dedicated to control transfers, and static event queues for deferred interrupt processing. + +Buffer Management +----------------- + +**Endpoint Buffers**: +- Allocated per endpoint at compile time +- Size defined by ``CFG_TUD_*_EP_BUFSIZE`` macros +- Used for USB data transfers + +**FIFO Buffers**: +- Ring buffers for streaming data +- Size defined by ``CFG_TUD_*_RX/TX_BUFSIZE`` macros +- Separate read/write pointers + +Threading Model +=============== + +Task-Based Design +----------------- + +TinyUSB uses a cooperative task model; it provides main tasks - ``tud_task()`` for device and ``tuh_task()`` for host operation. These tasks must be called regularly (typically less than 1ms intervals) to ensure all USB events are processed in task context, where application callbacks also execute. + +RTOS Integration +---------------- + +**Bare Metal**: +- Application calls ``tud_task()`` in main loop +- No threading primitives needed +- Simplest integration method + +**FreeRTOS**: +- USB task runs at high priority +- Semaphores used for synchronization +- Queue for inter-task communication + +**Other RTOS**: +- Similar patterns with RTOS-specific primitives +- OSAL layer abstracts RTOS differences + +Interrupt Handling +------------------ + +**Interrupt Service Routine**: +- Minimal processing in ISR +- Event capture and queuing only +- Quick return to avoid blocking + +**Deferred Processing**: +- All complex processing in task context +- Thread-safe access to data structures +- Application callbacks in known context + +Memory Usage Patterns +--------------------- + +**Flash Memory**: +- Core stack: 8-15KB depending on features +- Each class: 1-4KB additional +- Portable driver: 2-8KB depending on MCU + +**RAM Usage**: +- Core stack: 1-2KB +- Endpoint buffers: User configurable +- Class buffers: Depends on configuration diff --git a/docs/reference/boards.rst b/docs/reference/boards.rst index 3f8277247..12da5c90b 100644 --- a/docs/reference/boards.rst +++ b/docs/reference/boards.rst @@ -107,17 +107,20 @@ olimex_emz64 Olimex PIC32-EMZ64 pic32mz http olimex_hmz144 Olimex PIC32-HMZ144 pic32mz https://www.olimex.com/Products/PIC/Development/PIC32-HMZ144/open-source-hardware cynthion_d11 Great Scott Gadgets Cynthion samd11 https://greatscottgadgets.com/cynthion/ samd11_xplained SAMD11 Xplained Pro samd11 https://www.microchip.com/en-us/development-tool/ATSAMD11-XPRO -atsamd21_xpro SAMD21 Xplained Pro samd21 https://www.microchip.com/DevelopmentTools/ProductDetails/ATSAMD21-XPRO -circuitplayground_express Adafruit Circuit Playground Express samd21 https://www.adafruit.com/product/3333 -curiosity_nano SAMD21 Curiosty Nano samd21 https://www.microchip.com/en-us/development-tool/dm320119 -cynthion_d21 Great Scott Gadgets Cynthion samd21 https://greatscottgadgets.com/cynthion/ -feather_m0_express Adafruit Feather M0 Express samd21 https://www.adafruit.com/product/3403 -itsybitsy_m0 Adafruit ItsyBitsy M0 samd21 https://www.adafruit.com/product/3727 -metro_m0_express Adafruit Metro M0 Express samd21 https://www.adafruit.com/product/3505 -qtpy Adafruit QT Py samd21 https://www.adafruit.com/product/4600 -seeeduino_xiao Seeeduino XIAO samd21 https://wiki.seeedstudio.com/Seeeduino-XIAO/ -sparkfun_samd21_mini_usb SparkFun SAMD21 Mini samd21 https://www.sparkfun.com/products/13664 -trinket_m0 Adafruit Trinket M0 samd21 https://www.adafruit.com/product/3500 +atsamd21_xpro SAMD21 Xplained Pro samd2x_l2x https://www.microchip.com/DevelopmentTools/ProductDetails/ATSAMD21-XPRO +atsaml21_xpro SAML21 Xplained Pro samd2x_l2x https://www.microchip.com/en-us/development-tool/atsaml21-xpro-b +circuitplayground_express Adafruit Circuit Playground Express samd2x_l2x https://www.adafruit.com/product/3333 +curiosity_nano SAMD21 Curiosty Nano samd2x_l2x https://www.microchip.com/en-us/development-tool/dm320119 +cynthion_d21 Great Scott Gadgets Cynthion samd2x_l2x https://greatscottgadgets.com/cynthion/ +feather_m0_express Adafruit Feather M0 Express samd2x_l2x https://www.adafruit.com/product/3403 +itsybitsy_m0 Adafruit ItsyBitsy M0 samd2x_l2x https://www.adafruit.com/product/3727 +metro_m0_express Adafruit Metro M0 Express samd2x_l2x https://www.adafruit.com/product/3505 +qtpy Adafruit QT Py samd2x_l2x https://www.adafruit.com/product/4600 +saml22_feather SAML22 Feather samd2x_l2x https://github.com/joeycastillo/Feather-Projects/tree/main/SAML22%20Feather +seeeduino_xiao Seeeduino XIAO samd2x_l2x https://wiki.seeedstudio.com/Seeeduino-XIAO/ +sensorwatch_m0 SensorWatch samd2x_l2x https://github.com/joeycastillo/Sensor-Watch +sparkfun_samd21_mini_usb SparkFun SAMD21 Mini samd2x_l2x https://www.sparkfun.com/products/13664 +trinket_m0 Adafruit Trinket M0 samd2x_l2x https://www.adafruit.com/product/3500 d5035_01 D5035-01 samd5x_e5x https://github.com/RudolphRiedel/USB_CAN-FD feather_m4_express Adafruit Feather M4 Express samd5x_e5x https://www.adafruit.com/product/3857 itsybitsy_m4 Adafruit ItsyBitsy M4 samd5x_e5x https://www.adafruit.com/product/3800 @@ -125,10 +128,9 @@ metro_m4_express Adafruit Metro M4 Express samd5x_e5x http pybadge Adafruit PyBadge samd5x_e5x https://www.adafruit.com/product/4200 pyportal Adafruit PyPortal samd5x_e5x https://www.adafruit.com/product/4116 same54_xplained SAME54 Xplained Pro samd5x_e5x https://www.microchip.com/DevelopmentTools/ProductDetails/ATSAME54-XPRO +same70_qmtech SAME70 QMTech same7x https://www.aliexpress.com/item/1005003173783268.html +same70_xplained SAME70 Xplained same7x https://www.microchip.com/en-us/development-tool/atsame70-xpld samg55_xplained SAMG55 Xplained Pro samg https://www.microchip.com/DevelopmentTools/ProductDetails/ATSAMG55-XPRO -atsaml21_xpro SAML21 Xplained Pro saml2x https://www.microchip.com/en-us/development-tool/atsaml21-xpro-b -saml22_feather SAML22 Feather saml2x https://github.com/joeycastillo/Feather-Projects/tree/main/SAML22%20Feather -sensorwatch_m0 SensorWatch saml2x https://github.com/joeycastillo/Sensor-Watch ========================= =================================== ========== ================================================================================= ====== MindMotion @@ -202,10 +204,11 @@ circuitplayground_bluefruit Adafruit Circuit Playground Bluefruit nrf ht feather_nrf52840_express Adafruit Feather nRF52840 Express nrf https://www.adafruit.com/product/4062 feather_nrf52840_sense Adafruit Feather nRF52840 Sense nrf https://www.adafruit.com/product/4516 itsybitsy_nrf52840 Adafruit ItsyBitsy nRF52840 Express nrf https://www.adafruit.com/product/4481 -pca10056 Nordic nRF52840DK nrf https://www.nordicsemi.com/Software-and-Tools/Development-Kits/nRF52840-DK -pca10059 Nordic nRF52840 Dongle nrf https://www.nordicsemi.com/Software-and-Tools/Development-Kits/nRF52840-Dongle -pca10095 Nordic nRF5340 DK nrf https://www.nordicsemi.com/Software-and-Tools/Development-Kits/nRF5340-DK -pca10100 Nordic nRF52833 DK nrf https://www.nordicsemi.com/Software-and-Tools/Development-Kits/nRF52833-DK +nrf52833dk Nordic nRF52833 DK nrf https://www.nordicsemi.com/Software-and-Tools/Development-Kits/nRF52833-DK +nrf52840dk Nordic nRF52840DK nrf https://www.nordicsemi.com/Software-and-Tools/Development-Kits/nRF52840-DK +nrf52840dongle Nordic nRF52840 Dongle nrf https://www.nordicsemi.com/Software-and-Tools/Development-Kits/nRF52840-Dongle +nrf5340dk Nordic nRF5340 DK nrf https://www.nordicsemi.com/Software-and-Tools/Development-Kits/nRF5340-DK +nrf54h20dk Nordic nRF54H20 DK nrf https://www.nordicsemi.com/Software-and-Tools/Development-Kits/nRF5340-DK =========================== ===================================== ======== ============================================================================== ====== Raspberry Pi @@ -294,12 +297,13 @@ stm32l052dap52 STM32 L052 DAP stm32l0 n/a stm32l0538disco STM32 L0538 Discovery stm32l0 https://www.st.com/en/evaluation-tools/32l0538discovery.html stm32l412nucleo STM32 L412 Nucleo stm32l4 https://www.st.com/en/evaluation-tools/nucleo-l412kb.html stm32l476disco STM32 L476 Disco stm32l4 https://www.st.com/en/evaluation-tools/32l476gdiscovery.html +stm32l496nucleo STM32 L496 Nucleo stm32l4 https://www.st.com/en/evaluation-tools/nucleo-l496ZG-P.html stm32l4p5nucleo STM32 L4P5 Nucleo stm32l4 https://www.st.com/en/evaluation-tools/nucleo-l4p5zg.html stm32l4r5nucleo STM32 L4R5 Nucleo stm32l4 https://www.st.com/en/evaluation-tools/nucleo-l4r5zi.html stm32n6570dk STM32 N6570-DK stm32n6 https://www.st.com/en/evaluation-tools/stm32n6570-dk.html stm32n657nucleo STM32 N657X0-Q Nucleo stm32n6 https://www.st.com/en/evaluation-tools/nucleo-n657x0-q.html +stm32u083cdk STM32U083C-DK Discovery Kit stm32u0 https://www.st.com/en/evaluation-tools/stm32u083c-dk.html b_u585i_iot2a STM32 B-U585i IOT2A Discovery kit stm32u5 https://www.st.com/en/evaluation-tools/b-u585i-iot02a.html -stm32u083cdk STM32 U083C Discovery Kit stm32u0 https://www.st.com/en/evaluation-tools/stm32u083c-dk.html stm32u545nucleo STM32 U545 Nucleo stm32u5 https://www.st.com/en/evaluation-tools/nucleo-u545re-q.html stm32u575eval STM32 U575 Eval stm32u5 https://www.st.com/en/evaluation-tools/stm32u575i-ev.html stm32u575nucleo STM32 U575 Nucleo stm32u5 https://www.st.com/en/evaluation-tools/nucleo-u575zi-q.html diff --git a/docs/reference/concurrency.rst b/docs/reference/concurrency.rst index 776fa4b6d..99e7e7b70 100644 --- a/docs/reference/concurrency.rst +++ b/docs/reference/concurrency.rst @@ -3,17 +3,17 @@ Concurrency *********** The TinyUSB library is designed to operate on single-core MCUs with multi-threaded applications in mind. Interaction with interrupts is especially important to pay attention to. -It is compatible with optionally using a RTOS. +It is compatible with optionally using an RTOS. General ------- -When writing code, keep in mind that the OS (if using a RTOS) may swap out your code at any time. Also, your code can be preempted by an interrupt at any time. +When writing code, keep in mind that the OS (if using an RTOS) may swap out your code at any time. Also, your code can be preempted by an interrupt at any time. Application Code ---------------- -The USB core does not execute application callbacks while in an interrupt context. Calls to application code are from within the USB core task context. Note that the application core will call class drivers from within their own task. +The USB core does not execute application callbacks while in an interrupt context. Calls to application code are from within the USB core task context. Note that the application core will call class drivers from within its own task. Class Drivers ------------- @@ -38,5 +38,5 @@ Much of the processing of the USB stack is done in an interrupt context, and car In particular: -* Ensure that all memory-mapped registers (including packet memory) are marked as volatile. GCC's optimizer will even combine memory access (like two 16-bit to be a 32-bit) if you don't mark the pointers as volatile. On some architectures, this can use macros like _I , _O , or _IO. -* All defined global variables are marked as ``static``. +* Ensure that all memory-mapped registers (including packet memory) are marked as volatile. GCC's optimizer will even combine memory accesses (like two 16-bit to be a 32-bit) if you don't mark the pointers as volatile. On some architectures, this can use macros like _I , _O , or _IO. +* All defined global variables are marked as ``static``. diff --git a/docs/reference/dependencies.rst b/docs/reference/dependencies.rst index 1a088c989..de1603383 100644 --- a/docs/reference/dependencies.rst +++ b/docs/reference/dependencies.rst @@ -2,11 +2,11 @@ Dependencies ************ -MCU low-level peripheral driver and external libraries for building TinyUSB examples +MCU low-level peripheral drivers and external libraries for building TinyUSB examples -======================================== ================================================================ ======================================== ====================================================================================================================================================================================================================================================================================================================================================================== +======================================== ================================================================ ======================================== ============================================================================================================================================================================================================================================================================================================================================================== Local Path Repo Commit Required by -======================================== ================================================================ ======================================== ====================================================================================================================================================================================================================================================================================================================================================================== +======================================== ================================================================ ======================================== ============================================================================================================================================================================================================================================================================================================================================================== hw/mcu/allwinner https://github.com/hathach/allwinner_driver.git 8e5e89e8e132c0fd90e72d5422e5d3d68232b756 fc100s hw/mcu/analog/msdk https://github.com/analogdevicesinc/msdk.git b20b398d3e5e2007594e54a74ba3d2a2e50ddd75 maxim hw/mcu/artery/at32f402_405 https://github.com/ArteryTek/AT32F402_405_Firmware_Library.git 4424515c2663e82438654e0947695295df2abdfe at32f402_405 @@ -22,8 +22,8 @@ hw/mcu/gd/nuclei-sdk https://github.com/Nuclei-Software/nuc hw/mcu/infineon/mtb-xmclib-cat3 https://github.com/Infineon/mtb-xmclib-cat3.git daf5500d03cba23e68c2f241c30af79cd9d63880 xmc4000 hw/mcu/microchip https://github.com/hathach/microchip_driver.git 9e8b37e307d8404033bb881623a113931e1edf27 sam3x samd11 samd21 samd51 samd5x_e5x same5x same7x saml2x samg hw/mcu/mindmotion/mm32sdk https://github.com/hathach/mm32sdk.git b93e856211060ae825216c6a1d6aa347ec758843 mm32 -hw/mcu/nordic/nrfx https://github.com/NordicSemiconductor/nrfx.git 7c47cc0a56ce44658e6da2458e86cd8783ccc4a2 nrf -hw/mcu/nuvoton https://github.com/majbthrd/nuc_driver.git 2204191ec76283371419fbcec207da02e1bc22fa nuc +hw/mcu/nordic/nrfx https://github.com/NordicSemiconductor/nrfx.git 11f57e578c7feea13f21c79ea0efab2630ac68c7 nrf +hw/mcu/nuvoton https://github.com/majbthrd/nuc_driver.git 2204191ec76283371419fbcec207da02e1bc22fa nuc100_120 nuc121_125 nuc126 nuc505 hw/mcu/nxp/lpcopen https://github.com/hathach/nxp_lpcopen.git b41cf930e65c734d8ec6de04f1d57d46787c76ae lpc11 lpc13 lpc15 lpc17 lpc18 lpc40 lpc43 hw/mcu/nxp/mcux-sdk https://github.com/nxp-mcuxpresso/mcux-sdk a1bdae309a14ec95a4f64a96d3315a4f89c397c6 kinetis_k kinetis_k32l2 kinetis_kl lpc51 lpc54 lpc55 mcx imxrt hw/mcu/raspberry_pi/Pico-PIO-USB https://github.com/sekigon-gonnoc/Pico-PIO-USB.git 675543bcc9baa8170f868ab7ba316d418dbcf41f rp2040 @@ -80,10 +80,10 @@ hw/mcu/wch/ch32f20x https://github.com/openwch/ch32f20x.gi hw/mcu/wch/ch32v103 https://github.com/openwch/ch32v103.git 7578cae0b21f86dd053a1f781b2fc6ab99d0ec17 ch32v10x hw/mcu/wch/ch32v20x https://github.com/openwch/ch32v20x.git c4c38f507e258a4e69b059ccc2dc27dde33cea1b ch32v20x hw/mcu/wch/ch32v307 https://github.com/openwch/ch32v307.git 184f21b852cb95eed58e86e901837bc9fff68775 ch32v30x -lib/CMSIS_5 https://github.com/ARM-software/CMSIS_5.git 2b7495b8535bdcb306dac29b9ded4cfb679d7e5c imxrt kinetis_k32l2 kinetis_kl lpc51 lpc54 lpc55 mcx mm32 msp432e4 nrf saml2x lpc11 lpc13 lpc15 lpc17 lpc18 lpc40 lpc43 stm32c0 stm32f0 stm32f1 stm32f2 stm32f3 stm32f4 stm32f7 stm32g0 stm32g4 stm32h5 stm32h7 stm32h7rs stm32l0 stm32l1 stm32l4 stm32l5 stm32n6 stm32u0 stm32u5 stm32wb stm32wbasam3x samd11 samd21 samd51 samd5x_e5x same5x same7x saml2x samg tm4c -lib/CMSIS_6 https://github.com/ARM-software/CMSIS_6.git b0bbb0423b278ca632cfe1474eb227961d835fd2 ra +lib/CMSIS_5 https://github.com/ARM-software/CMSIS_5.git 2b7495b8535bdcb306dac29b9ded4cfb679d7e5c imxrt kinetis_k32l2 kinetis_kl lpc51 lpc54 lpc55 mcx mm32 msp432e4 nrf saml2x lpc11 lpc13 lpc15 lpc17 lpc18 lpc40 lpc43 stm32c0 stm32f0 stm32f1 stm32f2 stm32f3 stm32f4 stm32f7 stm32g0 stm32g4 stm32h5 stm32h7 stm32h7rs stm32l0 stm32l1 stm32l4 stm32l5 stm32u0 stm32u5 stm32wb stm32wbasam3x samd11 samd21 samd51 samd5x_e5x same5x same7x saml2x samg tm4c +lib/CMSIS_6 https://github.com/ARM-software/CMSIS_6.git 6f0a58d01aa9bd2feba212097f9afe7acd991d52 ra stm32n6 lib/FreeRTOS-Kernel https://github.com/FreeRTOS/FreeRTOS-Kernel.git cc0e0707c0c748713485b870bb980852b210877f all lib/lwip https://github.com/lwip-tcpip/lwip.git 159e31b689577dbf69cf0683bbaffbd71fa5ee10 all lib/sct_neopixel https://github.com/gsteiert/sct_neopixel.git e73e04ca63495672d955f9268e003cffe168fcd8 lpc55 tools/uf2 https://github.com/microsoft/uf2.git c594542b2faa01cc33a2b97c9fbebc38549df80a all -======================================== ================================================================ ======================================== ====================================================================================================================================================================================================================================================================================================================================================================== +======================================== ================================================================ ======================================== ============================================================================================================================================================================================================================================================================================================================================================== diff --git a/docs/reference/getting_started.rst b/docs/reference/getting_started.rst deleted file mode 100644 index b891d911b..000000000 --- a/docs/reference/getting_started.rst +++ /dev/null @@ -1,269 +0,0 @@ -*************** -Getting Started -*************** - -Add TinyUSB to your project ---------------------------- - -To incorporate tinyusb to your project - -* Copy or ``git submodule`` this repo into your project in a subfolder. Let's say it is ``your_project/tinyusb`` -* Add all the ``.c`` in the ``tinyusb/src`` folder to your project -* Add ``your_project/tinyusb/src`` to your include path. Also make sure your current include path also contains the configuration file ``tusb_config.h``. -* Make sure all required macros are all defined properly in ``tusb_config.h`` (configure file in demo application is sufficient, but you need to add a few more such as ``CFG_TUSB_MCU``, ``CFG_TUSB_OS`` since they are passed by make/cmake to maintain a unique configure for all boards). -* If you use the device stack, make sure you have created/modified usb descriptors for your own need. Ultimately you need to implement all **tud descriptor** callbacks for the stack to work. -* Add ``tusb_init(rhport, role)`` call to your reset initialization code. -* Call ``tusb_int_handler(rhport, in_isr)`` in your USB IRQ Handler -* Implement all enabled classes's callbacks. -* If you don't use any RTOSes at all, you need to continuously and/or periodically call ``tud_task()``/``tuh_task()`` function. All of the callbacks and functionality are handled and invoked within the call of that task runner. - -.. code-block:: c - - int main(void) { - tusb_rhport_init_t dev_init = { - .role = TUSB_ROLE_DEVICE, - .speed = TUSB_SPEED_AUTO - }; - tusb_init(0, &dev_init); // initialize device stack on roothub port 0 - - tusb_rhport_init_t host_init = { - .role = TUSB_ROLE_HOST, - .speed = TUSB_SPEED_AUTO - }; - tusb_init(1, &host_init); // initialize host stack on roothub port 1 - - while(1) { // the mainloop - your_application_code(); - tud_task(); // device task - tuh_task(); // host task - } - } - - void USB0_IRQHandler(void) { - tusb_int_handler(0, true); - } - - void USB1_IRQHandler(void) { - tusb_int_handler(1, true); - } - -Examples --------- - -For your convenience, TinyUSB contains a handful of examples for both host and device with/without RTOS to quickly test the functionality as well as demonstrate how API should be used. Most examples will work on most of :doc:`the supported boards <boards>`. Firstly we need to ``git clone`` if not already - -.. code-block:: bash - - $ git clone https://github.com/hathach/tinyusb tinyusb - $ cd tinyusb - -Some ports will also require a port-specific SDK (e.g. RP2040) or binary (e.g. Sony Spresense) to build examples. They are out of scope for tinyusb, you should download/install it first according to its manufacturer guide. - -Dependencies -^^^^^^^^^^^^ - -The hardware code is located in ``hw/bsp`` folder, and is organized by family/boards. e.g raspberry_pi_pico is located in ``hw/bsp/rp2040/boards/raspberry_pi_pico`` where ``FAMILY=rp2040`` and ``BOARD=raspberry_pi_pico``. Before building, we firstly need to download dependencies such as: MCU low-level peripheral driver and external libraries e.g FreeRTOS (required by some examples). We can do that by either ways: - -1. Run ``tools/get_deps.py {FAMILY}`` script to download all dependencies for a family as follow. Note: For TinyUSB developer to download all dependencies, use FAMILY=all. - -.. code-block:: bash - - $ python tools/get_deps.py rp2040 - -2. Or run the ``get-deps`` target in one of the example folder as follow. - -.. code-block:: bash - - $ cd examples/device/cdc_msc - $ make BOARD=feather_nrf52840_express get-deps - -You only need to do this once per family. Check out :doc:`complete list of dependencies and their designated path here <dependencies>` - -Build Examples -^^^^^^^^^^^^^^ - -Examples support make and cmake build system for most MCUs, however some MCU families such as espressif or rp2040 only support cmake. First change directory to an example folder. - -.. code-block:: bash - - $ cd examples/device/cdc_msc - -Then compile with make or cmake - -.. code-block:: bash - - $ # make - $ make BOARD=feather_nrf52840_express all - - $ # cmake - $ mkdir build && cd build - $ cmake -DBOARD=raspberry_pi_pico .. - $ make - -To list all available targets with cmake - -.. code-block:: bash - - $ cmake --build . --target help - -Note: some examples especially those that uses Vendor class (e.g webUSB) may requires udev permission on Linux (and/or macOS) to access usb device. It depends on your OS distro, typically copy ``99-tinyusb.rules`` and reload your udev is good to go - -.. code-block:: bash - - $ cp examples/device/99-tinyusb.rules /etc/udev/rules.d/ - $ sudo udevadm control --reload-rules && sudo udevadm trigger - -RootHub Port Selection -~~~~~~~~~~~~~~~~~~~~~~ - -If a board has several ports, one port is chosen by default in the individual board.mk file. Use option ``RHPORT_DEVICE=x`` or ``RHPORT_HOST=x`` To choose another port. For example to select the HS port of a STM32F746Disco board, use: - -.. code-block:: bash - - $ make BOARD=stm32f746disco RHPORT_DEVICE=1 all - - $ cmake -DBOARD=stm32f746disco -DRHPORT_DEVICE=1 .. - -Port Speed -~~~~~~~~~~ - -A MCU can support multiple operational speed. By default, the example build system will use the fastest supported on the board. Use option ``RHPORT_DEVICE_SPEED=OPT_MODE_FULL/HIGH_SPEED/`` or ``RHPORT_HOST_SPEED=OPT_MODE_FULL/HIGH_SPEED/`` e.g To force F723 operate at full instead of default high speed - -.. code-block:: bash - - $ make BOARD=stm32f746disco RHPORT_DEVICE_SPEED=OPT_MODE_FULL_SPEED all - - $ cmake -DBOARD=stm32f746disco -DRHPORT_DEVICE_SPEED=OPT_MODE_FULL_SPEED .. - -Size Analysis -~~~~~~~~~~~~~ - -First install `linkermap tool <https://github.com/hathach/linkermap>`_ then ``linkermap`` target can be used to analyze code size. You may want to compile with ``NO_LTO=1`` since ``-flto`` merges code across ``.o`` files and make it difficult to analyze. - -.. code-block:: bash - - $ make BOARD=feather_nrf52840_express NO_LTO=1 all linkermap - -Debug -^^^^^ - -To compile for debugging add ``DEBUG=1``\ , for example - -.. code-block:: bash - - $ make BOARD=feather_nrf52840_express DEBUG=1 all - - $ cmake -DBOARD=feather_nrf52840_express -DCMAKE_BUILD_TYPE=Debug .. - -Log -~~~ - -Should you have an issue running example and/or submitting an bug report. You could enable TinyUSB built-in debug logging with optional ``LOG=``. ``LOG=1`` will only print out error message, ``LOG=2`` print more information with on-going events. ``LOG=3`` or higher is not used yet. - -.. code-block:: bash - - $ make BOARD=feather_nrf52840_express LOG=2 all - - $ cmake -DBOARD=feather_nrf52840_express -DLOG=2 .. - -Logger -~~~~~~ - -By default log message is printed via on-board UART which is slow and take lots of CPU time comparing to USB speed. If your board support on-board/external debugger, it would be more efficient to use it for logging. There are 2 protocols: - - -* `LOGGER=rtt`: use `Segger RTT protocol <https://www.segger.com/products/debug-probes/j-link/technology/about-real-time-transfer/>`_ - - * Cons: requires jlink as the debugger. - * Pros: work with most if not all MCUs - * Software viewer is JLink RTT Viewer/Client/Logger which is bundled with JLink driver package. - -* ``LOGGER=swo`` : Use dedicated SWO pin of ARM Cortex SWD debug header. - - * Cons: only work with ARM Cortex MCUs minus M0 - * Pros: should be compatible with more debugger that support SWO. - * Software viewer should be provided along with your debugger driver. - -.. code-block:: bash - - $ make BOARD=feather_nrf52840_express LOG=2 LOGGER=rtt all - $ make BOARD=feather_nrf52840_express LOG=2 LOGGER=swo all - - $ cmake -DBOARD=feather_nrf52840_express -DLOG=2 -DLOGGER=rtt .. - $ cmake -DBOARD=feather_nrf52840_express -DLOG=2 -DLOGGER=swo .. - -Flash -^^^^^ - -``flash`` target will use the default on-board debugger (jlink/cmsisdap/stlink/dfu) to flash the binary, please install those support software in advance. Some board use bootloader/DFU via serial which is required to pass to make command - -.. code-block:: bash - - $ make BOARD=feather_nrf52840_express flash - $ make SERIAL=/dev/ttyACM0 BOARD=feather_nrf52840_express flash - -Since jlink/openocd can be used with most of the boards, there is also ``flash-jlink/openocd`` (make) and ``EXAMPLE-jlink/openocd`` target for your convenience. Note for stm32 board with stlink, you can use ``flash-stlink`` target as well. - -.. code-block:: bash - - $ make BOARD=feather_nrf52840_express flash-jlink - $ make BOARD=feather_nrf52840_express flash-openocd - - $ cmake --build . --target cdc_msc-jlink - $ cmake --build . --target cdc_msc-openocd - -Some board use uf2 bootloader for drag & drop in to mass storage device, uf2 can be generated with ``uf2`` target - -.. code-block:: bash - - $ make BOARD=feather_nrf52840_express all uf2 - - $ cmake --build . --target cdc_msc-uf2 - -IAR Support -^^^^^^^^^^^ - -Use project connection -~~~~~~~~~~~~~~~~~~~~~~ - -IAR Project Connection files are provided to import TinyUSB stack into your project. - -* A buildable project of your MCU need to be created in advance. - - * Take example of STM32F0: - - - You need ``stm32l0xx.h``, ``startup_stm32f0xx.s``, ``system_stm32f0xx.c``. - - - ``STM32L0xx_HAL_Driver`` is only needed to run examples, TinyUSB stack itself doesn't rely on MCU's SDKs. - -* Open ``Tools -> Configure Custom Argument Variables`` (Switch to ``Global`` tab if you want to do it for all your projects) - Click ``New Group ...``, name it to ``TUSB``, Click ``Add Variable ...``, name it to ``TUSB_DIR``, change it's value to the path of your TinyUSB stack, - for example ``C:\\tinyusb`` - -**Import stack only** - -Open ``Project -> Add project Connection ...``, click ``OK``, choose ``tinyusb\\tools\\iar_template.ipcf``. - -**Run examples** - -1. Run ``iar_gen.py`` to generate .ipcf files of examples: - - .. code-block:: - - > cd C:\tinyusb\tools - > python iar_gen.py - -2. Open ``Project -> Add project Connection ...``, click ``OK``, choose ``tinyusb\\examples\\(.ipcf of example)``. - For example ``C:\\tinyusb\\examples\\device\\cdc_msc\\iar_cdc_msc.ipcf`` - -Native CMake support -~~~~~~~~~~~~~~~~~~~~ - -With 9.50.1 release, IAR added experimental native CMake support (strangely not mentioned in public release note). Now it's possible to import CMakeLists.txt then build and debug as a normal project. - -Following these steps: - -1. Add IAR compiler binary path to system ``PATH`` environment variable, such as ``C:\Program Files\IAR Systems\Embedded Workbench 9.2\arm\bin``. -2. Create new project in IAR, in Tool chain dropdown menu, choose CMake for Arm then Import ``CMakeLists.txt`` from chosen example directory. -3. Set up board option in ``Option - CMake/CMSIS-TOOLBOX - CMake``, for example ``-DBOARD=stm32f439nucleo -DTOOLCHAIN=iar``, **Uncheck 'Override tools in env'**. -4. (For debug only) Choose correct CPU model in ``Option - General Options - Target``, to profit register and memory view. diff --git a/docs/reference/glossary.rst b/docs/reference/glossary.rst new file mode 100644 index 000000000..537769c43 --- /dev/null +++ b/docs/reference/glossary.rst @@ -0,0 +1,98 @@ +******** +Glossary +******** + +.. glossary:: + + BSP + Board Support Package. A collection of board-specific code that provides hardware abstraction for a particular development board, including pin mappings, clock settings, linker scripts, and hardware initialization routines. Located in ``hw/bsp/FAMILY/boards/BOARD_NAME``. + + Bulk Transfer + USB transfer type used for large amounts of data that doesn't require guaranteed timing. Used by mass storage devices and CDC class. + + CDC + Communications Device Class. USB class for devices that communicate serial data, creating virtual serial ports. + + Control Transfer + USB transfer type used for device configuration and control. All USB devices must support control transfers on endpoint 0. + + DCD + Device Controller Driver. The hardware abstraction layer for USB device controllers in TinyUSB. See also HCD. + + Descriptor + Data structures that describe USB device capabilities, configuration, and interfaces to the host. + + Device Class + USB specification defining how devices of a particular type (e.g., storage, audio, HID) communicate with hosts. + + DFU + Device Firmware Update. USB class that allows firmware updates over USB. + + Endpoint + Communication channel between host and device. Each endpoint has a direction (IN/OUT) and transfer type. + + Enumeration + Process where USB host discovers and configures a newly connected device. + + HCD + Host Controller Driver. The hardware abstraction layer for USB host controllers in TinyUSB. See also DCD. + + HID + Human Interface Device. USB class for input devices like keyboards, mice, and game controllers. + + High Speed + USB 2.0 speed mode operating at 480 Mbps. + + Full Speed + USB speed mode operating at 12 Mbps, supported by USB 1.1 and 2.0. + + Low Speed + USB speed mode operating at 1.5 Mbps, typically used by simple input devices. + + Interrupt Transfer + USB transfer type for small, time-sensitive data with guaranteed maximum latency. + + Isochronous Transfer + USB transfer type for time-critical data like audio/video with guaranteed bandwidth but no error correction. + + MSC + Mass Storage Class. USB class for storage devices like USB drives. + + OSAL + Operating System Abstraction Layer. TinyUSB component that abstracts RTOS differences. + + OTG + On-The-Go. USB specification allowing devices to act as both host and device. + + Pipe + Host-side communication channel to a device endpoint. + + Root Hub + The USB hub built into the host controller, where devices connect directly. + + Stall + USB protocol mechanism where an endpoint responds with a STALL handshake to indicate an error condition or unsupported request. Used for error handling, not flow control. + + Super Speed + USB 3.0 speed mode operating at 5 Gbps. Not supported by TinyUSB. + + tud + TinyUSB Device. Function prefix for all device stack APIs (e.g., ``tud_task()``, ``tud_cdc_write()``). + + tuh + TinyUSB Host. Function prefix for all host stack APIs (e.g., ``tuh_task()``, ``tuh_cdc_receive()``). + + UAC + USB Audio Class. USB class for audio devices. + + UVC + USB Video Class. USB class for video devices like cameras. + + VID + Vendor Identifier. 16-bit number assigned by USB-IF to identify device manufacturers. + + PID + Product Identifier. 16-bit number assigned by vendor to identify specific products. + + USB-IF + USB Implementers Forum. Organization that maintains USB specifications and assigns VIDs. diff --git a/docs/reference/index.rst b/docs/reference/index.rst index 8ac3cf924..d3c96eeee 100644 --- a/docs/reference/index.rst +++ b/docs/reference/index.rst @@ -1,10 +1,15 @@ -Index -===== +********* +Reference +********* + +Complete reference documentation for TinyUSB APIs, configuration, and supported hardware. .. toctree:: :maxdepth: 2 - getting_started + architecture + usb_concepts boards dependencies concurrency + glossary diff --git a/docs/reference/usb_concepts.rst b/docs/reference/usb_concepts.rst new file mode 100644 index 000000000..86ae97007 --- /dev/null +++ b/docs/reference/usb_concepts.rst @@ -0,0 +1,428 @@ +************ +USB Concepts +************ + +This document provides a brief introduction to USB protocol fundamentals that are essential for understanding TinyUSB development. + +TinyUSB API Naming Conventions +=============================== + +TinyUSB uses consistent function prefixes to organize its API: + +* **tusb_**: Core stack functions (initialization, interrupt handling) +* **tud_**: Device stack functions (e.g., ``tud_task()``, ``tud_cdc_write()``) +* **tuh_**: Host stack functions (e.g., ``tuh_task()``, ``tuh_cdc_receive()``) +* **tu_**: Internal utility functions (generally not used by applications) + +This naming makes it easy to identify which part of the stack a function belongs to and ensures there are no naming conflicts when using both device and host stacks together. + +USB Protocol Basics +==================== + +Universal Serial Bus (USB) is a standardized communication protocol designed for connecting devices to hosts (typically computers). Understanding these core concepts is essential for effective TinyUSB development. + +Host and Device Roles +---------------------- + +**USB Host**: The controlling side of a USB connection (typically a computer). The host: +- Initiates all communication +- Provides power to devices +- Manages the USB bus +- Enumerates and configures devices + +**TinyUSB Host Stack**: Enable with ``CFG_TUH_ENABLED=1`` in ``tusb_config.h``. Call ``tuh_task()`` regularly in your main loop. See the :doc:`../getting_started` Quick Start Examples for implementation details. + +**USB Device**: The peripheral side (keyboard, mouse, storage device, etc.). Devices: +- Respond to host requests +- Cannot initiate communication +- Receive power from the host +- Must be enumerated by the host before use + +**TinyUSB Device Stack**: Enable with ``CFG_TUD_ENABLED=1`` in ``tusb_config.h``. Call ``tud_task()`` regularly in your main loop. See the :doc:`../getting_started` Quick Start Examples for implementation details. + +**OTG (On-The-Go)**: Some devices can switch between host and device roles dynamically. **TinyUSB Support**: Both stacks can be enabled simultaneously on OTG-capable hardware. See ``examples/dual/`` for dual-role implementations. + +USB Transfers +============= + +Every USB transfer consists of the host issuing a request, and the device replying to that request. The host is the bus master and initiates all communication. +Devices cannot initiate sending data; for unsolicited incoming data, polling is used by the host. + +USB defines four transfer types, each intended for different use cases: + +Control Transfers +----------------- + +Used for device configuration and control commands. + +**Characteristics**: +- Bidirectional (uses both IN and OUT) +- Guaranteed delivery with error detection +- Limited data size (8-64 bytes per packet) +- All devices must support control transfers on endpoint 0 + +**Usage**: Device enumeration, configuration changes, class-specific commands + +**TinyUSB Context**: Handled automatically by the core stack for standard requests; class drivers handle class-specific requests. Endpoint 0 is managed by ``src/device/usbd.c`` and ``src/host/usbh.c``. Configure buffer size with ``CFG_TUD_ENDPOINT0_SIZE`` (typically 64 bytes). + +Bulk Transfers +-------------- + +Used for large amounts of data that don't require guaranteed timing. + +**Characteristics**: +- Unidirectional (separate IN and OUT endpoints) +- Guaranteed delivery with error detection +- Large packet sizes (up to 512 bytes for High Speed) +- Uses available bandwidth when no other transfers are active + +**Usage**: File transfers, large data communication, CDC serial data + +**TinyUSB Context**: Used by MSC (mass storage) and CDC classes for data transfer. Configure endpoint buffer sizes with ``CFG_TUD_MSC_EP_BUFSIZE`` and ``CFG_TUD_CDC_EP_BUFSIZE``. See ``src/class/msc/`` and ``src/class/cdc/`` for implementation details. + +Interrupt Transfers +------------------- + +Used for small, time-sensitive data with guaranteed maximum latency. + +**Characteristics**: +- Unidirectional (separate IN and OUT endpoints) +- Guaranteed delivery with error detection +- Small packet sizes (up to 64 bytes for Full Speed) +- Regular polling interval (1ms to 255ms) + +**Usage**: Keyboard/mouse input, sensor data, status updates + +**TinyUSB Context**: Used by HID class for input reports. Configure with ``CFG_TUD_HID`` and ``CFG_TUD_HID_EP_BUFSIZE``. Send reports using ``tud_hid_report()`` or ``tud_hid_keyboard_report()``. See ``src/class/hid/`` and HID examples in ``examples/device/hid_*/``. + +Isochronous Transfers +--------------------- + +Used for time-critical streaming data. + +**Characteristics**: +- Unidirectional (separate IN and OUT endpoints) +- No error correction (speed over reliability) +- Guaranteed bandwidth +- Real-time delivery + +**Usage**: Audio, video streaming + +**TinyUSB Context**: Used by Audio class for streaming audio data. Configure with ``CFG_TUD_AUDIO`` and related audio configuration macros. See ``src/class/audio/`` and audio examples in ``examples/device/audio_*/`` for UAC2 implementation. + +Endpoints and Addressing +========================= + +Endpoint Basics +--------------- + +**Endpoint**: A communication channel between host and device. + +- Each endpoint has a number (0-15) and direction +- Endpoint 0 is reserved for control transfers +- Other endpoints are assigned by device class requirements + +**TinyUSB Endpoint Management**: Configure maximum endpoints with ``CFG_TUD_ENDPOINT_MAX``. Endpoints are automatically allocated by enabled classes. See your board's ``usb_descriptors.c`` for endpoint assignments. + +**Direction**: +- **OUT**: Host to device (host sends data out) +- **IN**: Device to host (host reads data in) +- Note that in TinyUSB code, for ``tx``/``rx``, the device perspective is used typically: E.g., ``tud_cdc_tx_complete_cb()`` designates the callback executed once the device has completed sending data to the host (in device mode). + +**Addressing**: Endpoints are addressed as EPx IN/OUT (e.g., EP1 IN, EP2 OUT) + +Endpoint Configuration +---------------------- + +Each endpoint is configured with a specific **transfer type** (control, bulk, interrupt, or isochronous), a **direction** (IN, OUT, or bidirectional for control only), a **maximum packet size** that depends on USB speed and transfer type, and an **interval** for interrupt and isochronous endpoints. + +**TinyUSB Configuration**: Endpoint characteristics are defined in descriptors (``usb_descriptors.c``) and automatically configured by the stack. Buffer sizes are set via ``CFG_TUD_*_EP_BUFSIZE`` macros. + +Error Handling and Flow Control +------------------------------- + +**Transfer Results**: USB transfers can complete with different results. An **ACK** indicates a successful transfer, while a **NAK** signals that the device is not ready (commonly used for flow control). A **STALL** response indicates an error condition or unsupported request, and **Timeout** occurs when a transfer fails to complete within the expected time frame. + +**Flow Control in USB**: Unlike network protocols, USB doesn't use traditional congestion control. Instead, devices use NAK responses when not ready to receive data, applications implement buffering and proper timing strategies, and some classes (like CDC) support hardware flow control mechanisms such as RTS/CTS. + +**TinyUSB Handling**: Transfer results are represented as ``xfer_result_t`` enum values. The stack automatically handles NAK responses and timing. STALL conditions indicate application-level errors that should be addressed in class drivers. + +USB Device States +================= + +A USB device progresses through several states: + +1. **Attached**: Device is physically connected +2. **Powered**: Device receives power from host +3. **Default**: Device responds to address 0 +4. **Address**: Device has been assigned a unique address +5. **Configured**: Device is ready for normal operation +6. **Suspended**: Device is in low-power state + +**TinyUSB State Management**: State transitions are handled automatically by ``src/device/usbd.c``. You can implement ``tud_mount_cb()`` and ``tud_umount_cb()`` to respond to configuration changes, and ``tud_suspend_cb()``/``tud_resume_cb()`` for power management. + +Device Enumeration Process +========================== + +When a device is connected, the host follows this process: + +1. **Detection**: Host detects device connection +2. **Reset**: Host resets the device +3. **Descriptor Requests**: Host requests device descriptors +4. **Address Assignment**: Host assigns unique address to device +5. **Configuration**: Host selects and configures device +6. **Class Loading**: Host loads appropriate drivers +7. **Normal Operation**: Device is ready for use + +**TinyUSB Role**: The device stack handles steps 1-6 automatically; your application handles step 7. + +USB Descriptors +=============== + +Descriptors are data structures that describe device capabilities: + +Device Descriptor +----------------- +Describes the device (VID, PID, USB version, etc.) + +Configuration Descriptor +------------------------ +Describes device configuration (power requirements, interfaces, etc.) + +Interface Descriptor +-------------------- +Describes a functional interface (class, endpoints, etc.) + +Endpoint Descriptor +------------------- +Describes endpoint characteristics (type, direction, size, etc.) + +String Descriptors +------------------ +Human-readable strings (manufacturer, product name, etc.) + +**TinyUSB Implementation**: You provide descriptors in ``usb_descriptors.c`` via callback functions: +- ``tud_descriptor_device_cb()`` - Device descriptor +- ``tud_descriptor_configuration_cb()`` - Configuration descriptor +- ``tud_descriptor_string_cb()`` - String descriptors + +The stack automatically handles descriptor requests during enumeration. See examples in ``examples/device/*/usb_descriptors.c`` for reference implementations. + +USB Classes +=========== + +USB classes define standardized protocols for device types: + +**Class Code**: Identifies the device type in descriptors +**Class Driver**: Software that implements the class protocol +**Class Requests**: Standardized commands for the class + +**Common TinyUSB-Supported Classes**: +- **CDC (02h)**: Communication devices (virtual serial ports) - Enable with ``CFG_TUD_CDC`` +- **HID (03h)**: Human interface devices (keyboards, mice) - Enable with ``CFG_TUD_HID`` +- **MSC (08h)**: Mass storage devices (USB drives) - Enable with ``CFG_TUD_MSC`` +- **Audio (01h)**: Audio devices (speakers, microphones) - Enable with ``CFG_TUD_AUDIO`` +- **MIDI**: MIDI devices - Enable with ``CFG_TUD_MIDI`` +- **DFU**: Device Firmware Update - Enable with ``CFG_TUD_DFU`` +- **Vendor**: Custom vendor classes - Enable with ``CFG_TUD_VENDOR`` + +.. note:: + **Vendor Class Buffer Configuration**: Unlike other USB classes, the vendor class supports setting buffer sizes to 0 in ``tusb_config.h`` (``CFG_TUD_VENDOR_RX_BUFSIZE = 0``) to disable internal buffering. When disabled, data goes directly to ``tud_vendor_rx_cb()`` and the ``tud_vendor_read()``/``tud_vendor_write()`` functions are not available - applications must handle data directly in callbacks. + +See ``examples/device/*/tusb_config.h`` for configuration examples. + +USB Speeds +========== + +USB supports multiple speed modes: + +**Low Speed (1.5 Mbps)**: +- Simple devices (mice, keyboards) +- Limited endpoint types and sizes + +**Full Speed (12 Mbps)**: +- Most common for embedded devices +- All transfer types supported +- Maximum packet sizes: Control (64), Bulk (64), Interrupt (64) + +**High Speed (480 Mbps)**: +- High-performance devices +- Larger packet sizes: Control (64), Bulk (512), Interrupt (1024) +- Requires more complex hardware + +**Super Speed (5 Gbps)**: +- USB 3.0 and later +- Not supported by TinyUSB + +**TinyUSB Speed Support**: Most TinyUSB ports support Full Speed and High Speed. Speed is typically auto-detected by hardware. Configure speed requirements in board configuration (``hw/bsp/FAMILY/boards/BOARD/board.mk``) and ensure your MCU supports the desired speed. + +USB Controller Abstraction +=========================== + +USB controllers are hardware peripherals that handle the low-level USB protocol implementation. Understanding how they work helps explain TinyUSB's architecture and portability. + +Controller Fundamentals +----------------------- + +**What Controllers Do**: +- Handle USB signaling and protocol timing +- Manage endpoint buffers and data transfers +- Generate interrupts for USB events +- Implement USB electrical specifications + +**Key Components**: USB controllers consist of several key components working together. The **Physical Layer** provides USB signal drivers and receivers for electrical interfacing. The **Protocol Engine** handles USB packets and ACK/NAK responses according to the USB specification. **Endpoint Buffers** provide hardware FIFOs or RAM for data storage during transfers. Finally, the **Interrupt Controller** generates events for software processing when USB activities occur. + +Controller Architecture Types +----------------------------- + +Different MCU vendors implement USB controllers with varying architectures. +To list a few common patterns: + +**FIFO-Based Controllers** (e.g., STM32 OTG, NXP LPC): +- Shared or dedicated FIFOs for endpoint data +- Software manages FIFO allocation and data flow +- Common in higher-end MCUs with flexible configurations + +**Buffer-Based Controllers** (e.g., STM32 FSDEV, Microchip SAMD, RP2040): +- Fixed packet memory areas for each endpoint +- Hardware automatically handles packet placement +- Simpler programming model, common in smaller MCUs + +**Descriptor-Based Controllers** (e.g., NXP EHCI-style): +- Use descriptor chains to describe transfers +- Hardware processes transfer descriptors independently +- More complex but can handle larger transfers autonomously + +TinyUSB Controller Abstraction +------------------------------ + +TinyUSB abstracts controller differences through the TinyUSB **Device Controller Driver (DCD)** layer. +These internal details don't matter to users of TinyUSB typically; however, when debugging, knowledge about internal details helps sometimes. + +**Portable Interface** (``src/device/usbd.h``): +- Standardized function signatures for all controllers +- Common endpoint and transfer management APIs +- Unified interrupt and event handling + +**Controller-Specific Drivers** (``src/portable/VENDOR/FAMILY/``): +- Implement the DCD interface for specific hardware +- Handle vendor-specific register layouts and behaviors +- Manage controller-specific quirks and workarounds + +**Common DCD Functions**: +- ``dcd_init()`` - Initialize controller hardware +- ``dcd_edpt_open()`` - Configure endpoint with type and size +- ``dcd_edpt_xfer()`` - Start data transfer on endpoint +- ``dcd_int_handler()`` - Process USB interrupts +- ``dcd_connect()/dcd_disconnect()`` - Control USB bus connection + +Host Controller Driver (HCD) +----------------------------- + +TinyUSB also abstracts USB host controllers through the **Host Controller Driver (HCD)** layer for host mode applications. + +**Portable Interface** (``src/host/usbh.h``): +- Standardized interface for all host controllers +- Common device enumeration and pipe management +- Unified transfer scheduling and completion handling + +**Common HCD Functions**: +- ``hcd_init()`` - Initialize host controller hardware +- ``hcd_port_connect_status()`` - Check device connection status +- ``hcd_port_reset()`` - Reset connected device +- ``hcd_edpt_open()`` - Open communication pipe to device endpoint +- ``hcd_edpt_xfer()`` - Transfer data to/from connected device + +**Host vs Device Architecture**: While DCD is reactive (responds to host requests), HCD is active (initiates all communication). Host controllers manage device enumeration, driver loading, and transfer scheduling to multiple connected devices. + +TinyUSB Event System & Thread Safety +==================================== + +Deferred Interrupt Processing +----------------------------- + +**Core Architectural Principle**: TinyUSB uses a deferred interrupt processing model where all USB hardware events are captured in interrupt service routines (ISRs) but processed later in non-interrupt context. + +**Event Flow**: + +1. **Hardware Event**: USB controller generates interrupt (e.g., data received, transfer complete) +2. **ISR Handling**: TinyUSB ISR captures the event and pushes it to a central event queue +3. **Deferred Processing**: Application calls ``tud_task()`` or ``tuh_task()`` to process queued events +4. **Class Driver Callbacks**: Events trigger appropriate class driver functions and user callbacks + +**Buffer Integration**: The deferred processing model works seamlessly with TinyUSB's buffer/FIFO design. Since callbacks run in task context (not ISR), it's safe and straightforward to enqueue TX data directly in RX callbacks - for example, processing incoming CDC data and immediately sending a response. + +Controller Event Flow +--------------------- + +**Typical USB Event Processing**: + +1. **Hardware Event**: USB controller detects bus activity (setup packet, data transfer, etc.) +2. **Interrupt Generation**: Controller generates interrupt to CPU +3. **ISR Processing**: ``dcd_int_handler()`` reads controller status +4. **Event Queuing**: Events are queued for later processing (thread safety) +5. **Task Processing**: ``tud_task()`` processes queued events +6. **Class Notification**: Appropriate class drivers handle the event +7. **Application Callback**: User code responds to the event + +USB Class Driver Architecture +============================== + +TinyUSB implements USB classes through a standardized driver pattern that provides consistent integration with the core stack while allowing class-specific functionality. + +Class Driver Pattern +--------------------- + +**Standardized Entry Points**: Each class driver implements these core functions: + +- ``*_init()`` - Initialize class driver state and buffers +- ``*_reset()`` - Reset to initial state on USB bus reset +- ``*_open()`` - Parse and configure interfaces during enumeration +- ``*_control_xfer_cb()`` - Handle class-specific control requests +- ``*_xfer_cb()`` - Handle transfer completion callbacks + +**Multi-Instance Support**: Classes support multiple instances using ``_n`` suffixed APIs: + +.. code-block:: c + + // Single instance (default instance 0) + tud_cdc_write(data, len); + + // Multiple instances + tud_cdc_n_write(0, data, len); // Instance 0 + tud_cdc_n_write(1, data, len); // Instance 1 + +**Integration with Core Stack**: Class drivers are automatically discovered and integrated through function pointers in driver tables. The core stack calls class drivers during enumeration, control requests, and data transfers without requiring explicit registration. + +Class Driver Types +------------------- + +TinyUSB classes have different architectural patterns based on their buffering capabilities and callback designs. + +Most classes like CDC, MIDI, and HID always use internal buffers for data management. These classes provide notification-only callbacks such as ``tud_cdc_rx_cb(uint8_t itf)`` that signal when data is available, requiring applications to use class-specific APIs like ``tud_cdc_read()`` and ``tud_cdc_write()`` to access the data. HID is slightly different in that it provides direct buffer access in some callbacks (``tud_hid_set_report_cb()`` receives buffer and size parameters), but it still maintains internal endpoint buffering that cannot be disabled. + +The **Vendor Class** is unique in that it supports both buffered and direct modes. When buffered, vendor class behaves like other classes with ``tud_vendor_read()`` and ``tud_vendor_write()`` APIs. However, when buffering is disabled by setting buffer size to 0, the vendor class provides direct buffer access through ``tud_vendor_rx_cb(itf, buffer, bufsize)`` callbacks, eliminating internal FIFO overhead and providing direct endpoint control. + +**Block-Oriented Classes** like MSC operate differently by handling large data blocks through callback interfaces. The application implements storage access functions such as ``tud_msc_read10_cb()`` and ``tud_msc_write10_cb()``, while the TinyUSB stack manages the USB protocol aspects and the application manages the underlying storage. + +Power Management +================ + +USB provides power to devices: + +**Bus-Powered**: Device draws power from USB bus (up to 500mA) +**Self-Powered**: Device has its own power source +**Suspend/Resume**: Devices must enter low-power mode when bus is idle + +**TinyUSB Power Management**: +- Implement ``tud_suspend_cb()`` and ``tud_resume_cb()`` for power management +- Configure power requirements in device descriptor (``bMaxPower`` field) +- Use ``tud_remote_wakeup()`` to wake the host from suspend (if supported) +- Enable remote wakeup with ``CFG_TUD_USBD_ENABLE_REMOTE_WAKEUP`` + +Next Steps +========== + +- Start with :doc:`../getting_started` for basic setup +- Review ``examples/device/*/tusb_config.h`` for configuration examples +- Explore examples in ``examples/device/`` and ``examples/host/`` directories |