From 8c780a9564a05ea0f0e3bf0d929fd5dbe6c4806a Mon Sep 17 00:00:00 2001 From: slc-tl <91279938+slc-tl@users.noreply.github.com> Date: Fri, 14 Apr 2023 17:07:33 -0600 Subject: [PATCH 1/2] Update porting.rst Adds more in depth documentation of how tud_task does not need to be polled in implementations that use an RTOS / scheduler. --- docs/contributing/porting.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/contributing/porting.rst b/docs/contributing/porting.rst index 710af51c3..9ec392661 100644 --- a/docs/contributing/porting.rst +++ b/docs/contributing/porting.rst @@ -69,7 +69,7 @@ The code is almost entirely agnostic of MCU and lives in ``src/osal``. Device API ^^^^^^^^^^ -After the USB device is setup, the USB device code works by processing events on the main thread (by calling ``tud_task``\ ). These events are queued by the USB interrupt handler. So, there are three parts to the device low-level API: device setup, endpoint setup and interrupt processing. +After the USB device is setup, the USB device code works by processing events on the main thread (by calling ``tud_task``\ ). In RTOS configurations, tud_task blocks behind a synchronization structure when the event queue is empty, so that the scheduler may give the CPU to a different task. To take advantage of the library's capability to yield the CPU when there are no actionable USB device events, ensure that the `CFG_TUSB_OS` symbol is defined in your modified ``tusb_config.h``. For example `#define CFG_TUSB_OS OPT_OS_FREERTOS` enables the FreeRTOS scheduler to schedule other threads than that which calls `tud_task`. These events are queued by the USB interrupt handler. So, there are three parts to the device low-level API: device setup, endpoint setup and interrupt processing. All of the code for the low-level device API is in ``src/portable///dcd_.c``. From 090078542fd8b9a11d72163b11b99e7d25f63072 Mon Sep 17 00:00:00 2001 From: hathach Date: Fri, 28 Apr 2023 11:34:12 +0700 Subject: [PATCH 2/2] update osal note --- docs/contributing/porting.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/contributing/porting.rst b/docs/contributing/porting.rst index 9ec392661..f81d98782 100644 --- a/docs/contributing/porting.rst +++ b/docs/contributing/porting.rst @@ -62,14 +62,14 @@ Feel free to skip this until you want to verify your demo code is running. To im OS Abstraction Layer (OSAL) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The OS Abstraction Layer is responsible for providing basic data structures for TinyUSB that may allow for concurrency when used with an RTOS. Without an RTOS it simply handles concurrency issues between the main code and interrupts. +The OS Abstraction Layer is responsible for providing basic data structures for TinyUSB that may allow for concurrency when used with an RTOS. Without an RTOS it simply handles concurrency issues between the main code and interrupts. The code is almost entirely agnostic of MCU and lives in ``src/osal``. -The code is almost entirely agnostic of MCU and lives in ``src/osal``. +In RTOS configurations, tud_task()/tuh_task() blocks behind a synchronization structure when the event queue is empty, so that the scheduler may give the CPU to a different task. To take advantage of the library's capability to yield the CPU when there are no actionable USB device events, ensure that the `CFG_TUSB_OS` symbol is defined, e.g `OPT_OS_FREERTOS` enables the FreeRTOS scheduler to schedule other threads than that which calls `tud_task()/tuh_task()`. Device API ^^^^^^^^^^ -After the USB device is setup, the USB device code works by processing events on the main thread (by calling ``tud_task``\ ). In RTOS configurations, tud_task blocks behind a synchronization structure when the event queue is empty, so that the scheduler may give the CPU to a different task. To take advantage of the library's capability to yield the CPU when there are no actionable USB device events, ensure that the `CFG_TUSB_OS` symbol is defined in your modified ``tusb_config.h``. For example `#define CFG_TUSB_OS OPT_OS_FREERTOS` enables the FreeRTOS scheduler to schedule other threads than that which calls `tud_task`. These events are queued by the USB interrupt handler. So, there are three parts to the device low-level API: device setup, endpoint setup and interrupt processing. +After the USB device is setup, the USB device code works by processing events on the main thread (by calling ``tud_task``\ ). These events are queued by the USB interrupt handler. So, there are three parts to the device low-level API: device setup, endpoint setup and interrupt processing. All of the code for the low-level device API is in ``src/portable///dcd_.c``.