Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Hook function after xTaskResumeAll in IDLE task #349

Open
foldl opened this issue Jun 9, 2021 · 6 comments
Open

[Feature Request] Hook function after xTaskResumeAll in IDLE task #349

foldl opened this issue Jun 9, 2021 · 6 comments
Labels
enhancement New feature or request

Comments

@foldl
Copy link

foldl commented Jun 9, 2021

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:

( void ) xTaskResumeAll();

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

@foldl foldl added the enhancement New feature or request label Jun 9, 2021
@jefftenney
Copy link
Contributor

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
Copy link
Author

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

@jefftenney
Copy link
Contributor

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
Copy link
Author

foldl commented 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
Copy link
Contributor

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
Copy link
Author

foldl commented 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.

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

laroche pushed a commit to laroche/FreeRTOS-Kernel that referenced this issue Apr 18, 2024
* Break from potentially infinite loops in connection sharing demo

* Use QoS1 subscription for resilience against network disconnect

Co-authored-by: Oscar Michael Abrina <abrinao@amazon.com>
laroche pushed a commit to laroche/FreeRTOS-Kernel that referenced this issue Apr 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants