Scheduling Policies

Monday, August 5, 2024 7:13 PM

Time base source selection

FreeRTOS uses ARM cortex Mx Processor's internal systick timer as its time base.(RTOS ticking )
STM32 Cube HAL layer also by default uses systick timer as its time base source.
If you are using both freeRTOS and STM32 Cube HAL layer in your project, there will be a conflict
to use a timebase source.
To resolve this, it is strongly recommended to use STM32 cube HAL layer timebase source other
than systick timer (use any timer peripheral of the microcontroller)

What is SEGGER SystemView ??

• SystemView is software used to analyxe the embedded software behavior running on your target.
• The embedded software may contain embedded OS or RTOS or non-OS based applications.
• The systemview can be used to analyze how your embedded code is behaving on the target.
○ Example : In case of freeRTOS application
 You can analyze how many tasks are running and how much duration they consume
on CPU.
 ISR entry and exit timings and duration on the CPU.
 You can analyze the other behavior of tasks : like blocking, unblocking, notifying,
yielding etc.
 You can analyze CPU idle time so that you can think of sending CPU to sleed mode.
 Total runtime behavior of application.
 It sheds light on what exactly happened in which order, which interrupt has triggered
which task switch which interrupt and task has called which API function of the
underlying RTOS.
 Systemview should be used to verify that the embedded system behaves as expected
and can be used to find problems and inefficiencies such as superfluous and spurious
interrupts and unexpected task changes.
• SystemView comes in two parts :
○ PC visualization software ( Systemview Host Software )
○ Systemview Target codes ( this is used to collect the target events and sending back to PC
visualization software.)

What is an RTOS ??

• It's a OS, specially designed to run applications with very precise timing and a high degree of
reliability.
• Some of these operations inlcudes :
○ Handling of interrupts and system exceptions
○ Handling of critical section
○ Scheduling mechanism

RTOS vs GPOS :-

• Task scheduling is always based on priority while in GPOS it's not based on priority always.
• Throughput is high in GPOS as compared to RTOS
○ Throughput means – the total number of processes that complete their execution per unit
time.
• Latency is low in GPOS
• In GPOS, priority inversion effects are in-significant, in RTOS priority inversion effects must be

RTOS Page 1
 • In GPOS, priority inversion effects are in-significant, in RTOS priority inversion effects must be
solved

Scheduler :

Why do we need scheduler ??

• It just a piece of code which implements task switching in and Task switching out according to the
scheduling policy selected
• Scheduler is the reason why multiple tasks run on your system efficiently
• The basic job of the scheduler is to determine which is the next potential task to run on the CPU
• Scheduler has the ability to preempt a running task if you configure so

Scheduling Policy :

• simple Pre-emptive Scheduling (Round robin )

• Priority based Pre-Emptive Scheduling
• Co-operative Scheduling
• The scheduling policy is the algorithm used by the scheduler to decide which task to execute at
any point in time
• FreeRTOS or most of the Real Time OS most likely would be using Priority based Pre-emptive
Scheduling by default

Scheduler schedules tasks to run on the CPU according to the scheduling policy configured.
• Pre-emptive Scheduling ( configUSE_PREEMPTION = 1 )
• Co-operative scheculing ( configUSE_PREEMPTION = 0 )

vTaskStartScheduler()

• This is implemented in tasks.c of FreeRTOS kernel and used to start the RTOS scheduler .
• Remember that after calling this function only the scheduler code is initialized and all the Arch.
Specific interrupts will be activated.
• This function also creates the idle and Timer daemon task
• This function calls xPortStartScheduler() to do the Arch. Specific Initializations such as 1.
Configuring the SysTick timer to issue interrupts at desired rate (as configured in the config item
configTICK_RATE_HZ in FreeRTOSConfig.h) 2. Configures the priority for PendSV and Systick
interrupts. 3. Starts the first task by executing the SVC instruction
• So basically this function triggers the scheduler(i.e various Arch specific interrupts aka kernel
interrupts ) and never returns.

What are the functions of vTaskStartScheduler() ?

RTOS Page 2
Pre-emptive Scheduling :-
• Replacing a running task with another task.
• During pre-emption, the running task is made to give up processor even if it hasn't finished the
work.The scheduler does this to run some other tasks of the application.
• There are two types of pre-emptive scheduling.
○ Round-robin pre-emptive scheduling
 Scheduling tasks without priority ( also known as cyclic executive). Time slices are
assigned to each task in equal portions and in circular order.
○ Priority based pre-emptive scheduling
 Tasks are scheduled to run on the CPU based on their priority. A task with higher
priority will be made to run on the CPU forever unless the task gets
deleted/blocked/supspended or leaves voluntarily to give chances for others.

Co-operative Scheduling :
• A task cooperates with other tasks by explicitly giving up the processor.
• There is no pre-emption of the tasks by the scheduler. That is, the running task will never be
interrupted by the scheduler.
• The RTOS tick interrupt doesn’t cause any pre-emption, but the tick interrupts are still needed
to keep track of the kernel's real-time tick value.
• Tasks give up the CPU when they are done or periodically or blocked/supended waiting for a
resource.

