- Use xQueuePeek with no wait.
- See if I can do a take (no wait) on the semaphore. If I can give it back.
Calling xQueuePeek in vApplicationIdleHook stopped schedulre
Hi,
I wanted to use a counting semaphore to manage low power so that when all relevant client tasks had ‘checked in’ I would go into a deep sleep in the ApplicationHook instead of a normal sleep. (Cortex M3 port of 7.3.0).
I tried two ways while in the ApplicationHook (idle task) to check if the counting semaphore was non-zero.
Calling xQueuePeek in vApplicationIdleHook stopped schedulre
Do you have stack overflow checking enabled? It might be you are overflowing the idle task stack. The idle task stack size is set by configMINIMALSTACKSIZE.
Why not use the built in low power functionality?
http://www.freertos.org/low-power-tickless-rtos.html
http://www.freertos.org/low-power-ARM-cortex-rtos.html
Calling xQueuePeek in vApplicationIdleHook stopped schedulre
Thanks for the reply Dave. Yes I do have stack overflow check on, nevertheless, it is worth adjusting the minimal stack size to see. But that might not solve my problem…
Why not use build in low power? As far as I see there are two very good low power strategies for cortex:
- Use a timer other than systick for the rtos tick. This allows the idle hook to drop into a very low power mode where peripheral clocks and system clocks (including the one that drives Systick) are off. (I am using this strategy with a twist – more below)
- Tickless Idle. This is the ‘icing on the cake’. I don’t think I need to go this far. I can live with the short wakeup on every sys tick given the short time it takes the sheduler to determine that no tasks are on the ready list and therefore that it will go back to sleep.
Calling xQueuePeek in vApplicationIdleHook stopped schedulre
In the tickless idle mode you can use the pre sleep hook function to abort the low power entry if a comms operation is in progress.
Calling xQueuePeek in vApplicationIdleHook stopped schedulre
Nice proposal, one issue though. I see that in the tickless idle, where PRE and POST sleep are called (on either side of the key WFI call) that interrupts are disabled using CPSID.
Does this mean that if a tick happens between the CPSID and CPSIE that it will be missed?
But the system will wake because at an outer, microcontroller layer, the interrupt has actually triggered the wakeup logic. The handling is turned off only at the core. So, once sleep happens, i.e. WFI, then there is a low power period, now a tick happens but the tick counter is not incremented. Am I right?
But since we are woken, when will the scheduler next run? I.e when will other tasks be considered again for execution?
My original problem, described in my previous post, was that the IDLE task could be interrupted by the systick, the scheduler might run, causing a syncronisation problem with my flags.
The key difference here in the tickless implementation is the turning off of the interrupts at the core thus preventing any other task being rescheduled. I am trying to assess if that is going to work for me. Perhaps I could manually use this strategy in my ordinary old ‘tickful’ idle.