FreeRTOS Slides annotations.pdf

Sherif Hammad
Real Time Operating System
Introduction & “FreeRTOS”

2
Agenda
• RTOS Basics
• RTOS sample State Machine
• RTOS scheduling criteria
• RTOS optimization criteria
• Soft/Hard Real Time requirements
• Tasks scheduling

8
CPU Scheduling Criteria
• CPU Utilization: CPU should be as busy as possible (40% to 90%)
• Throughput: No. of processes per unit time
• Turnaround time: For a particular process how long it takes to
execute. (Interval between time of submission to completion)
• Waiting time: Total time process spends in ready queue.
• Response: First response of process after submission

9
Optimization criteria
• It is desirable to
o Maximize CPU utilization
o Maximize throughput
o Minimize turnaround time
o Minimize start time
o Minimize waiting time
o Minimize response time
• In most cases, we strive to optimize the average
measure of each metric
• In other cases, it is more important to optimize the
minimum or maximum values rather than the average

10
Soft/Hard Real Time
• Soft realtime requirements: state a time deadline—but breaching
the deadline would not render the system useless.
• Hard realtime requirements: state a time deadline—and breaching
the deadline would result in absolute failure of the system.
• CortexM4 has only one core executing a single Thread at a time.
• The kernel decides which thread should be executing by examining
the priority assigned to each thread by the application designer.
• Application designer could assign higher priorities to hardreal
timethreads and lower priorities to soft realtime

11
Why Use a Real-time Kernel?
• Abstracting away timing information
• Maintainability/Reusability/Extensibility
• Modularity
• Team development
• Improved efficiency (No Polling)
• Idle time:
The Idle task is created automatically when the kernel is started. It executes
whenever there are no application tasks wishing to execute. The idle task
can be used to measure spare processing capacity, to perform background
checks, or simply to place the processor into a lowpower mode.
• Flexible interrupt handling:
Interrupt handlers can be kept very short by deferring most of the required
processing to handler RTOS tasks.

12
Task Functions
• Arbitrary naming: Must return void: Must take a void pointer
parameter:
• Normally run forever within an infinite loop, and will not exit.
• FreeRTOS tasks must not be allowed to return from their
implementing function in any way—they must not contain a
‘return’ statement and must not be allowed to execute past the end
of the function.
• A single task function definition can be used to create any number
of tasks—each created task being a separate execution instance
with its own stack and its own copy of any automatic (stack)
variables defined within the task itself.

14
Top Level Task States
• When a task is in the Running state, the processor is
executing its code.
• When a task is in the Not Running state, its status having
been saved ready for it to resume execution the next time
the scheduler decides it should enter the Running state.
• When a task resumes execution, it does so from the
instruction it was about to execute before it last left the
Running state.

15
Creating Tasks
The xTaskCreate() API Function

18
Tick Interrupt
• To be able to select the next task to run, the scheduler itself
must execute at the end of each time slice.
• A periodic interrupt, called the tick interrupt, is used for this
purpose.
• The length of the time slice is effectively set by the tick
interrupt frequency, which is configured by the
configTICK_RATE_HZ compile time configuration constant in
FreeRTOSConfig.h.

2
Agenda
• Tasks priorities
• Task State Machine
• Periodic tasks
• Tasks Blocking

6
Task Creation After Schedule Started
(From Within Another Task)

7
Example 2: Single Task Function
“Instantiated Twice” (Two Task Instants)

8
Example 2: Single Task Function
“Instantiated Twice” (Two Task Instants)

9
Task Priorities
• The priority can be changed after the scheduler has been started by
using the vTaskPrioritySet() API function.
• The maximum number of priorities available is set by the
applicationdefined configMAX_PRIORITIES compile time
configuration constant within FreeRTOSConfig.h.
• The higher the configMAX_PRIORITIES value the more RAM the
kernel will consume, “keep it minimum”.
• Low numeric priority values denote lowpriority tasks, with priority
0 being the lowest priority possible.
• Where more than one task of the same priority is able to run, the
scheduler will transition each task into and out of the Running
state, in turn.
• Each such task executes for a ‘time slice‘; it enters the Running
state at the start of the time slice and exits the Running state at the
end of the time slice.

11
Task Priorities: Example 3; Starvation
• Both Tasks are made periodic by the “dummy” loop
• Both Tasks only needs CPU for short execution
time!
• Task 2 (High Priority) takes CPU all the time
• Task 1 suffers starvation
• Wastes power and cycles!
• Is there another smarter way?

12
Using the Blocked state to create a delay
• vTaskDelay() places the calling task into the Blocked state for a fixed number of
tick interrupts.
• While in the Blocked state the task does not use any processing time
• vTaskDelay() API function is available only when. INCLUDE_vTaskDelay is set to 1
in FreeRTOSConfig.h
• The constant portTICK_RATE_MS can be used to convert milliseconds into ticks.
• Portmacro.h: #define portTICK_RATE_MS ( ( portTickType ) 1000 /
configTICK_RATE_HZ )
• FreeRTOSConfig.h: #define configTICK_RATE_HZ ( ( portTickType ) 1000 )

13
Task Blocking: Example 4
• Each time the tasks leave the Blocked state
they execute for a fraction of a tick period
before re-entering the Blocked state.
• Most of the time there are no application tasks
that are able to run; The idle task will run.
• Idle task time is a measure of the spare
processing capacity in the system.

14
Expanding the ‘Not Running’ State
The Blocked State
• A task that is waiting for an event is said to be in the ‘Blocked’ state,
which is a sub-state of the Not Running state.
• Tasks can enter the Blocked state to wait for two different types of
event:
o 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.
o 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.

