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

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

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;
}

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.

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.

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””

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?

i’ve just found out the documentation about apis and isr’s here:
/fr-content-src/uploads/2019/07/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.

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”

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.

…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.

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!