FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [October 2013 Threads]
This might be a bit obscure and I might be jumping at shadows here.
I am running FreeRTOS 7.4.0 on an EFM32LGxxx (Cortex-M3 core). The OS ticks are implemented using the on-chip RTC and the system has my own tickless sleep mode implementation.
I have an ISR which is active during the tickless sleep, and this has a call to xTimerStartFromISR(). I am passing a valid memory address in for the second parameter - this seems to be essential to make sure that xQueueSendToBackFromISR() is called instead of xQueueSendToBack().
When entering tickless sleep, just before the call to portSUPPRESSTICKSAND_SLEEP() I see that vTaskSuspendAll() is called, and xTaskResumeAll() is called afterwards (from tasks.c). Looking at the documentation for vTaskSuspendAll(): "API functions that have the potential to cause a context switch (for example, vTaskDelayUntil(), xQueueSend(), etc.) must not be called while the scheduler is suspended."
Based on this, is it safe to call the xQueueSendToBackFromISR() / xTimerStartFromISR() functions? I gather that they will not cause a context switch, but I am just hoping to clarify this to make sure there are no problems!
this seems to be essential
Yes - you have to pass in a valid value in the pointer.
Based on this, is it safe to call the xQueueSendToBackFromISR() / xTimerStartFromISR()
functions?
I think this is fine. When the scheduler is suspended you cannot call a function from non-interrupt code that can cause the calling task to block. The reason being that a context switch cannot occur when the scheduler is suspended, so the task cannot block, and the program logic is therefore messed up. In your case you are calling the function from an ISR, so you don't have the scenario just described - you cannot block in an ISR anyway.
Regards.
Great, thanks very much for your quick answer Richard!
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.