Intelligente Gebäude, Kaffeemaschinen, die selbständig im Laden Nachschub ordern und Drucker, die bequem vom PC aus zu steuern sind - das alles klingt wie Science-fiction, ist aber schon längst Wirklichkeit. Früher wurde die Software für diese Systeme sehr hardwarenah in Assembler programmiert. Heute stellen Tools-Anbieter wie Microsoft, Inprise, Metrowerks und Spyglass visuelle Tools zur Verfügung. Auch Java soll künftig eine größere Rolle spielen.

Embedded-Systeme gehören schon seit längerem zum Alltag. War es am Anfang vielleicht eine Applikation für einen Taschenrechner, sind es heute Projekte wie Pathfinder - die Mars-Weltraumsonde. Pathfinder ist ein Embedded-System par Excellence und gibt einen Einblick in das Marktpotential für Software-Anbieter: Das Projektbudget betrug rund 200 Millionen Dollar. Daß es aber auch weniger spektakulär geht, zeigen Beispiele aus der Prozeßkontrolle oder Konsumelektronik: Mit Hilfe von Entwicklungs-Tools für Embedded-Systeme realisierte beispielsweise Mannesmann VDO ein Kfz-Telematiksystem und die Gebäudeleittechnik im Flughafen Berlin-Schönefeld. Auch im Internet-Fernseher "xelosmedia" von Loewe ist jede Menge Sofware "embedded".

Das Desktop-Erbe

Während Embedded-Systeme früher meist in Assembler programmiert wurden, benötigen heutige Lösungen eine anspruchsvollere Sprache. Integrated Development Environments (IDEs), wie sie Inprise, Metrowerks und Microsoft für den Desktop etabliert haben, setzen sich jetzt auch für die Entwicklung von Embedded-Systemen durch. Insbesondere Metrowerks hat sein IDE so angelegt, daß es sich an die sehr unterschiedlichen Bedingungen von Embedded-Systemen einfach anpaßt. Derzeit werden Mips, Power PC, 80x86, Mac, Play Station, Java-Systeme und Palm Pilots unterstützt.

Ein Vorteil von IDE ist das integrierte Projekt-Management. Embedded-Projekte beziehen sehr oft verschiedene Source-Files ein. Dazu gehören etwa der C-Code für Aktionen auf Applikationsniveau, Assembler für Interrupt-Service-Routinen und Gerätetreiber. Bevor IDEs aufkamen, mußte man für die vielen unterschiedlichen Sourcecode-Files innerhalb einer einzigen Applikation "Make files" anlegen. Diese sind zum Teil sehr schwer zu verstehen. Oft ist das Erlernen ihrer Syntax eine eigenständige Programmierroutine. Mit einer IDE dagegen lassen sich die verschiedenen Dateien visuell verwalten - unabhängig davon, ob es sich um Sourcecode-Files in einer Hochsprache oder in Assembler handelt. Das Kompilieren, Assemblieren und Linken erfolgt automatisch.

Der integrierte Debugger ist ein weiterer Vorteil von IDEs. Damit können Compiler und Assembler Informationen für das Quell- Code- Debugging in das "Final Executable" einbetten. Damit verkürzt sich die Zeit, die mit dem Suchen und Auflösen eines Bugs verbunden ist. Der Entwickler findet den Fehler, ohne die Entwicklungsumgebung verlassen zu müssen, geht für die Korrektur zurück in den Editor, kompiliert, verbindet die endgültige Applikation und testet erneut.

Neben den Entwicklungs- Tools werden auch die Echtzeit- Betriebssysteme vom Desktop oder teilweise für Embedded-Systeme übernommen. Aus dem ursprünglichen Windows etwa entstanden 32-Bit- Versionen, wobei sich "Win 32", das Programmier-Interface dafür, zu einer Art Standard für 32-Bit-Embedded-PC-Systeme entwickelte. Die "Embedded Tool Suite" von Phar Lap beispielsweise ist ein komplettes Echtzeit-Betriebssystem, das Win-32-APIs als Programmieroberfläche verwendet. Der Vorteil ist, daß der Entwickler für die endgültige Applikation ausgereifte Desktop- Entwicklungs-Tools wie "Visual C++" oder "Developer Studio" von Microsoft nutzen kann. Programmierer, die bereits mit dem Win-32- API arbeiten, können damit dann auch eingebettete Applikationen entwickeln. Ähnlich sieht es bei Windows CE aus, das eine Variante von Win 32 ist. Die Redmonder stellen eine Art Add-on für Visual C++ und Developer Studio bereit, das die notwendigen Zusatzkomponenten für Windows-CE-Applikationen liefert.

