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

Thanks

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/

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", configEMACTASKSTACKSIZE, NULL, configMAXPRIORITIES - 1, &xEMACTaskHandle );

/* The ISR for Ethernet: */ void ETHIRQHandler(void) { portBASETYPE 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 :-)

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.

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.