15
The Suspended State
• ‘Suspended’ is also a sub-state of Not Running.
• 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
• the only way out being through a call to the vTaskResume() or
xTaskResumeFromISR() API functions.
• Most applications do not use the Suspended state.
The Ready State
• Tasks that are in the Not Running state 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 their
priorities are not qualifying to be in the Running state.

2
Agenda
• Accurate task periods
• Continuous & Periodic Tasks
• Changing Tasks priorities
• Deleting tasks

3
Accurate Tasks Periods
• vTaskDelayUntil() is similar to vTaskDelay() “but”
• vTaskDelay() parameter specifies the number of tick interrupts that should occur
between a task calling vTaskDelay() and the same task once again transitioning
out of the Blocked state.
• The length of time the task remains in the blocked state is specified by the
vTaskDelay() parameter, but the actual time at which the task leaves the blocked
state is relative to the time at which vTaskDelay() was called.
• The parameters to vTaskDelayUntil() specify, instead, the exact tick count value
at which the calling task should be moved from the Blocked state into the Ready
state.
• vTaskDelayUntil() is the API function that should be used when a fixed execution
period is required (where you want your task to execute periodically with a fixed
frequency), as the time at which the calling task is unblocked is absolute, rather
than relative to when the function was called (as is the case with vTaskDelay()).
• vTaskDelayUntil() API function is available only when INCLUDE_vTaskDelayUntil
is set to 1 in FreeRTOSConfig.h.
vTaskDelayUntil()

3
state.
vTaskDelayUntil()
• Delay a task until a specified time. This function can be used by periodic tasks to ensure
a constant execution frequency.
• This function differs from vTaskDelay() in one important aspect: vTaskDelay() specifies
a time at which the task wishes to unblock relative to the time at which vTaskDelay() is
called, whereas vTaskDelayUntil() specifies an absolute time at which the task wishes
to unblock.
• vTaskDelay() will cause a task to block for the specified number of ticks from the
time vTaskDelay() is called.
• It is therefore difficult to use vTaskDelay() by itself to generate a fixed execution frequency
as the time between a task unblocking following a call to vTaskDelay() and that task
next calling vTaskDelay() may not be fixed [the task may take a different path through the
code between calls, or may get interrupted or preempted a different number of times each
time it executes].
• Whereas vTaskDelay() specifies a wake time relative to the time at which the function is
called, vTaskDelayUntil() specifies the absolute (exact) time at which it wishes to unblock.

3
state.
• It should be noted that vTaskDelayUntil() will return immediately (without blocking) if it is
used to specify a wake time that is already in the past.
• Therefore a task using vTaskDelayUntil() to execute periodically will have to re-calculate
its required wake time if the periodic execution is halted for any reason
(for example, the task is temporarily placed into the Suspended state) causing the task
to miss one or more periodic executions.
• This can be detected by checking the variable passed by reference as the
pxPreviousWakeTime parameter against the current tick count. This is however
not necessary under most usage scenarios.
• The constant portTICK_PERIOD_MS can be used to calculate real time from the tick rate -
with the resolution of one tick period.
vTaskDelayUntil()

3
state.

4
Accurate Tasks Periods (Example 5)

5
Example 6: Continuous & Periodic Tasks

6
Example 6: Continuous & Periodic Tasks

9
Priorities & Preemption
• 1_three_tasks_same_priority
• 2_three_tasks_different_priority
• 3_three_tasks_preemption_delete_task (Example 9)

2
The Idle Task and the Idle Task Hook
(Idle Task CallBack)
• An Idle task is automatically created by the scheduler when
vTaskStartScheduler() is called.
• The idle task does very little more than sit in a loop
• The idle task has the lowest possible priority (priority zero), to ensure it
never prevents a higher priority application task from entering the
Running state
• Idle task is always pre-empted by higher priority tasks
• idle hook (or idle callback) function—a function that is called
automatically by the idle task once per iteration of the idle task loop
• Common uses for the Idle task hook include:
o Executing low priority, background, or continuous processing.
o Measuring the amount of spare processing capacity.
o Placing the processor into a low power mode
• configUSE_IDLE_HOOK must be set to 1 within FreeRTOSConfig.h for the
idle hook function to get called.

3
Example 7: Idle Task CallBack

4

5
How many times IdelTask is called between tasks calls?
For how long the CPU is into Idle Task?

Real Time Operating System
“FreeRTOS”
Change Task Priority
Using the FreeRTOS Real Time Kernel - a Practical Guide - Cortex M3 Edition (FreeRTOS
Tutorial Books)
by Richard Barry
Sherif Hammad

2
Changing task priorities; Example 8

3

4

5

8
Deleting a Task; Example 9
Task 2
Preempts 1
Task 1 Resumes

6
The Scheduling Algorithm—A Summary
• Fixed Prioritized Preemptive Scheduling
o Each task is assigned a priority.
o Each task can exist in one of several states.
o Only one task can exist in the Running state at any one time.
o The scheduler always selects the highest priority Ready state task to enter
the Running state.
• Fixed Priority’ because each task is assigned a priority that is not
altered by the kernel itself (only tasks can change priorities);
• ‘Preemptive’ because a task entering the Ready state or having its
priority altered will always preempt the Running state task, if the
Running state task has a lower priority.

7
The Scheduling Algorithm—A Summary

FreeRTOS Slides annotations.pdf

Recommended

More Related Content

Similar to FreeRTOS Slides annotations.pdf (20)

Recently uploaded (20)

FreeRTOS Slides annotations.pdf