[Feature Request] Hook function after xTaskResumeAll in IDLE task

[foldl]

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:

https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/bad8f01afd2554d6f673f4ea9ea7adb51cd9da33/tasks.c#L3537

#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.

[jefftenney]

Hi Judd,

Could the application developer use vApplicationIdleResumedHook() for something that vApplicationIdleHook() can't do? Looking at the idle task linearly, as proposed it would call vApplicationIdleResumedHook() and then almost immediately call vApplicationIdleHook().

[foldl]

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 of prvCheckTasksWaitingTermination() and taskYIELD. But the code and its logic are a little bit weird.

[jefftenney]

Typically, after waking from tickless idle, another task is ready to execute. In that case, xTaskResumeAll() typically causes a context switch to that task, before vApplicationIdleResumedHook() can execute. If that's OK, then maybe it's also OK to wait for vApplicationIdleHook(). 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 propose configPOST_SUPPRESS_TICKS_AND_SLEEP_PROCESSING to pair with the existing configPRE_SUPPRESS_TICKS_AND_SLEEP_PROCESSING. But it would come before the call to xTaskResumeAll(), not quite the same as what you're proposing here.

[foldl]

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]

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]

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.

• By visually, I means vApplicationIdleHook() is above xTaskSuspendAll();
• By actually, I means, for each round of the for loop, vApplicationIdleHook() is run before xTaskSuspendAll(). Use vApplicationIdleHook() in round n+1 to do post processing for wakup round n is strange.