1 of 21

Lecture 14: Introduction To RTOS

ENGR 029

Spring 2024

Delano

2 of 21

Contents

Motivation
Introduction to RTOS and Keil RTX
Using full Mbed OS in Mbed studio
Why not use RTOS all the time?

3 of 21

Motivation

As programs become more and more complicated, we need systematic ways to manage different tasks
Limitations of synchronous state machines include:

Only one state machine can write to a global variable at a time, so state machines have no easy way of communicating with one another or updating a shared resource

The optional sections for today discuss two possibilities: task communication and queues

State machines have to “tick” at periods aligned by their GCD

We can use a task scheduler to help with this, but it has to check frequently

State machines have no “memory” so if they miss inputs, those inputs are gone forever

Queues are one approach to address this

Operating Systems consist of various subcomponents that create general purpose task scheduling and management, at the cost of complexity (code size, power, time) compared with state machines

4 of 21

Real-Time �Operating �Systems

5 of 21

Operating System Overview

Operating System (OS):

An intermediary interface between user applications and computer hardware
Facilitates application development (convenience and efficiency)
Various OSs are available in the market for various hardware platforms, e.g., Windows, Linux, Unix, Mac OS, Android, iOS.

Video driver

Audio driver

Memory driver

Mouse driver

OS kernel

OS shell

User application

Operating System

An operating system (OS) is a middleware between the developer and concrete hardware, such as processor, board, peripherals, etc. A developer should be able to realize code for similar hardware environments in a identical way. Hardware such as video, audio, etc. should always be handled equally when programming and implementing an application. Put another way, an OS provides functionality which can be used by as much hardware as possible, but the hardware itself must also (usually) provide a driver which can be handled by the OS. Therefore, an OS must adapt to hardware and hardware must provide OS-specific drivers.

The goal of an OS is the complete transparency, or ideally, invisibility, of the developer’s specific hardware. Developers should focus more on implementing a system’s functionality and less on addressing specific hardware issues.

6 of 21

Functions of an Operating System

An operating system acts as an interface between the high-level user application and the low-level hardware components, and it is usually capable of:

Managing the processor

Managing memory

Managing devices

Managing file systems

System security

Fault tolerance and error detection

Multitasking and job accounting

Task coordination

7 of 21

Types of Operating System

Distributed OS

Processing is distributed across multiple CPUs
Processors are interconnected via communication lines, such as internal high-speed buses or various types of networks

Embedded OS

Designed to be used in embedded computer systems
Limited resources such as memory, IOs, clock speed
Compact and energy efficient

Real-Time OS

Multitasking OS targeted at real-time applications, with real-time constraints
Must quickly and predictably respond to events

8 of 21

Real-Time Operating System Overview

A Real-time OS (RTOS) is an OS that:

Serve real-time applications
Responds to requests within a guaranteed and predictable delay
Processes data in deterministic cycles

RTOS aims at deterministic performance foremost, rather than high throughput

Performance can be measured by jitter: the variability of the time it takes to complete a task
Soft RTOS: more jitter, but usually or generally meets a deadline
Hard RTOS: less jitter, can meet a deadline deterministically

Real-time (definition): Real-time guarantees the completion of a process within a defined time interval.

Real-time does not make any statement about the total time duration or the processing speed.

9 of 21

RTOS Design Philosophies

There are two common designs for RTOS:

Event-driven RTOS

Pre-emptive task scheduling
An event of higher priority needs to be served first
Processes data more responsively

Time-sharing RTOS

Non-pre-emptive task scheduling
Tasks are switched on a regular clocked interrupt, and on events, e.g., round robin scheduling
Tasks are switched more often, giving a smoother multitasking
However, unnecessary task switching results in undesired overheads

An RTOS is based on two main design strategies: load and priority dependent, or independent. These two strategies are also called pre-emptive and non-pre-emptive.

A pre-emptive system allocates more processing time to a higher priority task. Lower priority tasks may be stopped until a higher priority task finishes. If the lower priority task is real-time, a very detailed plan is performed in advance, in order to provide sufficient time intervals for all potentially active tasks.

Non-pre-emptive schedule is much more predictive. All processes are started and stopped within defined time slices, regardless of whether they need the full time slice. This may be very inefficient for a system with a low load because it is constantly scheduling and switching tasks.

A more intelligent algorithm for time sharing could be the ‘round-robin’-method, which considers both priorities and the remaining loads of single processes.

10 of 21

RTOS Task Scheduling

In a typical RTOS, a task can have at least three states:

Running: task is currently executed by the CPU
Ready: task is ready to be executed by the CPU
Blocked: task is paused and waiting for an event, such as from I/O, to resume its execution

Task scheduling

Usually, only one task per CPU can run at any one time.
To efficiently switch between tasks, usually a task scheduler is used. Various scheduling algorithms exist, including:

