How to taskYIELD() a specific task ?

nobody wrote on Monday, April 10, 2006:

Is there any function similar to taskYIELD() that allow for scheduling a precise task ?

I am running multiple tasks, one beeing for polling the serial port and another beeing for sending data on it. I am having a serial_busy boolean flag that mention if some operation is going on already, to avoid messing with the serial port interruptions. However, testing that flag does not allow me to give  the hand back to the task that is supposed to have the control (I can only taskYIELD(), which will often give back control to the current task).

Any suggestion ?


-jfv (

nobody wrote on Tuesday, April 11, 2006:

Not sure I follow your logic here.  It sounds like you want to change the prioritisation of your tasks to achieve what you want.  Maybe you want to dynamically change the priorities to force one task to execute over another?

nobody wrote on Tuesday, April 11, 2006:

That is what Im doing right now, but it still does not acheive what I wanna do.

I have 2 threads TS and TR, respectively for sending and receiving data from the serial port. Moreover I have a flag that tells if the serial port is used at the moment, so that if the sending task or the receiving task loses hands in the middle of an operation, I am not messing with multiple interruptions on the serial port at a time (that leads to exceptions generally).

If my flag ‘serial_busy’ test flag is true and the serial_send task is running, then I have to switch to the serial_recv task, and the other way, if this flag is true and I am into the serial_recv task, then I need to switch to the serial_send task so that I dont lose too much cycles doing something irrelevant, instead of directly go to the task that needs to be executed.

It could simply be done having a taskYIELD() function which takes a parameter beeing the task handle that needs to be scheduled, unfortunately there is no such function in FreeRTOS (or I did not find it after looking a lot at the source code). I could do it using some assembly code but I dont know if this would implies big behavioral changes of the scheduler.

Anyone else has a suggestion on how to resolve this ?


-jfv <>

imajeff wrote on Tuesday, April 11, 2006:

Well everything about the task manager is to determine which task runs next, but maybe look into semaphores (or queues). The idea is that when one task tries to take a semaphore, it simply waits until another task which is running gives the semaphore.  Hence, one runs first, then tells the other to start running.