Windows CE
Windows CE im Bereich der Embedded Control Anwendungen.
1
Windows CE
Dipl.-Informatiker (FH) Dieter Prifling
Dipl.-Ing. (FH) Michael Schanz
Im Bereich der Embedded Control Anwendungen haben sich eine Reihe von Betriebssystemen derzeit etabliert. Mit Windows CE steht ein nun weiteres Betriebssystem zur Verfügung, das sich gerade durch seine grafischen Fähigkeiten in diesem Marktsegment behaupten will. Windows CE ist in aller Munde, aber erst wenige konnten schon Erfahrungen sammeln. Im folgenden werden die Grundzüge dieses neuen Systems sowie die Voraussetzungen geschildert, die zu einer Windows CE Implementation auf X86 Basis notwendig sind.
Architektur
Um kurz den Aufbau von Windows CE zu beschreiben: man hat es auf kleine, kompakte Systeme ausgelegt und versucht, den Speicherbedarf und den Overhead des Betriebssystems zur Laufzeit gering zu halten. Bild 1 zeigt den strukturellen Aufbau des Betriebssystems.
Bild 1.
OEM Abstraction Layer (OAL)
bildet die unterste und damit die hardwarenahe Ebene des Systems. In dieser Schicht findet die Anpassung an die Hardware, die Verwaltung der Interrupts und auch das Powermanagement statt. Vergleichbar ist diese Schicht mit dem âHardware Abstraction Layer (HAL)â von Windows NT, sie muà bei einer Windows CE Implementation vom Systemintegrator genau auf die Zielhardware abgestimmt werden.
Device Driver and PC Card Services
Das Treibermodell von Windows CE unterstützt statische und dynamische Device-Treiber. Während statische Treiber während des Systemstarts geladen werden und deshalb auch innerhalb der gesamten Sitzung präsent sind, werden dynamische Treiber von der Applikation nachgeladen. Sie sind deshalb auch nur zur Laufzeit der Applikation verfügbar. Zur Treiberentwicklung steht ein Device Driver Kit (DDK) zur Verfügung.
Das Treibermodell von Windows CE unterscheidet sich von Windows 95 und Windows NT, weshalb sämtliche Treiber neu erstellt werden müssen. Im Lieferumfang von Windows CE sind einige Treiber schon vorhanden, wie z. B. Grafiktreiber für die Grafikchips ET4000 und S3 Trio 64. Nicht enthalten sind in der aktuellen Version 2.0 z. B. IDE- und Floppy-Treiber, woran man die Ausrichtung von Windows CE auf den PC-Card Markt erkennen kann.
Kernel
Der Kernel ist, ähnlich wie bei Windows 95 und Windows NT, zuständig für das Speichermanagement, Verwaltung von Prozessen und Threads, sowie für die Ressourcenvergabe. Durch das präemptive Multitasking können mehrere Prozesse gleichzeitig laufen; zur ProzeÃsteuerung und -synchronisation sind verschiedene Mechanismen vorgesehen.
USER GDI
Das User und Graphics Device Interface wird auch mit Graphics-Windowing-Events-Subsystem (GWES) bezeichnet und bildet die Schnittstelle zum Benutzer. Dieser Teil des Systems regelt die grafischen Ausgaben, wie die Anzeigen von Fenstern und Bedienelementen, sowie Eingaben vom Benutzer.
Object Stores
Die Komponenten des Object Stores werden dazu verwendet, persistente Daten im nichtflüchtigen Speicher, z. B. Flash-Eprom, abzulegen. Ein spezieller Mechanismus bei der Abspeicherung der Daten verhindert, daà korrupte Datensegmente entstehen können, beispielsweise wenn während der Datenspeicherung ein Stromausfall oder ein Reset erfolgt.
TCP/IP, PPP, IrDA
Kommunikation mit dem System erfolg standardmäÃig mit dem Internet Protokoll TCP/IP in Verbindung mit PPP. Diese Protokolle kommen zum Zuge, wenn Systeme sowohl direkt über Kabel als auch via Modem miteinander verbunden sind. Zur drahtlosen Anbindung steht das IrDA Protokoll zur Verfügung.
API
Windows CE stellt eine Teilmenge der Win32 API zur Verfügung. Diese umfaÃt über 500 der am meisten gebrauchten Win32 APIs. Windows CE bietet eine zahlreiche Menge von Kommunikationsschnittstellen, wie âWindows Socketsâ, TAPI und Unimodem.
Da die API im Funktionsumfang reduziert ist, können viele für Windows 95 kompilierte Standardanwendungen nicht direkt auf Windows CE funktionieren. So sind beispielsweise die Anwendungsfenster nur im Vollbildmodus darstellbar. Die komplette Stringverarbeitung des API basiert auf Unicode (2 Byte Zeichen), was zu Lasten des Speicherbedarfs geht. Dennoch bietet das API genügend Funktionalität, um auch komplexere Anwendungen für Windows CE zu erstellen. Es stehen weitere Programmierschnittstellen, wie z. B. die Microsoft Foundation Class, zur Verfügung.
Remote Connectivity
Durch die Bereitstellung einer âRemote Access API (RAPI)â kann ein ferngesteuerter Datenaustausch erfolgen. Dies reicht von einfachem Austausch von Dateien zwischen Host- und Targetsystem bis hin zur Ãnderung der Registry.
Hardware
Windows CE ist von Haus aus für mehrere Hardwareplattformen geeignet. Dazu zählen u. a. die Hitachi SuperH
-Familie, die MIPS Prozessoren R4100, R4200 und R4300, Motorolas PowerPC82, sowie Prozessoren der Intel i486-Familie. Innerhalb von Windows CE werden Instructions verwendet werden, die erst ab dem i486 verfügbar sind, deshalb lassen sich Prozessoren der 386-Klasse nicht ohne weiteres betreiben. Das i386-Support-Paket der
JUMPtec AG, das diese Befehle abfängt und umsetzt, schafft hier Abhilfe. Somit wird Windows CE auch für den Bereich der Embedded Control Anwendungen interessant, wo kostengünstige Systeme auf i386 Basis sehr verbreitet sind. Die Kombination aus Low-Cost-Hardware mit integriertem grafischen Betriebssystem ermöglicht somit kostengünstige Komplettlösungen, die eine echte Alternative zu mikrocontrollerbasierten Systemen bilden. Die Vorteile der Kostenreduktion in der Softwareerstellung und âwartung sprechen für sich.
Windows CE Praxis
Im folgenden sollen nun kurz die Erfordernisse bei der Erstellung eines Windows CE Images dargelegt werden.
Bei Windows CE handelt sich es nicht um ein fertig installierbares Betriebssystem, viel mehr muà aufgrund der Hardwareabhängigkeit und der Modularität ein Image (das das Betriebssystem inkl. Anwendungen enthält) in einem komplizierten Buildprozeà erstellt werden.
Installation des Evaluationkits
Das komplette Windows CE Evaluationkit wird in Form von drei CD-ROMs geliefert. Es besteht aus zwei Teilen, dem âToolkit für VC++ 5.0â für die Anwendungsprogrammierung und dem âEmbedded Development Kitâ für die Erstellung des Windows CE Betriebssystems. Als Entwicklungsplattform wird ein NT4.0-Rechner mit vorinstalliertem VCC++ in der Version 5.0 vorausgesetzt; das Eval-Kit wird zu der bestehenden Installation hinzuinstalliert (ähnlich dem MS-DDK). Für eine Installation von âToolkitâ und âEmbedded Development Kitâ auf x86-Basis ist ca. 1GB zusätzlicher Plattenplatz notwendig. Vor der Installation sind alle Vorgänger-versionen zu entfernen. Im Gruppenverzeichnis von MS VC++ werden verschiedene Verknüpfungen auf die Windows CE Entwicklungsumgebung angelegt.
Demo Projekte
Das Evaluationkit enthält für die X86-Plattform mehrere Demo Beispiele um den Buildprozeà und verschiedene Anwendungsfälle zu erläutern. Sie reichen von der einfachen Windows CE Commandline bis hin zur kompletten Windows CE Shell mit Handschriftenerkennung. Mit Hilfe der Verknüpfung âWCE X86 Environmentâ können sie bei Bedarf kompiliert werden. Insbesondere muà hierbei beachtet werden, daà im ausführenden Batch-File die Environment-Variable für die Grafikhardware richtig gesetzt wird, um eine richtige Behandlung des Grafikchips zu gewährleisten.
Implementation auf der Zielhardware
Einer Implementation von Windows CE geht eine genaue Analyse der Erfordernisse voraus. Aufgrund dieser Analyse wird festgelegt, welche Anwendungen und Treiber erstellt werden müssen. Sind Anwendung und Treiber entwickelt, so wird das System in einem Makeprozeà erstellt.
MakeprozeÃ
Durch die Anpassung von Batch- und Makefiles wird die Konfiguration des Systems festgelegt. Im anschlieÃenden Buildprozeà wird eine Imagedatei erzeugt, die sowohl das Windows CE Betriebssystem als auch die zuvor im Makefile definierten Anwendungen beinhaltet. Die GröÃe dieser Imagedatei richtet sich nach der jeweiligen Konfiguration und bewegt sich im Bereich von einigen hundert Kilobytes bis mehrere Megabytes. Vorteilhaft für die Entwicklung erweist sich eine Zielhardware mit EPP und serieller Schnittstelle. Mit Hilfe der EPP-Schnittstelle und einem speziellen Kabel wird das erzeugte Image auf die Zielhardware übertragen. Die serielle Schnittstelle dient zum Remote-Debugging.
Bootloader
Zum Testen des Images wird das Programm "LOADCEPC.EXE" verwendet, das das Image in den Speicher des Targetsystems lädt. Dieses Programm setzt MS-DOS, HIMEM.SYS und VESA-Support des BIOS auf dem Targetsystem voraus. In der endgültigen Applikation übernimmt diese Funktionalität ein Bootloader, der das binäre Image in der Bootphase in den Speicher kopiert. Dabei befindet sich das Image entweder auf der Festplatte oder im ROM. Von Microsoft wird kein Bootloader geliefert; eine bereits vollständige Implementation kann von der JUMPtec AG bezogen werden. Dieser Bootloader erlaubt das direkte Hochfahren von Windows CE von einer BIOS (INT 13h) kompatiblen Festplatte oder Flashdisk. Unterstützt wird nur das FAT 16 Datei-system. Der Loader lädt sofort das NK.BIN Image und erfordert nicht den Einsatz eines IDE Treibers. Eine Weiterentwicklung des Bootloaders macht sogar das BIOS überflüssig, so daà nur noch Lizenzgebühren für Windows CE anfallen.
IDE-Treiber
Im Lieferumfang von Microsoft sind für die X86-Plattform leider nur Treiber für PCMCIA-Flash Karten enthalten, um Daten im Rahmen des Object Stores persistent abzuspeichern. In einem Standard-PC werden Daten auf einer Festplatte gespeichert; im Embedded Control Bereich kommen oft Speichermedien auf Flash-Basis zum Einsatz. Beide Verfahren erfordern innerhalb von Windows CE ebenfalls spezielle Treiber, die über Drittanbieter bezogen werden müssen. Der von der JUMPtec AG gelieferte IDE-Treiber erlaubt Schreib- und Lesezugriff auf bis zu vier IDE-kompatible Festplatten und Flashdisks. Die Laufwerke können ein Standard MS-DOS FAT Dateisystem beinhalten. Mit diesem Treiber besteht somit die Möglichkeit Konfigurations- oder Programmdaten abzuspeichern.
Grafiktreiber
Als Standardgrafikauflösung stehen 320x200 Pixel zur Verfügung. Um hier die VGA Auflösung von 640x480 Pixel zu erreichen, muà der Grafiktreiber angepaÃt werden. Dies ist notwendig, da eine Auflösung von 320x200 Pixel (64000 Byte) gerade noch in das 64 KByte groÃe Segment paÃt, welches von der Grafikkarte in den AdreÃraum des Prozessors eingeblendet wird. Bei höheren Auflösungen muà zwischen mehreren 64KByte Blöcken umgeschaltet werden. Das zur Umschaltung notwendige Verfahren ist vom verwendeten Grafikchip abhängig. Eine Anpassung ist insbesondere notwendig, wenn andere Grafikchips als ET4000 oder S3 Trio 64 zur Verwendung kommen, da nur für diese Chips Treiber zur Verfügung stehen.
Remote-Debugging
Im Entwicklungspaket ist ein Kernel-Debugger enthalten, der über die serielle Schnittstelle betrieben wird. Es handelt sich dabei um einen Source-Level-Debugger, mit dem sowohl Windows CE Treiber als auch Anwendungen debuggt werden können. Das Windows CE Kernel gibt zur Laufzeit Debug-Meldungen via COM1 aus, die auf dem Entwicklungssystem ausgewertet werden können.
Wie die bisherige Betrachtung von Windows CE erkennen läÃt, ist eine gesonderte Anpassung an die gegebene Hardware unumgänglich. Der Aufwand einer solchen komplizierten Anpassung kann durch den Einsatz von autorisierten Microsoft Windows CE Systemintegratoren erheblich reduziert werden.
Lizenzierung
Durch die Modularität und die Anwendungsvielfalt läÃt sich Windows CE nach einem 3-stufigen Modell lizenzieren:
Es wird zwischen
- Windows CE Kernel Version
- Windows CE Limited Version und
- Windows CE Full Version unterschieden.
Die Lizenzierung einer Baugruppe wird durch einen Lizenzsticker auf dem Massenspeicherbaustein (z. B. Flash-EEprom) signalisiert.
Fazit
Windows CE ist im Gegensatz zu Windows 95 und Windows NT kein Betriebssystem, das fertig installierbar angeliefert wird. Die Systemintegration von Windows CE erfordert tiefere Hard- und Software-Kenntnisse, sowohl im Bereich der BIOS-Entwicklung, als auch im Bereich des Win32 API. Es stehen deshalb sogenannte âMicrosoft Windows CE Authorized System Integratorsâ zur Verfügung, die die Systemintegration vornehmen.
2
WindowsCE in industriellen Anwendungen
Systemintegration am Beispiel einer multifunktionalen Bedienkonsole
Dipl.-Ing. (FH) Michael Schanz
Grafische Betriebssysteme waren bisher dem Consumer-Bereich vorbehalten. Im industriellen Bereich, wo weniger die Systemperformance als der Kostenfaktor im Vordergrund stand, kamen häufig Betriebsysteme zum Einsatz, deren grafische Fähigkeiten deutlich unter dem heutigen Standard lagen. Mit WindowsCE sollte sich das ändern: wo man noch vor kurzer Zeit auf teuere Speziallösungen zurückgreifen muÃte, besteht jetzt die Möglichkeit, sich seine Applikation gemäà seinen Anforderungen gezielt zu erstellen. WindowsCE ermöglicht dies durch seinen modularen Aufbau. Das System, das in einem komplizierten Buildprozeà erstellt wird, kann durch eine Vielzahl von Konfigurationsmöglichkeiten auf die Hardware abgestimmt werden. Natürlich zollt dies auch seinen Preis: Man muà sowohl die Hardware, die eigene Applikation, als auch das CE-Betriebssystem sehr genau kennen, um eine optimale Integration vornehmen zu können. Microsoft übertrug diese Aufgabe sogenannten CE-Systemintegratoren, die auch die nötigen Treiber für spezielle Hardware liefern. So sind z.B. im Lieferumfang von WindowsCE keine Treiber vorhanden, die es ermöglichen, Daten persistent auf Festplatte oder Floppy-Disk abzuspeichern. Wo bisher 50000.- DM und mehr für eine WindowsCE-Integration keine Seltenheit war, stehen jetzt kostengünstige Treiberpakete zur Verfügung, die den Integrationsaufwand erheblich reduzieren. Eine Systemintegration hat also eine enge Zusammenarbeit mit einem CE-Systemintegrator zur Folge. Zusätzlich werden von einigen CE-Systemintegratoren Schulungen angeboten, in denen das Grundwissen im Umgang mit WindowsCE vermittelt und somit der Einstieg erleichtert wird.
Hard-/Software-Anforderungen
Einer Integration geht die Auswahl der Komponenten voraus, wobei die Entscheidung für eine X86-Plattform sicherlich einige Vorteile bietet:
⢠standardisiertes System mit bekannten und dokumentierten Ressourcen
⢠Skalierbarkeit der verschiedenen CPU-Klassen von 386er bis Pentium bei gleichbleibender Software
⢠hochintegrierte Lösungen bieten eine direkte Grafikschnittstelle für LC-Displays (z.B. PC/104-All-In-One-Boards)
⢠zusätzliche Komponenten, wie Watchdog oder Matrixtastatur verringern den eigenen Designaufwand
⢠System kann sehr leicht neuen Erfordernissen angepaÃt werden (Systemupgrade)
⢠Softwareentwicklung kann auf einem Standard-PC erfolgen; man ist nicht auf teuere Entwicklungstools z.B. für spezielle Mikrocontroller angewiesen.
⢠die Verfügbarkeit und die Preisregulierung solcher Systeme wird durch eine Vielzahl von Second-Source Anbietern gewährleistet
⢠durch die Verwendung eines Standard- bzw. Stückzahlenproduktes reduzieren sich die Kosten
⢠umfassender Treibersupport
Bei Applikationen mit grafischer Anwendung wird man sich für ein System auf 486er-Basis (Bild 1) entscheiden, wobei in âblack-boxâ-Anwendungen (z.B. TCP/IP-Router) durchaus ein 386er-System zum Einsatz kommen kann. Ein 386er mit WindowsCE? Geht das? Auch hier sind inzwischen Treiber erhältlich, die WindowsCE auf einer 386er-Plattform lauffähig machen.
Bild 1: 486er PC/104-System, Fa. JUMPtec AG
Systemintegration
Ein ganz spezieller und geradezu idealer Markt für den Einsatz von WindowsCE ist der Bereich der abgesetzen Terminals. Eine Vielzahl verschiedenartiger Bedienkonsolen können nun mit grafischen Eigenschaften versehen werden, die bis dato Betriebssystemen wie Windows95 oder WindowsNT vorbehalten waren. Zum Vergleich: während eine Windows95 Installation mit ca. 45 MB zu Buche schlägt, kann man unter WindowsCE schon mit einer ImagegröÃe von unter 5 MB volles Windowing betreiben. Hinzu kommt hier noch die eigene Applikation.
Bild 2 zeigt z.B. ein abgesetzes Terminal der Fa. SWAC auf Basis eines 486er-Prozessorsytems der Fa. JUMPtec AG. Es wurde hier innerhalb kürzester Zeit und mit geringsten Kosten eine CE-Systemintegration mit einer Portierung von vorhandener Software vorgenommen. Ist bereits eine Windows-Applikation (NT oder 95) vorhanden, so stellt sich dies als Vorteil dar, denn viele Code-Fragmente der bestehenden Applikation können direkt übernommen werden. Dennoch soll nicht verschwiegen werden, daà innerhalb des Win32-APIs auf viele Funktionen verzichtet wurde. So steht z.B. unter CE kein Multiple-Document-Interface zur Verfügung; es sind nur Single-Document-Applikationen möglich. Aus diesem Grund sind auch die MFC (Microsoft Foundation Classes) nicht vollständig implementiert; man muà sich ggf. mit Ersatzfunktionen behelfen.
Bild2: SWAC Bedienkonsole
Debugging
Beim Debugging der Applikation stellen die CE Services einen recht effektiven Mechanismus zum Debugging dar. Das Entwicklungssystem ist hierbei über die serielle Schnittstelle mit dem Targetsystem verbunden. Das Debugging erfolgt wie gewohnt in der Microsoft VC++ Programmierumgebung; setzen von Breakpoints ist genauso möglich wie Single-Step-Betrieb. Aber auch direktes Debugging unter WindowsNT ist möglich. Das Toolkit sieht einen Emulator vor, mit dem eine Applikation begrenzt unter WindowsNT ausführbar ist. Begrenzt deshalb, da man weder auf Interrupte noch auf Ereignisse an Schnittstellen reagieren kann. Auch bei der Entwicklung von Treibern ist man auf ein Targetsystem angewiesen, das über serielle und paralelle Schnittstellen mit dem Entwicklungssystem verbunden ist. Dies bietet zudem den Vorteil, daà die Applikation in einer echten WindowsCE Umgebung läuft und deshalb das Systemverhalten exakt wiedergegeben wird. Zudem ist für die Entwicklung von Treibern der Kerneldebugger sehr hilfreich. In Verbindung mit einer speziellen Debugversion des Kernels läÃt sich hier das System auf unterster Ebene debuggen.
BuildprozeÃ
Ist die Applikation erstellt, so wird diese in den Buildprozeà des CE-Betriebsystems eingefügt. Wir erinnern uns: WindowsCE wird nicht wie Windows95 installiert, vielmehr wird in einem Buildprozeà eine Imagedatei erzeugt. Desweiteren werden zu diesem Zeitpunkt alle weiteren Definitionen, wie z.B. Startzeitpunkt der Applikation, vorgenommen. Sind Registry-Einträge notwendig, so werden sie jetzt vorgenommen. Sollen Daten persistent abgelegt werden, so sind ggf. Treiber für Floppy und Harddisk in den Makeprozeà einzufügen. Am Ende des Buildprozesses steht die CE-Imagedatei, die die Funktionalität des Gesamtsystems (WindowsCE und Applikationen) beinhaltet.
Um die Imagedatei auf die Targetplattform zu übertragen, werden im Entwicklungsstadium die Werkzeuge von Microsoft benutzt: Das Tool âLOADCEPC.EXEâ lädt das Imagefile über die parallele Schnittstelle in den Speicher des Targetsystems. Dieses Tool kann in der Release-Version ebenfalls benutzt werden, um das Image von der Harddisk zu laden, birgt jedoch folgende Nachteile:
⢠DOS muà gebootet werden, wodurch zusätzliche DOS-Lizenzkosten anfallen
⢠HIMEM.SYS muà installiert werden (Zeitverlust)
⢠das BIOS muà VESA-Support besitzen
Eleganter ist die Verwendung eines Bootloaders, der das Image während der Bootphase in das Memory kopiert und die Umschaltung in den richtigen Videomode vornimmt. Zusätzliche DOS-Lizenzkosten fallen hier nicht an.
Kommunikation mit der AuÃenwelt
Es stehen mehrere Möglichkeiten zur Verfügung, um mit der AuÃenwelt zu kommunizieren. Zum einen über die seriellen und parallelen Schnittstellen, zum andern über Ethernet oder IrDA. Bei der Verwendung der seriellen bzw. parallelen Schnittstellen ist darauf zu achten, daà sie in der Entwicklungsphase zu Debuggingzwecken benutzt werden und deshalb verschiedene Service-Dienste über sie abgewickelt werden.
IrDA-Connections sind über sog. Infrared Sockets, einer Erweiterung der bekannten Winsock möglich. WindowsCE unterstützt ebenso einen Network Stack mit einer Reihe von Funktionen:
⢠WinINET API unterstützt Internet Protokolle wie FTP und HTTP 1.0 ebenso wie verschiedene Internet Sicherheitsprotokolle
⢠Unterstützung einer Untermenge der Winsock 1.1 API
⢠RAS â Connections
⢠TCP/IP â Stack
⢠NDIS 4.0
In den untersten Schichten sind hier wiederum Treiber notwendig, die vom jeweiligen Chiphersteller zu beziehen sind. Leider stehen derzeit erst wenige Treiber für WindowsCE zur Verfügung. Insbesondere Treiber für Touch-Screens lassen noch auf sich warten; renomierte Hersteller haben sie jedoch für das erste Halbjahr ´99 angekündigt. Wenn alle Stricke reiÃen: ist ein NT-Treiber im Source-Code vorhanden, so läÃt sich daraus in den meisten Fällen ein CE-Treiber erstellen (so konnte z.B. innerhalb weniger Tage ein NT-Treiber für INTERBUS-S an ein CE-System angepaÃt werden).
JUMPtec Driver Solution Pack
Wie zuvor bereits erwähnt, ist ein weiterer Vorteil der x86-Plattform der tiefgreifende Treibersupport. Ein Standardsystem auf x86-Basis kann deshalb softwaretechnisch einfacher und deshalb kostengünstiger angepaÃt werden. Die Firma JUMPtec AG bietet für ihre Hardwarekomponenten ein komplettes Driver Solution Pack an, das die wichtigsten CE-Treiber enthält. Es stehen u.a. Bootloader, Ethernet-, VGA-, IDE- und Floppy-Treiber zur Verfügung:
Bootloader
Starten des WindowsCE-Images von einer BIOS (INT 13h) kompatiblen HDD oder Flashdisk
VGA-Treiber
Unterstützung für C&T bzw. Cirrus Logic Grafik-Controller
IDE-Treiber
Erlaubt Schreib-/Lese-Zugriffe auf bis zu vier IDE-kompatible HDD oder Flashdisks
Floppy-Treiber
Erlaubt Schreib-/Lese-Zugriffe auf PC-kompatible Floppydisk Laufwerke
Ethernet-Treiber
Netzwerk-Treiber für Crystal LAN Controller
386er Support
Unterstützung für Prozessoren der i386-Klasse (z.B. ALI6117). WindowsCE wird dadurch auch auf Low-Cost-Systemen einsetzbar.
3
Portierung und Debugging von Applikationen unter Windows CE
Dipl.-Informatiker (FH) Dieter Prifling
Bei der Portierung von Win32 Applikationen nach Windows CE sieht sich der Entwickler besonders im Embedded Bereich mit dem Problem der fehlenden Festplatte konfrontiert. Nach einer kurzen Einführung in die grundlegenden Schritte der Projekterstellung, Portierung und der Debuggingmöglichkeiten sollen hier Lösungen für diese Problematik präsentiert werden.
Microsoft Visual C++
Die Entwicklung von Applikationen für das Windows CE Betriebssystem erfolgt unter Windows NT und setzt das Microsoft Visual C++ 5.0 voraus.
Normale Applikationen können mit dem Windows CE Toolkit for Visual C++ 5.0 erstellt und debugged werden. Für die Entwicklung von Treibern ist das Windows CE Embedded Toolkit for Visual C++ 5.0 erforderlich. AuÃerdem bietet dieses die vollen Debugging Möglichkeiten und beinhaltet Support für die x86 Plattform. Die neue Version dieses Pakets heiÃt Platform Builder 2.11.
Debugging
Windows CE unterstützt mehrere Formen des Debuggings. Es wird zwischen Applikations- und Kerneldebugging unterschieden. Desweiteren existiert eine kleine "Shell", die es ermöglicht ProzeÃinformationen abzurufen. Hierbei werden jeweils verschiedende physikalische Schnittstellen verwendet, die den NT Entwicklungs-PC mit dem Windows CE Targetsystem verbinden.
Die CE Debugging Shell nutzt die parallele Schnittstelle, um einen Dateiserver für das Targetsystem zu implementieren. Zusätzlich können über dieses Tool Prozesse gestartet und gestoppt werden, ebenfalls ist eine Abfrage der laufenden Prozesse und geladenen Module möglich.
Eine serielle Schnittstelle wird vom Kerneldebugger verwendet. Dieser dient in erster Linie zum Debuggen von Treibern. Ferner erfolgt die Ãbertragung von Runtime-Ausgaben , die im Treiber mit der Funktion OEMWriteDebugString() erzeugt werden. OEMWriteDebugString() wird in der Regel über die Makros DEBUGMSG() und RETAILMSG() implizit verwendet.
Mit der anderen seriellen Schnittstelle wird eine TCP/IP Verbindung mit Remote Access (RAS) aufgebaut. Auf dem Entwicklungs-PC sind hierzu die Windows CE Services erforderlich.
Ãber diese Verbindung ist es für den Endanwender möglich, Dateien mit dem Targetsystem auszutauschen. Während der Entwicklung können zusätzlich Source Level Debugging mit VC++ durchgeführt, sowie die Windows CE Remote Tools genutzt werden.
Remote Tools
Die Remote Tools arbeiten analog zu den entsprechenden Tools des SDK. Sie werden vom Entwicklungsrechner aus bedient und wirken auf die Targetplatform.
⢠Remote Windows CE Registry Editor
erlaubt die Verwaltung der Registry-Einträge.
⢠Remote Windows CE Spy
zeigt Informationen der CE Systemprozesse, Threads, Windows und Window Messages des Targetsystems.
⢠Remote Windows CE Zoom
überträgt skalierbare Bildschirmausschnitte und stellt diese auf dem Desktop Rechner dar.
⢠Remote Windows CE Process Viewer
grafische Anzeige der Eigenschaften der CE Prozesse und Thread. Der Process Viewer zeigt desweiteren die Speicherauslastung und sucht nach Memory-Leaks.
⢠Remote Windows CE Heap Walker
zeigt Informationen über Heap IDs und Prozess Flags.
⢠Remote Windows CE Object Viewer
Zeigt in hierachischer Form den Inhalt des Windows CE Object Stores.
Windows CE Emulation unter Windows NT
Zum Debugging einfacher Applikationen ist eine Emulation vorhanden, die unter NT das Verhalten der Anwendung wiederspiegelt. Ein Targetsystem ist hierfür nicht erforderlich; die Anwendung wird innerhalb von VC++ als "WCE x86em" erstellt. Für das Debugging der grafischen Eigenschaften einer Anwendung ist die Emulation gut geeignet, jedoch bestehen eine Reihe von Einschränkungen:
⢠Keine Kommunikationsmöglichkeiten (Schnittstellenemulation)
⢠Nicht geeignet für Treiberentwicklung
⢠Keine Behandlung von Interrupts
⢠Ausführendes System ist NT, deshalb Abweichungen zum realen Verhalten unter CE
Hello World
Projekte für Windows CE werden in VC++ ähnlich angelegt, wie gewöhnliche Applikationen unter den anderen Win32 Varianten.
Hierzu wird im "File" Menü der Menüpunkt "New" ausgewählt. Das Windows CE Toolkit erweitert Visual C++ so, daà in der Auswahlliste für Projekte und Plattformen CE spezifische Einträge erscheinen.
Normale Applikationen werden wie herkömmlich durch Auswahl von "Win32 Application" erstellt. Soll die Applikation MFC verwenden, ist jedoch anstelle von "MFC AppWizard (exe)" der Eintrag "WCE MFC AppWizard (exe)" auszuwählen.
Unter der Option "Platforms" trifft man die Vorauswahl für welche Plattformen man die Anwendung später kompilieren möchte. Es empfiehlt sich hier folgende Einträge vorzunehmen:
⢠Win32
Normales EXE für Windows 9x und NT
⢠WCE x86
EXE Datei für Windows CE auf x86 Plattform
⢠WCE x86em
EXE Datei für Windows CE Emulation unter Windows NT
Für unser Beispiel wird als Project Name "Hello" eingetragen.
Als aktive WCE Konfiguration muà "HPC Ver. 2.00" ("MAXALL" bei neueren CE Versionen) und als aktive Konfiguration "Win32 (WCE x86) Debug" eingestellt werden.
Im Menü "Project" wird nun der Punkt "Add To Project" und "Newâ¦" ausgewählt um eine neue CPP Datei zu erstellen.
Listing 1 zeigt den Sourcecode des âHello Worldâ Beispielprogramms, welches eine einfache MessageBox darstellt.
// Hello.cpp
#include
int
WINAPI
WinMain(
HINSTANCE hInstance,
HINSTANCE hPrevInstance,
#ifdef UNDER_CE
LPWSTR lpCmdLine,
#else
LPSTR lpCmdLine,
#endif
int nShowCmd
)
{
MessageBox(NULL,TEXT("Hello World!"),TEXT("HelloBox"),0);
return 0;
}
Listing 1: Hello.cpp
Nach fehlerfreier Kompilierung wird versucht das erzeugte Programm automatisch über die CE Services auf das Targetsystem zu laden.
Durch Drücken von F5 wird das Programm auf dem Targetsystem ausgeführt. Sofern CEMON.EXE noch nicht unter CE zur Verfügung steht, wird es vor der Programmausführung selbständig installiert.
Die Applikation kann nun wie unter normalen Bedingungen debuggt werden. Single Step Betrieb sind ebenso wie das Setzen von Breakpoints möglich.
Portierung vorhandener Applikationen
Das Beispiel Hello.cpp verdeutlicht bereits einen der Hauptunterschiede zwischen Win32 unter CE und anderen Plattformen. Unter Windows CE sind alle Strings im Unicode Format. Das Makro TEXT() wird verwendet, um diesem Anspruch gerecht zu werden. Im Gegensatz zu den anderen Win32 Varianten ist hier sogar die WinMain() Funktion komplett in Unicode. Dies erklärt auch die Preprozessoranweisungen um dem lpCmdLine Parameter.
Die meisten Applikation verwenden Dateisystemfunktionen, um Programm- oder Konfigurationdaten abzuspeichern. Hierbei wird angenommen, daà die verwendeten Speichermedien diese Daten auch im ausgeschalteten Zustand behalten. Das grundlegende Dateisystem unter Windows CE ist jedoch ROM/RAM basiert. Der Inhalt aller von Applikationen erzeugten Dateien geht also nach dem Ausschalten wieder verloren. Dieser Umstand muà natürlich bei der Portierung berücksichtigt werden.
Verwendung von Festplatten
Es ist also unter Windows CE ist es nicht problemlos möglich, Daten persistent abzuspeichern. Insbesondere auf der PC Plattform gibt es standardmäÃig keinerlei Treibersupport. Möchte man dennoch Daten persistent speichern, beispielsweise auf einer IDE kompatiblen Harddisk, so ist ein spezieller Treiber notwendig, der über einen Dritthersteller bezogen werden muÃ. Eine kostengünstige Lösung bietet hier das Treiberpaket der Firma JUMPtec AG, das u.a. IDE-, Floppy-, Ethernet- und Grafiktreiber enthält. Mit dem IDE Treiber können auch problemlos IDE kompatible FlashDisks angesprochen werden. Bild 1 zeigt die Anordnung des Driver Solution Packs im Windows CE Gesamtsystem.
Bild 1: Windows CE System mit JUMPtec Driver Solution Pack
Das von Windows CE verwendete Dateisystem unterstützt keine Laufwerksbezeichnungen. Wie unter UNIX befinden sich alle Dateien in einem Hierarchiesystem in einem Wurzelverzeichnis. Physikalische Laufwerke werden jeweils in einem eigenen Verzeichnis abgebildet. Unter Windows CE 2.0 ist der Name des Verzeichnisses des ersten Laufwerks auf "Storage Card" festgelegt. Weitere Medien erscheinen als "Storage Card2" usw. Bei neueren CE Versionen kann der Name durch den Treiber bestimmt werden und wird von diesem in der Regel aus der Registry gelesen.
Aus einer Applikation kann also auf Dateien zugegriffen werden, indem dieser Name vor den eigentlichen Dateinamen, mit Backslash getrennt, gestellt wird.
Beim Design einer Applikation hat man drei Möglichkeiten um den Namen eines Mediums zu ermitteln:
⢠Der Name wird direkt im Sourcecode festgelegt.
⢠Der Name wird in der Registry abgelegt und ist so leicht zu ändern.
⢠Der Name wird dynamisch zur Laufzeit ermittelt. Hierzu können die Funktionen FindFirstFlashCard(), FindNextFlashCard() und FindClose() verwendet werden. Diese Funktionen stehen leider in der Embedded Version von Windows CE nicht zur Verfügung. Mit den Win32 Funktion FindFirstFile() und den geeigneten Dateiattributen läÃt sich diese Möglichkeit jedoch leicht abbilden.
Die zuletzt genannte Methode findet im folgenden Beispiel aus Listing 2 Anwendung. Hierbei wird eine Datei names "HelloDisk.txt" auf dem ersten Speichermedium angelegt.
Die Funktion GetFirstStorageFolder() soll den Namen des Verzeichnisses einer Festplatte ermitteln. Es werden mit den Funktionen FindFirstFile() und FindNextFile() alle Verzeichnis- und Dateinamen durchiteriert. Die von Treibern eingebundenen logischen Verzeichnisnamen sind im Unterschied zu normalen Verzeichnissen als temporär markiert. Diesen Umstand macht sich die Funktion GetFirstStorageFolder() aus dem Beispiel zunutze und gibt an den Aufrufer den in Backslashes eingefaÃten Namen des ersten Verzeichnissen zurück, welches diese Bedingung erfüllt.
Die WinMain() Funktion fügt nach dem erfolgreichem Aufruf von GetFirstStorageFolder() lediglich noch den Dateinamen "HelloDisk.txt" an und erzeugt dann eine leere Datei mit CreateFile() auf dem Medium.
// HelloDisk.cpp
#include
#define FILE_ATTRIBUTE_STORAGEFOLDER (FILE_ATTRIBUTE_DIRECTORY|FILE_ATTRIBUTE_TEMPORARY)
BOOL GetFirstStorageFolder(LPTSTR lpFolder)
{
WIN32_FIND_DATA fd;
HANDLE h;
h=FindFirstFile(TEXT("\\*"),&fd);
if (h!=INVALID_HANDLE_VALUE) {
do {
if ((fd.dwFileAttributes&FILE_ATTRIBUTE_STORAGEFOLDER)==FILE_ATTRIBUTE_STORAGEFOLDER) {
wsprintf(lpFolder,TEXT("\\%s\\"),fd.cFileName);
FindClose(h);
return TRUE;
}
} while (FindNextFile(h,&fd));
FindClose(h);
}
return FALSE;
}
int
WINAPI
WinMain(
HINSTANCE hInstance,
HINSTANCE hPrevInstance,
#ifdef UNDER_CE
LPWSTR lpCmdLine,
#else
LPSTR lpCmdLine,
#endif
int nShowCmd
)
{
HANDLE h;
TCHAR s[256];
if (!GetFirstStorageFolder(s))
MessageBox(NULL,TEXT("No storage folder available!"),TEXT("HelloDisk"),0);
else {
MessageBox(NULL,s,TEXT("HelloDisk.txt"),0);
wcscat(s,TEXT("HelloDisk"));
h=CreateFile(s,GENERIC_WRITE,0,NULL,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL);
if (h==INVALID_HANDLE_VALUE)
MessageBox(NULL,TEXT("Can't create file!"),TEXT("HelloDisk"),0);
else
CloseHandle(h);
}
return 0;
}
Listing 2: HelloDisk.cpp
Fazit
Auch wenn Windows CE nicht den vollen Umfang des Win32 APIs unterstützt, so ist die Portierung von vorhandenen Applikationen dennoch ein relativ geradliniger Prozess. Die Tools sind genauso komfortabel, vollständig und vertraut, wie bei den schon bekannten Win32 Plattformen. Durch den Einsatz von Treiber Packs läÃt sich auch im Embedded Bereich der Aufwand bei der Windows CE Integration und Applikationsportierung erheblich reduzieren.
