Multi Task and Functions...problem?

gotrunks86 wrote on Sunday, November 16, 2008:

Hello!

I have a little problem with functions which wokrs in more than one task.
Example :

If I use only this task it works perfectly.
void xTaskOne(void* param)
{
       for(;:wink:
       {
        
         rprintf("Send text to uart  1 \n ");

        }

}
but If is another task…
void xTaskTwo(void* param)
{
       for(;:wink:
       {
        
         rprintf("Send text to uart 2 \n ");

        }

}
Functions rprintf works strange but I know why ( that because scheduler works… ) and I want to block Task by Semaphores/Mutex
void xTask(void* param)
{
       for(;:wink:
       {
          if(xSemaphoreTake(xSemaphore,150 )==pdPASS)
          rprintf("Send text to uart \n ");
           xSemaphoreGive(xSemaphore )
        }

}
but this don’t work… System freezing. What should I do to make use functions in many Task???

I’m sorry for my english…

artlip wrote on Monday, November 17, 2008:

Who "give" semaphore before you try to "take" it?

In your case you try manage access to the resource and it can be convenient to create separate "driver" to do that. This can allow you to use (in tasks) simple driver function to e.g. print something without worrying about mechanism used to synchronize access to resource.

Regards,

nickreed wrote on Monday, November 17, 2008:

Mayby try only giving the semaphore back if you could take it first:

if(xSemaphoreTake(xSemaphore,150 )==pdPASS)
{
  rprintf("Send text to uart \n ");
  xSemaphoreGive(xSemaphore );
}

-----
Nick

rtel wrote on Monday, November 17, 2008:

If your rprintf() function does all the buffering you need then one simple solution is to use a critical section.  Each time you want to printf wrap the call to rprintf() in taskENTER_CRITICAL()/taskEXIT_CRITICAL().

taskENTER_CRITICAL();
rprintf( "Send the message here\n" );
taskEXIT_CRITICAL();

You could wrap this up in a function to prevent you having to write it out in full each time you print.

Critical sections are not a good solution where they would adversely effect the responsiveness of your system though.

Another solution is to write the driver so that you queue messages yourself.  If you want to write out a string you queue a pointer to the string.  The driver just reads out the strings from the queue in turn.  The driver (which could be an interrupt or a task) is then the only thing that is allowed to access the UART directly so serialisation and mutual exclusion are guaranteed.

Regards.