Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

Multi Task and Functions...problem?

Posted by Michael on 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(;;)
{

rprintf("Send text to uart 1 \n ");

}


}
but If is another task...
void xTaskTwo(void* param)
{
for(;;)
{

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(;;)
{
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...

RE: Multi Task and Functions...problem?

Posted by Artur on 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,

RE: Multi Task and Functions...problem?

Posted by Nick Reed on 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

RE: Multi Task and Functions...problem?

Posted by Richard on 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.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS