is the function"eTaskGetStateFromISR"exist?

rtel wrote on Sunday, October 12, 2008:

Which architecture have you ported to?

yukunduan wrote on Friday, August 21, 2015:

oh no,when i saw the function “vTaskDelete(task1),xTaskCreate(task1)”,they all have the assert “configASSERT( ( portNVIC_INT_CTRL_REG & portVECTACTIVE_MASK ) == 0 );” so ,is it impossible to execute according to my thought?

yukunduan wrote on Friday, August 21, 2015:

well,now ,I think i have two solutions:
1.I set a global variable to receive the TIM interrupt times,and create a task that check the state of the task.
like this:
xTaskCreate(task_check_functioin…)
void TIM interrupt(void)// 0.1 second
{
giv_time_count++;
}
void task_check_functioin()
{
check according giv_time_count;
if(eTaskGetState(task1_hadle) == eSuspended) {
if( //check 100 times ) {
vTaskDelete(task1)
xTaskCreate(task1)
}
}
}
2.using Blocked state.I saw function like xQueueSendToBack or xSemaphoreTake. I can set number of timeout .
when the interrupt occur ,release the semaphore.otherwise, timeout i will restart this task;
like this:
xSemaphore = xSemaphoreCreateBinary();
void DMA interrupt(void)// dma receive over
{
xSemaphoreGiveFromISR( xSemaphore, &xHigherPriorityTaskWoken );
}
void task()
{
xSemaphoreTake( xSemaphore, portMAX_DELAY );
}

richard_damon wrote on Friday, August 21, 2015:

Normally suspending/resuming a task like this is really the wrong thing to be doing. If the task wants to wait for a DMA interrupt then wait for a semaphore that is set by that interrupt. That way you can add a timeout on the wait and the task can handle its own cleanup. (You can also use the task notification system as a lightweight version of this).

Also killing and restarting a task is a good way to mess up your program enviroment. Maybe you know that task doesn’t hold any resources in this case, but in general it can be very bad. On “Big” OSes, you can kill a PROCESS and restart it, as the OS knows what resources a process owns and can clean those up. Tasks are much more light weight.

rtel wrote on Friday, August 21, 2015:

Just to re-iterate and emphasise Richard Damon’s point - using task suspend/resume as a synchronisation method in this way is dangerous and can lead to missed interrupts if there is a chance an interrupt arrived before the task has suspended. Suspending and resuming had no method of latching that an interrupt occured. I would also second the suggestion that the correct way to do this is with a semahore, because a semaphore does latch that an interrupt has occurred - better still use a direct to task notification as that is faster and has no RAM overhead.

Regards.