vTaskDelay() from ISR ?

niekiran wrote on Friday, February 17, 2017:

What happens if we call vTaskDealy() from ISR ?
Does it has any effect ?

Thanks

tlafleur wrote on Friday, February 17, 2017:

ISR, need to be quick and in most cases, have minimal code as it stall all other activities on the CPU…

Adding ANY type of delays in an ISR just degrades total system performance and should be avoided at all costs.

~~ _/) _/) _/) ``` _/) ~~

Tom Lafleur

On Feb 17, 2017, at 4:59 AM, kiran nayak niekiran@users.sf.net wrote:

What happens if we call vTaskDealy() from ISR ?
Does it has any effect ?

Thanks

vTaskDelay() from ISR ?

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/freertos/discussion/382005/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

heinbali01 wrote on Friday, February 17, 2017:

Hi Kiran,

It is a custom not to create any delay from within an ISR. Often it is better to defer the handling of interrupt events to a normal task. A typical method is to call vTaskNotifyGiveFromISR() to wake-up a task from within an ISR.

Here is an example from a FreeRTOS+TCP driver:


/* The task is created and 'xEMACTaskHandle' contains a handle to that task. */
		xTaskCreate( prvEMACHandlerTask, "EMAC", configEMAC_TASK_STACK_SIZE, NULL, configMAX_PRIORITIES - 1, &xEMACTaskHandle );

/* The ISR for Ethernet: */
void ETH_IRQHandler(void)
{
portBASE_TYPE xHigherPriorityTaskWoken = pdFALSE;
uint32_t ulDMASR = ETH->DMASR;

	/* Frame received */
	if( ( ulDMASR & ETH_DMA_IT_R ) != 0 )
	{
		/* Remember the event. */
		ulISREvents |= EMAC_IF_RX_EVENT;
		/* Give the semaphore to wakeup prvEMACHandlerTask. */
		if( xEMACTaskHandle != NULL )
		{
			vTaskNotifyGiveFromISR( xEMACTaskHandle, &xHigherPriorityTaskWoken );
		}
	}


	/* Clear all interrupt flags. */
	ETH->DMASR = ulDMASR;

	/* Switch tasks if necessary. */	
	if( xHigherPriorityTaskWoken != pdFALSE )
	{
		portEND_SWITCHING_ISR( xHigherPriorityTaskWoken );
	}
}
/*-----------------------------------------------------------*/

/* The interrupt events are handle by a task called prvEMACHandlerTask() */

static void prvEMACHandlerTask( void *pvParameters )
{
	for( ;; )
	{
		/* No events to process now, wait for the next. */
		ulTaskNotifyTake( pdFALSE, ulMaxBlockTime );
		/* Handle the events. */
	}

Now if you call vTaskDelay() from within an interrupt the application gets into serious trouble :slight_smile:

Beside being non-interrupt proof, vTaskDelay() normally last very long, 1 ms or more.

What you can do ( but it’s not usual ), is to call some blocking udelay() functions.

rtel wrote on Friday, February 17, 2017:

What happens if we call vTaskDealy() from ISR ?

In addition to the other replies about never wanting to delay at all in
an ISR:

Only API functions that end in FromISR() can be called from an ISR.

vTaskDelay() places the calling task into the Blocked state for a fixed
period. This is possible because tasks are controlled by software,
namely the FreeRTOS scheduler. Interrupts on the other hand are
controlled completely by hardware, so there is no semantic sense in
calling vTaskDelay() from an ISR - first it is not a task, and second
the hardware is not going to change its behaviour whether you are
running an RTOS or not.