feature(esp_tinyusb): TinyUSB task deletion notification driven (part 3/3) (IEC-441)

[roma-jam]

Description

This is the third and the final part of the plan: Make the TinyUSB task deletion notification driven

Implement the mechanism:

• User task sends a stop notification to TinyUSB task via xTaskNotify.
• TinyUSB task acknowledges start/stop completion via the start/stop semaphore so the user task knows when cleanup is safe.
• Use tud_task_ext(timeout_ms, false) with the configured timeout.
• Replace the existing stop/deletion logic with this notification-driven flow, keeping behavior identical when timeout_ms == 0 (legacy way of task deletion).

Additional tasks

• Solved _task_is_running bug (feature(tinyusb): Software VBUS monitoring feature on ESP32P4 (part1/2) (IEC-437) #305 (review))
• Compared CPU load in both cases (Both Run Time and CPU load in default mode (1s blocking) and legacy mode (indefinite blocking) are the same)
• Update the result table with the actual results based on the last changes
• Update CHANGELOG.md and README
• Profile the precise percentage calculation to find the calculation error (the total sum of percentage should be exactly 100%, find and eliminate the problem)
• Re-measure the results for CPU Load with precise percentage

CPU Load value has been excluded from this PR as it is re-calculated Run Time value.
The TinyUSB task CPU load is measured via the Run Time value instead.

The CPU Load calculation add on is in follow-up PR: [TBC]

Test description

CPU load test case was used as a measurement tool.

As the results vary from the launch, the test was launched three times in a row.
Test steps:

1. Re-power the test board
2. Perform launch1, get result1
3. Perform launch2, get result2
4. Perform launch3, get result3

After each launch, the result was placed in the table: result1 / result2 / result 3, for example 461 / 458 / 462

CPU Load all the time less than 1%, because tasks IDLE0 and IDLE1 use most of the CPU:

Name                   Run time CPU load
TinyUSB                    1667   0.09%
main                       8492   0.50%
IDLE1                    846330  50.06%
IDLE0                    844577  49.96%
ipc1                          0   0.00%
ipc0                          0   0.00%

Run Time and CPU Load of TinyUSB task for ESP32-S3

Case	Run Time
non-blocking ( timeout_ms = 0)	2276 / 2449 / 2417
default blocking (timeout_ms = 2000)	2122 / 1726 / 1769
blocking indefinitely (legacy mode, timeout_ms = UINT32_MAX)	1702 / 1700 / 1738

Run Time and CPU Load of TinyUSB task for ESP32-P4 (ECO5)

Case	Run Time (ticks)
non-blocking ( timeout_ms = 0)	1390 / 893 / 848
default blocking (timeout_ms = 1000)	967 / 469 / 458
blocking indefinitely (legacy mode, timeout_ms = UINT32_MAX)	968 / 473 / 460

Notes

• On ESP32-S2 the non-blocking Run Time is ~ 4200.
• On ESP32-S3 the non-blocking Run Time is ~ 1700.

Default timeout values may differ per CPU/target to match CPU load observed in legacy (block-forever) mode versus non-blocking mode. To minimize the difference with legacy mode the default timeout was selected based on the Run Time value according to the table above.

Related

• Prerequisites in refactor(esp_tinyusb): TinyUSB task deletion notification driven (part 1/3) #322
• Prerequisites in feature(esp_tinyusb): TinyUSB task deletion notification driven (part 2/3) #325
• Closes IEC-351

Testing

---

Checklist

Before submitting a Pull Request, please ensure the following:

• 🚨 This PR does not introduce breaking changes.
• All CI checks (GH Actions) pass.
• Documentation is updated as needed.
• Tests are updated or added as necessary.
• Code is well-commented, especially in complex areas.
• Git history is clean — commits are squashed to the minimum necessary.

[roma-jam]

I moved out the CPU Load improvements into another PR to unblock this one.

As the CPU Load value it re-calculated Run Time, we can make a decision based on the Run Time value.

CPU Load in percentage is nice to have feature and more user-friendly, but it is not important ATM.