Cooperative scheduling: no pre-emption, tasks can end themselves in a cooperative manner
Pre-emptive scheduling: tasks can be interrupted by other tasks of higher priorities
‘Earliest deadline first’ approach: the task with the earliest deadline is served first

Examples of RTOS include LynxOS, OSE, Windows CE, FreeRTOS, Arm Keil RTX, etc.

The raspberry PI, a common prototyping system, does not come with a native RTOS, which can limit its utility for embedded applications.

11 of 21

Highlights of Arm Keil RTX RTOS

Deterministic RTOS designed for Arm Cortex-M-based devices

Multitasking with flexible scheduling: round-robin, pre-emptive, and collaborative

High-speed real-time operation with low interrupt latency

Small footprint for resource-constrained systems

Royalty-free, deterministic RTOS with source code

Unlimited number of tasks each with 254 priority levels

Support for multithreading and thread-safe operation

Inter-task communication manages the sharing of data, memory, and hardware resources among multiple tasks

Unlimited number of mailboxes, semaphores, mutex, and timers (hardware-permitting)

Defined stack usage - each task is allocated a defined stack space, enabling predictable memory usage

12 of 21

Threads

A task can sometimes be referred to as a thread in multitasking systems

A Thread in mbed API can be in the following states:

Running: The thread that is currently running is in the Running state. Only one thread at a time can be in this state.

Ready: Threads that are ready to run are in the Ready state. Once the Running thread has terminated or is Waiting, the next Ready thread with the highest priority becomes the Running thread.

Waiting: Threads that are waiting for an event to occur are in the Waiting state.

Inactive: Threads that are not created or terminated are in the Inactive state. These threads typically consume no system resources.

Threads and tasks are often used synonymously although, strictly speaking, tasks are a combination of threads. As explained previously, tasks’ states are running, blocked and ready. Mbed adds two further states, ‘waiting’ and ‘inactive’:

Waiting means that the task is actively waiting for its initiating interrupt, but is not yet performing any action.
Inactive is a state in which the task waits to start.

Here is a sports-based example: During a competition, runners are inactive during the pole vault event. When the running competition is announced (creating a thread), the runners move into wait-state. As soon as each runner’s number is called (an interrupt), that runner proceeds to the starting block and waits for the start. When the starting pistol fires, the runners are running.

13 of 21

Thread Example

The example below shows how to create threads to blink LEDs:

/*

* SPDX-License-Identifier: Apache-2.0

*/

#include "mbed.h"

DigitalOut led1(LED1);

DigitalOut led2(LED2);

Thread thread;

void led2_thread()

{

while (true) {

led2 = !led2;

ThisThread::sleep_for(1000);

}

int main()

{

thread.start(led2_thread);

while (true) {

led1 = !led1;

ThisThread::sleep_for(500);

}

14 of 21

Contents

Introduction to RTOS and Keil RTX
Using full Mbed OS in Mbed studio
Why not use RTOS all the time?

15 of 21

How can we use these new features?

Mbed OS has two profiles:

Full profile (includes RTOS)
Bare metal profile (no RTOS, what we’ve been using so far)

Example is full OS unless it says baremetal. Lab 0 was based on the blinky-baremetal project.

See here for full comparison of bare metal and full profiles

16 of 21

Some RTOS features are “safe” to use in bare metal

Two relevant ones are the “Mutex” and “Semaphore” classes

17 of 21

Mutex

Mutex: Mutual Exclusion Object

Ensures no two threads are in their critical section accessing a shared resource at the same time

In RTOS, the mutex is used to:

Synchronize the execution of threads
Protect access to a shared resource, such as a shared memory image

18 of 21

Semaphore

A semaphore is a variable of abstract data type used to manage and protect access to shared resources. Unlike a mutex, it does not have the concept of an owner

Unlike a mutex, a semaphore can control access to several shared resources
For example, a semaphore enables access to and management of a group of identical peripherals

19 of 21

Considerations for using Threads, Mutex and Semaphore

Mutex and Semaphore work in bare metal profile, but can’t be used with blocking operations in ISR context

Just note that many functions are not available in ISR context (e.g. you can only use “try_acquire” but not “acquire” for example)

Most other thread functionality requires the full metal profile

The full metal profile involves extra protections in ISRs, printf will now no longer work in ISRs (you can use pc.write or print elsewhere)

This was not an issue with the bare metal profile because the bare metal profile doesn’t use a mutex on printf to make it thread safe

20 of 21

Switching to full metal profile

To use the RTOS you can:

Delete the line that requires bare metal in mbed_app.json
Start an empty project from scratch

If you start a project from scratch, mbed_app.json may not exist, and you will need to create it if you want to enable floating point printf