feat(task/interrupt): Allow runtime changes to task priority/core_id. Expose interrupt task methods for runtime control

[finger563]

Description

Adds an API to reconfigure an espp::Task's FreeRTOS priority and core affinity at runtime, and exposes the same control (plus task start/stop) on espp::Interrupt, which owns and starts its handler task in its constructor.

espp::Task:

• bool set_priority(size_t priority) — stores the new priority (used on the next start()) and, if the task is running, applies it immediately via vTaskPrioritySet(). Clamps to configMAX_PRIORITIES - 1. Returns true if applied to the live task.
• bool set_core_id(int core_id) — stores the new core id (used on the next start()). On the default ESP-IDF FreeRTOS port a running task's core affinity is fixed at creation, so it is applied on the next start(); if the build provides the SMP vTaskCoreAffinitySet API (configUSE_CORE_AFFINITY on a multi-core SMP build) the change is applied live. Returns true if applied to the live task.

Both setters always persist the value for the next start regardless of the return value, and the return value honestly reports whether the change hit the already-running task.

espp::Interrupt:

• bool set_task_priority(size_t) / bool set_task_core_id(int) — forward to the underlying handler Task.
• bool start_task() / bool stop_task() — forward to Task::start() / Task::stop(). Since the handler task is created in the constructor, these let callers restart it so a new core id from set_task_core_id() takes effect. stop_task()'s docs note that ISRs keep enqueueing while the task is stopped, so events are serviced on restart (not dropped) until the queue fills.

Motivation and Context

The BSP components recently gained Kconfig options for their espp::Interrupt task priority / core id, but those are compile-time only and global. This was raised as a follow-up: provide a programmatic/API way to set these values. Because every BSP already exposes interrupts(), this change makes the interrupt task's priority and core configurable at runtime on all of them with no per-BSP changes, e.g.:

auto &irq = espp::Esp32P4FunctionEvBoard::get().interrupts();
irq.set_task_priority(18);   // applied live
irq.set_task_core_id(1);     // stored
irq.stop_task();
irq.start_task();            // re-created pinned to core 1

Kconfig remains the zero-config default; the new API is an optional runtime override on top of it.

How has this been tested?

• Environment: ESP-IDF v6.0.1, macOS host, target esp32s3.
• Built the interrupt example (compiles task.cpp + interrupt.hpp and exercises set_task_priority / set_task_core_id / stop_task / start_task) — clean build.
• Built the task example (exercises set_priority / set_core_id / stop / start, reading back get_priority() / get_core_id()) — clean build.
• Verified the asymmetry behaves as documented: priority changes apply to the live task; core-affinity changes apply on (re)start on the default IDF FreeRTOS port.
• Confirmed all 15 BSP components already expose interrupts(), so the new setters are reachable on every b

Screenshots (if appropriate, e.g. schematic, board, console logs, lab pictures):

Task example

[TaskExample/I][24.678]: Task priority / core affinity example
[Reconfig Task/D][24.688]: Starting task
[Reconfig Task/D][24.688]: Thread id: 0x0, current id: 0x3fc97f44
[Reconfig Task/D][24.698]: Task started
Task started on core 0 at priority 5
[Reconfig Task/D][24.708]: Set priority to 10 for task 'Reconfig Task'
set_priority(10) applied live: true, priority now 10
[Reconfig Task/D][24.718]: Set core id to 1 for task 'Reconfig Task'
[Reconfig Task/W][24.728]: Cannot change core affinity of running task 'Reconfig Task'; new core id (1) will take effect on next start()
[Reconfig Task/D][24.738]: Stopping task
[Reconfig Task/D][24.748]: Watchdog already stopped!
[Reconfig Task/D][24.758]: Thread id: 0x3fcead94, current id: 0x3fc97f44
[Reconfig Task/D][24.758]: Task stopped
[Reconfig Task/D][24.768]: Starting task
[Reconfig Task/D][24.778]: Thread id: 0x0, current id: 0x3fc97f44
[Reconfig Task/D][24.778]: Task started
After restart, task running on core 1
[Reconfig Task/D][25.298]: Destroying task
[Reconfig Task/D][25.298]: Stopping task
[Reconfig Task/D][25.298]: Watchdog already stopped!
[Reconfig Task/D][25.298]: Thread id: 0x3fcead94, current id: 0x3fc97f44
[Reconfig Task/D][25.308]: Task stopped
[Reconfig Task/D][25.318]: Thread id: 0x0, current id: 0x3fc97f44
[Reconfig Task/D][25.318]: Task destroyed

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update
• Hardware (schematic, board, system design) change
• Software change

Checklist:

• My change requires a change to the documentation.
• I have added / updated the documentation related to this change via either README or WIKI

Software

• I have added tests to cover my changes.
• I have updated the .github/workflows/build.yml file to add my new test to the automated cloud build
• All new and existing tests passed.
• My code follows the code style of this project.

[github-actions]

✅Static analysis result - no issues found! ✅