Scribd
Upload
33 views

Rtlinux: and Embedded Programming

This document provides an overview of RTLinux, an operating system that allows real-time and non-real-time tasks to run concurrently on a single system. It describes RTLinux as a small, hard real-time kernel that runs Linux as its lowest priority task. RTLinux schedules real-time tasks independently of Linux to ensure predictable and precise timing. The document outlines common real-time applications and discusses how RTLinux provides benefits such as low latency, efficient real-time performance, and the ability to leverage Linux utilities and development costs.

Uploaded by

gamble19844891
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
33 views

Rtlinux: and Embedded Programming

This document provides an overview of RTLinux, an operating system that allows real-time and non-real-time tasks to run concurrently on a single system. It describes RTLinux as a small, hard real-time kernel that runs Linux as its lowest priority task. RTLinux schedules real-time tasks independently of Linux to ensure predictable and precise timing. The document outlines common real-time applications and discusses how RTLinux provides benefits such as low latency, efficient real-time performance, and the ability to leverage Linux utilities and development costs.

Uploaded by

gamble19844891
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 44

RTLinux

and embedded programming


Victor Yodaiken Finite State Machine Labs (FSM)

RTLinux p.1/33

Outline.
The usual: denitions of realtime.

RTLinux p.2/33

Outline.
The usual: denitions of realtime. Who needs realtime?

RTLinux p.2/33

Outline.
The usual: denitions of realtime. Who needs realtime? How RTLinux works.

RTLinux p.2/33

Outline.
The usual: denitions of realtime. Who needs realtime? How RTLinux works. Why RTLinux works that way.

RTLinux p.2/33

Realtime versus Time Shared

Time sharing software: switch between different tasks fast enough to create the illusion that all are going forward at once.

RTLinux p.3/33

Realtime versus Time Shared

Time sharing software: switch between different tasks fast enough to create the illusion that all are going forward at once. Realtime software: switch between different tasks in time to meet deadlines.

RTLinux p.3/33

Hard realtime
1. Predictable performance at each moment in time: not as an average. 2. Low latency response to events. 3. Precise scheduling of periodic tasks.

RTLinux p.4/33

Soft realtime
Good average case performance Low deviation from average case performance

RTLinux p.5/33

Traditional problems with soft realtime


The chips are usually placed on the solder dots.

RTLinux p.6/33

Traditional problems with soft realtime


The chips are usually placed on the solder dots. The machine tool generally stops the cut as specied.

RTLinux p.6/33

Traditional problems with soft realtime


The chips are usually placed on the solder dots. The machine tool generally stops the cut as specied. The power almost always shuts off before the turbine explodes.

RTLinux p.6/33

New problems with soft realtime


The voice-over-IP system only loses packets under stress.

RTLinux p.7/33

New problems with soft realtime


The voice-over-IP system only loses packets under stress. The cell-phone connect wont drop your Internet handset during a handoff unless there is heavy trafc.

RTLinux p.7/33

New problems with soft realtime


The voice-over-IP system only loses packets under stress. The cell-phone connect wont drop your Internet handset during a handoff unless there is heavy trafc. If you start a browser on one machine, most of the time sales transactions wont get lost on the other side of your SOHO router.

RTLinux p.7/33

You dont really need hard realtime


We have one failure every 100 hours of operation on the average, but some customers experience 5 failures in an hour.

RTLinux p.8/33

You dont really need hard realtime


We have one failure every 100 hours of operation on the average, but some customers experience 5 failures in an hour. Tell em to stop being such whiners.

RTLinux p.8/33

You dont really need hard realtime


We have one failure every 100 hours of operation on the average, but some customers experience 5 failures in an hour. Tell em to stop being such whiners. Poor performance? More memory and a faster processor!

RTLinux p.8/33

You dont really need hard realtime


We have one failure every 100 hours of operation on the average, but some customers experience 5 failures in an hour. Tell em to stop being such whiners. Poor performance? More memory and a faster processor! Whats wrong with quad Itaniums, 8 Gig of memory, and a liquid cooling system on a $100 SOHO router?

RTLinux p.8/33

Hard realtime is needed


1. If "rare" timing failures are serious. 2. If precise timing makes a process possible. 3. If precise timing makes a performance advantage.

RTLinux p.9/33

