Rechner-Peripherie


Prof. Jürgen Plate

Ein- und Ausgabeschnittstellen

Hier sollen einige Fakten über Schnittstellen kurz besprochen werden. Anschliessend folgen einige Bemerkungen über Embedded Systeme.

Rückblick: PC-Rechnerarchitektur

Von Neumann Architektur

Im Jahre 1944 legte John von Neumann, ein ehemaliges Mitglied des ENIAC-Projektes, ein Architektur-Konzept für einen speicherprogrammierten Universalrechner vor. Sein erster Entwurf ist heute als "von-Neumann-Maschine" oder "von-Neumann-Architektur" bekannt - ein weitsichtiges und visionäres Konzept, das auch noch aktuellen Computern zugrunde liegt. Eine Von-Neumann-Maschine weist folgende wichtige Merkmale auf:

  1. zentrale Recheneinheit (CPU = Central Processing Unit) mit
  2. Speicher
  3. Ein- und Ausgabe-Einheit
  4. internen Datenwegen(Busse)

Die Struktur des Rechners ist unabhängig von dem zu bearbeitenden Problem ( Universalrechner). Die verschiedenen Aufgaben werden durch entsprechende Programme gelöst. Programme und von diesen benötigte Daten werden in einem gemeinsamen Speicher abgelegt. Die Speicherplätze sind gleichlang und werden über Adressen einzeln angesprochen.

Die bedeutendste Neuerung war von Neumanns Idee, Programm und Daten zuerst in den Speicher zu laden und dann auszuführen. Bis dahin war das Programm noch hardwaremäßig verschaltet oder wurde über Lochstreifen schrittweise eingelesen und sofort (streng sequentiell) bearbeitet. Nun war es möglich:

Von Neumann erreichte mit seinem Konzept, dass der Rechner selbstständig logische Entscheidungen treffen kann. Damit ist der Übergang vom starren Programmablauf zur flexiblen Programmsteuerung vollzogen.

Die von Neumann Architektur hat aber auch einige Nachteile:

Bei falscher Adressierung können Speicherinhalte verändert werden, die nicht geändert werden dürfen, wie z. B. Befehle und Konstanten.

Da Daten und Befehle im Speicher gehalten werden, wird die Verbindung und Datenübertragung zwischen CPU und Speicher bzw. zur Ein-/Ausgabe über den Systembus zum sogenannten Von-Neumann-Flaschenhals. Jeglicher Datenverkehr von und zur CPU wird über den internen Bus abgewickelt, dessen Transfergeschwindigkeit langsamer ist, als die Verarbeitungsgeschwindigkeit der CPU. Dieses Problem versucht man in modernen PC's durch die Verwendung von schnellem Cache-Speicher, der meist in der CPU integriert ist, abzuschwächen.

Komponenten der von-Neumann-Rechnerarchitektur

Die CPU besteht aus Recheneinheit (ALU) und Steuereinheit. Die ALU hat eine feste Wortbreite, z. B. 8, 16, 32 oder 64 Bit, ihre Aufgabe besteht in der Bearbeitung der Daten, besonders dem Ausführen von arithmetischen und logischen Operationen.

Zur wichtigsten Aufgabe der Steuereinheit gehört die Koordination der zeitlichen Abläufe im Rechner. Dazu muss die Steuereinheit die Befehle aus dem Speicher holen, entschlüsseln und deren Ausführung steuern. Die Steuereinheit besteht aus Befehlsregister, Befehlsdecoder, Speicheradressregister und Befehlszähler.

Der Speicher eines von-Neumann-Rechners besteht aus einer Vielzahl von Speicherworten, die wahlfrei adressiert werden können.

Innerhalb eines von-Neumann-Rechners erfolgt der Datentransport auf internen Datenwegen, den Bussen:

PC-Architektur

In einem modernen PC verkörpert der Prozessor die ALU und die Steuereinheit, die Northbridge mit dem RAM den Speicher. Die Southbridge und der Rest bilden die Ein-/Ausgabe. Zu letzterer gehören z. B. der PCI-Bus ebenso wie die verschiedenen Schnittstellen der Peripheriegeräte und Festplatten.

Zentraler Bestandteil des PCs ist das Mainboard (Hauptplatine, Motherboard). Auf ihm sind die CPU, Arbeitsspeicher (RAM), das BIOS-ROM (bzw. BIOS-Flash-EEPROM) sowie verschiedene Steckplätze und Schnittstellenbausteine zur Koppelung dieser Komponenten montiert, die in der Regel aus "Northbridge" und "Southbridge" bestehen (s. u.).

Die Standards der Bussysteme für Peripheriekomponenten haben sich seit Einführung des PCs um 1980 sehr verändert. Begonnen hat alles mit dem ISA-Bus, der im Prinzip die Busleitungen der CPU wiederspiegelte. Mit immer höheren Taktfrequenzen der CPU-Typen konnte dieser Bus bald nicht mehr muthalten und so bildetetn sich immer neue Standards:

Die Northbridge enthält in PC-Systemen unter anderem den Speichercontroller, der den Datentransfer zwischen CPU und Hauptspeicher verwaltet. Dieser ist über den Frontsidebus (FSB) an die CPU gekoppelt. Außerdem synchronisiert die Northbridge noch den Datentransfer und die Datensteuerung zwischen CPU und AGP- bzw. PCI-Express-Grafikkarte. In neueren Systemen ist der Speichercontroller nicht mehr Bestandteil der Northbridge, sondern direkt in den Prozessor integriert (z. B. Athlon64) was den Datentransfer zwischen CPU und Speicher zusätzlich beschleunigt. Die Northbridge ist über den PCI-Bus, über PCI-X (schnellere 64-Bit-Variante von PCI) oder eine andere Schnittstelle mit der Southbridge verbunden. Die Southbridge ist für den Datentransfer und die Steuerung der peripheren Geräte (PCI-Steckkarten, IDE-Laufwerke, USB, Maus, Tastatur etc.) zuständig. Außerdem sind oftmals Peripheriegeräte bereits in die Southbridge integriert, beispielsweise OnBoard-Soundlösungen und LAN-Schnittstellen.

Northbridge und Southbridge bilden zusammen den sogenannten Chipsatz des Mainboards. In moderneren Systemen kann die Southbridge sogar direkt in die Northbridge integriert sein. Die Bezeichnungen "Northbridge" und "Southbridge" resultieren aus der räumlichen Anordnung der jeweiligen Chips auf dem Mainboard. Dreht man die Platine so, dass der Prozessorsockel oben ist, liegt die Northbridge näher an der CPU, also "im Norden der Platine", während die Southbridge weiter "südlich" im unteren Teil der Platine zu finden ist.

PCI

"PCI" steht für "Peripheral Component Interconnect". Wie schon erwähnt, handelt es sich um einen Bus zur Verbindung von Peripheriegeräten mit dem Chipsatz und dem Prozessor. Der PCI-Bus ist Industriestandard und wurde von Intel im Jahr 1990 entwickelt, um ISA und EISA abzulösen. Der ursprüngliche PCI-Bus übertrug 32 Bit pro Zyklus und lief mit 33 MHz. Die Bandbreite betrug insgesamt 133 MByte/s. 1993 wurde PCI 2.0 eingeführt, und 1995 kam PCI 2.1 heraus. PCI 2.2 hat Eigenschaften, die ihn für mobile Computer geegnet machen (vorwiegend solche zur Leistungs-Einsparung von Batteriestrom). Mittlerweile liegt PCI 2.3 vor. Der aktuelle PCI-Bus läuft mit bis zu 66 MHz und handhabt 64 Bit-Transfers.
Die PCI Spezial Interest Group (PCI-SIG) entwickelt seit 1998 den Standard PCI-X. Die Version 1.0 ist eng mit der PCI-Variante verwandt, die in PCs eingesetzt wird. Vorwiegender Einsatz von PCI-X ist in einem Dual-Prozessor-System. Die 64-Bit-Variante ermöglicht mit 133 MHz Taktfrequenz übertragungsraten von bis zu 1,06 GByte/s. PCI-X ist abwärtskompatibel zu PCI, wenn die verwendete Steckkarte mit 3,3 V Signalspannung und 66 MHz arbeiten. Durch Kodierkerben im Kontaktkamm und Slot ist dafür gesorgt, das 5-V-Karten nicht in den 3,3-V-Slot passen und umgekehrt. Die PCI-X-Version 2.0 verbessert die Effizienz auf dem PCI-Bus und bringt eine ECC-Fehlerkorrektur für die übertragenen Daten mit.

PCI-Express

PCI-Express (Peripheral Component Interconnect Express, PCIe) ist der Nachfolger von PCI und bietet eine höhere Datenübertragungsrate. Der 2004 eingeführte PCIe ist im Gegensatz zu PCI kein paralleler Bus, sondern eine serielle Punkt-zu-Punkt-Verbindung. Die PCI-Express-Spezifikation beschreibt das Software-Protokoll, elektrische und mechanische Eigenschaften der Steckverbinder und Erweiterungskarten. Wesentliche Eigenschaften sind:

