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] [November 2012 Threads] Message processing timePosted by Richard on November 12, 2012 If I post a message from an ISR does that message get immediately processed by the RTOS and acted upon or does it only get acted upon at the next RTOS tick?
RE: Message processing timePosted by Richard Damon on November 12, 2012 If the ISR activates the scheduler (The method is port specific) then a task waiting on the queue/semaphore the ISR acted on (if it is now the highest priority ready task) will be activated, otherwise it will need to wait for the next time the scheduler is activated, which should be no later than the next tick (assuming it becomes the highest priority waiting task).
RE: Message processing timePosted by Richard on November 12, 2012 If you call a function from an interrupt that causes a task to unblock, and the task that unblocks has a priority above or equal to the currently running task, then the interrupt will return directly to the unblocked task if you tell it to. Here is a generic example. Note this uses a macro call portEND_SWITCHING_ISR(). In some ports this is called portYIELD_FROM_ISR(), which does the same thing. void Dummy_IRQHandler(void) { long lHigherPriorityTaskWoken = pdFALSE;
/* Clear the interrupt if necessary. */ Dummy_ClearITPendingBit(); /* This interrupt does nothing more than demonstrate how to synchronise a task with an interrupt. A semaphore is used for this purpose. Note lHigherPriorityTaskWoken is initialised to zero. */ xSemaphoreGiveFromISR( xTestSemaphore, &lHigherPriorityTaskWoken ); /* If there was a task that was blocked on the semaphore, and giving the semaphore caused the task to unblock, and the unblocked task has a priority higher than the current Running state task (the task that this interrupt interrupted), then lHigherPriorityTaskWoken will have been set to pdTRUE internally within xSemaphoreGiveFromISR(). Passing pdTRUE into the portEND_SWITCHING_ISR() macro will result in a context switch being pended to ensure this interrupt returns directly to the unblocked, higher priority, task. Passing pdFALSE into portEND_SWITCHING_ISR() has no effect. */ portEND_SWITCHING_ISR( lHigherPriorityTaskWoken ); } Regards.
RE: Message processing timePosted by Richard on November 12, 2012 Awesome - this is the first time I've needed to use the HigherPriorityTaskWoken flag and had forgotten about this behavior - that's most likely our issue.
If most of our tasks are at the same priority, then will returning TRUE cause a task of the same priority level (assuming it is running) to be immediately preempted?
Many thanks Richard. Regards travfrog
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|