OS for Embedded Systems

What is an Embedded OS?

• An "embedded system" is any computer system or computing device that performs a dedicated function or is designed for use with a specific embedded software application.

• Embedded systems may use a ROM-based operating system or they may use a disk based system, like a PC. But an embedded system is not usable as a commercially viable substitute for general purpose computers or devices.

Introduction to Embedded Systems 2

What makes a good Embedded OS?

• • • • • • • Modular Scalable Configurable Small footprint CPU support Device drivers etc, etc, etc...

Introduction to Embedded Systems 3

What is Real Time?

“ A real time system is one in which the correctness of the computations not only depends upon the logical correctness of the computation but also upon the time at which the result is produced. If the timing constraints of the system are not met, system failure is said to have occurred.

”

- Donald Gillies

“ Real time in operating systems: The ability of the operating system to provide a required level of service in a bounded response time.

”

- POSIX Standard 1003.1

Introduction to Embedded Systems 4

What makes a good RTOS?

• • • • Multi-threaded and pre-emptible Thread priority has to exist because no deadline driven OS exists Must support predictable thread synchronization mechanisms A system of priority inheritance must exist

Introduction to Embedded Systems 5

Why use an RTOS?*

• • • An RTOS enables a design team to create a complex system that responds to every event with the right action at the right time,

every time.

Provides mechanisms to precisely synchronize a large number of tasks Reliable An RTOS provides mechanisms to handle faults, bugs, and other unexpected events that inevitably affect any system of embedded software When the level of complexity of an embedded system is such that partitioning the software into smaller, independently executing modules significantly lowers the overall design complexity and leads to greater system reliability Time-to-market pressure balances cost of the RTOS

* Mal Raddalgoda, QNX Software Systems, Ltd Introduction to Embedded Systems 6

• •

Pre-emptive schedule

General purpose operating systems are very democratic Every task or process has equal access to the CPU Scheduling decisions are based upon time sharing Tasks get to execute without interruption until their time slice is up Problem: If a less important task is running and a more important, deadline dependent task is pending, then the higher priority task must wait its turn

RTOSes are different!

Pre-emptive scheduling allows the higher priority task to take over the CPU from lower priority tasks Extends from application level code to drivers and interrupts

Introduction to Embedded Systems 7

Predictability

• • RTOSes must provide the designers with predictable performance data for system latencies Need to know best case and worst case scenarios for Task switching times Elapsed time from the completion of the last instruction of the prior task to the beginning of execution of the first task of the replacement process Measure of the overhead caused by the RTOS Interrupt handling Elapsed time from the arrival of the interrupt signal to the beginning of execution of the first instruction of the interrupt handler Worst case timing for a lower priority interrupt must take into account the time required to process all higher priority interrupts

Introduction to Embedded Systems 8

• • •

Selecting an RTOS - economic factors

Generally, we view RTOSes as intellectual property Pay a royalty to RTOS vendor for each copy of the RTOS that you deliver in your application ( annuity ) Example: WinCE royalty ~$15 per copy volumes > 10000 Cost of tools Some RTOS vendors supply complete development and debug environments for their customers One-stop shopping Products are well-integrated and work together Board support packages (BSP) Integrating an RTOS with your hardware platform ( target system ) is a non trivial exercise Requires expert knowledge of the O/S and hardware Is there an existing BSP for your hardware?

Pay the O/S vendor to do it? ( $50K - $1M )

Introduction to Embedded Systems 9

Selecting an RTOS - CPU issues

• • • • Has an RTOS been written and fine-tuned to your CPU choice?

Take advantage of specialized performance hardware on CPU?

Example: May contain shadow registers for rapid task switching May contain special registers for storing task tables context switching.

Key kernel functions written in assembly language for maximum performance Has performance of RTOS been fully characterized with your CPU?

Does the RTOS support the peripheral register set on your microcontroller?

Example: PowerPC 860 contains 200 registers for peripheral devices ( timers, ethernet ports, other O/S relevant I/O devices) require support Support for virtual and protected memory management?

Introduction to Embedded Systems 10

Selecting an RTOS - Application support

• • • • How many simultaneous tasks can the RTOS support?

How many interrupts can be supported?

Does RTOS vendor provide support services for specialized applications?

FAA and FDA certification of O/S for mission critical applications Protocol stacks for telecomm and datacomm ( TCP/IP ) Architecture of RTOS Flat memory model Applications and RTOS are built and linked as a single executable Entire address space of processor is available to O/S and all applications Generally fast, but very suceptible to crashes due to buggy code Errant pointers can overwrite critical kernel code

Introduction to Embedded Systems 11

Selecting an RTOS - Application support-2

• Microkernel architecture ( QNX ) Designed to support processors with on chip MMU’s Pentium, 386, 486, PowerPC, 68030-68060 Keeps a small portion of the RTOS,

microkernel,

in non-protected memory All other O/S services and applications are handled as tasks in protected memory Managed through the MMU ( See next slide ) Since each task is now isolated in its own protected memory space, errant pointers cannot crash the O/S Can write exception handlers to deal with buggy software Software executables can be built as a separate application programs, simplifying software development May be slower due to overhead of transferring from protected mode to microkernel services

Introduction to Embedded Systems 12

Task management with MMU

Physical address space Logical address space Segmented MMU Introduction to Embedded Systems 13

Microkernel RTOS

•

A microkernel RTOS implements a small

•

set of core services within the kernel itself Additional system services are provided through add-on processes.

•

Every driver, protocol, I/O manager, file system, graphics systems and GUI run in there own memory-protected address space

•

Task switch takes 1.95 uSEC on a 133 MHz Pentium CPU Source: QNX Introduction to Embedded Systems 14

WindRiver Products

Consulting Hardware Reference Boards Professional Services Vision Click Probe Doctor Design Systems Vision ICE Probe Software Development Tools SUPPORT Tornado Tools Prism Tools Hardware Software Int. Tools RealTime Software VxWorks OS VxWorks AE OS pSOS OS BSPs and Device Drivers Networks stacks & Protocols Introduction to Embedded Systems 15

• • • • • •

Why use an RTOS in the first place?

Application isolation Overrun protection Managing shared resources Memory management Predictability Reliability

Introduction to Embedded Systems 16

Application Isolation

• • • Why use a Real Time Operating System?

Answer: application isolation Why Isolate?

easier integration/debugging protection of critical applications decoupled design of apps Elements of Isolation Code/Data Corruption Exception Processing

Heap App 1 Q1 App Task 2 App Task 1 Kernel Tasks Kernel Objects Heap App 2 Q2 Sem 1 App Task 3 Introduction to Embedded Systems 17

Overrun Protection

• Why Protect Resources stack overruns heap overruns CPU lockouts • Applications are configured with limits on their memory and CPU resources • Overrunning will not damage other applications

Heap App 1 Q1 App Task 2 App Task 1 Introduction to Embedded Systems 19

Resource Reclamation

• • Issues Addressed avoid writing application clean up code avoid resource reclamation errors when an app completes Resources released when an application completes Heap memory Stack memory Shared Code memory (hidden) Shared Data memory (hidden)

Shared Data Heap App 1 Q1 App Task 2 App Task 1 Shared Code Kernel Tasks Introduction to Embedded Systems Kernel Objects 20

System Calls

• What is a system call?

We define a system call as being a call from a user mode protection domain to a kernel function • How do they work?

Linkage is via a linkage table in each PD to entry point An exception is generated which allows the OS to promote the task to supervisor mode

Shared Data User App #1 Shared Code User App #2 Link Table Kernel Introduction to Embedded Systems 21

But, How do We Share Code?

Shared Library Protection Domain

fooLib.o

int fooVal; void fooSet(int x) { fooVal = x; }

Application Domain 1 Application Domain 2

fooVal = 4 Task A

fooSet (4)

fooVal = 99 Task B

fooSet(99)

Introduction to Embedded Systems 22

VxWorks AE Overlapped Memory Model

Reserved Unmapped Unmapped Shared Data Modules SL PD Application PD1 Kernel Shared Library Modules Unmapped Application 1 Heap Unmapped Application 1 Modules Unmapped Kernel Application 1 Context Shared Data Modules Shared Library Modules Application 2 Modules Application 2 Heap Application 1 Modules Application 1 Heap Kernel Physical Memory Introduction to Embedded Systems Unmapped Application 2 Heap Unmapped Application 2 Modules Unmapped Kernel Application 2 Context SD PD Reserved Application PD2 Kernel 23

Complexity Forcing Standardization

Companies can’t afford (the time or the money) to choose and integrate a new supplier and a new software platform for every new project.

Circa 1995 Circa 2001 0% 20% 40% 60% 80% 100% Introduction to Embedded Systems Vendor Selection System Integration Development Test Manufacture 24

Products for Every Phase of Development

Hardware Bringup

Embedded Development Cycle

Driver & BSP Development RTOS Integration Application Development System Integration Manufacturing and QA WindLink Partner Products UGL, PersonalJWorks, and Zinc VxWorks, VxWorks AE, pSOSystem RTA Suite, WindView, and ESP SNiFF+ DIAB and GNU Compilers visionICE & visionPROBE emulation, visionCLICK & SingleStep Debuggers Reference Designs and Evaluation Boards visionWare visionWare Introduction to Embedded Systems visionWare 25

Inside an RTOS Development Environment

Wind River Systems’ Tornado Introduction to Embedded Systems 26

Tornado II Architecture Host: PC or UNIX

Standard Tornado Tools

Target

VxWorks 5.4

Scalable Run-time Real-time Embedded Application Tornado Plug-ins: WindView ScopePak, PerformancePak LOOK!

WFCs CodeTEST 3rd Party Tools SNiFF+ SingleStep (PPC) Diab Compiler & RTA (PPC) Simulation Environment VxSim File Systems Graphics Multi-processing Introduction to Embedded Systems Embedded Internet Networking Memory Protection POSIX Library wind Microkernel Debug Agent BSP 27

Cross-Development



Typical scenario:

1. Boot target.

2. Attach target server.

3. Edit & compile.

4. Download object module.

5. Test & Debug.

6. Return to 3 or 1 as necessary!

Ethernet RS-232 Development Host VxWorks Target Introduction to Embedded Systems 28

Developer’s Work Bench

Host-Based Tools

• Tornado Tools 3 • Compilers • Debuggers • Code Browsers • Project Manager • OS Configuration • Analysis Tools • Simulators

Host

Win, Linux, Solaris

Connections Target

ARM, MIPS, Pentium, PPC Virtual

Run-Time Components

• Board Support Package • VxWorks AE • Networking Stacks • Other Components • Your Application Serial BDM/JTAG

Hardware Debug Tools

• Target Ref Boards • BDM/JTAG Debuggers Ethernet

Only

Wind River

can provide complete, end-to-end

software & hardware

development solutions!

Introduction to Embedded Systems 29

Target Server / WDB Agent

Development Host Target WindSh CrossWind Browser WTX Protocol Target Server VxWorks WDB Protocol

(Ethernet, serial, netrom, custom)

WDB Application 3 rd Party

WTX = Wind River Tool eXchange

Introduction to Embedded Systems

WDB = Wind DeBug

30

VxWorks RTOS

Device Support Memory Management Scheduling & System Clock Facilities I/O system Synchronization & Intertask Communication File Systems Mutual Exclusion . . .

Networking Support Introduction to Embedded Systems 31

Board Support Package

• • • Most of VxWorks is independent of the particular target board used.

The board-specific code for initializing and managing a board’s hardware is called the BSP. The BSP provides VxWorks with standard hardware interface functions which allow it to run on a board.

The primary BSP source file, sysLib.c, lives in the BSP directory target\config\

bspName

. This is also the directory in which VxWorks may be reconfigured and rebuilt.

Introduction to Embedded Systems 32

VxWorks

• • VxWorks is a multitasking operating system optimized for real-time and embedded applications.

Low interrupt and context switch latency.

Low “system call” overhead.

Scalable.

Portable: well defined BSP.

VxWorks consists of core kernel facilities and peripheral facilities which depend on the kernel.

Loosely, kernel functions are those which can tasks.

directly change the states of

Introduction to Embedded Systems 33

What is a VxWorks Task?

• • A task is a

context of execution

. It has: a program counter (current location of execution).

private copies of CPU registers.

a stack for local variables, function arguments, and function call chain information.

As VxWorks is a uniprocessor system, only one task is actually executing at any given time.

When a task is not executing, its context is stored in its (TCB) and stack. The TCB is the data structure which the kernel uses to represent and control the task.

Task Control Block

Introduction to Embedded Systems 34

Performance Optimizations

• All tasks execute in the same address space: RAM fooLib.c

tTaskA fooSet(4)

text data bss static int x; void fooSet (int arg) { x = arg; }

tTaskB fooSet(99)

• All tasks execute at highest CPU privilege level.

Introduction to Embedded Systems 35

Task State Transition Diagram

PENDED READY EXEC

.

DELAYED PENDED & SUSPENDED SUSPENDED DELAYED & SUSPENDED Introduction to Embedded Systems 36

Preemptive Priority Scheduling

At any time, the highest priority task ready to run, runs!

A higher priority task which is made ready preempts the executing task.

Interrupts preempt any task.

Notes: On this board, INT 6 is the system clock, INT 3 is the network interrupt.

Introduction to Embedded Systems 37

Context Switches

• • • When one task stops executing and another task starts, a

switch

has occurred.

context

Context switches occur: If a higher priority task becomes ready to run made ready by executing task.

made ready in an interrupt, or times out on a blocking call.

If the executing task makes a blocking kernel call (moving into a delayed , or suspended state).

pended , What happens: CPU registers for outgoing task stored in its TCB.

CPU registers for incoming task retrieved from its TCB.

Introduction to Embedded Systems 38

Interrupt Service Routines

• • • • An ISR is a piece of code which is

connected

to a particular hardware interrupt. When the hardware interrupt occurs, the ISR runs.

ISR’s have an effective priority higher than any task.

Whether and how ISRs can preempt each other is board dependent.

An ISR has no permanent context; it is NOT a task.

An ISR may call only a limited set of VxWorks functions.

Basic rule of thumb: If a routine could block, an ISR cannot call it.

Introduction to Embedded Systems 39

Semaphores

• • • Semaphores are VxWorks kernel objects which allow blocking and unblocking of tasks, to coordinate tasks’ actions with those of other tasks and with external events.

VxWorks provides three varieties of semaphores: Binary (synchronization) semaphores.

Counting semaphores.

Mutex (mutual exclusion) semaphores.

Each type of semaphore is intended primarily for a particular kind of programming problem.

Introduction to Embedded Systems 40

Binary Semaphores

• • • Binary semaphores allow tasks to wait for an event without taking up CPU time polling.

The event might be an interrupt, or the action of another task.

Usage: Create the binary semaphore using semBCreate() A task which wishes to wait for the event calls semBTake() to block until the event occurs (or a specified time-out expires).

Whichever ISR or task detects or creates the event calls semBGive() to allow a waiting task to proceed.

Introduction to Embedded Systems 41

Mutex Semaphores

• • • Mutex semaphores are used when multiple tasks share a resource (data structure, file, hardware). When used correctly, mutex semaphores prevent multiple tasks from accessing the resource at the same time, and so corrupting it.

Usage: Create mutex for the resource with semMCreate().

A task wanting to use the resource first calls semMTake() to block until the resource is available (or time-out expires).

When done with the resource, a task calls semMGive() to allow other tasks to use the resource.

Introduction to Embedded Systems 42

Counting Semaphores

• • • • Binary semaphores keep track of whether or not an event has occurred, but not

how many times

last time the event was serviced).

the event has occurred (since the Counting semaphores keep a count of how many times the event has occurred, but not been serviced.

May be used to ensure that the event is serviced as many times as it occurs.

May also be used to maintain an atomic count of multiple equivalent available resources.

Introduction to Embedded Systems 43

Message Queues

• • FIFO buffers of bounded length messages.

Synchronization and mutual exclusion built in.

A task pends reading from empty queue, or writing to full queue. A time-out may be specified.

tConsumer msgQReceive(...) tProducer msgQSend (…) Introduction to Embedded Systems 44

Watchdogs

• • Watchdogs allow a routine to run after a specified delay, as part of the system clock tick ISR.

Used for high-reliability periodic polling, and deadline-miss detection.

Periodic Execution wwd = wdCreate(); wdStart (wd, period, myWdISR, arg); ...

void myWdISR (int param) { wdStart (wd, period, } myWdISR, param); doIt (param); Deadline-miss Recovery wd = wdCreate(); FOREVER { wdStart (wd, deadline, panicWd, arg); doWork(); } ...

void panicWd (int param) { /* Handle deadline miss */ } Introduction to Embedded Systems 45

VxWorks I/O System

• • Provides a consistent, familiar interface to various I/O devices and file systems.

Open a file/device by name with open().

Use the integer file descriptor read(), write(), and ioctl().

returned from open() in later calls to File descriptors may be shared among multiple tasks.

When all tasks are done with a file descriptor, have one task call close() so that the file descriptor may be reused.

Global or task-specific redirection of and

standard error

is possible.

standard input

,

standard output

,

Introduction to Embedded Systems 46

Additional I/O Support

• • • • • VxWorks supports the Standard C buffered I/0 library (ansiStdio, header file stdio.h): fopen(), fclose(), fread(), fwrite(), getc(), putc(), etc.

Built on top of VxWorks Basic I/O system.

Since the basic I/O system calls reach driver level very quickly (no protection boundary crossing overhead), buffered I/O may be less important.

VxWorks implements printf() in a separate library fioLib as an unbuffered call. This allows formatted output without support for buffering.

C++ Iostreams library provided.

Introduction to Embedded Systems 47

Local File Systems

• • • • • VxWorks provides an implementation of the DOS file system, dosFsLib.

Compatible with MS-DOS up to release 6.2.

File system may be used with local block devices such as SCSI, ATA, or floppy disk drives; or RAM disks.

To access the raw block device via the I/O system, rawFsLib may be used.

The module tapeFsLib may be used to access a SCSI sequential device (tape drive).

Introduction to Embedded Systems 48

VxWorks Network Support

• • Network interfaces: Ethernet PPP/SLIP/CSLIP Shared Memory Network (VME backplane) Custom Network Programming API’s: 4.3 BSD sockets.

zbuf (Zero-copy TCP/UDP) sockets.

Sun RPC.

Introduction to Embedded Systems 49

Network File Access

• VxWorks can act as client or server for remote file access:

Client VxWorks Server VxWorks Server Remote Host Client Remote Host Client: VxWorks target accesses files on remote host via NFS, FTP or RSH.

•

NFS

•

FTP or RSH nfsDrv netDrv, ftpLib Server: Remote host accesses files local to VxWorks target via NFS or FTP.

•

NFS

•

FTP nfsdLib, mountLib ftpdLib Introduction to Embedded Systems 50

• •

Software creation process

Objective: build an executable

image

constraints of an embedded system of the source software given the May or may not have operating system services Various code storage methods Mask ROM, EPROM, FLASH, Disk, distributed, On-chip Must account for variations in: Size of memory Boot-up procedures ROM-based or RAM-based execution Location of peripheral devices Memory mapped or I/O mapped Integrate the code modules ( files ) written by different team members Building code images from many different files MAKEFILES are a major source of burning resources

Introduction to Embedded Systems 51

Non-volatile storage

• • The vast majority of embedded systems do not have disk storage Code is typically held in non-volatile, solid-state memory EPROM: Electrically Programmable Read Only Memory EEPROM: Electrically Erasable Read Only Memory FLASH: Modern variant of EEPROM MASK ROM: Code is designed in at fabrication For cost-sensitive, high-volume applications ( N64 ) Code

may

be held in local disk memory Similar to PC’s Code may be remotely transferred from server or remote host Telecommunication systems Embedded controllers within computer systems Internet appliances Let’s look at this technology:

Introduction to Embedded Systems 52

• • • • • •

Other Than VxWorks?

Wind River Systems pSOS QNX Software Systems QNX Green Hills Software Integrity Mentor Graphics VRTX Palm Computing PalmOS Symbian SymbianOS • • • Embedded NT/XP “ Real-time ” control Windows CE (CE.NET) Internet devices Pocket PC 2002 Handheld PC ’ s and PDA ’ s

Introduction to Embedded Systems 53

• • • • • • • •

Commercial Embedded Linux

AMIRIX Embedded Linux derived from Debian Coollogic Coollinux combines Linux and Java for Internet apps Coventive Xlinux kernel can be as small as 143KB Esfia RedBlue Linux 400K, designed for wireless apps KYZO Pizza Box Linux SAMBA based file, print, CD server Lineo Embedix supports real time and high availability apps LynuxWorks BlueCat general purpose embedded solution MontaVista Linux general purpose embedded solution • • • • • • • • Neoware NeoLinux Red Hat derived for information appliances PalmPalm Tynux Internet appliance and multimedia Red Hat Embedded Linux general purpose embedded solution RedSonic Red-Ice Linux runs from DiskonChip or CompactFlash RidgeRun DSP Linux for multimedia, wireless, RT on DSP TimeSys Linux GPL low latency enhanced kernel Tuxia TASTE distro targets Internet appliances Vital Systems vLinux for ARM based embedded apps

Introduction to Embedded Systems 54

Open Source Embedded Linux

• • • • Embedded Debian Project convert Debian to an embedded OS ETLinux for PC104 SBC ’ s uCLinux for microprocessors that don ’ t have MM uLinux (muLinux) distro fits on a single floppy

Introduction to Embedded Systems 55

Commercial Linux RTOS

• • • • • • FSMLabs - Open RT Linux Lineo - Embedix Realtime LynuxWorks - BlueCat RT MontaVista Software - Real Time Extensions REDSonic - REDICE Linux TimeSys - Linux/Real-Time

Introduction to Embedded Systems 56

Open Source Linux RTOS

• • • • • ART Linux - real time extension based on RTLinux KURT - event schedules with 10us resolution Linux-SRT - for soft real time apps like multimedia Qlinux - provides Quality of Service guarantees RTAI “ hard ” Real Time Application Interface

Introduction to Embedded Systems 57

RTLinux

• • • • • • A “ hard real-time ” mini operating system runs Linux as it ’ s lowest priority execution thread Linux thread completely preemptible Real time threads and interrupt handlers never delayed by non-realtime operations Supports user level programming MiniRTL implementation fits on a floppy

Introduction to Embedded Systems 58

What

’

s so special about Linux?

• • • • • • • Multiple choices vs. sole source Source code freely available Robust and reliable Modular, configurable, scalable Superb support for networking and Internet No runtime licenses Large pool of skilled developers

Introduction to Embedded Systems 59

What

’

s so special about Linux?

Introduction to Embedded Systems 60

What

’

s special about Open Source?

Introduction to Embedded Systems 61

Flies in the Ointment

• • • • • • Lack of hardware device drivers Competing and/or lacking standards No formalized qualification testing No single source for marketing GPL license issues Startup vendors with shaky futures

Introduction to Embedded Systems 62

Projected Target CPU

’

s

Introduction to Embedded Systems 63

Any Development Tools Available?

• • • • • • QT/Embedded Other GUI/Windowing toolkits Arcom Control Systems GNUPro Tools Vendor specific Standard Linux toolset

Introduction to Embedded Systems 64

C or C++ for Development?

• • In general C is a better choice Advanced OOP features can cause code bloat C++ compilers can generate many routines for a single function Virtual methods and polymorphism slow program launch times significantly Size really

does

matter

Introduction to Embedded Systems 65

What

’

s It Being Used For?

• • • • • • • Control and Monitoring Applications Industrial Controllers TV Set Top Boxes (TiVO) Handheld PDA ’ s Automobile Computers Telecomm and Networking Hardware Myriad and sundry other uses...

Introduction to Embedded Systems 66

Target Applications

Introduction to Embedded Systems 67

The Embedded OS Market 2001

Introduction to Embedded Systems 68

The Embedded OS Market 2002

Introduction to Embedded Systems 69

Growth of Embedded Linux

Introduction to Embedded Systems 70

For Further Info

Web Sites

• • • • LinuxDevices.com http://www.linuxdevices.com/ Embedded Linux Consortium http://www.embedded-linux.org/index.php3

All Linux Devices http://alllinuxdevices.com/ Embedded Linux StarGate http://linux-embedded.com/

Introduction to Embedded Systems 71

For Further Info

Web Sites/Magazines

• Dr. Dobbs Embedded Systems http://www.ddjembedded.com/about/ • Embedded Linux Journal http://embedded.linuxjournal.com/ • Embedded Systems Programming http://www.embedded.com/mag.htm

Introduction to Embedded Systems 72