Die Datenübertragung erfolgt über sogenannte Lanes (Spuren, Wege), wobei jede Lane aus einem Leitungspaar für das Senden und einem zweiten Paar für das Empfangen besteht. Trotz dieses völlig anderen physischen Aufbaus ist PCIe softwareseitig voll kompatibel zu PCI, so dass weder Betriebssysteme, noch Treiber, noch Anwendungsprogramme angepasst werden müssen. PCIe ist vollduplexfähig und arbeitet mit einer Datenrate von maximal 250 MByte/s pro Lane und Richtung. Zählt man beide Richtungen zusammen erhält man sogar ca. 500 MByte/s (etwa das Dreifache des Standard-PCI Bus mit 32-Bit Busbreite bei 33 MHz).

Verwendet man nur eine Lane, spricht man von "PCIe x1". Durch die Koppelung mehrerer Lanes kann die Datenrate erhöht werden, beispielsweise "PCIE x2" mit zwei Lanes bis hin zu "PCI x32" mit 32 Lanes. Die PCI-SIG plant darüber hinaus zukünftige Versionen mit 500 und 1000 MByte/s pro Lane. Im Enduserbereich wird "PCIe x1" als Ersatz für den PCI-Bus und "PCIe x16" zur Anbindung einer Grafikkarte verwendet (PCI-Express For Graphics, PEG). Die Slots sind außerdem abwärts kompatibel, d. h. eine "PCI x4"-Karte kann z. B. auch in einen "PCI x8"-Slot gesteckt werden, die überzähligen vier Lanes werden dann nicht genutzt.

Rückblick: Aufgaben einer E/A-Schnittstelle

