why freertos use mostly static variables?

Kernel
1

blackflowers wrote on Friday, July 22, 2011:

why does freertos define most of its members as statics, as for example, tasks, semaphores etc.?

2

edwards3 wrote on Saturday, July 23, 2011:

That is normal good software engineering practice. Global variables are not a good thing, making them static ensures they are not global.

3

blackflowers wrote on Saturday, July 23, 2011:

But i have a problem because i need to use a semaphore in two different modules.

I have this in the main.c:

static xSemaphoreHandle xSemaphore;
xSemaphore = xSemaphoreCreateMutex();
if(xSemaphoreTake( xSemaphore, ( portTickType ) 1)==pdTRUE)   
			{
				//here is some code
				xSemaphoreGive( xSemaphore );
			}

and i need to use the same semaphore in this module, the same way,  in order to protect a global variable shared by both modules. (i know it should’t be used): port.c, on the timer2 interrupt function

void __attribute__((__interrupt__, auto_psv)) _T2Interrupt( void )
{	
IFS0bits.T2IF = 0;
if(xSemaphoreTake( xSemaphore, ( portTickType ) 1)==pdTRUE)   
			{
				//here is some code
				xSemaphoreGive( xSemaphore );
			}
PR2 = 0x1cca;
}
4

rtel wrote on Saturday, July 23, 2011:

I’m not sure I understand your question.  You asked why FreeRTOS uses static members, and received a reasonable reply.  However, the code you have posted is your own code, not FreeRTOS code.  You can write your own code however you want.

To use the same semaphore in two files you could make the semaphore declaration static, the provide a ‘get’ function for the other file to receive a reference to it - but that would seem overkill.  It would be better just to make it global.

A comment on the code you posted though.  It is breaking two very fundamental rules.  First, it is calling a FreeRTOS API function that does not end in “FromISR” from an ISR.  Second, the API function has a block time specified.  You cannot block in an interrupt!

Regards.

5

blackflowers wrote on Sunday, July 24, 2011:

ok, i got it working using global variables. Now it’s time to do it right, so i’m reading about sofware timer, and another basic freertos stuff. So i’ll keep on with this thread in order to get my application running freertos correctly.

6

blackflowers wrote on Sunday, July 24, 2011:

by the way, where can i find documentation about those “fundamental rules”? I mean, i couldn’t find any information about what you have said, about ““calling a FreeRTOS API function that does not end in “FromISR” from an ISR””

7

blackflowers wrote on Sunday, July 24, 2011:

besides, if i can’t use a semaphore into an interrupt (because it has a block time specified)… then how can i protect the global variable from being changed in the main() and in the interrupt()  simultaneously?

8

blackflowers wrote on Sunday, July 24, 2011:

i’ve just found out the documentation about apis and isr’s here:
http://www.freertos.org/index.html?http://www.freertos.org/a00110.html#kernel_priority

and there’s a “xSemaphoreGiveFromIsr” function indeed, but i couldn’t find “xSemaphoreTakeFromIsr” function anywhere.

9

richard_damon wrote on Sunday, July 24, 2011:

If you need to protect a variable used in both tasks and interrupts, you need to use a critical section (which basically disables interrupts). Because of how they work, they need to be kept short. The other option is to move the code in the interrupt that needs to access the variable into a high priority task, and have it waiting on a semaphore/queue from the interrupt.

As to where the rule on API usage in interrupts, it is at http://www.freertos.org/api.html, in the paragraph marked “API Usage”

10

rtel wrote on Monday, July 25, 2011:

http://www.freertos.org/api.html

Gosh - I didn’t realise that page was still live.  It is a little out of date as it refers to the FreeRTOS V5 API.  Some maintenance work required on my part!

Regards.

11

rtel wrote on Monday, July 25, 2011:

…if you look at the reference for the API function (macro) xSemaphoreTake() http://www.freertos.org/a00122.html it does states:  “This macro must not be called from an ISR. xQueueReceiveFromISR() can be used to take a semaphore from within an interrupt if required, although this would not be a normal operation . Semaphores use queues as their underlying mechanism, so functions are to some extent interoperable.”

There are other references too, for example, item 3 here: http://www.freertos.org/FAQHelp.html

Regards.

12

blackflowers wrote on Monday, July 25, 2011:

i finally did it using the task sincronized with the interrupt routine,  by a semaphore. I suppose this is the right way to do it, since with critical regions i give priority to the main program instead of the interrupt routine, and this is not what i needed.

Thanks!