Real Time Operating Systems Michael Thomas Date: Rev. 1.00Date.

Real Time Operating Systems

Michael Thomas

Date:

Rev. 1.00Date

2

Objective

Identify embedded programming models

Understand basic RTOS definitions and concepts

Points to consider when you “Buy or roll your own”

3

Defining application requirements

Real time: Computing with a deadlineA required level of service has to be provided in a bounded response time

Consequence of missing deadlines: “Hardness” of the problem/application

Hard real-time - absolute deadlines must be metFirm real-time - low occurrence of missing a deadline can be toleratedSoft real-time - tolerance in the order of human reaction time (50ms)

4

Basic concepts and definitions

Task: Self contained code that handles a singular functionality or semi-independent portion of the application that handles a specific duty.

Threads: Access to entire memory space

Processes: Memory access area limited based on process creation parameters

Priority

5

Basic concepts and definitions

Real-time Scheduling

Hard

Preemptive

Dynamic Static

Preemptive Non-preemptiveNon-preemptive

Soft

SchedulerImplements the scheduling policy

6

Basic concepts and definitions

DeterminismExact time taken for each thread to execute is a constant

Kernel(Scheduler + Memory management + IPC + Synchronization) primitives

Kernel latency (microkernel, picokernel etc)

Kernel space

7

Other Info

Task ID

Priority

Task Status

Register Contents

Program CounterContext

Typical TCB

Context switch time

current CPU task

Save context to TCB1 Save context to TCB2

Load context from TCB2 Load context from TCB1

Context Switch and Task Control Block

8

H8S Stack frames during a context switch

task1 task2

task1 readytask1 running

task2 readyContext Switchtask2 running

LOCALVARIABLES

LOCALVARIABLES

9

Clock Interrupts occur every ~10 ms (allow OS to run)OS checks to see if any higher priority process available in ready queueIf so, suspend current process and switch to new process

PreemptionP

riorit

y RTOS Context-Switch serviceISR

Time

Context Switch

task 2

task 1

RUNNING

WAITING

10

Embedded programming models

System designed around task scheduling policy

Endless loop

Simple cyclic executive

Time driven cyclic

Multi-rate cyclic

Multi-rate cyclic for periodic tasks

Multi-rate cyclic with interrupts (bg/fg programming)

Priority based pre-emptive

11

Task1

Task2

Task5

Task4

Task3

Simple cyclic

Task1

Task2

Task5

Task4

Task3

Timer Interrupt

Time driven cyclic

Timer Interrupt

Task1

Task1

Task1

Task2

Task3

Multi-rate cyclic

Task1

Task1

Task1

Task2

Task3

Timer Interrupt

Multi-rate cyclic for periodic

12

Where does an RTOS fit in?

Task management viewpoint:

13

RTOS Services

14

Task Management & Scheduling

Task is considered as a scheduling unit which implements a function

OS services that collectively move tasks from one state to another

Provide context switching services

Task parameters like deadline, period, priority etc need to be specified

15

Task Management

Task states in a typical RTOS:

Dormant

Waiting

Ready

Running

Interrupted

16

Task Management

State transitions of a task in a typical RTOS

Waiting for resourcesResources

available

Interrupt

ISR done

Task resumed

Task preempted

task deleted

17

Scheduler and Scheduling Policy

Scheduling algorithms generate a feasible execution sequence based on

task priority

task deadlines

resource requirements

Round Robin Earliest deadline First (EDF)

Maximum Urgency First (MUF)

Priority Ceiling Protocol (Resource based)

18

Interrupt Handling

RTOS Independent InterruptsISR preempts the RTOS and runs

Used for events that require accurate timing

• RTOS Dependant Interrupts:ISR is run within the RTOS

• RTOS should allow lower level ISR to be pre-empted by higher level ISR (RTOS Dependant Interrupts)

• ISR must complete as quickly as possible.

• Both Dependant and Independent ISRs can exist in one system