Im Echtzeit lebt Unix wieder auf

Aus der Unix-Welt stammt Posix, die Standardisierung des Unix- Betriebssystems. Viele Echtzeit-Betriebssysteme wie "LynxOS" von Lynx, "VxWorks" von Wind River Systems oder "QNX" von QNX Software haben ein Posix-kompatibles Interface. Vorteil von Posix ist, daß dieser Standard nicht nur von einem Hersteller geprägt wird - im Gegensatz zur Win-32-API, bei der Microsoft die Entwicklung komplett beeinflußt. Dadurch besteht die Gefahr, daß die Gates- Company die Win-32-Schnittstelle so ändert, daß es für Betriebssysteme außerhalb der Windows-Welt, inkompatibel wird.

Zugleich bietet Posix im Unterschied zu Win 32 spezielle Erweiterungen für die Unterstützung von Echtzeitsystemen. Ferner läßt sich eine Applikation, die auf der Basis von Posix- kompatiblen Programmaufrufen geschrieben wurde, relativ einfach auf ein anderes Betriebssystem portieren, das denselben Standard unterstützt.

So unglaublich es klingt, als Embedded-Version ist auch DOS immer noch weit verbreitet. Insbesondere in statischen Applikationen auf einer PC-kompatiblen Hardware und für Applikationen ohne Multitasking ist Embedded DOS in Gebrauch. Außerdem benötigt es lediglich die Rechenleistung eines 8088-Prozessors.

DOS forever!

Das DOS-Interface ist sowohl als Programmier-Interface - die altbekannten INT 21H Calls - als auch auf Bios-Niveau gut etabliert. Embedded-Versionen von MS DOS vertreiben etwa IBM, die "Embedded-PC-DOS plus", ein OEM Adaptation Kit anbieten, Datalight, die ROM-DOS im Programm haben, sowie Annasoft.

Ironischerweise ist Java, als Abkömmling einer Sprache namens OAK, die für Embedded-Systeme wie Set-top-Boxen designed wurde, immer noch auf der Suche nach seinem Platz bei eingebetteten Systemen. Dabei existiert Java sozusagen dreimal: als Sprache, als Runtime und als Satz von APIs. Für Java spricht sehr viel. Es ist wie C++ objektorientiert, vermeidet aber dessen durch Mehrfachvererbung oder Operator Overloading bedingte Komplexität. Außerdem ist Java sicherer, was teilweise damit zusammenhängt, daß keine Pointer erlaubt sind. Jedoch zahlen Embedded-Entwickler einen Preis für diese Sicherheit. So ist es mit Java unmöglich, Memory direkt zu adressieren. Und gerade für Embedded-Entwickler gehört dies zum täglichen Brot.

Um als Runtime zu gelten, wird Java interpretiert. Wird Java auf eine neue Plattform gezogen, wird auch die Java Virtual Machine (JVM) auf diese Plattform gezogen. Im Klartext: Es spielt keine Rolle, welcher Java-Compiler benutzt wird, ob "Visual J++" von Microsoft, "Code Warrior" von Metrowerks oder "Visual Café" von Symantec. Solange der Compiler Java-Byte-Code generiert, läuft er auf der JVM, unabhängig davon, wo sie liegt. Nachteilig ist die Langsamkeit interpretierter Sprachen.

Schwierig ist auch die Antwort auf die Frage, wieviel von einer JVM notwendigerweise auf einer bestimmten Plattform zu implementieren ist. Noch gibt es keine Tools, mit deren Hilfe der Entwickler spezifische JVMs erzeugen kann, die sich an eine ganz bestimmte Applikation auf einer ganz bestimmten Plattform anpassen und trimmen ließen.

