5. Vorwort
Der Lehrstuhl von Herrn Prof. Dillmann am Institut f¨r Anthropomatik der
u
Universit¨t Karlsruhe (TH) besch¨ftigt sich mit vielf¨ltigen Themen rund um
a a a
das Forschungsfeld der Robotik. Zu den Schwerpunkten z¨hlen mobile Service-
a
roboter und intelligente Fahrzeuge, maschinelles Lernen und Robotik in der
Medizin, um nur einige davon zu nennen.
Aus den laufenden Forschungsarbeiten am Institut ergaben sich in den letz-
ten Jahren zahlreiche Fragestellungen bei der Umsetzung spezieller Aufgaben
auf Linux-Systemen. Die Themen betrafen die Auswahl geeigneter Hardware-
Plattformen, die Komponentenanbindung, Netzwerkkommunikation, Software-
Entwicklung f¨r verschiedene Zielsysteme, Erstellung grafischer Benutzerober-
u
fl¨chen, Multithreading, Echtzeitf¨higkeit und Smart-Camera-Technologie.
a a
Die Antworten auf diese Fragen wurden zun¨chst in losen Blattsammlun-
a
gen festgehalten, teilweise in elektronischer Form dokumentiert oder auch nur
m¨ndlich weitergegeben. Das vorliegende Buch hat zum Ziel, das Wissen zu
u
strukturieren und zu b¨ndeln. Die Inhalte wurden hierzu systematisch aufge-
u
arbeitet, um Grundlagenwissen erg¨nzt und durch viele Beispielapplikationen
a
praxisgerecht veranschaulicht.
Embedded Linux ist mittlerweile das vierte Buch der Praxisbuchreihe, die nach
dem Start mit dem Buch Embedded Robotics im Jahre 2005 mit dem Praxisbuch
Computer Vision, und dessen englischsprachigem Pendant Computer Vision
– Principles and Practice, weitergef¨hrt wurde. Die zu diesen Themen vor-
u
liegenden Fachb¨cher sind oftmals als theoretische Lehrwerke konzipiert, ent-
u
sprechend trocken zu lesen und wenig hilfreich in der Praxis. Die Praxisb¨cher
u
sollen die Theorie ¨hnlich tiefgehend vermitteln, dar¨ber hinaus aber die In-
a u
halte um viele Versuche und Implementierungen erg¨nzen, die nicht nur im
a
Laborumfeld, sondern auch im produktiven Umfeld standhalten.
6. 6 Vorwort
Das entstandene Buch richtet sich an Studenten der Informatik und der Inge-
nieurswissenschaften, an Berufsanf¨nger, Praktiker und generell an alle Inter-
a
essierten.
Die vorgestellten Bibliotheken und Applikationen werden bei Erscheinen des
Buches online frei verf¨gbar sein. Der Download kann uber den Link auf der
u ¨
Website des Springer-Verlages oder uber http://www.praxisbuch.net erfol-
¨
gen.
Danksagung
Die Entstehung des vorliegenden Buches ist auch vielen anderen Menschen zu
verdanken, die bei den Implementierungen mitgewirkt, die Ergebnisse korri-
giert und viel Geduld mit den Autoren bewiesen haben. Es sind dies: Damira
Mambetova, Ulla Scheich, Susanne und Detlef Schr¨der, Steven Wieland, Tobi-
o
as Gindele, Manfred Kr¨hnert, Moritz Hassert, Alexander Bierbaum, Pedram
o
Azad, Alexander Kasper, Peter Steinhaus und Andreas B¨ttinger. Besonders
o
zu nennen sind an dieser Stelle auch Daniel Jagszent, der sein fundiertes Wis-
sen als Gastautor in Kapitel 12 eingebracht hat und Stephan Riedel, der die
Quelltext-Beispiele auf den verschiedenen Plattformen getestet hat.
Weiterhin m¨chten wir Herrn Prof. R¨diger Dillmann f¨r die Unterst¨tzung
o u u u
und f¨r das Vertrauen, das er in uns wissenschaftliche Mitarbeiter setzt, dan-
u
ken. Durch die hiermit verbundene Freiheit ist die Buchreihe der Praxisb¨cher
u
erst m¨glich geworden. Abschließend danken wir Frau Dorothea Glaunsinger
o
und Herrn Hermann Engesser vom Springer-Verlag f¨r die Motivation, Geduld
u
und die reibungslose und professionelle Zusammenarbeit.
Wir w¨nschen Ihnen viel Freude mit dem vorliegenden Buch und hoffen, Sie
u
f¨r den interessanten und zukunftstr¨chtigen Bereich der Embedded Systems
u a
unter Linux begeistern zu k¨nnen.
o
Karlsruhe, Das Autorenteam
den 5. Januar 2009
Hinweis
Die Informationen in diesem Buch werden ohne R¨cksicht auf einen eventuellen
u
Patentschutz ver¨ffentlicht. Die erw¨hnten Soft- und Hardware-Bezeichnungen
o a
k¨nnen auch dann eingetragene Warenzeichen sein, wenn darauf nicht geson-
o
dert hingewiesen wird. Sie sind Eigentum der jeweiligen Warenzeicheninhaber
und unterliegen gesetzlichen Bestimmungen. Verwendet werden u. a. folgende
gesch¨tzte Bezeichnungen: iPhone, Texas Instruments, Code Composer, Visi-
u
on Components, Sony, KEIL, µVision2.
15. 1
Grundlagen
1.1 Einfuhrung
¨
Eingebettete Systeme oder auch englisch, Embedded Systems, begegnen uns
mittlerweile uberall im Alltag. Im Handy, in der Waschmaschine, Klimaanla-
¨
ge, Digitalkamera, im Auto, in der DSL- und Hifi-Anlage, in der Spielekonsole.
Eine Besch¨ftigung mit diesem Thema ist entsprechend lohnenswert und in-
a
teressant. Aber wie lautet denn die genaue Definition der mittlerweile relativ
unscharf gebrauchten Bezeichnung? Zum Begriff der eingebetteten Systeme
existiert keine exakte DIN- oder ISO-Definition. Im Sprachgebrauch wird der
Begriff wie folgt verwendet:
Der Begriff des eingebetteten Systems bezeichnet einen Rechner (Mikrocontrol-
ler, Prozessor, DSP1 , SPS2 ), welcher dezentral in einem technischen Ger¨t,
a
in einer technischen Anlage, allgemein in einem technischen Kontext einge-
bunden (eingebettet) ist. Dieser Rechner hat die Aufgabe, das einbettende Sys-
tem zu steuern, zu regeln, zu uberwachen oder auch Benutzerinteraktion zu
¨
erm¨glichen und ist speziell f¨r die vorliegende Aufgabe angepasst.
o u
Dieser Versuch einer Definition umschließt mehrere Eigenschaften, einige ex-
plizit ausformuliert, einige als selbstverst¨ndlich zwischen den Zeilen vorausge-
a
setzt: Ein eingebettetes System ist vor Ort bzw. dezentral im Ger¨t, Fahrzeug
a
oder in der Anlage untergebracht. Es ist in Hard- und Software auf die jeweili-
ge Aufgabe zugeschnitten und entsprechend auch so einfach und preiswert wie
m¨glich gestaltet. Es ben¨tigt Schnittstellen zum Prozess, zu anderen Ger¨ten
o o a
und zur Außenwelt – hierunter f¨llt auch die Benutzerschnittstelle zum Anwen-
a
der. Wenn das eingebettete System eine schnelle Regelungsaufgabe bedient, so
1
Digitaler Signalprozessor: Spezialprozessor f¨r die Signalverarbeitung (Audio, Vi-
u
deo; allgemein: schnelle mathematische Funktionen).
2
Speicherprogrammierbare Steuerung: Steuerbaugruppe f¨r die Automatisierungs-
u
technik, programmierbar gem. der Norm EN 61131.
16. 18 1 Grundlagen
ist meist auch Echtzeitf¨higkeit gefordert. Da das System weiterhin fest in den
a
technischen Kontext eingebunden ist, ist es schlecht wartbar. Die Einheiten
m¨ssen entsprechend robust, wartungsarm und langlebig sein – eine Anforde-
u
rung, die auch eine geringe Temperaturentwicklung, geringe Leistungsaufnah-
me und damit niedrige Taktraten nach sich zieht. Aus dem gleichen Grund
sind auch mechanisch-bewegliche Komponenten wie L¨fter oder Festplatten
u
in solchen Systemen eher selten zu finden.
Der letzte Nebensatz des Definitionsversuches beschreibt die dedizierte Anpas-
sung an die gegebene Aufgabe. Entsprechend gelten auch im Sprachgebrauch
beispielsweise Organizer oder PDAs nicht als eingebettete Systeme, obwohl sie
viele der genannten Eigenschaften aufweisen. Diese Systeme sind bewusst nicht
an eine spezielle Aufgabe angepasst, sondern universell gehalten und k¨nnen
o
eine Vielzahl von Aufgaben ubernehmen.
¨
Im weiteren Text werden die Charakteristika eingebetteter Systeme genauer
¨
untersucht und auch anhand von Beispielen belegt. Um einen guten Uberblick
zu bieten, wird dabei in diesem Grundlagenkapitel noch keine Einschr¨nkung
a
hinsichtlich linuxbasierter Systeme vorgenommen.
Das Kapitel schließt nach dieser allgemein gehaltenen Einf¨hrung mit einer
u
Erl¨uterung zum Aufbau des vorliegenden Buches.
a
1.2 Architekturen, Plattformen und Geschichtliches
In Tabelle 1.1 wird die Entwicklung der Computertechnologie anhand der wich-
tigsten Meilensteine aufgezeigt. Hierbei wird die Mikrocontroller-Technologie
(MC) speziell f¨r eingebettete Systeme genutzt. In den fr¨hen Anf¨ngen wur-
u u a
de zwischen Mikroprozessoren und Mikrocontrollern noch nicht unterschieden;
erst mit dem Aufkommen von Derivaten mit Daten- und Programmspeicher
on board wurde die Bezeichnung Mikrocontroller gel¨ufig.
a
Mittlerweile kennzeichnet dieser Begriff Bausteine, die generell h¨her integriert
o
sind als Mikroprozessoren: Sie vereinen in monolithischer Bauweise den ei-
gentlichen Mikroprozessor, Speicher, das Bussystem, A/D-D/A-Wandler und
Schnittstellen zu seriellen Busssystemen (I2 C, RS-232, RS-485, CAN . . . ). Mi-
krocontroller, die f¨r spezielle Embedded-Anwendungen ausgelegt sind, be-
u
sitzen dar¨ber hinaus auch beispielsweise Hardware-Einheiten f¨r die Puls-
u u
breitenmodulation (Pulse Width Modulation, PWM), Quadratur-Decoder und
Capture-Compare-Einheiten.
Erste Embedded-Anwendungen wurden direkt in der Maschinensprache des
Controllers implementiert, sp¨ter erwies sich die Hochsprache C als ausrei-
a
chend maschinennah und erreichte eine weite Verbreitung. Mittlerweile wer-
den komplexe Embedded-Anwendungen meist in C++ programmiert. F¨r be- u
17. 1.2 Architekturen, Plattformen und Geschichtliches 19
sonders zeitkritische oder maschinennahe Programmteile k¨nnen Assembler-
o
Anweisungen aber auch jetzt noch in C/C++ als sog. Inline-Assembler-Code
eingebunden werden.
Neben der Entwicklung der h¨heren Programmiersprachen ver¨nderten sich
o a
auch die Anforderungen an die Betriebssysteme. Erste Mikroprozessoren besa-
ßen kein Betriebssystem, sondern nur einen sog. Bootstrap Loader, ein kleines
Programm im ROM des Controllers, welches beim Start die hinterlegten An-
wendungen l¨dt oder auch eine Verbindung zur Außenwelt zum Laden neuer
a
Programme herstellt.
Die quasiparallele Bearbeitung mehrerer Aufgaben wird im einfachsten Fall di-
rekt mit Interrupts realisiert. So k¨nnen kurze Routinen vom Timer-Interrupt
o
aufgerufen werden und auch externe Ereignisse einen (Hardware)-Interrupt
ausl¨sen. H¨ufig angef¨hrte Beispiele sind Aufzugsteuerungen oder Geldau-
o a u
tomaten. In beiden Beispielen muss der eingebettete Controller nicht nur die
Regelung der Motoren (Seilwinde, T¨rmechanik, Transportmechanik) und das
u
Auswerten der Sensoren im System (Drehgeber, Endschalter) abdecken, son-
dern auch eine Benutzerschnittstelle zur Außenwelt bedienen. Im einfachen
Fall des Aufzuges ist dies ein Bedien-Panel mit Tasten und eine Siebenseg-
mentanzeige. Im etwas komplexeren zweiten Beispiel werden im Regelfall eine
numerische Tastatur und ein Monitor eingesetzt.
Unter Verwendung des Timer-Interrupts und der damit m¨glichen Zuteilung
o
von Zeitscheiben zu Prozessen sind auch auf einfachen Mikrocontrollern Multi-
Threading-Anwendungen m¨glich, die Programmierung wird allerdings rasch
o
komplex und fehleranf¨llig. Mit der zus¨tzlichen Forderung der M¨glichkeit
a a o
einer Schnittstellenkapselung bzw. eines Treiberkonzeptes wurde entsprechend
der Wunsch nach einem Betriebssystem laut. Weiterhin werden mittlerweile
auch MP- und DSP-Boards in immer kleinerer Bauform hergestellt, und par-
allel steigt auch bei Embedded-Anwendungen der Ressourcenbedarf.
Entsprechend werden auch f¨r diese Anwendungen seit l¨ngerer Zeit nicht nur
u a
Mikrocontroller, sondern auch leistungsstarke Prozessoren mit leistungsf¨higen
a
Betriebssystemen eingesetzt. Typische Vertreter sind die ARM7/ARM9-
Prozessorfamilie, die TMS320-DSPs, die Atom-CPUs von Intel, die Modell-
reihe VIA Nano von VIA Technologies und die Geode-Familie von AMD.
Anzumerken ist, dass fast alle genannten Mikrocontroller-Technologien und
Entwicklungstechniken auch heute noch Anwendung finden. So haben moderne
32-bit-Controller die ersten 4- und 8-bit-Controller nicht g¨nzlich abgel¨st,
a o
sondern nur erg¨nzt. Ein Beispiel hierzu: die veraltete 8051-Technologie wird
a
auch aktuell noch von rund zw¨lf Herstellern angeboten, wobei auch modernste
o
Derivate einhundertprozentig befehlskompatibel zu der ersten Generation sind.
Ein Grund hierf¨r ist der wachsende Preisdruck. F¨r jede Anwendung wird
u u
der preiswerteste Controller verwendet, der f¨r die Aufgabe gerade noch in
u
Frage kommt. Weiterhin ist der Markt der eingebetteten Systeme ein tr¨ger
a
18. 20 1 Grundlagen
Jahr Entwicklungsschritt Kenngrößen Anmerkungen
1948 Herstellung erster Transistoren, Zuerst JFET Nach dem Patent von Julius
William B. Shockley Edgar Lilienfeld von 1925
1955 Herstellung des ersten Computers mit TRansistorized Airborne DIgital
Transistoren: der TRADIC, Bell Computer, entwickelt für die
Laboratories United States Air Force
1958 Erster integrierter Schaltkreis, monolithische Patent: „Solid Circuit made of
Jack S. Kilby Bauweise Germanium“
1961 Apollo Guidance Computer (AGC), monolithische Steuerrechner für das Apollo-
Charles Stark Draper / MIT Bauweise Raumfahrt-Programm
1961 Autonetics D-17 Guidance Computer monolithische Steuerrechner für die
Bauweise Minuteman-Raketen; erste
Mikroprozessor-Serienfertigung
1971 4004, Intel 4 bit Erste integrierte
Mikroprozessoren für
Taschenrechner
1972 8008, Intel 8 bit Erster 8-Bit-Prozessor
1974 TMS1000, Texas Instruments 4 bit Erster Mikrocontroller
1974 8080, Intel 8 bit MP
1974 6800, Motorola 8 bit MP
1975 8048, Intel 8 bit Erster MC mit RAM und ROM
1976 8748, Intel 8 bit MC mit EPROM
1976 TMS9000, Texas Instruments 16 bit MP
1977 Z80, Zilog 8 bit MP
1978 6805, Motorola 8 bit MC
1978 8086, Intel 16 bit MP
1979 68000, Motorola 16 bit MP
1979 2920, Intel 16 bit Erster DSP
1981 8051, Intel 8 bit MC
1983 TMS32010, Texas Instruments 32 bit Damals schnellster DSP auf dem
Markt; Grundsteinlegung der
TMS320-DSP-Familie
1983 IMS T400, INMOS 32 bit Erster Transputer für die
parallele Datenverarbeitung
1984 68HC11, Motorola 8 bit MC
1984 68020, Motorola 32 bit MP
1984 Erster FPGA, Ross Freeman / Xilinx Field-Programmable Gate Array
(FPGA), frei programmierbarer
Logikbaustein
1985 80386, Intel 32 bit MP
1987 ARM2, Acorn Computers Ltd. 32 bit Aktueller Stand: ARM9
RISC
1989 PICmicro, Microchip Technology Inc. 8 bit Low-Cost-MC; mitterweile auch
RISC 16 bit, 32 bit
1991 Erster FPAA, Edward Lee und Glenn Field-Programmable Analog
Gulak / Universität Toronto Array (FPAA), wie FPGA, zus.
auch analoge Schaltkreise
1993 C166/167, Siemens 16 bit MC
bis 2003 x86-Prozessorfamilie, Intel 32 bit MP; Intel ist Marktführer;
kleinere Hersteller: AMD, Cyrix
bis 2008 x86-Prozessorfamilie, Intel, AMD 32 bit MP: Intel und AMD
2005 Cell-Prozessorfamilie, Sony, 64 bit MP, Bsp.-Applikation: IBM
Toshiba,IBM (STI) Multi-Core Blade-PC; Sony Playstation 3
PowerPC
2008 Intel Atom, Intel 32 / 64 bit Low-Power-Design; Einsatz in
Low Power Mobile PCs und Embedded PCs
2008 VIA Nano, VIA Technologies 64 bit Low-Power-Design; höhere
x86 / x86-64 Leistung als Intel Atom;
Low Power demnächst: Dual-Core-Variante
Tabelle 1.1. Entwicklung der Mikroprozessoren und Mikrocontroller uber die Zeit
¨
(vgl. auch [Beierlein 04]).
19. 1.3 Eigenschaften eingebetteter Systeme 21
Markt. Die Maschinenbauer und Automatisierungstechniker weichen nur un-
gern von einer bew¨hrten Technik ab, da die Anspr¨che an die Systeme hin-
a u
sichtlich Sicherheit und Verf¨gbarkeit hier wesentlich h¨her sind als im PC-
u o
bzw. Consumer-Markt. Die Nutzung einer bew¨hrten Technologie uber einen
a ¨
Zeitraum von bis zu zehn Jahren ist keine Seltenheit, und so muss auch der
Halbleiter-Hersteller die langfristige Verf¨gbarkeit sichern.3
u
1.3 Eigenschaften eingebetteter Systeme
Einige der Eigenschaften eingebetteter Systeme wurden bereits in der Einf¨h-
u
rung angesprochen. Diese Charakteristika werden nun weiter ausgef¨hrt.
u
1.3.1 Formfaktor
Der Formfaktor eingebetteter Systeme ist im Regelfall ein anderer als bei
Standard-PCs, da die Baugruppen kompakter aufgebaut sind. Die g¨ngigen
a
Formfaktoren sind in Abbildung 1.1 zusammengestellt.
Erg¨nzend seien angef¨hrt: das Euro-Format (160×100 mm2 ), das halbe Euro-
a u
Format (80×100 mm2 ) und das VESA 75/100-Format4 f¨r Ger¨te, die auf die
u a
Aufnahme an der R¨ckseite eines Standard-VESA-Monitors passen. Es exis-
u
tiert dar¨ber hinaus aber auch eine Vielzahl von herstellerspezifischen Sonder-
u
formaten.
1.3.2 Mechanik, K¨ hlung, Robustheit
u
Eingebettete Systeme besitzen im Regelfall keine mechanisch-beweglichen
Komponenten. Die Prozessoren werden mit moderaten Taktraten betrieben
und k¨nnen entsprechend l¨fterlos passiv gek¨hlt werden. Der Vorteil eines
o u u
niedrig getakteten, l¨fterlosen Systems liegt auf der Hand: Die Komponen-
u
ten erw¨rmen sich weniger stark und haben daher eine l¨ngere Lebensdauer,
a a
das Geh¨use ben¨tigt keine Lufteinlass¨ffnungen und kann daher staubdicht
a o o
ausgef¨hrt werden (vgl. auch Schutzarten: IP54, IP65 usw.).
u
Dar¨ber hinaus werden eingebettete Systeme oft auch f¨r einen gr¨ßeren Tem-
u u o
peraturbereich spezifiziert, da die Prozessoren beispielsweise im Kfz einer viel
gr¨ßeren Temperaturschwankung ausgesetzt werden als im Standard-PC im
o
B¨ro. Je nach Einbauposition des Systems in der Fahrgastzelle kann hier ein
u
Temperaturbereich von bis zu −50 ℃ bis +120 ℃ erforderlich sein.
3
Beispiele: AMD garantiert f¨nf, Intel mittlerweile sieben Jahre Verf¨gbarkeit.
u u
4
Die Aufnahmebohrungen befinden sich an den Ecken eines Quadrates mit der
Kantenl¨nge 75 bzw. 100 mm. Der Monitor besitzt passend hierzu an der R¨ckseite
a u
vier M4-Gewinde.
20. 22 1 Grundlagen
Abb. 1.1. G¨ngige Formfaktoren in der Industrie [WhichSBC 08].
a
1.3.3 Speichermedien
Als Festspeichermedien kommen selten Festplatten, meist Flash-Speicher im
Controller oder auf dem Board oder auch in Form von SD- oder CF-Cards zum
Einsatz [Wikipedia 08, Solid State Drive]. Der Grund hierf¨r ist die h¨here
u o
Verf¨gbarkeit bzw. Robustheit dieser Medien. Weiterhin ist oft ein Verzicht auf
u
mechanisch-bewegliche Komponenten gefordert, und auch die Einbaulage des
Systems soll frei w¨hlbar sein – mechanische Festplatten weisen hier oftmals
a
Beschr¨nkungen auf.
a
Beim Einsatz von Flash-Speichermedien ist zu beachten, dass die Anzahl der
Schreibzugriffe minimiert werden sollte. Zwar verf¨gen moderne CF- und SD-
u
Karten und USB-Sticks uber internes Block Journaling und Wear Leveling 5 ,
¨
sie k¨nnen aber hinsichtlich der Langlebigkeit bei vielen Schreibzugriffen mit
o
modernen Festplatten noch nicht gleichziehen. Bei Karten ohne eigenen Con-
troller, z. B. vom Typ SmartMedia (SM), ist ohnehin gr¨ßte Vorsicht geboten.
o
5
Es handelt sich um Optimierungsverfahren, die die Schreibzugriffe pro Sektor mi-
nimieren.
21. 1.3 Eigenschaften eingebetteter Systeme 23
Hier empfiehlt sich die Verwendung eines geeigneten Dateisystems wie bei-
spielsweise jffs26 .
¨
Weiterhin kann auch durch die Uberdimensionierung des Speichermediums ein
gewisses Maß an Sicherheit und Langlebigkeit erkauft werden – der Faktor ist
n¨herungsweise gleich (n-fach uberdimensioniert bedeutet n¨herungsweise n-
a ¨ a
fache Anzahl m¨glicher Schreibzugriffe).
o
Eine weitergehende Untersuchung zur Langzeittauglichkeit von Flashspeicher-
medien ist zu finden unter [ct 08, Heft 23/06, S. 136]. Hier wurden im Rah-
men eines Langzeittests auf einer Datei 16 000 000 Schreiboperationen durch-
gef¨hrt, und die Datei war noch immer fehlerfrei lesbar. In diesem Test
u
wurde nicht auf physikalische, sondern auf logische Sektoren geschrieben.
Entsprechend ist hieraus eher auf die Leistungsf¨higkeit der Wear-Leveling-
a
Algorithmen, als auf die Haltbarkeit der Flash-Bausteine zu schließen.
Bei den in den Speichermedien eingesetzten Flash-Speicherbausteinen in
NAND-Bauweise existieren zwei Bauformen: In den Standard-Consumer-
Medien werden sog. Multi-Level-Cell-Chips (MLC-Chips) verwendet, f¨r die
u
die Hersteller um die 10 000 Schreibzyklen angeben. Bei den h¨herwertigen
o
Medien werden Single-Level-Cell-Chips (SLC-Chips) verbaut, die rund drei-
mal schneller beschreibbar sind und auch eine h¨here Lebensdauer von ca.
o
100 000 Schreibzyklen aufweisen (Quelle: der Flash Memory Guide von Kings-
ton, [Kingston 08]). Nach der Information, in welchen Produkttypen nun SLC-
bzw. MLC-Chips verbaut sind, muss der Anwender u. U. ein wenig suchen. F¨r
u
Kingston-Medien findet sich die Information auf der letzten Seite des Flash
Memory Guide.
1.3.4 Schnittstellen
Eingebettete Systeme besitzen im Regelfall zus¨tzliche Schnittstellen symme-
a
trischer Art (RS-422), Busschnittstellen (Inter-IC-Bus (I2 C)), Feldbusschnitt-
stellen (RS-485; CAN und Profibus auf RS-485), digitale Ein- und Ausg¨nge a
(DIOs), analoge Ein- und Ausg¨nge und Schnittstellen zu bestimmten LC-
a
Displays.
Auch auf Standard-PC-Boards lassen sich die meisten dieser Schnittstellen
nachr¨sten, und so kommen immer h¨ufiger USB-IO-Wandler, USB-RS-485-
u a
Wandler oder ¨hnliche Baugruppen zum Einsatz.
a
Etwas komplexer wird der Sachverhalt, falls echtzeitf¨hige IOs gefordert sind.
a
Hier versagen Umsetzer von USB nach I2 C oder von Ethernet nach DIO, da die
6
Journaling Flash File System, ein Dateisystem, welches speziell f¨r Flash-
u
Speichermedien ausgelegt ist und die Wear-Leveling-Funktionalit¨t bereits
a
enth¨lt.
a
22. 24 1 Grundlagen
¨
zwischengeschalteten seriellen Ubertragungsstrecken zu große Latenzen auf-
weisen. Dies ist auch ein Grund, weswegen die parallele Schnittstelle gem.
IEEE 1284 zumindest im Embedded-Bereich noch lange nicht ausgedient hat.
1.3.5 Stromversorgung
Die Stromversorgung eingebetteter Systeme ist im Regelfall einfach aufgebaut.
Die Systeme kommen meist mit einer geringen Anzahl von Versorgungsspan-
nungen aus (Bsp.: durchg¨ngig 5 VDC) bzw. generieren weitere Spannungen
a
on board, und weisen auch durch die kleineren Taktraten und das Fehlen me-
chanischer Komponenten einen geringen Stromverbrauch auf.
Ein weiterer Vorteil hierbei ist die M¨glichkeit, einen mobilen Akku-Betrieb
o
einfacher umsetzen zu k¨nnen. Anwendungen finden sich beispielsweise im Kfz
o
oder auch in einem fahrerlosen Transportfahrzeug (FTF) in der Fertigung.
1.3.6 Chips¨tze
a
Die in eingebetteten Systemen verwendeten Chips¨tze sind oft andere als bei
a
Standard-PCs. Zum einen bieten die Chips¨tze teilweise zus¨tzliche Schnitt-
a a
stellen oder Funktionalit¨ten7 , zum anderen m¨ssen sie auch sehr viel l¨nger
a u a
lieferbar sein, da Industriekunden eine Sicherheit von bis zu zehn Jahren f¨r die
u
Ersatzteilstellung fordern. Weiterhin sind die verwendeten Chips¨tze und Pro-
a
zessoren nicht auf Geschwindigkeit optimiert, sondern auf Robustheit, kleinen
Platzbedarf und geringe Herstellungskosten.
Aktuell zeichnet sich hierbei ein interessanter neuer Trend ab: Die Low-Power-
Embedded-Prozessoren und Chips¨tze Atom (Fa. Intel) und Nano (Fa. VIA)
a
haben sich auch als sehr geeignet erwiesen f¨r den Einsatz in der jungen Pro-
u
duktfamilie der sog. Netbooks8 .
Dieser neue Trend im Consumer-Markt hin zu stromsparenden, robusten
und preiswerten PCs wird voraussichtlich auch weiterhin auf den Markt der
Embedded-PCs einen großen Einfluss haben.
1.3.7 Watchdog
Eingebettete Systeme verf¨gen im Regelfall uber einen sog. Watchdog. Es han-
u ¨
delt sich hierbei um einen Z¨hler, der hardwareseitig st¨ndig inkrementiert
a a
7
Bspw. sog. General Purpose Inputs/Outputs (GPIOs).
8
Preiswerte, besonders baukleine Notebook-PCs ohne Laufwerke, teilweise auch
ohne mechanische Festplatte.
23. 1.3 Eigenschaften eingebetteter Systeme 25
¨
wird und der beim Uberlauf (im Fehlerfall) das System neu startet. Entspre-
chend muss der Z¨hler im fehlerfreien Betrieb vom laufenden Hauptprogramm
a
oder auch vom Betriebssystem regelm¨ßig zur¨ckgesetzt werden. Dieserart ist
a u
gew¨hrleistet, dass das System, das u. U. schwer zug¨nglich in einer Anlage
a a
verbaut ist, im Fehlerfall selbstst¨ndig wieder anl¨uft.
a a
Je nachdem, welcher Prozess den Z¨hler zur¨cksetzt, k¨nnen blockierende Feh-
a u o
ler im Betriebssystem und/oder Fehler im Anwenderprogramm erkannt wer-
den. Zu weiteren Details vgl. Abschnitt 5.6 und die dort vorgestellte Watchdog-
Implementierung.
1.3.8 Echtzeitf¨higkeit
a
Der Begriff der Echtzeit bzw. Real-time wird mittlerweile nicht nur im Zusam-
menhang mit schnellen Regelungen, sondern auch in vielen anderen Bereichen
wie z. B. im Multimedia-Bereich verwendet und wurde entsprechend in den
letzten Jahren ein wenig verwaschen. An dieser Stelle sollen nun f¨r den Ge-
u
brauch im vorliegenden Buch die Begriffe nochmals klar dargelegt werden.
Die DIN 44300, Teil 9 definiert den Begriff der Realzeitverarbeitung (Real-time
Processing) wie folgt: Eine Verarbeitungsart, bei der Programme zur Verarbei-
tung anfallender Daten st¨ndig ablaufbereit sind, derart, dass die Verarbei-
a
tungsergebnisse innerhalb einer vorgegebenen Zeitspanne verf¨gbar sind. Die
u
Daten k¨nnen je nach Anwendungsfall nach einer zeitlich zuf¨lligen Vertei-
o a
lung oder zu bestimmten Zeitpunkten anfallen.
Hier wird entsprechend gleichgesetzt: Echtzeit = Rechtzeitigkeit. Tats¨chlich
a
kann die Verarbeitung aber auch zu schnell erfolgen, bzw. es k¨nnen Ergeb-
o
nisse zu fr¨h vorliegen. Je nach System sind die folgenden unterschiedlichen
u
Zeitbedingungen einzuhalten (vgl. auch [W¨rn 05]):
o
Exakter Zeitpunkt: Bei dieser zeitlichen Bedingung wird ein exakter Zeit-
punkt t0 definiert, bei welchem die Aktion stattfinden muss. Wird der
Zeitpunkt nicht eingehalten, so arbeitet das System nicht mehr inner-
halb seiner Spezifikation. Ein Beispiel hierf¨r ist das Einfahren eines ICE-
u
Personenzuges in den Bahnhof. Hier muss der Bremsvorgang exakt zum
gegebenen Zeitpunkt t0 erfolgen, da sonst die Wagen nicht mehr innerhalb
der ausgewiesenen Bahnsteigbereiche zum Halten kommen.
Sp¨tester Zeitpunkt: Hier wird ein maximaler Zeitpunkt tmax angegeben,
a
bis zu welchem ein Ereignis stattfinden muss. Ein typisches Beispiel ist das
Halten einer Lore in einem fahrerlosen Transportsystem an einem gegebe-
nen Haltepunkt (rote Ampel). Das Fahrzeug darf auf keinen Fall sp¨ter a
halten und in den Kreuzungsbereich hineinfahren. Ein etwas verfr¨hteru
Halt ist aber vertretbar.
24. 26 1 Grundlagen
Fr¨ hester Zeitpunkt: Hierbei wird ein minimaler Zeitpunkt tmin angege-
u
ben, der einzuhalten ist. Ein klassisches Beispiel ist die Abh¨ngigkeit von
a
einem anderen Ereignis. So darf das Entladen einer Lore fr¨hestens dann
u
erfolgen, wenn diese die Entladestation erreicht hat, aber auch sp¨ter.
a
Zeitintervall: Hier wird ein Zeitbereich zwischen tmin und tmax f¨r eine
u
m¨gliche Bearbeitung angegeben. Ein Beispiel hierf¨r ist wieder der Ent-
o u
ladevorgang der Lore. Je nach Systemkonfiguration muss die Lore zu einer
bestimmten Zeit (sp¨testens) den Entladeplatz verlassen haben, da bereits
a
die n¨chste Lore ankommt.
a
Absolute und relative Zeitbedingung: Eine absolute Zeitbedingung ist in
Form einer Uhrzeit angegeben. Ein Beispiel: Das Flugzeug muss fr¨hestens,
u
exakt oder sp¨testens um 15:00 Uhr starten. Eine relative Zeitbedingung
a
ist in Form eines Zeitbereiches und in Abh¨ngigkeit von einem anderen
a
Ereignis angegeben. Ein Beispiel: Der Stellwert in einer Regelung muss
fr¨hestens, exakt oder sp¨testens 2 s nach dem Vorliegen des Istwertes
u a
ausgegeben werden.
Periodizit¨t: Periodische Ereignisse sind immer wiederkehrend. Ein typi-
a
sches Beispiel ist eine Regelstrecke, bei welcher nach jedem Regelintervall
die errechneten Stellwerte ausgegeben und neue Istwerte von den Sensoren
eingelesen werden.
Synchronit¨t: Bei einem synchronen System erfolgt die zeitliche Abarbei-
a
tung der Prozessschritte in einem festen Raster, gebunden an einen Master-
Takt. Ein Beispiel hierf¨r ist ein System zur Achslageregelung. Hier ist
u
die Abtastrate des unterlagerten Drehzahlreglers zeitlich synchron an jene
des Lagereglers gebunden bzw. ein ganzzahliges Vielfaches davon (Abbil-
dung 1.2).
Abbildung 1.2 zeigt ein Beispiel f¨r ein System mit mehreren parallelen
u
Echtzeit-Tasks. Hier werden auch die Begriffe Periodizit¨t und Synchronit¨t
a a
rasch klar.
Harte Echtzeit: Die Anforderung der harten Echtzeit liegt dann vor, wenn
bei Nichteinhalten der Zeitbedingung Schaden droht. Ein typisches Beispiel
ist der besagte Transportroboter, der auf eine rote Ampel zuf¨hrt. F¨r die
a u
harte Echtzeitbedingung gilt: Wenn das System die Bedingung verletzt,
so arbeitet es außerhalb seiner Spezifikation und muss in einen sicheren
Zustand uberf¨hrt werden (abgeschaltet werden).
¨ u
Feste Echtzeit: Die Anforderung der festen Echtzeit liegt dann vor, wenn bei
Nichteinhalten der Bedingung zwar kein Schaden droht, aber das Ergebnis
der Operation wertlos wird.
Weiche Echtzeit: Die Bedingung der weichen Echtzeit liegt vor, wenn die
vorgegebenen Zeiten eher als Richtgr¨ßen, denn als feste Vorgaben zu sehen
o
sind. Ein typisches Beispiel ist ein Multimedia-System, bei welchem bei der
25. 1.4 Betriebssysteme 27
Idle Task
Kommunikation
nichtzyklisch
Vorbereitung
nichtzyklisch
Interpolator
zyklisch
Lageregler
zyklisch, t
periodisch
Interpolatortakt: ti
Lageregeltakt: tl
Abb. 1.2. Eine Robotersteuerung als Beispiel f¨r ein echtzeitf¨higes, synchrones
u a
System.
Filmwiedergabe ein selten auftretendes Ruckeln noch problemlos toleriert
werden kann.
Die verschiedenen M¨glichkeiten der Realisierung dieser Bedingungen werden
o
im nachfolgenden Abschnitt 1.4 weiter ausgef¨hrt.
u
1.4 Betriebssysteme
1.4.1 Allgemeine Anforderungen
Wie bereits angesprochen, ist f¨r ein einfaches eingebettetes System ein Be-
u
triebssystem nicht unbedingt erforderlich. Im einfachsten Fall der diskreten
Regelschleife besteht das Programm aus einer einzigen Hauptschleife, welche
ohne Unterbrechung (ohne Interrupts) ausgef¨hrt wird. Am Ende eines Schlei-
u
fendurchlaufes werden die berechneten Gr¨ßen ausgegeben und von den Sen-
o
soren neue Istwerte eingelesen.
Derart einfache Systeme sind in der Praxis nur selten ausreichend. Meist ist
neben der Regelung noch eine komplexe Kommunikationsroutine aufzurufen,
es sind externe Interrupts von Achs-Endschaltern zu bearbeiten und Ausga-
ben weiterer Sensoren f¨r Temperatur u. ¨. zu behandeln. Oft kommt weiterhin
u a
noch eine Benutzerschnittstelle hinzu. Sp¨testens jetzt ist der Einsatz eines Be-
a
triebssystems sinnvoll; es organisiert und priorisiert den quasiparallelen Ablauf
der einzelnen Tasks in Zeitscheiben, es bietet eine Kapselung f¨r Schnittstellen,
u
verwaltet den Arbeitsspeicher und regelt den Zugriff auf Festspeichermedien
uber ein Dateisystem.
¨
26. 28 1 Grundlagen
Abweichend von den klassischen Betriebssystemen, wie sie bei Desktop-PCs
zum Einsatz kommen, wird bei eingebetteten Systemen weiterhin oft die Da-
tenverarbeitung zu harten Echtzeitbedingungen gefordert. Hierzu wiederum
eine Definition:
Ein Echtzeitbetriebssystem ist ein Betriebssystem, das die Konstruktion eines
Echtzeit-Systems erlaubt. [Marwedel 07]
Aus diesen Anforderungen an ein Echtzeitbetriebssystem erwachsen auch be-
stimmte Anforderungen an die Interrupt-Behandlung und an das Scheduling-
Verfahren (vgl. Abschnitt 1.4.2). In Tabelle 1.2 sind die Eigenschaften von
konventionellen Betriebssystemen und Echtzeitbetriebssystemen einander ge-
gen¨bergestellt.
u
Konventionelles Betriebssystem Echtzeit-Betriebssystem (RTOS)
Logisch korrekte Ergebnisse Logisch und zeitlich korrekte
Ergebnisse
Keine Garantie für die maximale Garantierte Antwortzeit (Latenz);
Antwortzeit, Zeitüberschreitungen bei harten Echtzeitanforderungen
sind tolerierbar sind Zeitüberschreitungen fatal
Effizientes, aber nicht einfach Vorhersagbares und kontrollierbares
vorhersagbares Scheduling Scheduling
Optimiert auf maximalen Optimiert auf minimale
Datendurchsatz Antwortzeiten, typisch um die 20 μs
Optimiert auf den Optimiert auf den maximalen
durchschnittlichen Lastfall Lastfall (Worst Case)
Langsamer Scheduler, geringe Schneller Scheduler, hohe zeitliche
zeitliche Auflösung und Genauigkeit Auflösung und Genauigkeit, typisch:
(Standard-Linux: 10 ms) 20—200 μs
Standard-Scheduling-Verfahren: Deterministische Scheduling-
Time-Sharing, First Come First Verfahren wie Earliest Deadline
Served, Round-Robin, Round-Robin First; kurze und deterministische
mit Prioritätsklassen Zeiten für Taskwechsel
Nur Systemprozesse laufen im Systemprozesse und zeitkritische
Kernelmode Anwenderprozesse laufen im
Kernelmode
Periodischer Timer-Interrupt Nicht zwingend periodischer, aber
hochaufgelöster Timer-Interrupt
(Stichwort: One-Shot-Timer)
Teilweise langes Sperren (Maskieren) Schnelle Interrupt-Behandlung
der Interrupts
Tabelle 1.2. Gegen¨berstellung der Eigenschaften der Betriebssysteme.
u
http://www.uni-koblenz.de/~agrt/lehre/ws2003/SeminarEchtzeitsysteme/marco_lang.pdf
http://www.fh-wedel.de/~si/seminare/ws01/Ausarbeitung/6.linuxrt/LinuxRT0.htm
27. 1.4 Betriebssysteme 29
1.4.2 Prozess-Scheduling
Der sog. Scheduler ist jener Teil des Betriebssystems, der den Prozessen bzw.
Tasks den Prozessor bzw. die Rechenzeit zuteilt.9 F¨r diese Zuteilung sind
u
mehrere Algorithmen gebr¨uchlich, wobei die Auswahl von der jeweiligen An-
a
wendung abh¨ngt (Abbildung 1.3).
a
So steht bei einfachen Ablaufsteuerungen ein hoher Datendurchsatz im Vorder-
grund, wohingegen von Systemen mit Benutzerinteraktion eine schnelle Ant-
wortzeit gefordert wird. Echtzeit-Systeme wiederum verlangen nicht unbedingt
schnelle, aber daf¨r garantierte Antwortzeiten.
u
Task 1 Task 2 Task n
Programm-Code Programm-Code ... Programm-Code
Programm-Kontext Programm-Kontext Programm-Kontext
Task-Wechsel
Anmerkungen:
Beim Task-Wechsel
Prozessor muss der Kontext
Register gesichert werden.
Der Algorithmus zur
Hauptspeicher Prozessorzuteilung
heißt Scheduler.
Abb. 1.3. Bei Systemen mit einem Prozessor und mehreren Tasks muss eine Task-
Umschaltung mit Sicherung des Kontextes erfolgen.
Eine erste Klassifizierung der Scheduling-Algorithmen erfolgt in nicht-
verdr¨ngendes (non-preemptive) und verdr¨ngendes (preemptive) Scheduling.
a a
Im ersten Fall kann auch ein Prozess h¨herer Priorit¨t einen laufenden Pro-
o a
zess nicht verdr¨ngen; er wird erst nach Abschluss des laufenden Prozesses
a
ausgef¨hrt. Im zweiten Fall kann ein h¨herpriorer Prozess einen anderen, ak-
u o
tuell laufenden Prozess zum Pausieren zwingen. Der niederpriore Prozess wird
bis zum Abschluss der Bearbeitung des neuen Prozesses angehalten.
Folgende Scheduling-Verfahren sind gebr¨uchlich [Brosenne 08]:
a
9
Zu Details bzgl. Tasks und Threads vgl. Kapitel 12.
28. 30 1 Grundlagen
Shortest Job First
Bei diesem einfachen Scheduling-Verfahren wird jeweils der Prozess mit der
k¨rzesten Rechenzeit als n¨chstes gerechnet. Laufende Prozesse werden hier-
u a
bei nicht unterbrochen (nicht-verdr¨ngend, non-preemptive). Das Verfahren
a
ist nicht fair, da kurze Prozesse lange Prozesse uberholen k¨nnen und damit
¨ o
bevorzugt behandelt werden. Das Verfahren ist f¨r Echtzeitanwendungen un-
u
geeignet.
First Come First Served
Wieder handelt es sich um ein relativ einfaches Scheduling-Verfahren: Die Pro-
zesse werden gem¨ß ihrer Ankunftsreihenfolge dem Prozessor zugeteilt. Auch
a
hier werden laufende Prozesse nicht unterbrochen (nicht-verdr¨ngend, non-
a
preemptive). Das Verfahren ist fair, da gesichert ist, dass jeder Prozess bear-
beitet wird. Das Verfahren ist f¨r Echtzeitanwendungen ungeeignet.
u
Round-Robin
Im Vergleich zu den vorangegangenen Verfahren ist das Round-Robin-
Scheduling bereits vergleichsweise ausgefeilt. Bei diesem Verfahren wird die
Rechenzeit in Zeitscheiben gleicher L¨nge aufgeteilt, die Prozesse werden in
a
eine Warteschlange eingereiht und gem. dem Verfahren First-In-First-Out aus-
gew¨hlt. Ein zu rechnender Prozess wird nach Ablauf der aktuellen Zeitscheibe
a
unterbrochen. Er pausiert und wird erneut hinten in die Warteschlange ein-
gef¨gt. Das Verfahren ist fair, die Rechenzeit wird gleichm¨ßig und gerecht
u a
auf die Prozesse aufgeteilt. Es ist mit Einschr¨nkungen f¨r Anwendungen mit
a u
weichen Echtzeitanforderungen geeignet.
Round-Robin mit Priorit¨ten
a
Das Round-Robin-Verfahren kann durch die Einf¨hrung von Priorit¨ten
u a
erg¨nzt werden. Hierbei werden Prozesse mit gleicher Priorit¨t zusammen-
a a
gefasst in eine gemeinsame, dedizierte Warteschlange. Dann wird immer die
Prozess-Warteschlange mit den h¨chstprioren Prozessen nach dem Round-
o
Robin-Verfahren abgearbeitet. Es ist allerdings zu beachten, dass es geschehen
kann, dass Prozesse nie gerechnet werden (verhungern). Eine m¨gliche Abhilfe
o
ist eine Erh¨hung der Priorisierung gem. der Wartezeit.
o
Dieses Scheduling-Verfahren, in Kombination mit Erweiterungen um das ge-
nannte Verhungern auszuschließen, stellt den Stand der Technik bei Desktop-
Betriebssystemen wie Windows XP oder Linux dar.
29. 1.4 Betriebssysteme 31
Statisches Echtzeit-Scheduling am Beispiel des
Rate-Monotonic Scheduling (RMS)
Beim statischen Scheduling wird der Schedule bereits zur Compile-Zeit f¨r
u
alle m¨glichen Tasks aufgestellt. Folgende Voraussetzungen werden nun f¨r
o u
die weiteren Betrachtungen festgehalten:
1. Die zeitkritischen Prozesse treten periodisch auf.
2. Vor dem Bearbeiten der n¨chsten Periode muss die Bearbeitung der aktu-
a
ellen Periode abgeschlossen sein.
3. Abh¨ngigkeiten zwischen den Prozessen sind ausgeschlossen.
a
4. Die Bearbeitungszeiten sind konstant.
5. Wenn nicht-periodische Prozesse auftreten, so sind sie nicht zeitkritisch.
6. Prozesse werden verschieden priorisiert und k¨nnen einander unterbrechen
o
(es liegt ein preemptives System vor).
Hieraus l¨sst sich bereits eine allgemeine Bedingung formulieren. Ein Schedule
a
existiert genau dann, wenn gilt:
n
∆ti
≤1 (1.1)
i=1
Per i
Hierin ist: n: Anzahl der Prozesse, ∆ti : Bearbeitungszeit des i-ten Prozesses,
Per i : Periode des i-ten Prozesses.
Weiterhin stellt sich nun die Frage, wie eine sinnvolle Priorisierung vorge-
nommen werden kann. Das RMS-Verfahren verwendet hierzu eine Priorisie-
rung anhand der Periode des Prozesses. Die Regel lautet: Der Prozess mit
der k¨rzesten Periode (der h¨chsten Wiederholrate) erh¨lt die h¨chste Prio-
u o a o
rit¨t. Die zugrunde liegende und relativ bekannte Ver¨ffentlichung hierzu ist
a o
[Liu 73]: Scheduling Algorithms for Multiprogramming in a Hard Real-time
”
Environment.“
Die Autoren weisen nach, dass mit dieser Vorgehensweise bei einer CPU-
Auslastung ≤ 70 % ein Schedule garantiert werden kann. Allgemein gilt f¨r
u
das Existieren eines Schedules nach diesem Verfahren folgender Zusammen-
hang:
n
∆ti
µ= ≤ n(21/n − 1) (1.2)
i=1
Per i
F¨r n → ∞ konvergiert die rechte Seite gegen 0,693. Aber auch bei h¨heren
u o
Auslastungen ist ein Schedule nicht unm¨glich. Wenn im System z. B. alle
o
30. 32 1 Grundlagen
Periodenzeiten Vielfache der k¨rzesten Periode sind, so existiert auch f¨r eine
u u
CPU-Auslastung von 100 % ein Schedule.
Der Vorteil des Verfahrens ist ein garantierter Schedule bei den genannten Be-
dingungen. Nachteilig ist, dass nur statisch geplant werden kann und dass bei
einer Prozessorlast > 70 % eine feste Schedule-Zusage nicht mehr m¨glich ist.
o
Eine typische Anwendung des Verfahrens ist die Verarbeitung vorher bekann-
ter Audio- oder Video-Streams.
Dynamisches Echtzeit-Scheduling am Beispiel des
Earliest Deadline First-Verfahrens (EDF)
Beim dynamischen Scheduling wird der Schedule zur Laufzeit f¨r die aktu-
u
ell auszuf¨hrenden Tasks erstellt. Ein g¨ngiges Verfahren hierf¨r ist das Ear-
u a u
liest Deadline First-Verfahren. Hierbei wird von einem preemptiven System mit
dynamischer Priorit¨tenverteilung ausgegangen, ansonsten sind die Vorausset-
a
zungen die gleichen wie bei RMS. Die einfache Regel lautet nun: Ausgef¨hrtu
wird immer der Prozess, der aktuell die k¨rzeste Deadline aufweist.
u
Die Vorteile des Verfahrens sind, dass es einfach zu implementieren ist und den
Prozessor bis zu 100 % ausnutzen kann. Ein gravierender Nachteil ist aber, dass
ein korrekter Schedule nicht in allen F¨llen sichergestellt werden kann.
a
Neben den Scheduling-Verfahren ist bei Auswahl oder Einsatz eines
(Echtzeit-)Multitasking-Betriebssystems auch bei der Interprozesskommuni-
kation besonderes Augenmerk erforderlich. Weiterhin muss auch der gemein-
same Zugriff auf Ressourcen wie angebundene Hardware oder Speicher orga-
nisiert werden. Zu weiterf¨hrenden Informationen hierzu vgl. [Marwedel 07;
u
Brosenne 08].
1.4.3 Systembeispiele
Zur Realisierung eines Echtzeit-Betriebssystems sind verschiedene Ans¨tze
a
denkbar. Ein erster einfacher Ansatz ist die Modifikation des Kernels derart,
dass Unterbrechungen m¨glich werden (preemptives Multitasking). Erg¨nzt
o a
mit einer Minimierung der Interrupt-Maskierungszeiten ist mit einem solchen
System zumindest weiche Echtzeit gut m¨glich. Vertreter dieser Architektur
o
sind: SunOS 5.x und AiX 3.0.
Eine andere M¨glichkeit ist die Erweiterung eines Standard-Betriebssystems
o
um einen preemptiven, echtzeitf¨higen Mikrokernel. Bei diesem aufw¨ndigen
a a
Ansatz ist entsprechend auch eine Neu-Implementierung des Schedulers not-
wendig, das System kann damit aber auch f¨r harte Echtzeitanforderungen
u
ausgelegt werden. Vertreter: VxWorks und QNX.
31. 1.5 Software-Entwicklung 33
Eine weitere Technik, die auch h¨ufig angewandt wird, ist der Ersatz des
a
Standard-Schedulers durch einen Echtzeit-Scheduler, welcher prim¨r das a
Scheduling der Real-Time-Tasks organisiert und dem eigentlichen Basis-
Betriebssystem nur dann Rechenzeit zugesteht, wenn die RT-Tasks abgear-
beitet sind. Hier l¨uft das Basissystem als sog. Idle Task. Mit dieser Methode
a
sind auch herk¨mmliche Systeme relativ leicht f¨r (synchrone) Echtzeitanwen-
o u
dungen zu erweitern. Vertreter dieser Architektur sind beispielsweise: RTAI
Linux, OSADL Realtime Linux.
Zu weiteren Details vgl. auch die weiterf¨hrende Literatur unter [W¨rn 05;
u o
Marwedel 07; Yaghmour 08].
1.5 Software-Entwicklung
Bei der Software-Entwicklung f¨r eingebettete Systeme sind verschiedene Vor-
u
¨
gehensweisen m¨glich. Ublich, wenn auch nicht zwingend, ist die Software-
o
Entwicklung auf einem Standard-PC mit einer leistungsf¨higen IDE10 . Erst
a
¨
nach Abschluss des Ubersetzungsvorganges wird dann die Bin¨rdatei zum Tes-
a
ten auf das eingebettete System, das Target, geladen. In Abbildung 1.4 ist solch
ein Entwicklungssystem als Beispiel skizziert.
In diesem Beispiel wird der freie C-Compiler SDCC (Small Device C Compi-
ler) verwendet, der auf dem GNU-Compiler basiert. Dieser sog. Cross Compi-
ler l¨uft auf dem Entwicklungs-PC unter Linux oder auch Windows, erzeugt
a
aber Maschinencode f¨r eine zweite Plattform – im Beispiel f¨r den 8051-
u u
Mikrocontroller.
Der Aufruf erfolgt standardm¨ßig an der Kommandozeile, der Compiler kann
a
aber auch in eine IDE eingebunden werden. Ein Simulator ist nicht vorhan-
¨
den. Nach dem Ubersetzen wird die entstandene Datei, welche den Controller-
Maschinencode im standardisierten Intel-HEX-Format enth¨lt, mit einem Tool
a
wie beispielsweise AtmelISP seriell in den Flash-Speicher des Controllers
ubertragen und dort ausgef¨hrt.
¨ u
Die Vorteile eines solchen Entwicklungssystems sind die Einfachheit und die
geringen Anschaffungskosten, der große Nachteil ist, dass im Falle eines Pro-
grammfehlers keinerlei Informationen zu Registerinhalten oder Speicherbele-
gung zug¨ngig sind. Die einzige M¨glichkeit, an Debugging-Informationen zu
a o
gelangen, ist, in den Quelltext an sinnvollen Stellen printf()-Kommandos ein-
zubauen.
Bei der Programmausf¨hrung ubertr¨gt der Controller dann die fraglichen
u ¨ a
Ausgaben uber eine zweite serielle Schnittstelle zur¨ck zum PC, wo sie in einem
¨ u
Terminal-Programm wie SerialPort oder Minicom empfangen und angezeigt
10
Integrated Development Environment, integrierte Entwicklungsumgebung.