Idle Task :-
• It is lowest priority task which is automatically created when the scheduler is started to ensure
there is always at least one task that is able to run.
• The idle task is responsible for freeing memory allocated by the RTOS to tasks that have been
deleted
• When there are no tasks running, Idle task will always run on the CPU.
• You can give an application hook function in the idle task to send the CPU to lower power mode
when there are no useful tasks are executing.

Idle Task application hook :-

RTOS Page 3
Idle Task application hook :-
• Idle task hook function implements a callback from idle task to your application .
• You have to enable the idle task hook function feature by setting this config item
configUSE_TICK_HOOK to 1 within FreeRTOSConfig.h.
• Then implement the below function in your application
void vApplicationIdleHook( void );
• That’s it , whenever idle task is allowed to run, your hook function will get called, where you can
do some useful stuffs like sending the MCU to lower mode to save power.
• When the hook function is called, care must be taken that the idle hook function does not call
any API functions that could cause it to block.

Timer Service Task :

• This is also called as timer daemon task
• This timer daemon task deals with "Software timers"
• This task is created automatically when the scheduler is started and if configUSE_TIMERS=1 in
freeRTOSConfig.h
• The RTOS uses this daemon to manage freeRTOS software timers and nothing else.
• If you don't use software timers in your freeRTOS application then you need to use this Timer
daemon task. For that just make configUSE_TIMERS=0 in freeRTOSConfig.h
• All software timer callback functions execute in the context of the timer daemon task.

Scheduler :-
• In freeRTOS the scheduler code is actually combination of freeRTOS Generic Code (tasks.c) +
Architecture Specific codes.

Architecture Specific Code :-

• Architecture Specific Codes and configurations are implemented in port.c and portmacro.h

Interrupts in RTOS :-
• SVC Interrupt (Used to launch the very first task )
• PendSV Interrupt ( This is used to carry out context switching between tasks )
• SysTick Interrupt ( Used to manage RTOS tick management )

RTOS Tick :-
• #define configTICK_RATE_HZ ((portTickType)1000)
• RTOS ticking is implemented using timer hardware of the MCU

Why RTOS tick required ??

• To keep track of time elapsed
○ Ex :- To waken up one task at 100 ms
○ Used for Context Switching to the next potential task
• There is global variable called "xTickCount", and it is incremented by one whenever tick
interrupt occurs
• RTOS ticking is implemented using SysTick timer of the ARM Cortex Mx processor.
• Tick interrupt happens at the rate of configTICK_RATE_HZ configured in the freeRTOSConfig.h

Who configured the RTOS Tick Timer ??

RTOS Page 4
 •

Context Switching :-

• Context switching is process of switching out of one task and switching in to another task on the
CPU to execute.
• In RTOS, context switching is taken care by scheduler
• In freeRTOS, context switching is taken care by pendSV Handler found in port.c
• Whether context switching should have happen or not depends upon the scheduling policy of
the scheduler
• If the scheduler is priority based pre-emptive scheduler, then for every RTOStick interrupt,the
scheduler will compare the priority of the running task with the priority of ready tasks list. If

RTOS Page 5
 scheduler will compare the priority of the running task with the priority of ready tasks list. If
there is any ready task whose priority is higher than the running task then context switch will
occur.
• On freeRTOS you can also trigger context switch manually using taskYIELD() macro
• Context switch also happens immediately whenever new task unblocks and if its priority is
higher than the currently task.

Task State :-

• When a task executes on the processor it utilizes

○ Processor core registers
○ If a task wants to do any push and pop operation ( during function call ) then it uses its
own dedicated stack memory
• ARM Cortex Mx Core registers

PSP :- Process stack pointer :-user task uses PSP to track individual stack of the task
MSP : Main Stack pointer :- kernel task uses MSP to track kernel content

Task Switching out procedure

• Processor core registers R0,R1,R2,R3,R12,LR,PC,xPSR(stack frame ) are saved on to the task's

private stack automatically by the processor sysTick interrupt entry sequence.
• If context switch is required than systick timer will pend the PendSV exception and pendSV
handler runs.

RTOS Page 6
 handler runs.
• Processor core registers (R4-R11,R14) have to saved manually on the task's private stack
memory( saving the context).
• Save the new top of the stack value (PSP) into first member of the TCB.
• Select the next potential task to execute on the CPU. Taken care by vTaskSwitchContext()
implemented in task.c

Task Switching in Procedure

• So at this time, we already know which task (TCB) should be switched in. That means new
switchable task's TCB can be accessed by pxCurrentTCB
• First get the address of top of stack. Copy the value of pxTopOfStack in to PSP register.
• Pop all the registers (R4-R11,R14) (Restoring the context)
• Exception exit : Now PSP is pointing to the start address of the stack frame which will be popped
out automatically due to exception exit.

States of Task

• Non-running task --> Blocked,Suspended,Ready