Für Embedded-Systeme ist die sogenannte Müllhalde (Garbage Collection) der Java Runtime ein weiteres Problem. Seltsamerweise wird sie von Non-Embedded-Programmierern geradezu als Vorteil gesehen. Diese Funktion läßt sich jedoch nicht unterdrücken, so daß Java in einem Echtzeitsystem kaum zu gebrauchen ist, da hier die wichtigsten Tasks eine garantierte Verarbeitungszeit brauchen. Deswegen erarbeiten Entwickler typischerweise die Routine für das User Interface mit Java und benutzen C oder Assembler, die "außerhalb" des JVM laufen, für die wirklichen Echtzeitabläufe.

Außer Java, immer C oder Assembler

Für den Embedded-Entwickler sind drei Java-APIs relevant:

-"Personal Java" eignet sich für Embedded-Systeme innerhalb von Personal Digital Assistants (PDAs) oder Handies. Die Personal- Java-Spezifikation an sich gibt es seit November 1997. Auf dieser Basis hat Alcatel bereits ein intelligentes Telefon auf den Markt gebracht. Im Frühjahr 1998 kam ein erstes Release der Spezifikation für Embedded Java heraus, das immer noch im Entwicklungsstadium ist und Details auslößt.

-"E Java" benötigt ein Real Time Operating System (RTOS). Ein Teil des E-Java-Toolsets ist ein Übersetzer, der den Java-Sourcecode analysiert und daraus C-Code erstellt. Ein zum Ziel-RTOS nativer C-Compiler kompiliert und C-Code dazu linked. Mit E-Java-Tools lassen sich ROM-Versionen der Applikationen erstellen. Andere Tools plazieren Teile der Applikation im Flash-Memory oder batteriegesichertem RAM, so daß sich die Applikation im praktischen Einsatz jederzeit aktualisieren läßt.

-Das dritte Java-API ist "Java-Card", das Anfang Juli 1998 in Version 2.0 herauskam und einen Subset der Sprache Java für Smart- Cards definiert. Smart-Cards zeichnen sich durch extrem geringe Runtime-Ressourcen aus. Das API läuft auf einer speziellen Version der JVM namens Java Card VM. Zu den Tools wird auch ein Java Card Converter gehören. Zum Kompilieren der Java-Applikation eignet sich jeder Java-Compiler. Der so erzeugte Java Byte Code durchläuft den Konverter, der den Code als Java-Card-2.0- kompatibel verifiziert, optimiert und linked.

Ein relativ neues Gebiet im Embedded-Markt ist Embedded Internet, das für die Internet-Verbindung der Hardware sorgt. Interessanterweise war das Netz der Netze die Bühne, auf der Java ursprünglich auftrat. Neben den bereits ausgeführten Plattformen und Sprachen ist die Integration von Internet-Protokollen in Embedded-Applikationen eine weitere Herausforderung. Beispiel: Ein Netzwerkdrucker ist aufgrund eines integrierten Embedded-Systems HTML-fähig. Statt über die kleine und meist komplizierte Bedienungstasten am Drucker, kann der Anwender den Drucker dank HTTP über einen Browser auf dem Monitor an seinem Arbeitsplatz konfigurieren.

Drucker künftig über den Browser steuern

Einer der Pioniere in diesem Bereich ist Spyglass, das seinen "MicroServer" beispielsweise an Xerox lizenziert hat, das die High-end-Drucker mit Internet-Technologie ausrüsten will. Der Embedded-Web-Server "EMIT" von Emware geht sogar noch einen Schritt weiter. Auch er erlaubt die Kontrolle von kleinen Embedded Devices über das Internet, wobei Eware die Intelligenz in Java- Applets plaziert, die auf dem Client laufen. Diese Applets kommunizieren mit einem kleinen Server auf dem Endgerät (Embedded Target), wobei die Speicheranforderungen extrem niedrig sind. Ein Emware Server läuft in weniger als einem KB ROM und 30 Byte RAM. Darüber hinaus kann er einen 8-Bit-8051-Prozessor als CPU benutzen. Fortschritte in der Hardware haben Entwicklungen in der Embedded-Software erzwungen.

*Rick Grehan ist freier Autor und lebt in Texas.