Hello @Davide Dalfra
Azure RTOS ThreadX, which is the real-time operating system for AzureRTOS, has a similar concept but uses different APIs. In ThreadX, the equivalent functionality is achieved using a combination of tx_interrupt_control and tx_thread_resume or tx_event_flags_set depending on the situation.
Here's how you can signal that a thread should be resumed (or an event flag should be set) from an ISR in ThreadX:
- Resuming a Thread from an ISR: To resume a thread from an ISR, you would typically use tx_thread_resume However, you need to ensure that the ISR is at the correct priority level to call this API directly. If the ISR is at a priority level that is not allowed to call tx_thread_resume, you would need to defer the resume to a lower-priority interrupt or a system thread.
VOID my_isr(VOID)
{
// ... ISR code ...
// Resume the thread.
tx_thread_resume(&my_thread);
// ... ISR code ...
}
- Setting Event Flags from an ISR: If you're using event flags to communicate between tasks and ISRs, you can set these flags within an ISR using tx_event_flags_set
VOID my_isr(VOID)
{
// ... ISR code ...
// Set the event flag.
tx_event_flags_set(&my_event_flags_group, FLAGS_TO_SET, TX_OR);
// ... ISR code ...
}
-
Yielding from an ISR: If an ISR makes a higher-priority thread ready to run, ThreadX's scheduler will automatically perform a context switch to that thread when the ISR completes. There is no need to explicitly yield from the ISR as you would in FreeRTOS.
However, if you need to force a context switch from an ISR in a more controlled manner, you can use tx_thread_system_resume or tx_thread_system_suspend to manage thread readiness and the scheduler will take care of the context switch.
Remember that in ThreadX, the system is designed to be preemptive, and the scheduler will automatically yield to the highest-priority ready thread after an ISR completes, assuming that the ISR code has made a higher-priority thread ready to run.