• Running task
○ When the task is currently executing on processor,it is said to be in running state
• Ready state
○ Task that can run on the CPU when scheduler schedules them.
○ The scheduler may not schedule the task to running on the CPU if some higher priority
task is currently executing on the CPU.
○ In RTOS, whenever new task is created, it enters READY state.
• Blocked state
○ A task can leave the CPU from the running state and choose not to run on the CPU until
an internal or external event is met. This state is BLOCKED state.
○ When a task is in BLOCKED state, it won’t consume any CPU time.
○ In freeRTOS, there is an API called vTaskDelay(500). If a task calls this function then It will
enter a BLOCKED state for 500 RTOS ticks, after which it unblocks and enter the READY
state.
○ A task can also block waiting on an external event, like data arrival to the queue,
nonavailability of lock in the case of mutex or semaphore etc.
○ Task in a BLOCKED state has a timeout period; after the timeout period, it unblocks and
enters the ready state even for which it is waiting has not occurred.

RTOS Page 7
 enters the ready state even for which it is waiting has not occurred.
○
• Suspended state
○ A task enters suspended state when it or another task called vTaskSuspend(task_handle).
○ A suspended task will not enter READY state unless some other running tasks cancel the
suspension by calling the api vTaskResume(task_handle_of_suspended_task)
○ Unlike blocked state task, a task in SUSPENDED state doesn't have timeout period
○ Task in READY state can directly enters into SUSPENDED state if some other running task
calls vTaskSuspend(task_handle); using task handle of the READY state task.

Task Delay API

• vTaskDelay()
• vTaskDelayUntil()

Why use them :- Delay a task without engaging the processor

Implementation of periodic tasks

Task Notification API

• Each RTOS has 32 bit notification value which is initialised with zero at the time task is created
• xTaskNotify() : To notify the task
○ xTaskNotify sends an event directly to and potentially unblock an RTOS, and optionally
update the receiving task's notification value in one of the following ways
 Write a 32 bit number to the notification value
 Add one the notification value
 Set one or more bits in the notification value
 Leave the notification value unchanged
○ This function must not be called from interrupt handler instead called
xTaskNotifyFromISR()
• xTaskNotifyWait() :
○ If a task calls xTaskNotifyWait(), then it waits with an optional timeout until it receives a
notification from some other task or interrupt handler

Modes in RTOS
• There are two modes in which RTOS operates
• Processor always start in thread mode with priviledge access
○ Handler mode
 Priviledge access
 ISR/Exception handler always runs in Handler mode of the processor
○ Thread mode
 Unpriviledge access
 User level code runs in thread mode of the processor
 Cannot access some of the settings of the processor

Memory in RTOS

RAM vs Flash

RTOS Page 8
Who decides the heap size and starting address in RTOS ??
• By default, the heap size is declared by freeRTOS kernel.
• Setting configAPPLICATION_ALLOCATED_HEAP to 1 allows the heap to instead be declared by
the application

FreeRTOS heap memeory management schemes

• RTOS uses five types of heap memory management

○ Heap_1

○ Heap_2
○ Heap_3
○ Heap_4
○ Heap_5

freeRTOS synchronization and mutual exclusion services

• freeRTOS supports Queue, Semaphore and mutex for synchronization

Task Priority vs Hardware Priority

• Task Priority
○ Task priority is priority of tasks
○ It runs in thread mode
• Hardware Priority
○ Is the priority value assigned to various interrupts and system exceptions of the processor
○ Interrupt handler runs in handler mode of the processor

Queue Mangement in RTOS

Creating Queue

• xQueueHandle xQueueCreate(unsigned portBASE_TYPE uxQueueLength,unsigned

portBASE_TYPE uxItemSize)
○ uxQueueLength --> how many items this queue should hold
○ uxItemSize --> what's the size of single item in bytes
xQueueHandle ---> If creation is successful api returns the reference ( a pointer ) to the

RTOS Page 9
 ○ xQueueHandle ---> If creation is successful api returns the reference ( a pointer ) to the
created queue otherwise NULL

Sending data to queue

• xQueueSendToFront() --> sends data to the front (head) of the queue

• xQueueSendToBack() --> sends data to the back of the queue

○ Same as above, the only difference is that the above api will send data to the front of the
queue while this api will send the data to back of the queue.

Receiving data to queue

• xQueueReceive()

• xQueuePeak()
○ The only difference between this and above is that this api will not remove the data after
being read while the above api will remove the data after read.

Why separate "FromISR" APIs ??

• It makes APIs implementation simpler.
○ When called from task context, many RTOS APIs can put the calling task to a blocked
state, but the same cannot happen when called from interrupt handlers because you
cannot put the interrupt handler or interrupt context code to blocked state. The blocked
state is for tasks, not for interrupt handlers.
○ So, now the API must determine from which context it was being called, interrupt or task
context, and decide accordingly.
○ This approach increases code overhead, and some architecture doesn't support
determining the context. To overcome this problem, freeRTOS gives separate APIs to be
called from interrupt handlers and prohibits using APIs which doesn't end with "FromISR"
inside an interrupt handler.

RTOS Page 10
 inside an interrupt handler.
• Some API function parameters would become redundant and confusing.

Disadvantages of using separate APIs

• Application writer must redesign the logic when there is a need to call a third party function
from an interrupt handler that uses freeRTOS API that doesn't end with "FromISR".

RTOS Page 11