You are not logged in

Log in into our community

Log in so you acess some hidden content

* Fields are required.

Register into our community!

Sign up now for some good content

* Fields are required.

Lost something?

Enter your username or email to reset your password.

* Fields are required.

FREE RTOS task states

Posted on : Wed , 07 2014 by : virusi

Theory on FREE RTOS task states :

Today let’s take a look at all of the states in which a task can be.

Fig.1 task states.

As you can the task can be in 2 super states (running and ready). In the running state the task is active and running but in the blocking state the task is waiting to go into the running state. Only one task can be in running state. When the task is created it is in blocking super state and more exactly in the ready sub state.

Ready sub state of the not running super state :

Tasks that are in the Not Running but are not Blocked or Suspended are said to be in the Ready state. They are able to run, and therefore ‘ready’ to run, but not currently in the Running state.

Suspended sub state of the not running super state :

Tasks in the Suspended state are not available to the scheduler. The only way into the Suspended state is through a call to the vTaskSuspend() API function, and the only way out through a call to the vTaskResume() or xTaskResumeFromISR() API functions. Most applications don’t use the Suspended state.

Blocked sub state of the not running super state :

Tasks can enter the Blocked state to wait for two different types of event :

1. Temporal (time related) events – the event being either a delay period expiring or an absolute time being reached. For example a task may enter the Blocked state to wait for 10 milliseconds to pass.

2. Synchronization events – where the events originate from another task or interrupt. For example, a task may enter the Blocked state to wait for data to arrive on a queue. Synchronization events cover a broad range of event types.

It is possible for a task to block on a synchronization event with a timeout, effectively blocking on both types of event simultaneously. For example, a task may choose to wait for a maximum of 10 milliseconds for data to arrive on a queue. The task will leave the Blocked state if either data arrives within 10 milliseconds, or 10 milliseconds pass with no data arriving.
Now let’s take a look at an example and create 2 tasks with the same priority and check the task sequences.

LPC1768 Practical Example :

Schematic :

Fig.2 Schematic of LPC1768 with Led connection.

Step by step software tutorial :

In this example will configure and create a task that will be called at every 10ms using FreeRtos kernel.

1. Download the source code from Free Rtos code example

Fig.3 Download link.

2. Create a new uVision project

In our projects we are uVision to compile and build our soft and we have decided to make a tutorial on how to create and compile a new project using uVision. Let’s begin.

1. We need to create our skeleton of our project. Create our core folder where everything will be kept (In our case it is project). After this we should create 3 folders where the code, object and Listing files will be kept. Inside of the code folder will create the same 3 folders ( Core where the main file will be kept , Startup where the configuration file will be keep , and system folder where all system files will be kept)

3. Add a new component

Fig.4 “Rtos” component.

4. Add flowing files into the “rtos” component

Fig.5 “Rtos” Component files.

5. And don’t forget to include path for the “rtos“ component in the Flash >> Configure Flash Tools >> C/C++.

Fig.6 Include Path.


1. Init the system clock:

/* Initialize clocks */

2. Set Port direction as output and turn off all the LED’s :

static void PortInit(void)
	/* Configure P 2.00... P 2.07 as output */
	LPC_GPIO2->FIODIR |= ((1UL << 0u)|(1UL << 1u)|
  						  (1UL << 2u)|(1UL << 3u)|
                          (1UL << 4u)|(1UL << 5u)|
                          (1UL << 6u)|(1UL << 7u)) ;
	/* turn off all the LEDs */            
	LPC_GPIO2->FIOCLR = 0x000000FF;		

3. Create a 500ms and 250ms task and start the RTOS :

static void RtosInit(void)
	xTaskCreate( fnc_500msTask, "500msTask", 240, NULL , 1 , NULL );
	xTaskCreate( fnc_250msTask, "250msTask", 240, NULL , 1 , NULL );

	/* Start the scheduler so the tasks start executing. */

4. Toggle 2 led in the 250ms task :

const portTickType delay250 = (250/portTICK_RATE_MS);
static void fnc_250msTask(void *pvParameters)
	static unsigned char led2stat = 0x00;
 	portTickType xLastWakeTime;
 	xLastWakeTime = xTaskGetTickCount();

		/* Toogle all outputs leds */
		led2stat = led2stat^SET_LED_2;
		if(led2stat == SET_LED_2)
			LPC_GPIO2->FIOPIN |= led2stat;  

		/* delay task for 500ms */	
	   	vTaskDelayUntil(&xLastWakeTime, delay250);

		/* Allow the other sender task to execute. */

5. Toggle 1 led in the 500ms task :

const portTickType	delay500 = (500/portTICK_RATE_MS);
static void fnc_500msTask(void *pvParameters)
 	static unsigned char led1stat = 0x00;
 	portTickType xLastWakeTime;
 	xLastWakeTime = xTaskGetTickCount();

		/* Toogle all outputs leds */
		led1stat = led1stat^SET_LED_1;
		if(led1stat == SET_LED_1)
			LPC_GPIO2->FIOPIN |= led1stat;  

		/* delay task for 500ms */	
	   	vTaskDelayUntil(&xLastWakeTime, delay500);

		/* Allow the other sender task to execute. */

Adapt FreeRtosConfig.h

1. Activate TaskDelayUntil

#define INCLUDE_vTaskDelayUntil	1

Adapt startup_LPC17xx.s

1. Add SVCHandler , PendSVHandler , SysTickHandler functions used for RTOS :


			; FreeRTOS specific handlers.
			EXTERN 	vPortSVCHandler
			EXTERN  xPortPendSVHandler
			EXTERN  xPortSysTickHandler

2. Adapt Interrupt vector table :

DCD     vPortSVCHandler           ; SVCall Handler
DCD     DebugMon_Handler          ; Debug Monitor Handler
DCD     0                         ; Reserved
DCD     xPortPendSVHandler        ; PendSV Handler
DCD     xPortSysTickHandler       ; SysTick Handle

Task sequence call :

After all the necessary changes are done the LEDS should be turned on and off after every 500ms.Let’s take a look at the RTOS execution sequence.

Fig.7 Task sequence call.

We are not showing the Kernel calls but keep in mind that they are done always.

1. Both 250ms task and 500ms task are in the ready state but 250ms task is called because it is the last created one. The 250 ms will toggle the 2 led.

2. After the 250ms task is send in the blocked state by the kernel, the 500ms task is called immediately and the 1 led is toggled.

3. Because both 500ms and 250ms task are in block state the idle task is called.

4. The idle task is called until the 250ms task is in the blocked state. After 250 ms task the 500 ms task is not called because it has a higher delay. The 2 led is toggled.

5. After the 250 ms task is executed the idle task is called until the 250 ms wait time is not over.

6. After timer has expired the 250ms task and the 2 led is toggled.

7. Because the delay for 500ms task has expired and the 250 ms task in the block state the 1 led toggled.

8. Both tasks are in the block state and the idle task is called.

9. The process is executed continuously.

Because both tasks have the same priority (in or case is 1) you should be careful that task calls are not mixed to avoid this situation you can assign a higher priority for the task that is called more often.

Download :

A compiled and running version is available just click Rtos task states example .

Last updated on Sat , 08 2014

This page is waiting for your comment.

Share and Leave a comment.

You must be logged in to post a comment.

Back to Top