Timing
1. A 30 microsecond delay can drop 20 Gig Ethernet packets. 2. 10 70hz video streams need packets unloaded at millisecond rates. 3. Time for 1 degree error on manipulator: 10 microseconds.

RTLinux p.10/33

Low end examples.


1. Replace a digital joystick with an analog joystick and a sound card. 2. Reduce control loop times by sampling A/D at 100 microseconds. 3. Log data over the network using Linux utilities with no software development costs. 4. Use Apache standard web server as a control interface with no software development costs.

RTLinux p.11/33

Larger examples.
Multiple software "Virtual routers" operating on packets in realtime. Interactive robot control with non-RT graphical interface.

RTLinux p.12/33

The RTLinux operating system


A small hard realtime operating system that runs Linux (or BSD) as its lowest priority task. Used for everything from making chain-saw chains, to switching packets to animating movies.

RTLinux p.13/33

One view of RTLinux

RTLinux p.14/33

Another view of RTLinux

RTLinux p.15/33

RTLinux is decoupled from Linux


RTLinux schedules itself Linux scheduler is not involved. Linux cannot delay or interrupt execution of RTLinux

RTLinux p.16/33

Results
1. Example on AMD SC520 133Mhz. Low latency response to events. 15microseconds or less. Precise scheduling of periodic tasks. 20 microseconds or less error. 2. On a standard PC: 19 microseconds and 50 microseconds 3. On SOCs we are in the single digits

RTLinux p.17/33

Programming model
1. For Realtime tasks and event handlers: POSIX Pthreads. 2. For Linux processes connection via POSIX I/O, shared memory, and signals. As standard as possible with no efciency loss.

RTLinux p.18/33

Programming view
1. The hard realtime component of realtime applications should run in a simple, minimal, predictable environment. 2. The non-realtime components should run in UNIX until something better is invented. 3. Hard realtime and non-realtime should be decoupled in operation.

RTLinux p.19/33

Programming interface
1. "Lean" POSIX threads for RT components, standard POSIX for non-RT components. 2. RTLinux can support alternate APIs. 3. API is programmer convenience: not technology fundamental.

RTLinux p.20/33

A typical simple application

RTLinux p.21/33

The simplest user side data logging program


cat < /dev/rtf0 > logfile

RTLinux p.22/33

How to use RTLinux

RTLinux p.23/33

Where is it used?
1. Communications: PBXs, routers, ... 2. Factory automation: machine tools, production lines. 3. Robotics: stepper motors, A/D, ... 4. Multimedia: animations, ...

RTLinux p.24/33

RTLinux Version 3.0


1. V1 was a research project. 2. V2 was the rst production version. 3. V3 is the rst industrial strength version. x86, Alpha, PPC, MIPS, smp support, ... 4. V4 on the way.

RTLinux p.25/33

But why not integrate RT into Linux?


Experience shows: performance limits and engineering costs.

RTLinux p.26/33

Why is decoupling so important?


1. Mars Lander almost broke because a low priority non-realtime process was able to lock a resource needed by a critical realtime task. The lock was hidden in complex code shared by all tasks, realtime and non-realtime. 2. RTLinux makes all interactions between RT and non-RT explicit and transparent .

RTLinux p.27/33

The RTLinux technical synergy.


1. Highly efcient realtime. 2. Connected to a reliable and powerful networked operating system (Linux). 3. Running on standard PCs, servers, and embedded hardware.

RTLinux p.28/33

The RTLinux cost advantage.


1. The costs of maintaining general purpose software data bases, networks, graphics, development, ... are shared with server and desktop companies. 2. Prototype on PCs. 3. Access to source is essential for important applications.

RTLinux p.29/33

Coming in V4
1. RT networking. (for industrial control and comms). 2. User mode RTLinux functions. 3. Failover technologies. 4. Optimizations.

RTLinux p.30/33

Finite State Machine Labs


1. Core kernel development and GPL and non-GPL RTLinux distributions. 2. Training, engineering services and product support. 3. Application software in communications and factory automation.

RTLinux p.31/33

Why non-GPL development


1. Some of our customers need it: niche products or close hardware/software interaction is common in embedded. 2. We need it: we cannot pay for development on contract services. 3. Our non-GPL is source to customers, but no rights to remarket our code.

RTLinux p.32/33

www.rtlinux.com

w.fsmlabs.com@

RTLinux p.33/33

You might also like