Hi! I have issue where semaphore behaves likea mutex
after creating: vSemaphoreCreateBinary(xSemaphoreTest); i have to call immidiatelly: xSemaphoreTake(xSemaphoreTest, 0); to make next, real ‘Take’, to work  and wait for ‘give’. Is it possible? In program i am not givving semaphore for sure. That semaphore is given in interrupt, and that interrupt is turned on after creating this dummy ‘Take’ . If semaphore would be given by accident in interrupt, then my workaround shouldnt work before turning on of that interrupt. This dummy ‘take’ is call just after create, if so, my app works.
So…. after code: vSemaphoreCreateBinary(xSemaphoreTest);
xSemaphoreTake(xSemaphoreTest, 0);
My app works, without that ‘take’ above, it doesnt :( It seems that it works like a Mutex and it is given after creating?

You can see the vSemphoreCreateBinary() code in semphr.h. Mutexes are created to contain the mutex, so the first call to take the mutex succeeds, which is what you want when the presense of a mutex indicates the the resource it is protecting is available. Binary semaphores are create so the semphore is not available, so the first call to tkae fails. This means the task that creates the semaphore can immediately then block on the seamphore to wait for an event. If the semaphore is used to signal an event, then the event will not have happened when the semaphore is created.

thanx davedoors :) i know what it is semaphore and mutex.
So… explain then, why calling ‘take’ of the semaphore makes my app working and not calling that dummy ‘take’ just after creating makes my app synchronization failed? Let me mention that this creation of semaphore and followed empty ‘take’ is called only once, after POR, it is not called ever after in application.
Do you think that after creation of semaphore something is giving it? Be sure that not, nothing is giving because nothing has that possibility, no task, no interrupt, nothing. to be sure i did all interrupts disable betweeb ‘create’ and empty ‘take’:

asm("di");
    vSemaphoreCreateBinary(xSemaphoreI2C_1);
    if(xSemaphoreI2C_1==NULL)
    {
        for(;;);
    }   
    xSemaphoreTake(xSemaphoreI2C_1, 0);
asm("ei");

and with ‘take’ my app works, without it my app fail synchronisation

Hmmm…
I have looked into semphr.h and saw:

#define vSemaphoreCreateBinary( xSemaphore )                                                                                                    
    {                                                                                                                                           
        ( xSemaphore ) = xQueueGenericCreate( ( unsigned portBASE_TYPE ) 1, semSEMAPHORE_QUEUE_ITEM_LENGTH, queueQUEUE_TYPE_BINARY_SEMAPHORE ); 
        if( ( xSemaphore ) != NULL )                                                                                                            
        {                                                                                                                                       
            xSemaphoreGive( ( xSemaphore ) );                                                                                                   
        }                                                                                                                                       
    }

hmmm… what is it :
xSemaphoreGive( ( xSemaphore ) ); ???

hmmm… what is it :
xSemaphoreGive( ( xSemaphore ) ); ???

It is a standard FreeROTS semaphore function, that is documented in the API reference on the web site. Regards.

Hi! My question was about what it is doing there? Is semaphore after create ‘given’??? I thought that after create calling ‘take’ of semaphore will fail, but, if you read whole thread, is done like a mutex do. Am i wrong or dont understand semaphores? Semaphore first must be ‘taken’ or ‘given’ after creation?

I mean: semaphore is initially ‘given’ ??

That is correct.  Despite previous comments, when the queue that implements the semaphore is created, the queue is empty, so to ensure that when vSemaphoreCreateBinary() exits (when the macro has completed to be more accurate) the semaphore actually exists, xSemaphoreGive() is called to place an item (the semaphore) into the queue. Regards.

hmmm… i think that confuses a little, because i was sure that after create of semaphore, when i call ‘take’ i will be waiting for my ‘give’  but here… surprise :) semaphore is ‘given’ :) just like mutex doeas. Dont you think that queue has to be empty after creation of semaphore? i mean, semaphore must not be given.

I don’t think there is a right or wrong way of doing it.  Some applications want it created “empty” and others want it created “full”.  It cannot be both. If you want it to be created empty then call create the semaphore, then immediately take it.  You can take it with a block time of 0 as you know the semaphore will be there – it was just created.  In that case, the code manually sets it to the state it wants it to be in.  In the other case, where the code wants it to be available on creation, it does not have to manually do anything, just create it. Regards.

Ok, but manual says nothing about it :( and i was thinking that semaphore initialy was empty and thats why my app couldt synchronize becasue my first use of semaphore was ‘take’. I can say more: in examples in manual, i am talking about pictures clearifying using of semaphores, suggesting very clearly that semaphore is initially empty:

And last one for the end :) you shouldupdate API with information that semaphore is given initially after semaphore was created. As i can see, lots of people think as me, e.g. first answer on my post by davedoors:

…
Binary semaphores are create so the semphore is not available, so the first call to tkae fails.
…

I take your point that maybe the API documentation should say this, I’m not sure if the tutorial book does or doesn’t without checking.  However, the animated image you have linked to does not give the impression one way or the other as it shows nothing about the initial state. Regards.

:) yeah it is academic discussion:) if semaphore is created to synchronise soem tasks, interrupt or whatever, then ‘take’ should wait for ‘give’: ‘i can do it if i wait for the permission to do it from somewhere’ but it turns out that i have permission and nobody gave me that:)
and back to the linked picture: i understand it that the task, in that picture, is waiting for permission from interrupt  to do something… then… initially i have no permission (no semaphore) because that permission/semaphore is given only from that interrupt, isnt it? semaphore, in that example, holds task in waiting till interrupt give semaphore for that task, for me it is simple that task can not run antil it takes semaphore from interrupt not from creation procedure.
But it is only my point of view and how i understand semaphores: something should give it to something other could take it. Another way of understanding for me is mutex that indicate that something is free to use and i can ‘take’ it for me and block using it for others, and it is why mutexes are ‘given’ initially. But in generally, in both situations, i think that the resource  initiating procedure has to decide if it is free to use or not, i mean: if i create semaphore/mutex for some resource sharing or process synchronisation, then its initialization procedure should ‘give’ it to say it is free to use or not. Now i understand your point, that i have to do opposite: i have to at initialisation say that resource is not given yet. Anyway…. FreeRTOS is just great:)