ECEN 421 - Quiz #8

Why RTOS are important

Why RTOS are important

enable hard and firm real-time system implementations, priority based scheduling, event driven, modular task based development, API functions

Scheduler

determines which task is running at a given time

Objects

special constructs used to create application behavior

Services

operations that the RTOS performs on objects

Task

a unique continuous behavior executing on a CPU

Ready state

tasks that have been triggered to execute but are not currently executing

Running state

a task currently executing on the CPU

Waiting state

tasks that are not running and have not been triggered in order to start to execute

Blocked state

entered into by an instruction that has to wait for a hardware system event. Exited from when the hardware event occurs

Suspended state

entered into, and exited from, by program instructions

Release time

the point from which the task can be executed

Deadline

the point in time by which the task must complete

Execution time

the time the task takes to execute

Jitter

the delay between when a task becomes ready and the time that it starts executing

Context Switch

saving and retrieving the current processor state to the stack when a task switches to another task that has preempted it

Four RTOS States

Running, Ready, Blocked, Suspended

Basic RTOS Services

Task management, resources synchronization, inter-task communication, timer management, memory management, interrupts and event handling, i/o management

Why use FreeRTOS

free, small footprint, supported on popular microcontrollers and CPUS, large community of users, maintained by amazon web services, integrates easily with IoT development

FreeRTOS Open Sources

can be customized to specific architectures

Vanilla FreeRtos

original FreeRTOS that runs only on single-core CPUs

Xtensa Port of FreeRTOS

Extends Vanilla FreeROTS to support dual core processing on Xtensa architecture

Symmetric Multiprocessing (SMP) System Concepts

have multiple processor cores running independently, each core has an identical view of memory, multiple threads can execute at the same time, thread can switch between CPU cores during execution

ESP-IDF Free RTOS Task Management Functions

Creating tasks with Vanilla RTOS functions, ESP-IDF specific functions

Characteristics of ESP-IDF FreeRTOS Tasks

can only be in one of the 4 task states (running, ready, block, or suspended), implemented in user-defined a function that never returns, typically implemented in an infinite loop

Semaphore

a “key” that one or more tasks can acquire or release for the purpose of synchronization or mutual exclusion (binary, counting and MuTex)

Binary Semaphore Basics

can have two possible values (0 or 1), when a task takes a semaphore its value becomes 0, when a task releases the semaphore its value becomes 1

Counting semaphore basics

used for access to a pool of identical resources, can have values from 0 to N, when a task takes a counting its value is decremented by 1, when n=0, counting semaphore is no longer available, when task releases the counting its value is incremented by 1, n=1 is just a binary semaphore

MuTex (Mutual Exclusion Object)

same general concept as binary semaphore except locking mechanism, is an object, only modified by the current task, operations are locked or unlocked

Advantages of MuTex over Binary Semaphore

provides mutually exclusive access to a critical selection, only one thread can acquire the lock at a time, if a thread acquires a lock no other thread can take it away, prevents race conditions when multiple threads try to acquire the lock simultaneously

Inter-Task Communication Mechanisms in FreeRTOS

Direct Task Notifications, Mailboxes, Queues, Pipes

Direct Task Notifications in FreeRTOS

event sent directly to a task that can unblock the receiving task, and optionally update the receiving task’s notification value, can only be used when theres only one task that can be the recipient of the event

Mailboxes in FreeRTOS

data buffer managed by the RTOS and used for sending a message to a task, object is like a posting mailbox, task can have a mailbox into which others can post mail, any task or ISK can send the message to mailbox of another task

Using message queues in FreeRTOS

queue can be considered an array of mailboxes, FIFO structure, task or ISR deposits message out in the order they were put in

Queue creation includes

name or ID, length, sending task waiting list, receiving task waiting list

Pipes for RTOS Inter-Task Communication

RTOS object that provides simple communication channels used for unstructured data exchange among tasks, can be opened closed written to and read from, unidirectional data exchange