Die Gesamtheit der Einrichtungen, über welche die CPU mit den peripheren Geräten kommuniziert, nennt man E/A-Schnittstelle. Im Allgemeinen findet ein (bidirektionaler) Datentransport zwischen Speicher und Peripherie statt. Neben dem reinen Datentransport ist eine Anpassung der Datendarstellung zwischen CPU und Peripherie erforderlich = Umsetzung der Bus- auf die Peripherieschnittstelle: Zeitliche Anpassung (CPU und Peripherie arbeiten i. a. nicht synchron, d. h. sie sind zeitlich zu entkoppeln).
  • Signalumsetzung (z. B. Pegelanpassung)
  • Datenformatanpassung (z. B. seriell/parallel-Wandlung)
  • Codewandlung
  • Fehlererkennung und -korrektur Schnittstellen können von unterschiedlicher Komplexität sein:

    Methoden des Datentransfers

    Programmierter E/A-Transfer

    Einfache E/A-Schnittstellen für programmierten E/A-Transfer bestehen wesentlich aus: Sie ist normalerweise an den Systembus der CPU angeschlossen. Das EADR dient zur Zwischenspeicherung des zu übertragenden Datenwerts (zeitliche Anpassung). Neben den zu übertragenden Daten braucht die Schnittstelle Signale zur richtigen Abwicklung des Datentransfers:

    Diese Signale werden - soweit sie für längere Zeit zur Verfügung stehen müssen - im EASR gespeichert. Das EASR kann auch aus separaten Registern für Status- und Steuersignale bestehen. Normalerweise verfügt ein Computer über mehr als eine E/A-Schnittstellen Adressierung erforderlich. Für die Adressierung der E/A-Schnittstellen gibt es zwei Möglichkeiten: Im allgemeinen erhalten EADR und EASR eine eigene, separate Adresse. Beide sind am Datenbus angeschlossen. Steuersignale werden wie Datenwerte ins EASR geschrieben, Statussignale werden wie Datenworte aus dem EASR gelesen - die Verarbeitung muss in der CPU durch geeignete Befehle erfolgen (z.B. log. Verknüpfung).

    Programmgesteuerter programmierter Transfer

    Die E/A-Befehlsfolge steht innerhalb eines Programms und wird im Rahmen der normalen Programmausführung abgearbeitet. Die gesamte Initiative zur E/A geht vom Programm aus. Zeigt der Inhalt des EASR an, dass keine neuen Daten im EADR stehen, muss das Programm erneut das EASR abfragen Warteschleife, "Polling". Dabei können zwei "Randbereiche" Probleme verursachen:

    Unterbrechungsgesteuerter programmierter Transfer

    Die E/A-Befehlsfolge wird durch einen von der E/A-Schnittstelle ausgelösten Interrupt gestartet. Der Interrupt wird von der Schnittstelle abgesetzt, wenn ein Datenwort empfangen wurde und im EADR steht (bzw. wenn ein Datenwort aus dem EADR abgeholt wurde). Die CPU braucht nicht in einer Programmschleife zu warten, sondern kann in der Zwischenzeit ein anderes Programm bearbeiten, das durch den Interrupt kurzzeitig unterbrochen wird. Der interruptgesteuerte Transfer gestattet zudem die quasi-simultane Bedienung mehrerer langsamer Schnittstellen. Zur Realisierung muß eine Interrupt-Leitung von der E/A-Schnittstelle (EASR) zum Unterbrechungswerk der CPU vorhanden sein.

    Vorteil des programmierten Transfers: Sehr einfache Schnittstellen, die übersichtlich und leicht zu verwenden sind.

    Nachteil des programmierten Transfers: Für den Transfer jedes einzelnen Datenworts wird die CPU benötigt. Diese muss dabei relativ viel Verwaltungsaufwand leisten (Laden/lesen EASR, Interrupt-Behandlung) die maximale Datenrate ist sehr begrenzt.

    Direktspeicherzugriff (DMA = Direct Memory Access)

    Beim DMA steuert die E/A-Schnittstelle den Transfer nach Anstoß durch die CPU selbstständig und ohne Zuhilfenahme der CPU Datentransport zwischen Speicher und Peripherie unter Umgehung der CPU. Selbst, wen die CPU in dieser Zeit nichts anderes tut, ist ein wesentlich schnellerer Datentransport möglich (weitgehender Wegfall der Verwaltungsarbeit). Daher ist DMA für den schnellen Transfer großer Datenmengen besonders geeignet. Zum Anstoßen des DMA-Transfers übermittelt die CPU der DMA-Schnittstelle: Die DMA-Schnittstelle benötigt zwei weitere Register:

    Da während des DMA-Transfers anstelle der CPU die DMA-Schnittstelle die Kontrolle über den Systembus besitzt, muss sie zusätzlich über eine Bus-Steuerlogik verfügen (Konkurrenz zwischen DMA Schnittstelle und CPU um den Bus).

    Ablauf eines DMA-Transfers:

    Man unterscheidet verschiedene DMA-Modi:

    PC-Schnittstellen

    Die Schnittstellen des PC (USB, serielle Schnittstelle, parallele Schnittstelle, Tastatur etc.) werden an anderer Stelle behandelt:

    Embedded Systems

    "Embedded Systems" ist der englische Fachbegriff für eingebettete (Computer-)Systeme, die in der Regel unsichtbar ihren Dienst in einer Vielzahl von Anwendungsbereichen und Geräten versehen, wie z.B. in Flugzeugen, Autos, Kühlschränken, Fernsehern, Werkzeugmaschinen, Kaffeeautomaten, DVD-Playern oder anderen Geräten. In der Computerbranche werden solche Systeme auch gerne "Appliance" genannt. ("appliance: A device or instrument designed to perform a specific function, especially an electrical device, such as a toaster.)

    Wenn man den Begriff aufschlüsselt ergibt sich:

    Ein eingebettetes System verrichtet, weitgehend unsichtbar für den Benutzer, den Dienst in einer Vielzahl von Anwendungsbereichen und Geräten, wie z. B. in Flugzeugen oder Autos, Haushaltsgeräten, in der Unterhaltungselektronik, bei Mobiltelefonen oder in industriellen Steuerungen. Ein eingebettetes System interagiert mit seiner meist elektromechanischen Umwelt. Dabei ist kein menschlicher Benutzer vonnöten; er muss auch keinerlei Kenntnisse über die technischen Innereien des eingebetteten Systems haben, um das Gesamtsystem bedienen zu können. Im Fall von komplexen Gesamtsystemen handelt es sich dabei meist um eine Vernetzung einer Vielzahl von autonomen, eingebetteten Systemen.

    Eingebettete Systeme können in Einzelfällen auf ähnlicher Hardware wie Arbeitsplatzcomputer basieren (sogenannte embedded-PCs), in der Regel unterliegen sie jedoch stark einschränkenden Randbedingungen: Minimale Kosten, geringer Platz-, Energie-, Speicherverbrauch. Einzelne Komponenten wie Prozessor oder Arbeitsspeicher müssen auch wesentlich länger auf dem Markt verfügbar sein, um die langfristige Einsetzbarkeit und Ersatzteilbeschaffung zu gewährleisten. „Moderne“ eingebettete Systeme basieren auf den verschiedensten Prozessor-Plattformen, die in Bezug auf die Peripheriemodule hochintegriert sind und durch moderne Stromspartechniken wenig Energie verbrauchen.

    "Embedded Systems" vereinigen daher durch ihre oftmals sehr hardwarenahe Konstruktion die große Flexibilität von Software mit der Leistungsfähigkeit der Hardware. Die Software-Entwicklung für diese Systeme unterscheidet sich oft grundsätzlich von jener für Desktop- oder PC-Systeme: oftmals werden Betriebssysteme eingesetzt, die zwar nicht über eine grafische Benutzeroberfläche verfügen, dafür jedoch Echtzeitanforderungen genügen.

    Bevorzugte Programmiersprachen sind daher z. B. Assembler oder C. Bekannte Embedded-Betriebssysteme sind z.B. QNX, VxWorks, Windows CE, DOS, LynxOS, Nucleus, zunehmend auch spezielle Linux-Derivate, wenn die Echtzeitbedingungen keine dominante Rolle spielen. Einige Beispiele für Embedded Systems sind:

    Kennzeichnende Merkmale von embedded Systemen sind: Sekundäre Merkmale von embedded Systemen sind: Eingebettete Systeme beanspruchen einen Marktanteil bei der Prozessor-Produktion von ca. 98%. Die restlichen 2% dienen dem Aufbau von interaktiven Systemen wie z. B. Laptops, Desktop-Computern und Servern. Nahezu die Hälfte der gesamten Microcontroller-Jahresproduktion sind immer noch 8-Bit-Prozessoren. Bereits heute gibt es mehr eingebettete Systeme als Menschen auf der Welt. Deren Elektronik dient oft als Wegwerf-Artikel (z. B. RFID-Tags, Grusspostkarten).

    Man setzt deshalb für die Definition des eingebetteten Systems voraus, dass

    Tatsächlich haben sich im der Industrie immer häufiger Standard-PC-Komponenten bei Neuentwicklungen von eingebetteten Systemen durchgesetzt -- geringe bis mittlere Stückzahlen und kurze Produktzyklenzeiten vorausgesetzt. Die Komponenten von der Stange ("Commodity of the Shelf", COTS) kosten oft nur einen Bruchteil vergleichbarer proprietärer Industrielösungen und sind dabei wesentlich flexibler. Diese "Embedded PCs" sind aber nicht überall sinnvoll: Oft zwingen rauhe Umgebungen und Platzmangel zu speziellen Eigenentwicklungen. Bei hohen Stückzahlen ist dies ohnehin obligatorisch.

    Anders als stationäre Systeme haben eingebettete Systeme besondere Anforderungen hinsichtlich Robustheit, Energieverbrauch und Speicherbedarf, Im Gegensatz zu einem Arbeitsplatzrechner wird ein eingebettetes System im Allgemeinen nicht "heruntergefahren", bevor man es ausschaltet. Es muss im Gegenteil damit zurechtkommen, dass ihm der Strom jederzeit und ohne Vorwarnung abgestellt werden kann. Damit ein solcher Shutdown, etwa aufgrund eines Stromausfalls, problemlos überstanden wird und die Software nach dem Booten in einen definierten Anfangszustand gelangt.

    Bewegliche Teile wie Lüfter oder Festplatte sind meist nicht erwünscht. Besonders sind auch meist die Umgebungsbedingungen wie Temperatur und Feuchtigkeit. Um auch diesen Anforderungen gerecht zu werden, steht eine möglichst geringe Stromaufnahme des Prozessors bzw. des Boards im Vordergrund. Im Vergleich zum "Stomfresser" im Desktop-Rechner kommt ein embedded Board meist mit weniger als 1 Watt aus. Embedded Systems laufen buchstäblich während ihrer gesamten Lebensdauer, also an sieben Tagen pro Woche und 24 Stunden pro Tag. Gelegentliche Abstürze mit der Notwendigkeit eines Neustarts sind hier absolut inakzeptabel (insofern fällt mein kürzlich erworbener DVB-T-Empfänger/Decoder aus dem Rahmen, bei schlechtem Empfang hängt er sich schon mal auf).

    Embedded Systems basieren also oft auf ähnlicher Hardware wie Arbeitsplatzcomputer, unterliegen jedoch meist stark einschränkenden Randbedingungen: minimale Kosten und damit geringer Platz-, Energie-, Speicherverbrauch. Die Fertigung in großen Stückzahlen, oft im Millionen-Bereich, ist ein weiterer wichtiger Punkt zur Kostenreduzierung. Hinzu kommt, dass die einzelnen Komponenten wie Prozessor und RAM auf Weiterentwicklungen älterer Komponenten basieren, was die Langlebigkeit steigert, Stromverbrauch und -kosten jedoch senkt.

    Für viele Anwendungen können auch ältere Komponenten eingesetzt werden, wenn zudem die Vereinfachung der Architektur des ursprünglichen Systems dazu beiträgt, weitere Kosten zu senken. Programme eines Embedded Systems müssen oft Echtzeitanforderungen genügen. In der Regel existieren verglichen mit Desktop-PC-Hardware nur stark reduzierte Ressourcen, zumeist ohne Festplatte, Betriebssystem, Tastatur oder Bildschirm. Ein ROM- oder Flash-Speicher ersetzt meist mechanische Speicherkomponenten wie eine Festplatte: bewegliche Teile bedeuten Verschleiß, der hier unerwünscht ist. Wenn überhaupt, dann gibt es meist nur ein Tastenfeld und die Ausgabe wird -- soweit überhaupt vorgesehen -- durch ein LCD realisiert.

    Design von Embedded Systems

    Die Elektronik wird meist von einem Mikroprozessor mit entsprechender Peripherie oder einem Microcontroller gebildet. Vielfach handelt es sich auch um komplette PC-Boards mit stromsparenden Bauteilen und anderem Formfaktor. Ein solcher PC gilt bereits als groß, wenn er Postkartenformat besitzt. Um das Board herum ist dann die dem Aufgabengebiet entsprechende Peripherie angeordnet. Folgende Aspekte spielen u. a. bei Designentscheidungen von Embedded Systems eine Rolle:

    So weit wie im letzten Punkt beschrieben, soll hier nicht gegangen werden. Wir verwenden einen relativ "normalen" PC, der wahlweise eine Festplatte oder einen Compact-Flash-Speicher als Massenspeicher besitzt. Als Betriebssystem kommt Linux zum Einsatz.

    Hardware für Embedded PC-Systeme

    Linux läuft mittlerweile auf fast allen 32-Bit-Prozessoren, die eine Speicherverwaltungseinheit aufweisen. Dennoch konzentrieren sich derzeit die Embedded-Linux-Bestrebungen weitestgehend auf x86-kompatible Systeme. Dazu zählen vor allem die (in der mittelständischen Industrie weit verbreiteten ca. 10cm x 10cm großen) Mini-PC-Systeme mit PC104-Bus (ähnlich dem alten ISA-Bus). Für x86-Rechner gibt es auch etliche Mini-Linux-Distributionen, die als gute Ausgangsbasis für eigene Entwicklungen dienen können. Manche dieser Embedded PC-Systeme haben aber Komponenten auf der Platine, die sich mit Linux nicht vertragen wollen, so dass vor der Anschaffung mit dem Hersteller die Linuxverträglichkeit sichergestellt werden sollte. Sonst muss man eventuell selbst einen Treiber schreiben -- was nicht jedermanns Sache ist.

    Handelsübliche Festplatten sind nicht immer einsetzbar, wenn es sich um eine rauhe Industrieumgebung handelt. Schock-, Staub und Temperaturempfindlichkeit setzen ihnen Grenzen -- obwohl heutige Festplatten viel aushalten. Den Ausweg bieten sogenannte "Solid-State-Disks" auf der Basis von Flash-Speichern, Permanentspeicher ohne verschleißempfindliche Teile mit einer logischen oder physikalischen Festplatten-Schnittstelle. Leider vertragen Flash-Bausteine selten mehr als einige 10000 bis 100000 Schreibzyklen, so dass es sich nicht unbedingt empfiehlt, darauf Logdateien oder Swap-Partitionen anzulegen. Auch das Aktualisieren des Dateisystems (Eintragen des letzten Zugriffs auf eine Datei, usw.) muss abgeschaltet werden. Für variable Dateien bietet sich das Anlegen einer RAM-Disk an, deren Inhalt gegebenenfalls in größeren Zeitabständen auf das Flash-Dateisystem kopiert wird. Für Flash-Disks gibt es etliche Anbieter, im Bereich Embedded-Linux haben sich aus Kostengründen die Produkte von SanDisk (und den zahlreichen Second-Source-Lieferanten) durchgesetzt.

    Hier gibt es eine schier unüberschaubare Produktpalette, beginnend beim 3,5-Zoll-Festplattenersatz bis hin zu CompactFlash-Karten und einzelnen Flash-Chips mit den dazugehörigen Mikrocontrollern (IDE und PCMCIA-Interfaces). Bei 2 MByte bis 2 GByte dürfte für jeden Zweck was dabei sein. Ein Zielsystem lässt sich also zunächst unter Verwendung einer gewöhnlichen Festplatte erstellen und bei der Serienproduktion durch eine Flash-Disk mit IDE-Schnittstelle ersetzen. Der Entwickler muss sich nicht um spezielle Treiber kümmern, das eingebettete System setzt aber einen unter Linux nutzbaren IDE-Controller voraus.

    Als Beispiel: Embedded Linux

    Linux ist natürlich nicht das einzige Betriebssystem für Embedded Systems und auch nicht für alle Anwendungsfälle geeignet. So besitzt ein Standard-Linux beispielsweise keine Echtzeitfähigkeit. Viele Industriesysteme laufen auch heute noch mit DOS-Anwendungen -- bei Singletasking-Anwendungen ist das ja auch kein Problem. Aber DOS wird schon lange nicht mehr verkauft, fällt deshalb bei Neuentwicklungen schon aus. Warum nicht als Ersatz zu Linux greifen, denn:

    Wo Licht ist, da ist auch Schatten. Die Nachteile von Linux für Embedded Systems sollen nicht verschwiegen werden: Linux besitzt eine vollständig modulare Struktur und ist dadurch recht einfach skalierbar. Gerade im Bereich der eingebetteten Systeme ist diese Eigenschaft unbedingt notwendig. Linux unterstützt inzwischen nahezu alle wichtigen 32-Bit-Prozessorarchitekturen mit und ohne MMU (Memory Management Unit = Speicherverwaltungseinheit). Aus diesem Grund und wegen der nicht vorhandenen Lizenzkosten ist Linux besonders für den Einsatz als eingebettetes Betriebssystem in der Automatisierungstechnik und im Bereich "Messen, Steuern und Regeln (MSR)" geeignet.

    Um die Verbreitung von Linux als Embedded-Betriebssystem zu fördern, wurden 2001 in den USA das "Embedded Linux Consortium (ELC)" und in Japan die "Emblix Vereinigung" gegründet. Beide Institutionen verfügen dank ihrer zahlreichen Mitglieder über nicht unerhebliche Finanzmittel und wollen Linux durch gezielte Pressearbeit, Messeauftritte und Internet-Präsenz zum führenden Embedded-Betriebssystem entwickeln.

    Wie klein muss ein Kernel sein? Bei eingebetteten System natürlich so klein wie möglich, aber bitte schön mit aller Funktionalität, die Linux bietet! Diese Forderung muss natürlich zu Kompromissen führen. Wer aber mit extrem knappen Ressourcen zu kämpfen hat, sollte sich überlegen, ob er nicht zu einem anderen, "dünneren" Betriebssystem greift.

    Generell verwendet man bei Embedded-Projekten die jeweilige Portierung für die Plattform. Die spezifischen Eigenschaften werden durch die Konfiguration festgelegt, d. h. durch die Auswahl der Komponenten und Module.

    Eine Besonderheit stellt hier uClinux dar. Hierbei handelt es sich um eine Linux-Portierung auf Systeme, die keine MMU (Memory Management Unit) haben, wie es bei Mikrocontrollern der Fall ist. Durch die fehlende MMU ergeben sich einige Einschränkungen für uClinux. Ohne MMU kann kein Speicherschutz implementiert werden, was bedeutet, dass Programme sich gegenseitig und sogar den Kernel zum Absturz bringen können. Es gibt natürlich keinen virtuellen Speicher und Paging. fork() ist nicht implementiert, sondern nur vfork(). Der Elternprozess wird bei vfork() blockiert, bis execve() oder exit() aufgerufen wird. Es wird auch keine Kopie des Speicherbereiches des Elternprozesses erstellt, da dazu virtueller Speicher nötig wäre. Trotzdem können Prozesse parallel laufen. Das Fehlen von virtuellem Speicher bedingt ein spezielles Binärformat, das "Flat Binary Format", das relozierbare Executables erlaubt, bei denen anhand einer Relozierungstabelle die Adressen an die Speicherposition angepasst werden können.

    Der verwendete Prozessor entscheidet also darüber, welche Betriebssystem-Variante eingesetzt werden kann. Typische Varianten sind:

    Echtzeit-Linux

    Parallel zur Verbreitung als eingebettetes Betriebssystem wachsen die Wünsche der Anwender. Ganz vorn auf der Wunschliste ist die Echtzeit-Fähigkeit zu finden. Linux ist standardmäßig kein Echtzeit-Betriebssystem. Das heißt, die Reaktionsgeschwindigkeit auf externe Ereignisse, wie zum Beispiel Interrupts, hängt in erster Linie von der aktuellen Systemauslastung ab. Das Zeitverhalten ist somit nicht deterministisch, wofür es eine Reihe von Gründen gibt:

    Das Echtzeit-Verhalten wird bei Linux nicht von einer einzigen Institution entwickelt. Gleich mehrere Firmen und Institute verfolgen mit unterschiedlichen Ansätzen das Ziel, den Einsatz von Linux in zeitkritischen Applikationen zu ermöglichen. Einige dieser Entwicklungen, wie zum Beispiel das RTLinux von FSMLabs, legen sich als Echtzeit-Kernel unterhalb von Linux direkt über die Hardware und lassen das nicht echtzeitfähige (Standard-)Linux als eigenen Task ablaufen ("Dual Kernel Approach"):

    Durch diesen Ansatz steht zum einen die komplette Linux-Funktionalität zur Verfügung, zum anderen können harte Echtzeitanforderungen erfüllt werden. Es gibt zwei Projekte, die den geschilderten Ansatz implementieren: RT-Linux, entwickelt am New Mexico Institute of Mining and Technology (NMT) von einer Arbeitsgruppe um Prof. Victor Yodaiken und Michael Barabonov, und RTAI (Real Time Application Interface), entwickelt am Dipartimento di Ingegneria Aerospaziale des Politecnico di Milano von einer Arbeitsgruppe um Prof. Paolo Mantegazza.

    Beide Systeme sind ausgereift und im Kern vollständig. Ein anderer Ansatz implementiert die Echtzeit-Fähigkeit über die SMP-Schnittstelle (SMP = Symmetric Multiprocessing) eines ansonsten unveränderten Linux-Kernels.

    Was man für Embedded Linux benötigt

    Grundsätzlich besteht ein Embedded Linux aus drei Grundbausteinen:

    Diese drei Bausteine können in Form eines einzigen Binärimage oder auch als separate Dateien vorliegen. In diesem Fall besteht dann sogar die Möglichkeit, Embedded Linux z. B. von der DOS-Kommandozeile zu booten. Der Linux-Kernel wird in der Regel als komprimierter Binärcode gespeichert, der sich beim Systemstart automatisch entpackt. Linux benötigt immer ein Dateisystem, auch wenn keine mechanischen Laufwerke wie Harddisk, Floppy oder CD-ROM vorhanden sind. Aus diesem Grund wird über weitere Boot-Parameter eine RAM-Disk eingerichtet und die Datei mit dem Root-Dateisystem in diese RAM-Disk kopiert. ELinOS, eine Embedded-Linux-Distribution für industrielle Anwendungen, bietet die Möglichkeit, eine bootfähige Diskette mit Linux zu erstellen, die dann von einem Embedded System gestartet wird. Die Diskette erhält zuvor über das Hilfsprogramm SYSLINUX den erforderlichen Bootloader. Dieser Loader wird direkt in den Bootsektor der Diskette kopiert.

    Beim Linux-Systemstart wird zuerst immer der Bootloader aktiviert, der in der Regel auf dem ersten Sektor des Bootmediums liegt (Master Boot Record, MBR). Als Bootloader kommen meist LILO oder GRUB zum Einsatz. Der Bootloader lädt den Kernel in den Arbeitsspeicher und startet ihn. Der Kernel entpackt sich zunächst selbst und erzeugt danach die RAM-Disk oder bindet die Festplatte ins System ein. Er sucht dabei auch nach einer VGA-Karte und, falls es diese nicht gibt, nach einer seriellen Schnittstelle, um dort seine Boot-Meldungen auszugeben. Nachdem das Dateisystem vollständig ist und alle Dateien im Verzeichnisbaum der RAM-Disk vorliegen, löst der Kernel den sogenannten Systeminit-Prozess aus, indem er ein Programm startet. Welches das ist, kann in den Bootoptionen festgelegt werden, z. B. init=myinitprog. Ist nichts anderes angegeben, wird nacheinander eines der Programme /sbin/init, /etc/init, /bin/init oder /bin/sh gesucht und, falls gefunden, gestartet. In der Regel wird dies also /sbin/init sein. Dieses Programm aktiviert unter Umständen weitere Programme gemäß dem Inhalt der Konfigurationsdatei /etc/inittab. Will man ohne Platte booten, wird es schwieriger.

    Der Init-Prozess seinerseits startet die systemnahen Dienste (Deamons), beispielsweise für Login oder Netzwerkdienste. In /etc/inittab sind auch verschiedene Runlevel vorgesehen, die festlegen, welche Dienste gestartet werden.

    In der inittab wird auch festgelegt, welche Programme nach ihrer Beendigung sofort wieder gestartet werden sollen ("respawn"-Option) und wie sich das System bei Stromausfällen verhalten soll (Reaktion auf Signale der USV). Zum automatischen Starten von Programmen beim Systemstart gibt es somit folgende Möglichkeiten:

    Weiterführende Informationen

    Copyright © Hochschule München, FK 04, Prof. Jürgen Plate
    Letzte Aktualisierung: 28. Mar 2008