19

Clocks and Timers

Tick timerDecides granularity of system.

System response time limited by tick timerEg: 50 microsec motor control interrupt cannot be handled by a 1 millisec

tick timer OS.

Timer primitivesAllow user to specify “Run task every x unit of time” during task creation. eg: scan keyboard

20

Synchronization

Synchronization primitive used to provide:Mutual exclusion: Critical sections not accessed simultaneously

Conditional synchronization: Ensure tasks run in a specific order

• Synchronization constructs:Mutex (Binary semaphore)

Semaphore (Counting semaphore)

21

Synchronization and Semaphores

Two tasks and single bufferProducer task and consumer task

Consumer task to wait till producer task is done with buffer.

Synchronization and data integrity achieved by using a semaphore to lock access to buffer.

Issues:Deadlocks

Priority Inversion: Low priority thread obtains a lock that blocks a higher priority thread

22

Priority Inversion

Tasks L & H both need access to resource XTask L has locked this resource and hence delays H.Task M preempts L causing further delay to H; this is priority inversion

Ready to run

Running

time

preemption

Preemption after resource X released

High priority task H

Low priority task L

Medium priority task M

X

23

Inter Task Communication

Primary requirements/characteristics:Non-blocking communication

Bounded latency

Asynchronous communication

Shared Memory

Mailbox/Message Queues

24

Mailbox/Message Queue

Task 1

Task 3

Task 2

Mailbox 1

25

Memory Management

Memory Management Unit (MMU)Handles Virtual memory operations.

Memory protection esp. in process based OS

Dynamic memory allocationHeap; non-fragmenting memory allocation techniques

“Pool” allocation mechanism

26

Dynamic Memory allocation: RTOS heap

31 62 127 255 511 Buffer size

Free buffer list

27

RTOS classification based on architecture

Soft, Firm and Hard real-time

Pre-emptive, Non pre-emptive

Thread based, Process based

Scheduling policy: RM, EDF, RR, MUF etc

Dynamic, Static

Cost structure

28

RTOS aware debugging

Standard source level debugging not sufficient in multithreaded/multitasking environment.

Potential bugs:Data corruption due to improper synchronization

Deadlock

Starvation

Stack Overflow

Memory leaks

RTOS-aware debuggers provide tools that help detect such conditions for quicker debugging.

Extra windows showing state of all tasks (running, waiting etc), including buffers currently used by each task, semaphores used etc.

29

Buy vs Roll your Own

Factors:Cost Structure.

Support and documentation

Scalability

Portability

Debugging tools

Testing

30

Buy vs Roll your Own

Cost Structure.Royalty per product/ one time payment

Overall development, debugging, testing and support resources for in-house tool usually far outweigh investing in a commercial RTOS

Support and documentationInsufficient documentation

Small team responsible for R&D and maintenance

Commercial RTOSes are well documented with good support

31

Buy vs Roll your Own

ScalabilityIn-house tools are usually designed to meet exact specifications so it might be a good fit

Commercial vendors allow significant customization of the kernel (in some cases a GUI for this purpose), so the notion of too much overhead code is unfounded

Some commercial vendors also provide source code to allay engineer fears of “I cant see the code so I don’t know what’s going on”

32

Buy vs Roll your Own

PortabilityPorting an in-house solution to different hardware will require significant re-investment of time and resources

Commercial vendors have ports for all major hardware targets and will usually port to others as well

Debugging toolsDebugging tools have to be developed/ported for in house RTOS; usually takes 4x time needed to develop the RTOS

Commercial vendors have readily available debuggers and will port over desired features in most cases

33

Buy vs Roll your Own

TestingIn-house testing; takes 10x development time to properly test RTOS

Commercial RTOSes are sufficiently tested and have also been used by many customers so most bugs will have been ironed out.

34

Objectives: Recap

Identify embedded programming models

Understand basic RTOS definitions and concepts

Points to consider when you “Buy or roll your own”