I am trying to handle an ISR in a task. To do so, I call vTaskNotifyGiveFromISR() to a task that is wait on ulTaskNotifyTake(). E.g. In the ISR,
~~~
/* Notification variable for Task */
BaseType_t xHigherPriorityTaskWoken = pdFALSE;
/* Set the Task to Highest Priority */
vTaskNotifyGiveFromISR( sLINTaskUART, &xHigherPriorityTaskWoken);
/* Force a scheduler call on exit */
if( xHigherPriorityTaskWoken == pdTRUE )
{
portYIELD_FROM_ISR();
}
~~~
in the Task
~~~
while(1)
{
/* Wait forever for Notification */
notified = ulTaskNotifyTake( pdTRUE,0xFFFFFFFF );
if( notified == 0 )
{
// We've been idle for a loooong time. Go back to waiting I guess...
continue;
}
/* Task do stuff */
}
~~~
I did some timing measurements and I found that there is about a 6 millisecond delay from the ISR to the task executing. I thought this could either be
1. Context switching just takes that long ( I don’t believe it does )
2. I wasn’t switching into the task right away (The handler task is the highest priority).
However, when I increased my configTICK
RATEHZ from 100Hz to 1kHz, the delay between the ISR went down dramatically…
I don’t understand. I have preemption enabled. Shouldn’t that mean that the task is entered immediately from the ISR in either case? If that’s true, then the Tick Rate shouldn’t impact the delay between the ISR and the task.
Can someone clarify for me? I’ve read “Mastering the FreeRTOS Real Time Kernel” but this behavior doesn’t seem to match the behavior there.
I am on an ESP32 and using the ESP-IDF’s version of FreeRTOS, but that shouldn’t change this behavior.