Is it safe to call these functions from inside an ISR? Instead of using semaphores or queues to save on memory, my application can make do with suspend and resume but after suspending i require that the task is resumed from inside an ISR. Can this be done? Also can passing NULL to vTaskSuspend  function called by another function suspend the main calling task. I am pretty sure this would work as i suppose that the ‘running’ task information would be taken from the scheduler.

Q1) Generally this would be a VERY bad idea, however what would actually happen depends on the port you are using.  Ports that use software interrupts for task switches might be ok provided the interrupt is cleared prior to suspending. Can you give an example of why you would want to do this?  Perhaps there is a different solution? Q2) Not sure what you are asking here.  Are you still meaning from within an ISR?  If so then I still think that using these functions from within an ISR would not be a good idea.  It was never intended and not tested.  Again what actually happens would depend on the port.  It could well work – but I cannot guarantee it.  If a task is interrupted, and the ISR calls vTaskSuspend(NULL) then the function call would try to suspend the task that was interrupted.  Another task would be chosen as the current task.  Then returning from the interrupt could start the new task. Regards.

Hmmm… Yup it is a bad idea indeed but was just a thought i had for saving some RAM. I would actually be more interested in knowing if i can safely use vTaskResume from an ISR as i can do vTaskSuspend from within the task code itself. The second question was not referring to an ISR but any normal function called within the Task code. I guess there should be no problem here. (?) I am using the AVR port.

If you look at the demo AVR serial port ISR [ SIGNAL( SIG_UART_RECV ) in serial.c if you are using the GCC port ] you will see that if receiving the character makes another task wake it calls taskYIELD() to ensure that the ISR returns to the highest priority task. Now if you look at the function vTaskResume() within tasks.c you will see that if the function being resumed has a higher priority than the current task a task switch is performed again by calling taskYIELD().  The mechanism is therefore the same so this to could well work from within an ISR.  The stack structures would be identical so should switch with no problem.  I say >should< because I don’t know :-) Give it a go and see but look out for requiring more stack space within the task as you are using more stack within the interrupting ISR.  Also ensure that the call to vTaskResume() is the very last call in the ISR and that the interrupt is cleared prior to it being called. Regards.

Thanks for the help. Actually here is why i am looking at this option. I have a task whose job starts with triggering the ADC start conversion process. The ADC driver itself is interrupt driven. Hence i would like to suspend the task until the ADC conversion is complete. After calling the start conversion function which returns immidiately, the task suspends itself. Then once the conversion complete interrupt is triggered, the ISR resumes this task. I could use semaphores here but a was held back considering the amount of memory being consumed to setup a semaphore. Any better ways of doing this?

Hi guys, Using vTaskResume for this is a nice idea as the example is similar to the serial port example quoted previously.  But beware.  The semaphore also provides sequencing.  If the task starts the conversion, but the ADC interrupt occurs before the task completes its suspend (maybe it was pre-empted so took a long time) then when it does suspend it will sleep forever as the interrupt has already occurred.

Oops! Ur absolutely right! I am still not thinking multithreading here! Still the good old fashioned guy. Thanks for pointing out. I think ill just stick to traditions for my first application. Will experiment later then.