FreeRTOS – LPC2148 Counting Semaphore

In our previous tutorials we have seen How to use the Binary semaphore with ISR and without ISR. Today we will see the FreeRTOS Counting Semaphore Tutorial in LPC2148. Lets start.

Suggest To Read

FreeRTOS Counting Semaphore Tutorial in LPC2148


Before we starting this tutorial we should know about the semaphore. If you go through the RTOS Basics two parts you can go ahead.For others I will give you the small introduction about semaphore.


A semaphore (sometimes called a semaphore token) is a kernel object that one or more threads of execution can acquire or release for the purposes of synchronization or mutual exclusion. This is useful for when two or more task accessing same resource. A binary semaphore used for synchronization does not need to be ‘given’ back after it has been successfully ‘taken’ (obtained).

A kernel can support many different types of semaphores, including

  • binary,
  • counting, and
  • mutual‐exclusion (mutex) semaphores.

Binary Semaphore

  • Similar to mutex
  • Can have a value 1  or  0
  • Whenever a task asks for semaphore, the OS checks if the semaphore’s value is 1
  • If so, the call succeeds and the value is set to 0
  • Else, the task is blocked

Binary semaphores are treated as global resources,

  • They are shared among all tasks that need them.
  • Making the semaphore a global resource allows any task to release it, even if the task did not initially acquire it?

Counting Semaphores

  • Semaphores with an initial value greater than 1
  • Can give multiple tasks simultaneous access to a shared resource, unlike a mutex
  • Priority inheritance, therefore, cannot be implemented

Whenever we are giving semaphore from any task, then the semaphore count increase upto the maximum number that we have generated.

Applications of Counting Semaphore

Counting semaphores are typically used for two things:

  1. Counting events.
  2. Resource management.

Counting events

In this usage scenario, an event handler will ‘give’ the semaphore each time an event occurs, and a handler task will ‘take’ the semaphore each time it processes an event.
The semaphore’s count value will be incremented each time it is ‘given’ and decremented each time it is ‘taken’. The count value is therefore the difference between the number of events that have occurred and the number of events that have been processed. Semaphores created to count events should be created with an initial count value of zero, because no events will have been counted prior to the semaphore being created.

Resource management

In this usage scenario, the count value of the semaphore represents the number of resources that are available.
To obtain control of a resource, a task must first successfully ‘take’ the semaphore. The action of ‘taking’ the semaphore will decrement the semaphore’s count value. When the count value reaches zero, no more resources are available, and further attempts to ‘take’ the semaphore will fail.
When a task finishes with a resource, it must ‘give’ the semaphore. The action of ‘giving’ the semaphore will increment the semaphore’s count value, indicating that a resource is available, and allowing future attempts to ‘take’ the semaphore to be successful.
Semaphores created to manage resources should be created with an initial count value equal to the number of resource that are available.

APIs Used

  • xSemaphoreCreateCounting()
  • uxSemaphoreGetCount()
  • xSemaphoreGive ()
  • xSemaphoreTake()

Here we have already know the last two APIs. Because we were already discussed in our previous tutorials.


Creates a counting semaphore, and returns a handle by which the semaphore can be
referenced. Each counting semaphore requires a small amount of RAM that is used to hold the semaphore’s state. If a counting semaphore is created using xSemaphoreCreateCounting() then the required RAM is automatically allocated from the FreeRTOS heap. If a counting semaphore is created using xSemaphoreCreateCountingStatic() then the RAM is provided by the application writer, which requires an additional parameter, but allows the RAM to be statically allocated at compile time.

#include “FreeRTOS.h”
#include “semphr.h”

SemaphoreHandle_t xSemaphoreCreateCounting( UBaseType_t uxMaxCount,
                                      UBaseType_t uxInitialCount );

To use Counting Semaphore you should add below line in the FreeRTOSConfig.h



  • uxMaxCount The maximum count value that can be reached. When the semaphore reaches this value it can no longer be ‘given’.
  • uxInitialCount The count value assigned to the semaphore when it is created.


  • NULL Returned if the semaphore cannot be created because there is insufficient
    heap memory available for FreeRTOS to allocate the semaphore data structures.
  • Any other value The semaphore was created successfully. The returned value is a handle by which the created semaphore can be referenced.


This function Returns the count of a semaphore.
Binary semaphores can only have a count of zero or one. Counting semaphores can have a count between zero and the maximum count specified when the counting semaphore was created.

#include “FreeRTOS.h”
#include “semphr.h”

UBaseType_t uxSemaphoreGetCount( SemaphoreHandle_t xSemaphore );


  • xSemaphore : The handle of the semaphore being queried.


The count of the semaphore referenced by the handle passed in the xSemaphore parameter.


In this code i’ve created two tasks and Counting Semaphore with the value of 3. So two tasks are waiting for the semaphore. Once interrupt occurred, task 2 will take that semaphore and prints. But task 1 is still waiting. So next occurrence of interrupt, task 1 takes the semaphore and prints. Here i’m adding only the main file. If you want to download the full project, please visit here (GitHub).


[Download This Project]

0 0 vote
Article Rating
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Newest Most Voted
Inline Feedbacks
View all comments
Saikiran Muppidi
Saikiran Muppidi
January 8, 2019 12:30 AM

Nice explanation
I need clarification regarding how Task1, Task2 switching alternatively I think portMAX_DELAY(semaphore wait period) is reason for that am I correct?

Reply to  Saikiran Muppidi
November 24, 2019 12:57 PM

Yes you are correct. When you use portMAX_Delay, it put that tasks into sleep for the mentioned time.

Would love your thoughts, please comment.x
%d bloggers like this: