Embedded Systems Introduction to Real-Time Operating Systems

Embedded SystemsIntroduction to Real-Time

Operating Systems C.-Z. Yang

http://syslab.cse.yzu.edu.tw/~czyang

Sept.-Dec. 2001

[email protected] Embedded Systems - Introduction to Real-Time Operating Systems

2

元智大學資訊工程系

OS Architectures

• A traditional UNIX system architecture


3


OS Architectures

• A monolithic OS kernel


4


OS Architectures

• A real-time kernel implementation


5


OS Architectures

• A micro-kernel RTOS


6


Case Study: Real Time or Real Linux? A Realistic Alternative

Paul N. Leroux

Technology Analyst

QNX Software Systems Ltd.


7


Using Linux as a Real-time OS

• For the embedded systems designer, Linux poses a dilemma.– Linux has a rich legacy of source code, and industry-stand

ard POSIX APIs.

– The standard Linux kernel can't deliver the "hard" real-time capabilities.

• Several innate problems– Process scheduling

– Preemptible kernel


8


Process Scheduling

• Preemptive priority– Rather than use a preemptive priority-based scheduler, as

an RTOS would, Linux implements a "fairness" policy so that every process gets a reasonable opportunity to execute.

– In fact, the OS will sometimes interrupt a high-priority process to give a lower-priority process a share of CPU time.


9


Preemption

• The standard Linux kernel isn't preemptible.– A high-priority process can never preempt a kernel call, bu

t must instead wait for the entire call to complete - even if the call was invoked by the lowest-priority process in the system.


10


Real Time Implemented Outside of Linux

• Running Linux as a task on top of a realtime kernel– Any tasks that require deterministic scheduling also run in

this preemptible kernel, but at a higher priority than Linux.


11


The Dual-kernel model

• System Operations– The realtime kernel always gets first dibs on hardware

interrupts.

– Otherwise, the kernel will pass the interrupt to Linux for processing.

• Advantages– All this work is invisible to applications running in the

Linux environment - except, of course, for the CPU cycles lost to the realtime kernel and its tasks.

– System development is very flexible.


12


Shortcomings of The Dual-kernel model

• Duplicated coding efforts– Tasks running in the realtime kernel can't make full use of

existing Linux system services.

• Fragile execution environment– Tasks running in the realtime kernel don't benefit from the

robust MMU-protected environment.

• Limited portability– With the dual-kernel approach, realtime tasks aren't Linux

processes at all, but threads and signal handlers written to a small subset of the POSIX API or, in some cases, a non-standard API.


13


Shortcomings of The Dual-kernel model

• No determinism for existing Linux applications and drivers– Because Linux processes don't run in the realtime kernel,

they don't gain any deterministic behavior.

• Limited design options– The APIs supported by the realtime kernel provide only a

subset of the services provided by standard POSIX and Linux APIs.


14


"Pure" Realtime Linux?

• It allows developers to use a standard Linux kernel and programming model.

• It helps address the low-latency requirements of reactive, event-driven systems.

• However, – such low-latency patches don't address the complexity of

most realtime environments.

– For example, modifications of the Linux driver and virtual file system (VFS) are needed.


15


Difficulties in a Pure Realtime Linux

• In any case, it's unclear which realtime modifications, will eventually be integrated into the standard Linux kernel.

• After all, most Linux-based systems rely on the kernel's current approach, which sacrifices predictability to achieve higher overall throughput.


16


The Best of Both Worlds

• The RTOS should be able to– allow Linux developers to keep their existing tools, source

code, and programming model

– maintain the key benefits, such as easier troubleshooting and OS customization, of Linux's open source model

– address the shortcomings of realtime Linux extensions


17


Several Problems

• How well can an RTOS support the Linux programming model?– The answer lies, to a great degree, in the POSIX APIs adop

ted by Linux.

– As a result, an RTOS can support the same POSIX APIs as Linux without adopting Linux's non-deterministic kernel.

• A need for a new lingua franca among embedded Linux developers.


18


QNX model

• A realtime, microkernel architecture


19


Embedded Linux: a new definition

• As a set of APIs, along with a test suite to measure conformance.

• As a result,– the RTOS inherently supports embedded Linux

applications, while simultaneously providing all the benefits of a true RTOS designed from the ground up for embedded systems.


20


More Benefits

• A tougher runtime model– This model provides an environment for realtime

applications that's inherently more robust than Linux - and certainly much tougher than the unprotected realtime kernels used in the dual-kernel approach.

• A unified environment– The realtime and non-realtime environments are one and

the same.


21


More Benefits

• Less duplicated effort– All drivers run in user space, so they can be developed

using standard source-level tools and techniques.


22


Background


23


An Embedded RTOS

• At boot-up time, your application usually gets control first, and it then starts the RTOS.

• Many RTOSs do not protect themselves as carefully from your application as do desktop OS.– For many embedded systems, it may not matter if the appli

cation takes the RTOS down with it: the whole system will have to be rebooted anyway.


24


An Embedded RTOS

• To save memory RTOSs typically include just the services that you need for your embedded system and no more.

• Most RTOSs allow you to configure them extensively before you link them to the application.


25


Several Purchase Options

• Run faster

• Use less memory

• Have a better API

• Have better debugging tools

• Support more processors

• Have more already-debugged network drivers


26


Tasks and Task States


27


Tasks

• The basic building block

• Three states


28


The Scheduler

• It keeps track of the state of each task and decides which one task should go into the running state.

• The schedulers in most RTOSs are entirely simpleminded about which task should get the processor:– They look at priorities you assign to the tasks.

• The scheduler assume that you knew what you were doing when you set the task priorities.


29


State Transitions

• A task will only block because it decides for itself that it has run out of things to do.

• While a task is blocked, it never gets the microprocessor.

• The shuffling of tasks between the ready and running states is entirely the work of the scheduler.


30


Some Common Questions

• How does the scheduler know when a task has become blocked or unblocked?– Through a collection of RTOS function calls.

• What happens if all the tasks are blocked?– The scheduler will spin in some tight loop somewhere

inside of the RTOS, waiting for something to happen.


31



• What if two tasks with the same priority are ready?– It depend upon which RTOS you use.

– At least one system solves this problem by making it illegal to have two tasks with the same priority.

– Some other RTOSs will time-slice between two such tasks.

– Some will run one of them until it blocks and then run the other.


32



• If one task is running and another, higher-priority task unblocks, does the task that is running get stopped and moved to the <ready> state right away?– A preemptive RTOS will stop a lower-priority task as

soon.

– A non-preemptive RTOS will only take the microprocessor away from the lower-priority task when that task blocks.


33


A Simple Example

• The classic situation

This task will be unblocked as soon as the user pushes a button.


34


A Simple Example

• The computational task


35


System Operations

• Transitions


36


Initialization Code

• Assigning the priorities


37


Features of Using an RTOS

• Two tasks can be written independently of one another, and the system will still respond well.

• The RTOS will make the response good whenever the user presses a button by turning the microprocessor over to the task that responds to the buttons immediately.


38


Tasks and Data


39


Context

• Each task has its own private context.– the register values,

– a program counter,

– a stack.

• All other data is shared among all of the tasks in the system.– Global

– static

– initialized

– ...


40


An Example

• A common data area


41


Sharing Data

• Two main functionsvRespondToButton vCalculateTankLevels


42


Shared-data problems

• Another example– Task2 interrupts Task1


43


A clearer examination

• The assembly code


44


A clearer examination

• The flow


45


Reentrancy

• Reentrant functions are – functions that can be called by more than one task and that

will always work correctly.

– Even if the RTOS switches from one task to another in the middle of executing the function.


46


Three Rules

• A reentrant function may not use variables in a nonatomic way unless they are stored on the stack of the task that called the function or are otherwise the private variables of that task.

• A reentrant function may not call any other functions that are not themselves reentrant.

• A reentrant function may not use the hardware in a nonatomic way.


47


A Review of C Variables

• Where will the variables in the following code be stored?


48


Applying the Reentrant Rules

• Is this example reentrant?


49


Gray Areas of Reentrancy

• A reentrant function may not use non-stack variables in a non-atomic way.

Is incrementing cErrors atomic?


50


A closer look

• A 8051 code • A 80x86 code


51


Semaphores and Shared Data


52


A Railroad Story

• The scenario


53


RTOS Semaphors

• take/release

• TakeSemaphore() and ReleaseSemaphore()

• A binary semaphore– Only one task can have the semaphore at a time.


54


A Typical Use

• The tank application


55


The Sequence of Events

• If the user presses a button while the levels task is still modifying the data and still has the semaphore,– The RTOS will switch to the “button task,” just as before,

moving the levels task to the ready state.

– When the button task tries to get the semaphore by calling TakeSemaphore it will block because the levels task already has the semaphore.

– The RTOS will then look around for another task to run.

– When the levels task releases the semaphore by calling ReleaseSemophore, the button task will no longer be blocked.


56


Execution Flow

• The flow


57


Execution Flow

• The flow


58


The Nuclear Reactor System

• Semaphore-related functions– OSSemPost(): release the semaphore

– OSSemPend(): take the semaphore

– OSSemCreate(): initialize the semaphore

• Related data structures– OS_EVENT: the data representing the semaphore

– WAIT_FOREVER: indicates that the task making the call is willing to wait forever

• Other functions– OSTimeDly(): block functions


59


The Code

• The data structures


60


The Code

• The main function


61


The Code

• Two tasks

A potential bug!


62


Reentrancy and Semaphores

• Now adding a semaphore to the previous code

Atomic now!


63


Multiple Semaphores

• Some RTOS allows you to have as many semaphores as you like.

• The advantages– In a system with only one semaphore, if the lower-priority

task takes the semaphore to change data, the higher-priority task might block waiting for the semaphore.

• How does the RTOS know which semaphore protects which data?– It doesn’t.– You must decide what shared data each of your semaphores

protects!


64


Semaphores as a Signaling Device

• Another common use of semaphores is as a simple way to communicate– from one task to another or

– from an interrupt routine to a task.

• For example,– printing task

– formatting task


65


The code

• The data structures


66


The functions

• Functions


67


The functions

• Functions


68


Semaphore Problems

• Do semaphores represent the solutions to all of our shared-data problems?– No!

• Semaphores should be also carefully used.


69


Semaphore Problems

• Forgetting to take the semaphore

• Forgetting to release the semaphore

• Taking the wrong semaphore

• Holding a semaphore for too long

• Causing a deadly embrace


70


An Example

• Priority inversion


71


Another Example

• Deadly embrace– Two tasks may all block.


72


Semaphore Variants

• Counting semaphores

• Resource semaphores

• Mutex semaphores


73


Ways to Protect Shared Data

• Disabling interrupts

• Using semaphores

• Disabling task switch

Embedded Systems Introduction to Real-Time Operating Systems

Documents