Applications and RTOSs

Instructor: G. Rudolph, Summer 2008 2

System Layers

Everything above hardware is softwareLayered Architecture

Hardware

Firmware

Application(s)/Programs

Instructor: G. Rudolph, Summer 2008 3

Command and Control App

This kind of application shows up over and over again in Embedded Systems

Simple Command ShellMay use serial portMay use internet if you assume network stack

is operational

Instructor: G. Rudolph, Summer 2008 4

Command Representation

NameHandlerOptional ParametersShell must build an internal representation

of any legal commandOne structure entry per commandIn C, we link names to function pointersIn OO systems, we would typically link a

command to an object rather than a method

Instructor: G. Rudolph, Summer 2008 5

Command Table

In text, all commands are in a single fileSingle place to look in the code

In Java, we “can’t” do that the same way, but we can do other thingsPut all command objects in the same packageModularity is usually better in long run than monolithic

files

Lejos JVM is written in C for efficiency and convenience. But JVM is an OS, not an application.

Instructor: G. Rudolph, Summer 2008 6

RTOS

Embedded System May or may not use an OS

Many RTOS’s availableRTOS is NOT democratic!Highest priority task that is ready to run

gets all the time it needsIf other tasks starve, it’s the programmer’s

fault

Instructor: G. Rudolph, Summer 2008 7

Reasons to Use an RTOS

If not using an RTOS, use alternate software frameworkMake writing programs easier

Multi-taskingSchedulingTimersInter-task communicationIsolate/manage software changes WRT

hardware

Instructor: G. Rudolph, Summer 2008 8

OS Kernel

SchedulerFIFOShortest task firstPriorityRound Robin

Intertask Communication MechanismsPipesQueuesShared Memory [Variables (Mutex’s)]

Instructor: G. Rudolph, Summer 2008 9

Real-time Scheduling Algorithms

Many tasks have deadlines, some may notReal-time ExecutiveEarliest deadline FirstMinimal Laxity FirstResource Reservation

Which algorithm you choose depends upon your goalsCritical timing constraints MUST be metMost RTOSs use preemptive multitasking scheme

Instructor: G. Rudolph, Summer 2008 10

Scheduling Points

Task CreationTask deletionClock TickTask BlockTask Unblock

Instructor: G. Rudolph, Summer 2008 11

Tasks/Threads

States: Ready, Running, Waiting, DeadSee Fig 10-4 pg. 180 of text

Current task will run until it terminates a higher task is ready to run it blocks waiting for external event or resource

Scheduler most often uses a Priority Queue for each non-running state to keep track of tasks

Each task has its own Call Stack and Context

Instructor: G. Rudolph, Summer 2008 12

Task Starvation

ProblemsProcessor overloadLow-priority tasks never get to runA bug in the code

SolutionsFaster ProcessorDifferent algorithmFix all bugs

Instructor: G. Rudolph, Summer 2008 13

Init task-specificresources

Wait for event

Handle Event/Do Work

Task Behavior

Code becomes a collection of tasks

Don’t know in which order tasks will be executed

Use “Run-to-completion” semantics when writing code

Instructor: G. Rudolph, Summer 2008 14

Intertask Communication

Goal: Avoid disabling interruptsMutex (binary flag) and Semaphore

(counter)

DangersDeadlockPriority Inversion

Instructor: G. Rudolph, Summer 2008 15

Message Queue

Pass messages between tasks using a Queue

Tasks + Message Queues + Eventsform the basis for coding reactive FSM frameworks

Instructor: G. Rudolph, Summer 2008 16

Really Real-time

Tasks have deadlines—a late answer is as bad as a wrong one best, worst and average interrupt handling

times

DeterministicCan calculate worst-case execution time of any

system call

Time Used for Context Switch