Repository navigation
[Feature Request] Hook function after xTaskResumeAll in IDLE task #349
Description
Is your feature request related to a problem? Please describe.
On ARM Cortex-M SoC (not sure for other systems),
for tickless idle feature, developers can define generally one hook and three functions:
- vApplicationIdleHook
- PreSuppressTicksAndSleepProcessing
- PreSleepProcessing
- PostSleepProcessing
In PostSleepProcessing, the whole system continues its processing, and some OS APIs are quite likely to be called here. But, at this moment, OS is suspended, only a small portion of
APIs are allowed.
Describe the solution you'd like
Suggest to add a hook after xTaskResumeAll() in prvIdleTask:
Line 3537 in bad8f01
#if ( configUSE_IDLE_RESUMED_HOOK == 1 )
{
extern void vApplicationIdleResumedHook( void );
/* Call the user defined function from within the idle task. This
allows the application designer to add background functionality
without the overhead of a separate task.
*/
vApplicationIdleResumedHook();
}
#endif /* configUSE_IDLE_RESUMED_HOOK */Describe alternatives you've considered
Use xSemaphoreGiveFromISR in PostSleepProcessing to notify a another task.
This is not convenient.
Activity
jefftenney commentedon Jun 10, 2021
Hi Judd,
Could the application developer use
vApplicationIdleResumedHook()for something thatvApplicationIdleHook()can't do? Looking at the idle task linearly, as proposed it would callvApplicationIdleResumedHook()and then almost immediately callvApplicationIdleHook().foldl commentedon Jun 11, 2021
Hi Jeff,
In my case,
vApplicationIdleResumedHook()is be used to do extra post processing after waking up from tickless idle, where most of the FreeRTOS APIs can be called.The idea is to split
PostSleepProcessing()into two parts, one is called when OS is suspended; the other (i.e.vApplicationIdleResumedHook()) is called immediately after OS is resumed.It's possible to move the post processing to
vApplicationIdleHook()if ignoring the impact ofprvCheckTasksWaitingTermination()andtaskYIELD. But the code and its logic are a little bit weird.jefftenney commentedon Jun 11, 2021
Typically, after waking from tickless idle, another task is ready to execute. In that case,
xTaskResumeAll()typically causes a context switch to that task, beforevApplicationIdleResumedHook()can execute. If that's OK, then maybe it's also OK to wait forvApplicationIdleHook(). If that's not OK, then maybe a different solution is needed.Can you give an example of what might be done in
vApplicationIdleResumedHook()? I'm curious because I've been meaning to proposeconfigPOST_SUPPRESS_TICKS_AND_SLEEP_PROCESSINGto pair with the existingconfigPRE_SUPPRESS_TICKS_AND_SLEEP_PROCESSING. But it would come before the call toxTaskResumeAll(), not quite the same as what you're proposing here.foldl commentedon Jun 11, 2021
Let's consider a TDD communication system, which requires accurate timing control.
Assume that radio operation is started by hardware timer running at tens of mega hertz.
Then, the expected sleep duration is updated according the next radio activity.
When wakeup, typically only radio activity is started, and after
xTaskResumeAll()there is no context switch. Looking in to the operations of "start radio", besides starting the hardware, some OS APIs are also needed. (Oh, these APIs calls may cause context switch after
xTaskResumeAll(), but they are likely not allowed to be called at all.)vApplicationIdleResumedHook()can hold the code that calls OS APS.jefftenney commentedon Jun 11, 2021
In the case you describe, where only the idle task is ready to execute upon wakeup, and if the idle task is where you want to put this work, then the existing idle hook seems to be the best fit. If you still want to propose this new feature, you can leave the feature request active so over time others from the community can comment or perhaps somebody from FreeRTOS.
foldl commentedon Jun 11, 2021
It's possible to use the existing idle hook, but not the the best solution in my opinion: post processing after OS resumed is called before suspending both visually and actually.
vApplicationIdleHook()is abovexTaskSuspendAll();forloop,vApplicationIdleHook()is run beforexTaskSuspendAll(). UsevApplicationIdleHook()in roundn+1to do post processing for wakup roundnis strange.Add macro to break from potential infinite loops (FreeRTOS#349)
Fix incorrect operator from FreeRTOS#349 (FreeRTOS#352)