Xm b

6,359 views
6,224 views

Published on

c

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,359
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Xm b

  1. 1. X. systems.press
  2. 2. X.systems.press ist eine praxisorientierteReihe zur Entwicklung und Administration vonBetriebssystemen, Netzwerken und Datenbanken.
  3. 3. Joachim Schröder · Tilo Gockel · Rüdiger DillmannEmbedded LinuxDas Praxisbuch123
  4. 4. Dipl.-Ing. Joachim Schröder Prof. Dr.-Ing. Rüdiger DillmannUniversität Karlsruhe Universität KarlsruheInformatikfakultät InformatikfakultätLehrstuhl IAIM Prof. Dr.-Ing. R. Dillmann Lehrstuhl IAIM Prof. Dr.-Ing. R. DillmannKaiserstraße 12 Kaiserstraße 1276128 Karlsruhe 76128 Karlsruheschroede@ira.uka.de dillmann@ira.uka.deDr.-Ing. Tilo GockelUniversität KarlsruheInformatikfakultätLehrstuhl IAIM Prof. Dr.-Ing. R. DillmannKaiserstraße 1276128 Karlsruhegockel@ira.uka.deISBN 978-3-540-78619-1 e-ISBN 978-3-540-78620-7DOI 10.1007/978-3-540-78620-7Springer Dordrecht Heidelberg London New YorkX.systems.press ISSN 1611-8618Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.© Springer-Verlag Berlin Heidelberg 2009Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die derÜbersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funk-sendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung inDatenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Ver-vielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen dergesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. Septem-ber 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwider-handlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes.Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk be-rechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne derWarenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermannbenutzt werden dürften.Einbandentwurf: KünkelLopka, HeidelbergGedruckt auf s¨ urefreiem Papier aSpringer ist Teil der Fachverlagsgruppe Springer Science+Business Media (www.springer.de)
  5. 5. VorwortDer Lehrstuhl von Herrn Prof. Dillmann am Institut f¨r Anthropomatik der uUniversit¨t Karlsruhe (TH) besch¨ftigt sich mit vielf¨ltigen Themen rund um a a adas Forschungsfeld der Robotik. Zu den Schwerpunkten z¨hlen mobile Service- aroboter und intelligente Fahrzeuge, maschinelles Lernen und Robotik in derMedizin, 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 Aufgabenauf Linux-Systemen. Die Themen betrafen die Auswahl geeigneter Hardware-Plattformen, die Komponentenanbindung, Netzwerkkommunikation, Software-Entwicklung f¨r verschiedene Zielsysteme, Erstellung grafischer Benutzerober- ufl¨chen, Multithreading, Echtzeitf¨higkeit und Smart-Camera-Technologie. a aDie Antworten auf diese Fragen wurden zun¨chst in losen Blattsammlun- agen festgehalten, teilweise in elektronischer Form dokumentiert oder auch nurm¨ndlich weitergegeben. Das vorliegende Buch hat zum Ziel, das Wissen zu ustrukturieren und zu b¨ndeln. Die Inhalte wurden hierzu systematisch aufge- uarbeitet, um Grundlagenwissen erg¨nzt und durch viele Beispielapplikationen apraxisgerecht veranschaulicht.Embedded Linux ist mittlerweile das vierte Buch der Praxisbuchreihe, die nachdem Start mit dem Buch Embedded Robotics im Jahre 2005 mit dem PraxisbuchComputer Vision, und dessen englischsprachigem Pendant Computer Vision– Principles and Practice, weitergef¨hrt wurde. Die zu diesen Themen vor- uliegenden Fachb¨cher sind oftmals als theoretische Lehrwerke konzipiert, ent- usprechend trocken zu lesen und wenig hilfreich in der Praxis. Die Praxisb¨cher usollen die Theorie ¨hnlich tiefgehend vermitteln, dar¨ber hinaus aber die In- a uhalte um viele Versuche und Implementierungen erg¨nzen, die nicht nur im aLaborumfeld, sondern auch im produktiven Umfeld standhalten.
  6. 6. 6 VorwortDas entstandene Buch richtet sich an Studenten der Informatik und der Inge-nieurswissenschaften, an Berufsanf¨nger, Praktiker und generell an alle Inter- aessierten.Die vorgestellten Bibliotheken und Applikationen werden bei Erscheinen desBuches 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.DanksagungDie Entstehung des vorliegenden Buches ist auch vielen anderen Menschen zuverdanken, die bei den Implementierungen mitgewirkt, die Ergebnisse korri-giert und viel Geduld mit den Autoren bewiesen haben. Es sind dies: DamiraMambetova, Ulla Scheich, Susanne und Detlef Schr¨der, Steven Wieland, Tobi- oas Gindele, Manfred Kr¨hnert, Moritz Hassert, Alexander Bierbaum, Pedram oAzad, Alexander Kasper, Peter Steinhaus und Andreas B¨ttinger. Besonders ozu nennen sind an dieser Stelle auch Daniel Jagszent, der sein fundiertes Wis-sen als Gastautor in Kapitel 12 eingebracht hat und Stephan Riedel, der dieQuelltext-Beispiele auf den verschiedenen Plattformen getestet hat.Weiterhin m¨chten wir Herrn Prof. R¨diger Dillmann f¨r die Unterst¨tzung o u u uund f¨r das Vertrauen, das er in uns wissenschaftliche Mitarbeiter setzt, dan- uken. Durch die hiermit verbundene Freiheit ist die Buchreihe der Praxisb¨cher uerst m¨glich geworden. Abschließend danken wir Frau Dorothea Glaunsinger ound Herrn Hermann Engesser vom Springer-Verlag f¨r die Motivation, Geduld uund die reibungslose und professionelle Zusammenarbeit.Wir w¨nschen Ihnen viel Freude mit dem vorliegenden Buch und hoffen, Sie uf¨r den interessanten und zukunftstr¨chtigen Bereich der Embedded Systems u aunter Linux begeistern zu k¨nnen. oKarlsruhe, Das Autorenteamden 5. Januar 2009HinweisDie Informationen in diesem Buch werden ohne R¨cksicht auf einen eventuellen uPatentschutz ver¨ffentlicht. Die erw¨hnten Soft- und Hardware-Bezeichnungen o ak¨nnen auch dann eingetragene Warenzeichen sein, wenn darauf nicht geson- odert hingewiesen wird. Sie sind Eigentum der jeweiligen Warenzeicheninhaberund unterliegen gesetzlichen Bestimmungen. Verwendet werden u. a. folgendegesch¨tzte Bezeichnungen: iPhone, Texas Instruments, Code Composer, Visi- uon Components, Sony, KEIL, µVision2.
  7. 7. InhaltsverzeichnisTeil I Grundlagen und Plattformen1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.1 Einf¨hrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 17 1.2 Architekturen, Plattformen und Geschichtliches . . . . . . . . . . . . . 18 1.3 Eigenschaften eingebetteter Systeme . . . . . . . . . . . . . . . . . . . . . . . 21 1.3.1 Formfaktor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.3.2 Mechanik, K¨hlung, Robustheit . . . . . . . . . . . . . . . . . . . . . u 21 1.3.3 Speichermedien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 1.3.4 Schnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1.3.5 Stromversorgung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.3.6 Chips¨tze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a 24 1.3.7 Watchdog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.3.8 Echtzeitf¨higkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a 25 1.4 Betriebssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 1.4.1 Allgemeine Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 27 1.4.2 Prozess-Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 1.4.3 Systembeispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 1.5 Software-Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 1.6 Aufbau und Gebrauch des Buches . . . . . . . . . . . . . . . . . . . . . . . . . 382 Hardware-Plattformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.1 Einf¨hrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 41 2.2 Network-Attached-Storage NSLU2 . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.3 WLAN-Router WL-500gP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.4 MicroClient Jr. und Sr. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.5 OpenRISC Alekto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 2.6 Mini-ITX-Mainboard D945GCLF2 mit Dual-Core Atom CPU . 52 2.7 Pegelanpassung f¨r die RS-232-Schnittstelle . . . . . . . . . . . . . . . . . u 55
  8. 8. 8 Inhaltsverzeichnis3 OpenWrt auf dem WLAN-Router WL-500g Premium . . . . . 57 3.1 Einf¨hrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 57 3.2 Einrichtung des OpenWrt-Build-Systems . . . . . . . . . . . . . . . . . . . 58 3.2.1 Aufspielen des Flash-Images . . . . . . . . . . . . . . . . . . . . . . . . 61 3.2.2 Der erste Einlog-Vorgang . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.3 Schnelleres Einloggen mit SSH-Keys . . . . . . . . . . . . . . . . . . . . . . . 64 3.4 Software-Entwicklung f¨r OpenWrt . . . . . . . . . . . . . . . . . . . . . . . . u 65 3.5 Erstellung eigener OpenWrt-Module . . . . . . . . . . . . . . . . . . . . . . . 67 3.6 IO-Warrior-Erweiterung und Kernelmodule unter OpenWrt . . . 714 Debian auf dem NAS-Ger¨t NSLU2 . . . . . . . . . . . . . . . . . . . . . . . a 75 4.1 Einf¨hrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 75 4.2 Debian-Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.3 Erste Schritte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.4 Software-Entwicklung f¨r die NSLU2 . . . . . . . . . . . . . . . . . . . . . . . u 80 4.5 NSLU2 als Druckerserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 4.6 Weiterf¨hrende Hinweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 84 4.6.1 Erstellung eines vollst¨ndigen NSLU2-Backups . . . . . . . . a 84 4.6.2 Einstellung der Taster-Funktion . . . . . . . . . . . . . . . . . . . . . 84 4.6.3 Probleme beim Booten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845 Debian auf dem Embedded-PC OpenRISC-Alekto . . . . . . . . . 87 5.1 Einf¨hrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 87 5.2 Angepasste Debian-Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.3 Erste Schritte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.4 Software-Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.5 Zugriff auf die Alekto-Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.5.1 Anwendung der /proc-Erweiterungen in der Konsole . . . 93 5.5.2 Zugriff uber ioctl()-Befehle . . . . . . . . . . . . . . . . . . . . . . . ¨ 94 5.6 Watchdog-Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.7 Erstellung eines eigenen Alekto-Kernels . . . . . . . . . . . . . . . . . . . . 97 5.8 Vollst¨ndige Debian-Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . a 986 Puppy Linux auf dem Embedded-PC MicroClient Jr./Sr. . . 101 6.1 Einf¨hrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 101 6.2 Puppy-Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 6.3 Paket-Management unter Puppy . . . . . . . . . . . . . . . . . . . . . . . . . . 103 6.4 Software-Entwicklung unter Puppy . . . . . . . . . . . . . . . . . . . . . . . . 105Teil II Anwendungen7 Legacy-Schnittstellen und digitale IOs . . . . . . . . . . . . . . . . . . . . . 111 7.1 Einf¨hrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 u 7.2 RS-232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
  9. 9. Inhaltsverzeichnis 9 7.2.1 Grundlagen der RS-232-Schnittstelle . . . . . . . . . . . . . . . . . 112 7.2.2 Ansteuerung und Programmierung . . . . . . . . . . . . . . . . . . 116 7.2.3 Ansteuerung einer seriellen Relaiskarte . . . . . . . . . . . . . . . 121 7.3 Centronics und IEEE 1284 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 7.4 General Purpose Input/Output (GPIO) . . . . . . . . . . . . . . . . . . . . 127 7.5 Schnittstellenerweiterung uber IO-Warrior . . . . . . . . . . . . . . . . . . ¨ 129 7.5.1 IO-Warrior-Bausteine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 7.5.2 Installation der IO-Warrior-Treiber unter Debian . . . . . . 1308 Der Inter-IC-Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 8.1 Einf¨hrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 133 8.2 I2 C-Daten¨bertragung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 136 8.2.1 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 8.2.2 Steuersignale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 8.2.3 Clock Stretching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 8.2.4 Multi-Master-Betrieb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 8.2.5 Adressierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 8.2.6 I2 C-Buserweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 8.3 I2 C-Anbindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 8.3.1 I2 C-Steckverbindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 8.3.2 Verwendung des I2 C-Busses bei NSLU2 und Alekto . . . . 147 8.3.3 I2 C-Busanbindung uber einen IO-Warrior-Baustein . . . . ¨ 149 8.3.4 Die IO-Warrior-I2 C-Bibliothek . . . . . . . . . . . . . . . . . . . . . . 150 8.4 Alternative serielle Bussysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 8.4.1 Controller Area Network (CAN) . . . . . . . . . . . . . . . . . . . . . 153 8.4.2 Local Interconnect Network (LIN) . . . . . . . . . . . . . . . . . . . 154 8.4.3 1-Wire-Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 8.4.4 Serial Peripheral Interface (SPI) . . . . . . . . . . . . . . . . . . . . . 156 8.4.5 Universal Serial Bus (USB) . . . . . . . . . . . . . . . . . . . . . . . . . 1569 Inter-IC-Bus-Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 9.1 Einf¨hrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 161 9.2 Die I2 C-Bibliothek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 9.2.1 Die Klasse IICBus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 9.2.2 Die Klasse IICBase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 9.3 Tastatur- und LC-Display-Ansteuerung mit PCF8574 . . . . . . . . 167 9.3.1 Philips 8-Bit-I/O-Erweiterung PCF8574 . . . . . . . . . . . . . . 167 9.3.2 I2 C-Tastaturmodul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 9.3.3 Die Klasse IICKeyboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 9.3.4 I2 C-LC-Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 9.3.5 LC-Display-Treiberbaustein HD44780 . . . . . . . . . . . . . . . . 171 9.3.6 Die Klasse IICDisplay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 9.3.7 Die Klasse IICIOExpander . . . . . . . . . . . . . . . . . . . . . . . . . 176 9.4 Temperaturmessung mit DS1631 . . . . . . . . . . . . . . . . . . . . . . . . . . 177 9.4.1 Dallas DS1631 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
  10. 10. 10 Inhaltsverzeichnis 9.4.2 Die Klasse IICTempSensor . . . . . . . . . . . . . . . . . . . . . . . . . 178 9.5 A/D- und D/A-Wandler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 9.5.1 Philips PCF8591 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 9.5.2 Die Klasse IICADConverter . . . . . . . . . . . . . . . . . . . . . . . . 180 9.6 TMC222-Schrittmotorsteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 9.6.1 Trinamic TMC222 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 9.6.2 Conrad C-Control I2 C-Bus-Stepper-Driver . . . . . . . . . . . . 185 9.6.3 Die Klasse IICStepper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 9.6.4 Programmierung des TMC222-OTP-Speichers . . . . . . . . . 189 9.7 Chipkarten-Ansteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 9.7.1 EEPROM-Chipkarte AT24Cxx . . . . . . . . . . . . . . . . . . . . . . 191 9.7.2 Die Klasse IICChipcard . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 9.7.3 AES-Verschl¨sselung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 194 9.7.4 Die Klasse AES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 9.8 I2 C-Bus-Erweiterung uber Multiplexer . . . . . . . . . . . . . . . . . . . . . ¨ 199 9.8.1 Philips PCA9548 I2 C-Multiplexer . . . . . . . . . . . . . . . . . . . 199 9.8.2 Die Klasse IICMultiplexer . . . . . . . . . . . . . . . . . . . . . . . . . . 20010 USB-Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 10.1 Einf¨hrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 203 10.2 USB-Audioanbindung: MP3-Player und Sprachausgabe . . . . . . . 204 10.3 USB-WLAN-Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 10.3.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 10.3.2 Netgear MA111 unter Puppy . . . . . . . . . . . . . . . . . . . . . . . 207 10.3.3 Alternative: WLAN-Anbindung uber Access Point . . . . . ¨ 209 10.4 USB-Bluetooth-Erweiterung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 10.4.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 10.4.2 Die Werkzeuge Bluez-Utils . . . . . . . . . . . . . . . . . . . . . . . . . 211 10.4.3 Datentransfer mit ObexFTP . . . . . . . . . . . . . . . . . . . . . . . . 216 10.4.4 Serielle Bluetooth-Kommunikation und AT-Befehle . . . . 217 10.4.5 Das Mobiltelefon als Fernbedienung . . . . . . . . . . . . . . . . . . 219 10.5 USB-GPS-Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 10.5.1 Der GPS-Daemon GPSD . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 10.5.2 GPS in der Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 10.5.3 Die Klasse GPSReceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 10.6 USB-Speichererweiterung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 10.6.1 Partitionierung und Einbindung eines USB-Sticks . . . . . 226 10.6.2 Auslagerung des Home-Verzeichnisses auf einen USB-Stick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22811 Ger¨tetreiber und Kernelmodule . . . . . . . . . . . . . . . . . . . . . . . . . . a 231 11.1 Einf¨hrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 231 11.2 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 11.2.1 Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 11.2.2 Der Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
  11. 11. Inhaltsverzeichnis 11 11.3 Programmierung von Kernelmodulen . . . . . . . . . . . . . . . . . . . . . . . 237 11.3.1 Aufbau von Kernelmodulen . . . . . . . . . . . . . . . . . . . . . . . . . 237 ¨ 11.3.2 Ubersetzung von Kernelmodulen . . . . . . . . . . . . . . . . . . . . 239 11.3.3 Test und Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 ¨ 11.3.4 Ubergabe von Kommandozeilenparametern . . . . . . . . . . . 242 11.4 Zeichenorientierte Ger¨tetreiber . . . . . . . . . . . . . . . . . . . . . . . . . . . a 243 11.4.1 Major-, Minor- und Ger¨tenummern . . . . . . . . . . . . . . . . . a 243 11.4.2 Modul-Registrierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 11.4.3 Ger¨tetreiber-Registrierung nach alter Schule . . . . . . . . . a 248 11.5 Implementierung von Dateioperationen . . . . . . . . . . . . . . . . . . . . . 249 11.5.1 Die Struktur file operations . . . . . . . . . . . . . . . . . . . . . . 249 11.5.2 Kopieren von Daten zwischen Kernel- und User-Space . . 250 11.5.3 Die ioctl()-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 11.5.4 Verwendung von Ger¨tetreibern in der Anwendung . . . . a 255 11.6 Hardware-Zugriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 11.6.1 Zugriff uber IO-Ports und IO-Speicher . . . . . . . . . . . . . . . ¨ 257 11.6.2 Zugriff uber das Dateisystem . . . . . . . . . . . . . . . . . . . . . . . ¨ 26012 Multithreading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 12.1 Einf¨hrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 263 12.2 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 12.3 Posix-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 12.3.1 Thread-Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 12.3.2 Mutex-Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 12.3.3 Funktionen f¨r Zustandsvariablen . . . . . . . . . . . . . . . . . . . u 272 12.3.4 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 12.4 C++-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 12.4.1 Die Klasse Thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 12.4.2 Die Klasse Mutex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 12.4.3 Die Klasse WaitCondition . . . . . . . . . . . . . . . . . . . . . . . . . . 279 12.4.4 Die Klasse PeriodicThread . . . . . . . . . . . . . . . . . . . . . . . . . . 282 12.5 Anwendungsbeispiel: Servo-Ansteuerung . . . . . . . . . . . . . . . . . . . . 284 12.5.1 Servo-Anbindung an einen PC . . . . . . . . . . . . . . . . . . . . . . 285 12.5.2 Software-Entwurf zum Beispiel . . . . . . . . . . . . . . . . . . . . . . 286 12.5.3 Linux und Echtzeitf¨higkeit . . . . . . . . . . . . . . . . . . . . . . . . . a 288 12.5.4 Zeitmessung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29013 Netzwerkkommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 13.1 Einf¨hrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 295 13.2 Daten¨bertragung via UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 297 13.2.1 Grundlagen zu Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 13.2.2 Berkeley Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 13.2.3 Verwendung der Berkeley Socket API . . . . . . . . . . . . . . . . . 307 13.2.4 Socket-Debugging mit NetCat . . . . . . . . . . . . . . . . . . . . . . . 310 13.2.5 Host Byte Order und Network Byte Order . . . . . . . . . . . . . 310
  12. 12. 12 Inhaltsverzeichnis 13.2.6 Practical Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 13.2.7 Definition eigener Protokolle auf Anwendungsschicht . . . 313 13.2.8 Verwendung der Practical Sockets . . . . . . . . . . . . . . . . . . . 318 13.3 Kommunikation mit einer Qt-Anwendung . . . . . . . . . . . . . . . . . . 320 13.3.1 Client-Server-Kommunikation mit Qt4 . . . . . . . . . . . . . . . 321 13.3.2 Remote-Schrittmotorsteuerung mit grafischer Benutzeroberfl¨che . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a 327 13.4 Interaktion mit einem Webserver via CGI . . . . . . . . . . . . . . . . . . 333 13.4.1 Messdatenanzeige . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 13.4.2 Gezielte Anfragen mit JavaScript . . . . . . . . . . . . . . . . . . . . 33814 Video for Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 14.1 Einf¨hrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 341 14.2 Treiberinstallation und Inbetriebnahme . . . . . . . . . . . . . . . . . . . . 341 14.3 Bildeinzug unter Linux per V4L . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 14.4 Treiberkapselung f¨r die IVT-Bibliothek . . . . . . . . . . . . . . . . . . . . u 35215 Intelligente Kamera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 15.1 Einf¨hrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 355 15.2 Sicherheitssystem mit Bewegungserkennung . . . . . . . . . . . . . . . . . 355 15.3 Weiterf¨hrende Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 358 15.3.1 Kommentare zum Hardware-Aufbau . . . . . . . . . . . . . . . . . 358 ¨ 15.3.2 Triggerung und IEEE 1394-Ubertragung . . . . . . . . . . . . . . 360 15.3.3 Weitere Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36216 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 16.1 Communities, Projekte, Trends . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 16.2 Schlusswort und Kontaktdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369Teil III AnhangA Kurzreferenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 A.1 Einf¨hrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 373 A.2 Die Linux-Konsole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 A.2.1 Basisbefehlsschatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 A.2.2 Editoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 A.3 Netzwerkeinstellungen und SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 A.3.1 Netzwerkeinstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 A.3.2 Secure Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 A.4 Weitere Werkzeuge und Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . 384 A.4.1 Paketverwaltung APT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384 A.4.2 Umgebungsvariablen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 A.4.3 Erstellung von Ger¨tedateien mit mknod . . . . . . . . . . . . . . a 387 A.4.4 Zugriffsrechte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
  13. 13. Inhaltsverzeichnis 13 A.4.5 Root-Rechte mit sudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390 A.4.6 Cronjob-Verwaltung mit crontab . . . . . . . . . . . . . . . . . . . . 391 A.5 Diagnose- und Failsafe-Modi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 A.5.1 Asus WL500g Premium . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 A.5.2 Linksys WRT54G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 A.5.3 Linksys NSLU2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394B Alternative Hardware-Plattformen . . . . . . . . . . . . . . . . . . . . . . . . . 395 B.1 Einf¨hrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 395 B.2 Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 B.3 Network Attached Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 B.4 Industrielle Kompaktsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396 B.5 Einplatinencomputer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396 B.6 Sonderl¨sungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 396C Die IVT-Bibliothek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 C.1 Einf¨hrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 399 C.2 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 C.2.1 Die Klasse CByteImage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 C.2.2 Anbindung von grafischen Benutzeroberfl¨chen . . . . . . . . a 401 C.2.3 Anbindung von Bildquellen . . . . . . . . . . . . . . . . . . . . . . . . . 402 C.2.4 Anbindung der OpenCV . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 C.2.5 Anbindung von OpenGL uber Qt . . . . . . . . . . . . . . . . . . . . ¨ 404 C.3 Beispielapplikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405 C.3.1 Verwendung der Basisfunktionalit¨t . . . . . . . . . . . . . . . . . . a 405 C.3.2 Verwendung einer grafischen Benutzeroberfl¨che . . . . . . . a 405 C.3.3 Verwendung eines Kameramoduls . . . . . . . . . . . . . . . . . . . 405 C.3.4 Verwendung der OpenCV . . . . . . . . . . . . . . . . . . . . . . . . . . 406 C.3.5 Verwendung der OpenGL-Schnittstelle . . . . . . . . . . . . . . . 406 ¨ C.4 Ubersicht zu weiterer Funktionalit¨t der IVT . . . . . . . . . . . . . . . a 407 C.5 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 C.5.1 OpenCV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 C.5.2 Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 C.5.3 Firewire und libdc1394/libraw1394 . . . . . . . . . . . . . . . . . . 410 C.5.4 IVT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411D Die Qt-Bibliothek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 D.1 Einf¨hrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 417 D.1.1 Installation und Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . 417 D.1.2 Signals und Slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420 D.1.3 Ein universelles Qt-Makefile . . . . . . . . . . . . . . . . . . . . . . . . 424 D.2 Oberfl¨chenerstellung mit Qt Designer . . . . . . . . . . . . . . . . . . . . . . a 425 D.2.1 Installation und Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . 425 D.2.2 Verwendung der Qt Designer Plugins . . . . . . . . . . . . . . . . . 428 D.2.3 Erstellung der Qt Designer Plugins . . . . . . . . . . . . . . . . . . . 430
  14. 14. 14 InhaltsverzeichnisE Bezugsquellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435F Verzeichnisbaum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441Sachverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
  15. 15. 1Grundlagen1.1 Einfuhrung ¨Eingebettete Systeme oder auch englisch, Embedded Systems, begegnen unsmittlerweile 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- ateressant. Aber wie lautet denn die genaue Definition der mittlerweile relativunscharf gebrauchten Bezeichnung? Zum Begriff der eingebetteten Systemeexistiert keine exakte DIN- oder ISO-Definition. Im Sprachgebrauch wird derBegriff wie folgt verwendet:Der Begriff des eingebetteten Systems bezeichnet einen Rechner (Mikrocontrol-ler, Prozessor, DSP1 , SPS2 ), welcher dezentral in einem technischen Ger¨t, ain 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 uDieser Versuch einer Definition umschließt mehrere Eigenschaften, einige ex-plizit ausformuliert, einige als selbstverst¨ndlich zwischen den Zeilen vorausge- asetzt: Ein eingebettetes System ist vor Ort bzw. dezentral im Ger¨t, Fahrzeug aoder in der Anlage untergebracht. Es ist in Hard- und Software auf die jeweili-ge Aufgabe zugeschnitten und entsprechend auch so einfach und preiswert wiem¨glich gestaltet. Es ben¨tigt Schnittstellen zum Prozess, zu anderen Ger¨ten o o aund zur Außenwelt – hierunter f¨llt auch die Benutzerschnittstelle zum Anwen- ader. Wenn das eingebettete System eine schnelle Regelungsaufgabe bedient, so1 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. 16. 18 1 Grundlagenist meist auch Echtzeitf¨higkeit gefordert. Da das System weiterhin fest in den atechnischen Kontext eingebunden ist, ist es schlecht wartbar. Die Einheitenm¨ssen entsprechend robust, wartungsarm und langlebig sein – eine Anforde- urung, die auch eine geringe Temperaturentwicklung, geringe Leistungsaufnah-me und damit niedrige Taktraten nach sich zieht. Aus dem gleichen Grundsind auch mechanisch-bewegliche Komponenten wie L¨fter oder Festplatten uin solchen Systemen eher selten zu finden.Der letzte Nebensatz des Definitionsversuches beschreibt die dedizierte Anpas-sung an die gegebene Aufgabe. Entsprechend gelten auch im Sprachgebrauchbeispielsweise Organizer oder PDAs nicht als eingebettete Systeme, obwohl sieviele der genannten Eigenschaften aufweisen. Diese Systeme sind bewusst nichtan eine spezielle Aufgabe angepasst, sondern universell gehalten und k¨nnen oeine Vielzahl von Aufgaben ubernehmen. ¨Im weiteren Text werden die Charakteristika eingebetteter Systeme genauer ¨untersucht und auch anhand von Beispielen belegt. Um einen guten Uberblickzu bieten, wird dabei in diesem Grundlagenkapitel noch keine Einschr¨nkung ahinsichtlich linuxbasierter Systeme vorgenommen.Das Kapitel schließt nach dieser allgemein gehaltenen Einf¨hrung mit einer uErl¨uterung zum Aufbau des vorliegenden Buches. a1.2 Architekturen, Plattformen und GeschichtlichesIn 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 ade zwischen Mikroprozessoren und Mikrocontrollern noch nicht unterschieden;erst mit dem Aufkommen von Derivaten mit Daten- und Programmspeicheron board wurde die Bezeichnung Mikrocontroller gel¨ufig. aMittlerweile kennzeichnet dieser Begriff Bausteine, die generell h¨her integriert osind als Mikroprozessoren: Sie vereinen in monolithischer Bauweise den ei-gentlichen Mikroprozessor, Speicher, das Bussystem, A/D-D/A-Wandler undSchnittstellen zu seriellen Busssystemen (I2 C, RS-232, RS-485, CAN . . . ). Mi-krocontroller, die f¨r spezielle Embedded-Anwendungen ausgelegt sind, be- usitzen dar¨ber hinaus auch beispielsweise Hardware-Einheiten f¨r die Puls- u ubreitenmodulation (Pulse Width Modulation, PWM), Quadratur-Decoder undCapture-Compare-Einheiten.Erste Embedded-Anwendungen wurden direkt in der Maschinensprache desControllers implementiert, sp¨ter erwies sich die Hochsprache C als ausrei- achend maschinennah und erreichte eine weite Verbreitung. Mittlerweile wer-den komplexe Embedded-Anwendungen meist in C++ programmiert. F¨r be- u
  17. 17. 1.2 Architekturen, Plattformen und Geschichtliches 19sonders zeitkritische oder maschinennahe Programmteile k¨nnen Assembler- oAnweisungen aber auch jetzt noch in C/C++ als sog. Inline-Assembler-Codeeingebunden werden.Neben der Entwicklung der h¨heren Programmiersprachen ver¨nderten sich o aauch die Anforderungen an die Betriebssysteme. Erste Mikroprozessoren besa-ßen kein Betriebssystem, sondern nur einen sog. Bootstrap Loader, ein kleinesProgramm im ROM des Controllers, welches beim Start die hinterlegten An-wendungen l¨dt oder auch eine Verbindung zur Außenwelt zum Laden neuer aProgramme herstellt.Die quasiparallele Bearbeitung mehrerer Aufgaben wird im einfachsten Fall di-rekt mit Interrupts realisiert. So k¨nnen kurze Routinen vom Timer-Interrupt oaufgerufen werden und auch externe Ereignisse einen (Hardware)-Interruptausl¨sen. H¨ufig angef¨hrte Beispiele sind Aufzugsteuerungen oder Geldau- o a utomaten. In beiden Beispielen muss der eingebettete Controller nicht nur dieRegelung der Motoren (Seilwinde, T¨rmechanik, Transportmechanik) und das uAuswerten der Sensoren im System (Drehgeber, Endschalter) abdecken, son-dern auch eine Benutzerschnittstelle zur Außenwelt bedienen. Im einfachenFall des Aufzuges ist dies ein Bedien-Panel mit Tasten und eine Siebenseg-mentanzeige. Im etwas komplexeren zweiten Beispiel werden im Regelfall einenumerische Tastatur und ein Monitor eingesetzt.Unter Verwendung des Timer-Interrupts und der damit m¨glichen Zuteilung ovon Zeitscheiben zu Prozessen sind auch auf einfachen Mikrocontrollern Multi-Threading-Anwendungen m¨glich, die Programmierung wird allerdings rasch okomplex und fehleranf¨llig. Mit der zus¨tzlichen Forderung der M¨glichkeit a a oeiner Schnittstellenkapselung bzw. eines Treiberkonzeptes wurde entsprechendder Wunsch nach einem Betriebssystem laut. Weiterhin werden mittlerweileauch 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 aMikrocontroller, sondern auch leistungsstarke Prozessoren mit leistungsf¨higen aBetriebssystemen 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 undEntwicklungstechniken auch heute noch Anwendung finden. So haben moderne32-bit-Controller die ersten 4- und 8-bit-Controller nicht g¨nzlich abgel¨st, a osondern nur erg¨nzt. Ein Beispiel hierzu: die veraltete 8051-Technologie wird aauch aktuell noch von rund zw¨lf Herstellern angeboten, wobei auch modernste oDerivate einhundertprozentig befehlskompatibel zu der ersten Generation sind.Ein Grund hierf¨r ist der wachsende Preisdruck. F¨r jede Anwendung wird u uder preiswerteste Controller verwendet, der f¨r die Aufgabe gerade noch in uFrage kommt. Weiterhin ist der Markt der eingebetteten Systeme ein tr¨ger a
  18. 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-VarianteTabelle 1.1. Entwicklung der Mikroprozessoren und Mikrocontroller uber die Zeit ¨(vgl. auch [Beierlein 04]).
  19. 19. 1.3 Eigenschaften eingebetteter Systeme 21Markt. Die Maschinenbauer und Automatisierungstechniker weichen nur un-gern von einer bew¨hrten Technik ab, da die Anspr¨che an die Systeme hin- a usichtlich Sicherheit und Verf¨gbarkeit hier wesentlich h¨her sind als im PC- u obzw. Consumer-Markt. Die Nutzung einer bew¨hrten Technologie uber einen a ¨Zeitraum von bis zu zehn Jahren ist keine Seltenheit, und so muss auch derHalbleiter-Hersteller die langfristige Verf¨gbarkeit sichern.3 u1.3 Eigenschaften eingebetteter SystemeEinige der Eigenschaften eingebetteter Systeme wurden bereits in der Einf¨h- urung angesprochen. Diese Charakteristika werden nun weiter ausgef¨hrt. u1.3.1 FormfaktorDer Formfaktor eingebetteter Systeme ist im Regelfall ein anderer als beiStandard-PCs, da die Baugruppen kompakter aufgebaut sind. Die g¨ngigen aFormfaktoren sind in Abbildung 1.1 zusammengestellt.Erg¨nzend seien angef¨hrt: das Euro-Format (160×100 mm2 ), das halbe Euro- a uFormat (80×100 mm2 ) und das VESA 75/100-Format4 f¨r Ger¨te, die auf die u aAufnahme an der R¨ckseite eines Standard-VESA-Monitors passen. Es exis- utiert dar¨ber hinaus aber auch eine Vielzahl von herstellerspezifischen Sonder- uformaten.1.3.2 Mechanik, K¨ hlung, Robustheit uEingebettete Systeme besitzen im Regelfall keine mechanisch-beweglichenKomponenten. Die Prozessoren werden mit moderaten Taktraten betriebenund k¨nnen entsprechend l¨fterlos passiv gek¨hlt werden. Der Vorteil eines o u uniedrig getakteten, l¨fterlosen Systems liegt auf der Hand: Die Komponen- uten erw¨rmen sich weniger stark und haben daher eine l¨ngere Lebensdauer, a adas Geh¨use ben¨tigt keine Lufteinlass¨ffnungen und kann daher staubdicht a o oausgef¨hrt werden (vgl. auch Schutzarten: IP54, IP65 usw.). uDar¨ber hinaus werden eingebettete Systeme oft auch f¨r einen gr¨ßeren Tem- u u operaturbereich spezifiziert, da die Prozessoren beispielsweise im Kfz einer vielgr¨ßeren Temperaturschwankung ausgesetzt werden als im Standard-PC im oB¨ro. Je nach Einbauposition des Systems in der Fahrgastzelle kann hier ein uTemperaturbereich von bis zu −50 ℃ bis +120 ℃ erforderlich sein.3 Beispiele: AMD garantiert f¨nf, Intel mittlerweile sieben Jahre Verf¨gbarkeit. u u4 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. 20. 22 1 Grundlagen Abb. 1.1. G¨ngige Formfaktoren in der Industrie [WhichSBC 08]. a1.3.3 SpeichermedienAls Festspeichermedien kommen selten Festplatten, meist Flash-Speicher imController oder auf dem Board oder auch in Form von SD- oder CF-Cards zumEinsatz [Wikipedia 08, Solid State Drive]. Der Grund hierf¨r ist die h¨here u oVerf¨gbarkeit bzw. Robustheit dieser Medien. Weiterhin ist oft ein Verzicht auf umechanisch-bewegliche Komponenten gefordert, und auch die Einbaulage desSystems soll frei w¨hlbar sein – mechanische Festplatten weisen hier oftmals aBeschr¨nkungen auf. aBeim Einsatz von Flash-Speichermedien ist zu beachten, dass die Anzahl derSchreibzugriffe minimiert werden sollte. Zwar verf¨gen moderne CF- und SD- uKarten und USB-Sticks uber internes Block Journaling und Wear Leveling 5 , ¨sie k¨nnen aber hinsichtlich der Langlebigkeit bei vielen Schreibzugriffen mit omodernen Festplatten noch nicht gleichziehen. Bei Karten ohne eigenen Con-troller, z. B. vom Typ SmartMedia (SM), ist ohnehin gr¨ßte Vorsicht geboten. o5 Es handelt sich um Optimierungsverfahren, die die Schreibzugriffe pro Sektor mi- nimieren.
  21. 21. 1.3 Eigenschaften eingebetteter Systeme 23Hier empfiehlt sich die Verwendung eines geeigneten Dateisystems wie bei-spielsweise jffs26 . ¨Weiterhin kann auch durch die Uberdimensionierung des Speichermediums eingewisses Maß an Sicherheit und Langlebigkeit erkauft werden – der Faktor istn¨herungsweise gleich (n-fach uberdimensioniert bedeutet n¨herungsweise n- a ¨ afache Anzahl m¨glicher Schreibzugriffe). oEine 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 uwurde nicht auf physikalische, sondern auf logische Sektoren geschrieben.Entsprechend ist hieraus eher auf die Leistungsf¨higkeit der Wear-Leveling- aAlgorithmen, als auf die Haltbarkeit der Flash-Bausteine zu schließen.Bei den in den Speichermedien eingesetzten Flash-Speicherbausteinen inNAND-Bauweise existieren zwei Bauformen: In den Standard-Consumer-Medien werden sog. Multi-Level-Cell-Chips (MLC-Chips) verwendet, f¨r die udie Hersteller um die 10 000 Schreibzyklen angeben. Bei den h¨herwertigen oMedien werden Single-Level-Cell-Chips (SLC-Chips) verbaut, die rund drei-mal schneller beschreibbar sind und auch eine h¨here Lebensdauer von ca. o100 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 uKingston-Medien findet sich die Information auf der letzten Seite des FlashMemory Guide.1.3.4 SchnittstellenEingebettete Systeme besitzen im Regelfall zus¨tzliche Schnittstellen symme- atrischer 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- aDisplays.Auch auf Standard-PC-Boards lassen sich die meisten dieser Schnittstellennachr¨sten, und so kommen immer h¨ufiger USB-IO-Wandler, USB-RS-485- u aWandler oder ¨hnliche Baugruppen zum Einsatz. aEtwas komplexer wird der Sachverhalt, falls echtzeitf¨hige IOs gefordert sind. aHier versagen Umsetzer von USB nach I2 C oder von Ethernet nach DIO, da die6 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. 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 StromversorgungDie 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 aon 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 oeinfacher umsetzen zu k¨nnen. Anwendungen finden sich beispielsweise im Kfz ooder auch in einem fahrerlosen Transportfahrzeug (FTF) in der Fertigung.1.3.6 Chips¨tze aDie in eingebetteten Systemen verwendeten Chips¨tze sind oft andere als bei aStandard-PCs. Zum einen bieten die Chips¨tze teilweise zus¨tzliche Schnitt- a astellen oder Funktionalit¨ten7 , zum anderen m¨ssen sie auch sehr viel l¨nger a u alieferbar sein, da Industriekunden eine Sicherheit von bis zu zehn Jahren f¨r die uErsatzteilstellung fordern. Weiterhin sind die verwendeten Chips¨tze und Pro- azessoren nicht auf Geschwindigkeit optimiert, sondern auf Robustheit, kleinenPlatzbedarf 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) ahaben sich auch als sehr geeignet erwiesen f¨r den Einsatz in der jungen Pro- uduktfamilie der sog. Netbooks8 .Dieser neue Trend im Consumer-Markt hin zu stromsparenden, robustenund preiswerten PCs wird voraussichtlich auch weiterhin auf den Markt derEmbedded-PCs einen großen Einfluss haben.1.3.7 WatchdogEingebettete 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 a7 Bspw. sog. General Purpose Inputs/Outputs (GPIOs).8 Preiswerte, besonders baukleine Notebook-PCs ohne Laufwerke, teilweise auch ohne mechanische Festplatte.
  23. 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 aoder auch vom Betriebssystem regelm¨ßig zur¨ckgesetzt werden. Dieserart ist a ugew¨hrleistet, dass das System, das u. U. schwer zug¨nglich in einer Anlage a averbaut ist, im Fehlerfall selbstst¨ndig wieder anl¨uft. a aJe nachdem, welcher Prozess den Z¨hler zur¨cksetzt, k¨nnen blockierende Feh- a u oler 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 aDer Begriff der Echtzeit bzw. Real-time wird mittlerweile nicht nur im Zusam-menhang mit schnellen Regelungen, sondern auch in vielen anderen Bereichenwie z. B. im Multimedia-Bereich verwendet und wurde entsprechend in denletzten Jahren ein wenig verwaschen. An dieser Stelle sollen nun f¨r den Ge- ubrauch im vorliegenden Buch die Begriffe nochmals klar dargelegt werden.Die DIN 44300, Teil 9 definiert den Begriff der Realzeitverarbeitung (Real-timeProcessing) wie folgt: Eine Verarbeitungsart, bei der Programme zur Verarbei-tung anfallender Daten st¨ndig ablaufbereit sind, derart, dass die Verarbei- atungsergebnisse innerhalb einer vorgegebenen Zeitspanne verf¨gbar sind. Die uDaten k¨nnen je nach Anwendungsfall nach einer zeitlich zuf¨lligen Vertei- o alung oder zu bestimmten Zeitpunkten anfallen.Hier wird entsprechend gleichgesetzt: Echtzeit = Rechtzeitigkeit. Tats¨chlich akann die Verarbeitung aber auch zu schnell erfolgen, bzw. es k¨nnen Ergeb- onisse zu fr¨h vorliegen. Je nach System sind die folgenden unterschiedlichen uZeitbedingungen 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. 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 uEchtzeit-Tasks. Hier werden auch die Begriffe Periodizit¨t und Synchronit¨t a arasch 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. 25. 1.4 Betriebssysteme 27 Idle Task Kommunikation nichtzyklisch Vorbereitung nichtzyklisch Interpolator zyklisch Lageregler zyklisch, t periodisch Interpolatortakt: ti Lageregeltakt: tlAbb. 1.2. Eine Robotersteuerung als Beispiel f¨r ein echtzeitf¨higes, synchrones u aSystem. Filmwiedergabe ein selten auftretendes Ruckeln noch problemlos toleriert werden kann.Die verschiedenen M¨glichkeiten der Realisierung dieser Bedingungen werden oim nachfolgenden Abschnitt 1.4 weiter ausgef¨hrt. u1.4 Betriebssysteme1.4.1 Allgemeine AnforderungenWie bereits angesprochen, ist f¨r ein einfaches eingebettetes System ein Be- utriebssystem nicht unbedingt erforderlich. Im einfachsten Fall der diskretenRegelschleife besteht das Programm aus einer einzigen Hauptschleife, welcheohne Unterbrechung (ohne Interrupts) ausgef¨hrt wird. Am Ende eines Schlei- ufendurchlaufes werden die berechneten Gr¨ßen ausgegeben und von den Sen- osoren neue Istwerte eingelesen.Derart einfache Systeme sind in der Praxis nur selten ausreichend. Meist istneben 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 anoch eine Benutzerschnittstelle hinzu. Sp¨testens jetzt ist der Einsatz eines Be- atriebssystems sinnvoll; es organisiert und priorisiert den quasiparallelen Ablaufder einzelnen Tasks in Zeitscheiben, es bietet eine Kapselung f¨r Schnittstellen, uverwaltet den Arbeitsspeicher und regelt den Zugriff auf Festspeichermedienuber ein Dateisystem.¨
  26. 26. 28 1 GrundlagenAbweichend von den klassischen Betriebssystemen, wie sie bei Desktop-PCszum Einsatz kommen, wird bei eingebetteten Systemen weiterhin oft die Da-tenverarbeitung zu harten Echtzeitbedingungen gefordert. Hierzu wiederumeine Definition:Ein Echtzeitbetriebssystem ist ein Betriebssystem, das die Konstruktion einesEchtzeit-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 vonkonventionellen 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. 27. 1.4 Betriebssysteme 291.4.2 Prozess-SchedulingDer sog. Scheduler ist jener Teil des Betriebssystems, der den Prozessen bzw.Tasks den Prozessor bzw. die Rechenzeit zuteilt.9 F¨r diese Zuteilung sind umehrere Algorithmen gebr¨uchlich, wobei die Auswahl von der jeweiligen An- awendung abh¨ngt (Abbildung 1.3). aSo 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 unbedingtschnelle, 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 aIm ersten Fall kann auch ein Prozess h¨herer Priorit¨t einen laufenden Pro- o azess nicht verdr¨ngen; er wird erst nach Abschluss des laufenden Prozesses aausgef¨hrt. Im zweiten Fall kann ein h¨herpriorer Prozess einen anderen, ak- u otuell laufenden Prozess zum Pausieren zwingen. Der niederpriore Prozess wirdbis zum Abschluss der Bearbeitung des neuen Prozesses angehalten.Folgende Scheduling-Verfahren sind gebr¨uchlich [Brosenne 08]: a9 Zu Details bzgl. Tasks und Threads vgl. Kapitel 12.
  28. 28. 30 1 GrundlagenShortest Job FirstBei diesem einfachen Scheduling-Verfahren wird jeweils der Prozess mit derk¨rzesten Rechenzeit als n¨chstes gerechnet. Laufende Prozesse werden hier- u abei nicht unterbrochen (nicht-verdr¨ngend, non-preemptive). Das Verfahren aist nicht fair, da kurze Prozesse lange Prozesse uberholen k¨nnen und damit ¨ obevorzugt behandelt werden. Das Verfahren ist f¨r Echtzeitanwendungen un- ugeeignet.First Come First ServedWieder handelt es sich um ein relativ einfaches Scheduling-Verfahren: Die Pro-zesse werden gem¨ß ihrer Ankunftsreihenfolge dem Prozessor zugeteilt. Auch ahier werden laufende Prozesse nicht unterbrochen (nicht-verdr¨ngend, non- apreemptive). Das Verfahren ist fair, da gesichert ist, dass jeder Prozess bear-beitet wird. Das Verfahren ist f¨r Echtzeitanwendungen ungeeignet. uRound-RobinIm Vergleich zu den vorangegangenen Verfahren ist das Round-Robin-Scheduling bereits vergleichsweise ausgefeilt. Bei diesem Verfahren wird dieRechenzeit in Zeitscheiben gleicher L¨nge aufgeteilt, die Prozesse werden in aeine Warteschlange eingereiht und gem. dem Verfahren First-In-First-Out aus-gew¨hlt. Ein zu rechnender Prozess wird nach Ablauf der aktuellen Zeitscheibe aunterbrochen. Er pausiert und wird erneut hinten in die Warteschlange ein-gef¨gt. Das Verfahren ist fair, die Rechenzeit wird gleichm¨ßig und gerecht u aauf die Prozesse aufgeteilt. Es ist mit Einschr¨nkungen f¨r Anwendungen mit a uweichen Echtzeitanforderungen geeignet.Round-Robin mit Priorit¨ten aDas Round-Robin-Verfahren kann durch die Einf¨hrung von Priorit¨ten u aerg¨nzt werden. Hierbei werden Prozesse mit gleicher Priorit¨t zusammen- a agefasst in eine gemeinsame, dedizierte Warteschlange. Dann wird immer dieProzess-Warteschlange mit den h¨chstprioren Prozessen nach dem Round- oRobin-Verfahren abgearbeitet. Es ist allerdings zu beachten, dass es geschehenkann, dass Prozesse nie gerechnet werden (verhungern). Eine m¨gliche Abhilfe oist eine Erh¨hung der Priorisierung gem. der Wartezeit. oDieses 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. 29. 1.4 Betriebssysteme 31Statisches Echtzeit-Scheduling am Beispiel desRate-Monotonic Scheduling (RMS)Beim statischen Scheduling wird der Schedule bereits zur Compile-Zeit f¨r ualle m¨glichen Tasks aufgestellt. Folgende Voraussetzungen werden nun f¨r o udie 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. a4. 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 aexistiert genau dann, wenn gilt: n ∆ti ≤1 (1.1) i=1 Per iHierin 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 mitder k¨rzesten Periode (der h¨chsten Wiederholrate) erh¨lt die h¨chste Prio- u o a orit¨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 udas Existieren eines Schedules nach diesem Verfahren folgender Zusammen-hang: n ∆ti µ= ≤ n(21/n − 1) (1.2) i=1 Per iF¨r n → ∞ konvergiert die rechte Seite gegen 0,693. Aber auch bei h¨heren u oAuslastungen ist ein Schedule nicht unm¨glich. Wenn im System z. B. alle o
  30. 30. 32 1 GrundlagenPeriodenzeiten Vielfache der k¨rzesten Periode sind, so existiert auch f¨r eine u uCPU-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 beieiner Prozessorlast > 70 % eine feste Schedule-Zusage nicht mehr m¨glich ist. oEine typische Anwendung des Verfahrens ist die Verarbeitung vorher bekann-ter Audio- oder Video-Streams.Dynamisches Echtzeit-Scheduling am Beispiel desEarliest Deadline First-Verfahrens (EDF)Beim dynamischen Scheduling wird der Schedule zur Laufzeit f¨r die aktu- uell auszuf¨hrenden Tasks erstellt. Ein g¨ngiges Verfahren hierf¨r ist das Ear- u a uliest Deadline First-Verfahren. Hierbei wird von einem preemptiven System mitdynamischer Priorit¨tenverteilung ausgegangen, ansonsten sind die Vorausset- azungen die gleichen wie bei RMS. Die einfache Regel lautet nun: Ausgef¨hrtuwird immer der Prozess, der aktuell die k¨rzeste Deadline aufweist. uDie Vorteile des Verfahrens sind, dass es einfach zu implementieren ist und denProzessor bis zu 100 % ausnutzen kann. Ein gravierender Nachteil ist aber, dassein korrekter Schedule nicht in allen F¨llen sichergestellt werden kann. aNeben 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; uBrosenne 08].1.4.3 SystembeispieleZur Realisierung eines Echtzeit-Betriebssystems sind verschiedene Ans¨tze adenkbar. Ein erster einfacher Ansatz ist die Modifikation des Kernels derart,dass Unterbrechungen m¨glich werden (preemptives Multitasking). Erg¨nzt o amit einer Minimierung der Interrupt-Maskierungszeiten ist mit einem solchenSystem zumindest weiche Echtzeit gut m¨glich. Vertreter dieser Architektur osind: SunOS 5.x und AiX 3.0.Eine andere M¨glichkeit ist die Erweiterung eines Standard-Betriebssystems oum einen preemptiven, echtzeitf¨higen Mikrokernel. Bei diesem aufw¨ndigen a aAnsatz ist entsprechend auch eine Neu-Implementierung des Schedulers not-wendig, das System kann damit aber auch f¨r harte Echtzeitanforderungen uausgelegt werden. Vertreter: VxWorks und QNX.

×