Software,
Download

Software-
entwicklung

Nachrichten-
technik
  Antennen
  Embedded
  DVB-T

Internet

Aktuelles,
Sonstiges

Infos,
Kontakt

Sitemap

Transcript von Wolfgangs Weblog, Kategorie Embedded

[19.04.2008] SPARK Your Imagination - Windows Embedded CE auch für Hobby-Entwickler
[06.05.2008] eBox SPARK Jump Start Kit - Bezugsquelle in Deutschland
[23.05.2008] eBox-4300 - Die erste Inbetriebnahme
[24.05.2008] Ermittlung der Systemeigenschaften mit Hilfe von WR-Tools ResInfo
[25.05.2008] Bildschirmausgabe mittels Remote Display Control
[26.05.2008] Installation von Microsoft Visual Studio 2005 Professional
[27.05.2008] Parallelinstallation mit Microsoft Windows CE 5.0
[30.05.2008] Installation von Microsoft Windows Embedded CE 6.0 R2
[01.06.2008] Installation des Board Support Package für die eBox-4300
[01.06.2008] WR-Tools als Windows Embedded CE 6.0 Catalog Component
[03.06.2008] CPU Identifikation und Taktfrequenz des VIA Eden ULV Prozessors
[10.06.2008] Erstellung eines Runtime-Images mit dem Platform Builder 6.00
[11.06.2008] Erstellung eines deutschen Tastaturtreibers für Windows Embedded CE 6.0
[01.07.2008] Serielle ActiveSync-Verbindung zwischen Desktop-PC und CEPC
[06.07.2008] Tips und Tricks zur ICOP eBox-4300 mit Windows Embedded CE 6.0 R2
[20.07.2008] Erstellung eines plattformspezifischen Software Development Kits
[08.08.2008] Ein kurzer Blick auf das Speicherabbild der ICOP eBox-4300
[16.08.2008] Unterstützung für Dateisynchronisierung auf externen Datenträgern
[17.08.2008] Hintergrundthread für das Zurückschreiben der Registry
[23.08.2008] Das Windows Embedded CE 6.0 Test Kit (CETK)
[20.06.2009] Neues VIA x86 Board Support Package, Version 3.44

SPARK Your Imagination - Windows Embedded CE auch für Hobby-Entwickler

Der Softwarehersteller Microsoft hat die Community-Initiative SPARK Your Imagination gestartet. Zusammen mit fünf Geräteherstellern wird eine Kombination aus Hardware, Vollversion von Visual Studio 2005 Professional und Windows Embedded CE 6.0 R2 für den nichtkommerziellen Einsatz angeboten. Dabei sollen die Preise dieser "Windows-Embedded-CE-Hobbykits" nur geringfügig überhalb der Hardware liegen.

Besonders interessant finde ich die beiden eBox Jump Start Kits der ICOP Technology Inc. und das XScale PXA270-basierte Referenzkit der deutschen Firma Keith & Koep GmbH. Das letztere Kit ist schon für etwa 150 € erhältlich.

eBox SPARK Jump Start Kit - Bezugsquelle in Deutschland

Für die eBox Embedded PC's von ICOP Technology Inc. hatte ich mich schon länger interessiert. Diese x86-basierten VESA PCs sind sehr klein, kompakt und stabil. Da per PC-BIOS ein DOS gebootet wird, sind die Geräte zudem sehr einfach und universell einsetzbar. Zudem hat die eBox durch ihre große Verbreitung und deren Einsatz beim Imagine Cup eine große Community.

Meine Angebotsanfrage beim deutschen ICOP Großhändler JSC Industrial Personal Computer 2U GmbH (IPC2U) wurde an die OMTEC KG weitergeleitet. Dort konnte ich das eBox-MSJK-SPARK Jump Start Kit als Privatkunde beziehen.

Ich habe mich für die "große" eBox-4300 mit VIA Eden ULV 500MHz CPU, VIA CX700M Chipsatz und VIA UniChrome Pro II GPU entschieden.

eBox-4300 - Die erste Inbetriebnahme

Meine eBox-4300-MSJK-SPARK ist eingetroffen. Auf dem Karton ist DMP Electronics Inc. als Hersteller angegeben. Diese Firma gehört wie ICOP Technology Inc. zur DM&P Group.

Einer sofortigen Inbetriebnahme steht nichts im Wege, da alle notwendigen Kabel beiliegen und ein funktionsfähiges Windows Embedded CE 6.0 R2 Abbild auf der EmbedDisk vorinstalliert ist.

Der erste Menüpunkt des MS-DOS-Startmenüs sorgt dafür, daß der CEPC Bootloader loadcepc.exe das lokal vorliegende OS Image nk.bin startet. Schon nach kurzer Zeit erscheint der Standard-Desktop von Microsoft Windows Embedded CE 6.0. Dieser wird mit einer Auflösung von 800x600x16 BPP angezeigt.
Es fällt auf, daß im Startmenü der Menüpunkt "Suspend" fehlt. Der Ein/Aus-Taster schaltet das Gerät sofort aus.

Mit dem Tool VTUtility aus dem Ordner "\Windows" kann man den VGA-Port an den angeschlossenen Bildschirm anpassen. Am Analogeingang meines LCD-Displays ergab die Option CRT die beste Darstellung. Bei TV blieb der Bildschirm schwarz.

Ich bin gespannt, ob dieses und die anderen im Image vorgefundenen OEM-Tools im Board Support Package (BSP) enthalten sind oder ob sie separat mit eingebunden werden müssen.

Um die serielle Schnittstelle zu testen, habe ich den COM1-Port der eBox mit dem beiliegenden Nullmodem-Kabel an den RS232-Port eines PC's angeschlossen und dort unter Windows XP HyperTerminal gestartet (COM1: 38400 8-N-1). Damit Windows CE Debug-Meldungen an den COM1-Port umleitet, muß dem Bootloader loadcepc.exe der Parameter /C:1 übergeben werden.
Das OS Image wurde jedoch so erstellt, daß es keine Debug-Meldungen erzeugt. Somit war das Ergebnis recht dürftig:

Debug Serial Init

SysInit: GDTBase=81698000 IDTBase=816a63a0 KData=816a1800
Windows CE Kernel for i486 Built on Oct 1 2007 at 16:06:49
VIAPWM.LIB 4.22, Nov 3 2006, 11:35:48
X86Init done, OEMAddressTable = 80222910, RAM mapped = 20000000.
x

Weitere Test werden verschoben bis ein Backup der Flashdisk vorliegt.

Die eBox-4300 wird übrigens außen kaum warm. Eine CompactFlash-Karte im CF-Schacht nimmt jedoch überraschend viel Wärme auf. Mir ist noch nicht klar, ob die CPU eine mangelnde Verbindung zum Kühlkörper aufweist oder ob der Chipsatzbaustein für die hohe Temperatur im inneren des Gerätes verantwortlich ist.
Aussagen zur Dimensionierung des Netzteils kann ich ebenfalls noch nicht machen, da bisher noch keine Lasttests möglich waren.
Auch die BIOS-Einstellungen wurden noch nicht genauer untersucht.

Der Hardware lag keine gedruckte Dokumentation bei. Auf der CD-ROM findet man neben BSP, SDK und einem OS Image noch den "eBox-4300 Windows Embedded CE 6.0 Jump Start Guide" und ein umfangreiches Curriculum "Introduction to Embedded Systems using Windows Embedded CE".

Ermittlung der Systemeigenschaften mit Hilfe von WR-Tools ResInfo

Die Installation von zusätzlicher Software geschieht am einfachsten über eine CF-Karte oder einem Flash-Speicherstick. Allerdings konnte ich aktuell weder auf ein Stick noch auf ein CF-Lesegerät zugreifen.

Somit kam das der eBox-4300 beiliegende Cross Over LAN-Kabel zum Einsatz. Nach kurzer Zeit wurde der eBox eine IP-Adresse zugeteilt und man konnte per UNC-Pfad (\\HOST\SharedFolder) im Windows-Explorer auf einen freigegebenen Ordner des Desktop-PC's zugreifen.

Obwohl das Gerät den Prozessortyp PROCESSOR_INTEL_486 meldet, ist für die Programminstallation eine CAB-Datei notwendig, die unter [CEDevice] mit dem Prozessortyp 686 markiert wurde.

Das Utility WR-Tools ResInfo zeigt auf der Seite System 425 MB RAM an. Dieser Wert ist stimmig, da von den 512 MB DDR2 RAM 64 MB für den Bildschirmspeicher reserviert werden und das Runtime Image (nk.bin) vollständig in das RAM geladen wird.

Auf der Seite Speicher bin ich kurz ins grübeln gekommen, da dort die Summe aus Programmspeicher (297 MB) und Objektspeicher (243 MB) deutlich größer war als der nutzbare Hauptspeicher. Hier wurde nämlich die 256 MB große IDE Flash Disk als Startlaufwerk im Wurzelverzeichnis des Dateisystems eingebunden. Diese hatte ich als bereitgestellten Datenträger vermutet. Ein Blick auf die Seite Datenträger von ResInfo gab Klarheit. Hier war sie nicht zu finden.

Da von den 425 MB Hauptspeicher 297 MB als Programmspeicher abgetrennt wurden, fehlen hier 128 MB. Wo sind sie geblieben? Scheinbar gibt es doch noch ein Objektspeicher. Vermutlich für das Dateisystem und die Datenbanken. Die Registry liegt ja Hive-basiert als Datei vor. Auch die Systemeigenschaften in der Systemsteuerung (Reiter Speicher) sorgen hier nicht für Klarheit. Die Werte für den Objektspeicher sind negativ und sobald man den Schieberegler anklickt, wird nur noch Unsinn angezeigt. Die Skala oben im Symbol von ResInfo zeigt das Verhältnis von 297 MB zu 128 MB jedoch korrekt an.

Legt man eine CF-Speicherkarte ein, wird diese als "Hard Disk" in das Dateisystem eingebunden. Leider ist dieser IDE-Port nicht Hot-Plug-fähig. Man muß die Karte vor dem Systemstart einstecken und darf sie während des Betriebs nicht entfernen oder gar austauschen.

Massenspeichergeräte, wie USB-Speichersticks oder eine Digitalkamera, werden als "USB Storage" angezeigt.

Der Zugriff auf die Registry geschieht sehr langsam. Vermutlich wird sie bei jeder Änderung sofort vollständig auf den Datenträger zurückgeschrieben.

Bildschirmausgabe mittels Remote Display Control

Meinen LCD-Bildschirm kann ich zwar vom digitalen Eingang (Desktop PC) auf den analogen Eingang (eBox-4300) umschalten; praktischer wäre es in manchen Fällen jedoch, wenn man gleichzeitig beide Bildschirmausgaben sehen könnte.

Dazu ist das Tool Remote Display Control sehr hilfreich. Auf der eBox-4300 wird der Client CE Remote Display sogar automatisch gestartet.

Leider wollte mir erst keine Verbindung gelingen. Es fehlte auch der in der Doku beschriebene Menüpunkt "Connect". Ein weiterer Hinweis in der Readme-Datei führte dann zur Lösung: Client und Host müssen die gleiche Versionsnummer besitzen. Mein Host hatte die Version 2.03, der Client auf dem Gerät hingegen schon die Version 3.00. Zudem darf die Farbtiefe des Gerätes maximal 16 Bit pro Pixel betragen.

Inzwischen hängt die eBox-4300 auch am lokalen Netzwerk. Somit habe ich dann auch das letzte Kabel, welches dem Jump Start Kit beilag, verwendet. Die Remote Display Control-Verbindung über Ethernet funktioniert bei Vollbildübertragung einwandfrei. WR-Tools CpuLoad zeigt dabei eine CPU-Auslastung von 40% an.

Installation von Microsoft Visual Studio 2005 Professional

Dem SPARK Jump Start Kit liegt Microsoft Windows Embedded CE 6.0 und Windows Embedded CE 6.0 R2 bei. Der enthaltene Platform Builder ist keine eigenständige Anwendung mehr. Er wird als Plug-In in Microsoft Visual Studio 2005 (ab Standard Edition) eingebunden.
Im JSK ist daher auch eine Vollversion von Visual Studio 2005 Professional in englischer Sprache enthalten.

Leider fehlt die MSDN Library und damit jede Dokumentation. Sie müßte aber vollständig online verfügbar sein. Wer ausreichend breitbandig am Internet angebunden ist, kann sie sich auch hier herunterladen. Bereits vorhandene Dokumentationen können mit dem Manager für die kombinierte Visual Studio 2005-Hilfeauflistung integriert werden.

Der eBox-4300 liegt eine CD-ROM bei, auf der in einzelnen Dokumenten Hinweise zur Installation enthalten sind.
Die vollständige Installation erfolgt ohne Benutzeraktion. Es muß nur einmal die DVD gewechselt werden.

Das notwendige Visual Studio 2005 Service Pack 1 findet man hier.
Nutzer von Microsoft Windows Vista benötigen noch das Service Pack 1 Update.

Es gibt natürlich auch aktuellere Windows SDK's mit neueren Compilern. Allerdings sollte man sich überlegen, ob man ein solches wirklich für eigene Entwicklungen benötigt. Durch die Installation von Visual Studio, MSDN Library, Windows SDK, Platform Builder und Windows Embedded CE werden sehr viele Einträge in der Registry unterhalb des Windows Installers angelegt. Da bei allen neuen Installationen und Deinstallationen, die den Windows Installer verwenden, diese Einträge mehrfach durchsucht werden, können diese Vorgänge sehr lange andauern.

So wie es aussieht, liegt dem Softwarepaket die EULA der normalen Verkaufsversion bei. Allerdings wird der Nutzungsumfang des Visual Studio in der Lizenzvereinbarung zu Windows Embedded CE 6.0 R2 deutlich und klar eingeschränkt.

Wer das Visual Studio nicht kennt benötigt sicher eine gewisse Zeit für die Einarbeitung. So ist nicht immer klar was sich genau hinter jedem Menüpunkt verbirgt. Die Konfigurationseigenschaften von Projekten sind sehr umfangreich. Zudem wird man nicht gleich Herr über die vielen Tool- und Dokumentenfenster.

Als erstes sollte man einstellen, ob ein Hilfethema nur lokal, zuerst online oder zuerst lokal gesucht werden soll. Auch der RSS-Feed auf der Startseite kann frei gewählt werden.

Parallelinstallation mit Microsoft Windows CE 5.0

In diesem Blog von Doug Cook wird beschrieben, ob Windows Embedded CE 6.0 nebeneinander mit Windows CE 5.0 installiert werden kann.

Hat man sich entschlossen Windows CE 5.0 zu deinstallieren, müssen alle darauf basierenden Zusatzpakete zuerst entfernt werden. So schlägt z.B. eine nachträgliche Deinstallation des Device Emulator: ARMV4I BSP for Windows CE 5.0 oder des Mainstone Board Support Package Update for Windows CE 5.0 fehl.

Es kann auch sein, daß nach einer Deinstallation noch Einträge in der Registrierungsdatenbank verbleiben. Das Tool CEFileWiz zum Erstellen eigener Katalogeinträge funktioniert z.B. nicht mehr richtig, wenn sich noch der Pfad <HKLM|HKCU>\SOFTWARE\Microsoft\Platform Builder\5.00 in der Registry befindet.

Installation von Microsoft Windows Embedded CE 6.0 R2

Ab Version 6.0 ist der Platform Builder ein Plug-in für Microsoft Visual Studio 2005. Erst wenn Visual Studio 2005, Visual Studio 2005 SP1 und ggf. Visual Studio 2005 SP1 Update for Vista inklusive .NET Framework 2.0 und der Smart Device Programmability for C++ auf dem Zielrechner vorhanden sind, kann Windows Embedded CE 6.0 R2 vollständig installiert werden. Das Setup weist darauf hin, falls das .NET Framework 2.0 oder die Smart Device Programmability for Visual C++ noch nicht installiert wurden.

Als erstes wird Windows Embedded CE 6.0 von der DVD #1 installiert.

Als Softwareentwickler sollte man neben dem Platform Builder und dem Windows Embedded CE 6.0 Test Kit auf jeden Fall noch die Shared Sources auf die Festplatte überspielen.
Als CPU empfehle ich x86 für die eBox-4300 und ARMV4I für den Geräteemulator zu installieren.
Auch wenn man noch sehr viel Platz auf der Festplatte frei hat, sollte man nicht alle verfügbaren CPU's auswählen. Denn Microsoft stellt zu jeder CPU monatlich Updates zur Verfügung. Es wird dann sehr aufwendig, das System aktuell zu halten.
Ich empfehle zudem, den vorgegebenen Pfad C:\WINCE600 für das Betriebssystem zu übernehmen, da einige externe Tools diesen leider "hart" kodieren.

Das Setup erfolgt ohne weitere Benutzerinteraktion. Bei zwei CPU's dauert sie etwa 30 Minuten.
Ein Neustart des Rechners ist bei keiner der hier beschriebenen Installationen notwendig.

Als nächstes wird das Windows Embedded CE 6.0 SP1 installiert.

Das Setup dauert etwa 10 Minuten. Während der Installation des Microsoft Remote Tools Frameworks greift dieses auf das Netzwerk zu. Eventuell muß man dies einer installierten Firewall manuell gestatten.

Anschließend installiert man Windows Embedded CE 6.0 R2 von der DVD #2.

Das Setup bringt drei zusätzliche BSP's mit, die man je nach installierter CPU optional mit installieren kann. Die Installation dauert etwa 10 Minuten.

Inzwischen ist Windows Embedded CE 6.0 R3 verfügbar. "R3" enthält alle Updates zu "R2" und kann sofort nachinstalliert werden:

Windows Embedded CE 6.0 R3

Nun folgen die Updates. Sie beseitigen nicht nur Fehler, sondern bringen ab und zu auch neue Funktionen mit. Die Updates werden monatlich für jede CPU separat bereitgestellt. Zum Jahresanfang wird zudem ein Gesamtpaket über alle Updates des vorhergehenden Jahres als Rollup zur Verfügung gestellt.

Die Updates können nun "in einem Rutsch" installiert werden. Jedes Setup dauert etwa 1 Minute.

Windows Embedded CE 6.0 Cumulative Product Update Rollup Package (through 12/31/2010)

Mit dem CE Update Check Tool kann überprüft werden, ob man alle Updates korrekt installiert hat. Es läßt sich über das Visual Studio aufrufen.

Beim ersten Start des Visual Studio 2005 nach Installation von Windows Embedded CE 6.0 wird man gefragt, ob die Entwicklungsumgebung (IDE) für die Arbeit mit dem Platform Builder angepaßt werden soll. Stimmt man dem zu, werden die vorhandenen Toolfenster, Werkzeugleisten, Tastenkürzel, Hilfethemen-Filter und der Newsfeed mit denen des Platform Builders ersetzt. Man kann aber jederzeit wieder seine selbst gespeicherten oder die vordefinierten Entwicklungseinstellungen importieren.

Jetzt kann man über das Dialogfeld "Neues Projekt" ein Projekt zum Erstellen eines Windows Embedded CE 6.0-Betriebssystems anlegen.

Um ein OS Image für die eBox-4300 zu erstellen, muß aber vorher noch das entsprechende Board Support Package (BSP) installiert werden. Das BSP für den ARM-basierten Geräteemulator wird mitgeliefert. Ein entsprechendes Image kann sofort erstellt werden.

Installation des Board Support Package für die eBox-4300

Ein Board Support Package (BSP) enthält u.a. einen zur Hardware passenden Bootloader, die Hardware-Anpassungsschicht, alle notwendigen Gerätetreiber und diverse Konfigurationsdateien. Manchmal ist auch ein angepaßtes Power Management enthalten.

Das BSP für die eBox befindet sich auf der CD-ROM zum Gerät. Aktualisierte Versionen können hier heruntergeladen werden. Die Buchstaben hinter der 60 weisen auf die Version hin. ICOP_eBox4300_60DS ist z.B. aktueller als ICOP_eBox4300_60CS und ICOP_eBox4300_60A.

Auch VIA Technologies, Inc. bietet eigene Treiber und Board Support Packages an. Die BSP's sind dann aber nicht an die eBox angepaßt. Ein Vergleich der BSP's (auch für andere Chipsätze) mit WinDiff ist dennoch interessant und hilfreich, falls man einzelne Treiber aktualisieren möchte.

Das BSP für die eBox-4300 von ICOP ist schnell installiert. Es wird im Ordner "C:\WINCE600\PLATFORM" abgelegt.
Anschließend kann man Visual Studio 2005 starten und mit Hilfe des Platform Builders eine darauf basierende Plattform erstellen.

Möchte man die Hardware oder das Verhalten des Gerätes ändern (z.B. Speicher erweitern, Funktion des Ausschalters ändern, COM-Ports tauschen, Bildschirmauflösung ändern), muß das BSP modifiziert werden. In solchen Fällen ist es sinnvoll mit einer Kopie des BSP zu arbeiten.
Über den Menüpunkt "Clone BSP" kann man daher ein Board Support Package sehr einfach klonen. Statt des originalen BSP wählt man dann beim Erstellen der Plattform einfach die eigene Kopie aus. Es ist aber auch möglich innerhalb eines bestehenden Projektes das BSP zu wechseln.

Auf der ICOP Support CD findet man noch eine CoreCon Komponente. CoreCon steht für Core Connectivity und stellt neben ActiveSync und KITL eine weitere Methode bereit, den Entwicklungsrechner mit dem Gerät zu verbinden.
Dazu müssen ein paar Systemdateien auf das Gerät übertragen werden. Installiert man die CoreCon Komponente, kann man diese bequem im Katalog des Platform Builders auswählen und mit in das OS Image übernehmen.

Auf einem deutschen Entwicklungsrechner führt dies jedoch beim Erstellen einer Plattform zu einem Fehler, da ICOP den Dateipfad zu den Quelldateien in englisch "hart" kodiert hat. Zur Korrektur muß die Datei "C:\WINCE600\PUBLIC\ConMan_x86\postlink.bat" modifiziert werden.

Dazu ersetzt man am besten alle Vorkommen von C:\Program Files\Common Files durch %CommonProgramFiles%.

Fest programmierte Dateipfade bei Drittprodukten kommen leider sehr oft vor. Und das, obwohl Microsoft sehr viele Parameter und Pfade in Umgebungsvariablen definiert. Öffnet man bei geladenem Projekt über den Menüpunkt "Open Release Directory in Build Window" eine Eingabeaufforderung, kann man sich sehr einfach über den Befehl "SET" alle Variablen anzeigen lassen.

Auf der Support CD ist noch ein Customized OEM Software Development Kit (SDK) für die eBox enthalten. Dieses können Drittentwickler verwenden, um Software passend für die jeweilige Plattform zu entwickeln. Ein solches SDK enthält genau nur die API-Funktionen, die auch im dazugehörigen OS Image implementiert wurden. Modifiziert man eine Plattform durch Hinzufügen oder Entfernen von Komponenten, muß auch das SDK neu erstellt werden.

WR-Tools als Windows Embedded CE 6.0 Catalog Component

Wer möchte, kann die WR-Tools gerne in sein CE6 OS Image mit einbinden.
Entsprechende Komponenten für den Katalog des Platform Builders 6.0 stehen hier zum Download zur Verfügung:

WR-Tools ResInfo
WR-Tools CpuLoad
WR-Tools HotKeys
WR-Tools WRJpeg

Entpacken Sie die Dateien bitte in den folgenden Ordner: "%_WINCEROOT%\3rdParty" (z.B. C:\WINCE600\3rdParty)
Es werden die Prozessoren ARMV4I, MIPSII, SH4, X86 sowie die Gebietsschemas 0407 (DE-DE) und 0409 (EN-US) unterstützt.

Zum Download der Projektdateien für Windows CE 5.0 ersetzen Sie in den Links einfach die 6 durch eine 5.

CPU Identifikation und Taktfrequenz des VIA Eden ULV Prozessors

In der eBox-4300 werkelt der 1-Watt-Prozessor VIA Eden ULV 500 MHz. Im Leerlauf soll die CPU sogar nur 0,1 Watt benötigen.

Im BIOS ist die Option VIA Processor Power Management abgeschaltet. Auch das im BSP enthaltene Power Saver Utility, welches die Taktfrequenz der CPU dynamisch ändern kann (VIA PowerSaver-Technologie), wird scheinbar nicht mit in das OS Image eingebunden (Zumindest nicht das Systemsteuerungselement). Der Prozessor müßte also mit maximaler Geschwindigkeit zur Verfügung stehen.

Zur Kontrolle habe ich mir ein kleines Utility geschrieben, mit dem man die aktuelle Taktfrequenz ermitteln kann.

Die CPU gibt sich mit dem richtigen Namen zu erkennen und die CPUID bestätigt den C7 Esther-Kern. Der Kerntakt wurde mit 499 MHz gemessen.

Erstellung eines Runtime-Images mit dem Platform Builder 6.00

Mit dem Visual Studio ist das Zusammenstellen, Konfigurieren, Erstellen und Ausführen eines Runtime-Images einfach, schnell und problemlos bewerkstelligt, solange man nur auf die in der Entwicklungsumgebung verfügbaren Komponenten aus dem Katalog von Windows Embedded CE zurückgreift.

Will man das Betriebssystem darüber hinaus anpassen oder mit eigenen bzw. fremden Produkten erweitern, sieht man sich sehr schnell mit Schwierigkeiten konfrontiert. Zudem kann man bei Modifikationen schnell sehr viel falsch machen.

Nachfolgend führe ich in Stichpunkten ein paar Erfahrungen auf, die ich bei meinen ersten Gehversuchen mit dem Platform Builder gemacht habe.

Dokumentation

Der JumpStart Guide von der eBox-4300 Support CD stellt eine kurze Schnellanleitung dar. Er enthält wichtige Informationen zur Konfiguration des Zielgerätes.

Auf der Support CD befindet sich noch ein Curriculum zu Windows Embedded CE. Es enthält in verschiedenen Kapiteln weitere nützliche Infos über das Erstellen eines OS Designs.

Als Nachschlagewerk ist die Onlinehilfe unverzichtbar. Leider ist sie zum Stöbern sehr unübersichtlich. Viele Grundlagenartikel und Hintergrundinformation aus früheren Dokumentationen scheinen in der aktuellen Version zu fehlen.

Für Einsteiger ist das MCTS Exam Preparation Kit Pflicht. Alles Wichtige ist dort leicht verständlich und in übersichtlicher Form enthalten.

Wer Visual Studio, Platform Builder und Windows CE noch nicht installiert hat, kann mit Hilfe der Virtual Labs erst einmal mit einer IDE auf einem Virtual PC Server üben.

Raucht der Kopf vom vielen Lesen, bieten die Videos aus den eHow-tos and Tutorials eine schöne Alternative.

Findet man zu einer Frage keine Antwort, stellt man diese am Besten in der Platform Builder Newsgroup.

OS Design Wizard

Ich empfehle, nicht das originale BSP zu verwenden, sondern vorher einen Klon davon zu erstellen und diesen zu selektieren. Man kann zwar später das BSP wechseln, vergißt aber schnell, das alte OS Design zu bereinigen. Zudem muß das Projekt neu konfiguriert und erstellt werden.

Wählt man "PDA Device" und "Enterprise Web Pad" als Design Template, erhält man eine recht vollständige Plattform, zu der man nicht mehr viele Komponenten hinzufügen muß.

Auf den beiden nächsten Seiten kann man schon ein paar Komponenten aus- oder abwählen. Hier sollte man nur die Features wählen, die man auch wirklich braucht und dessen Funktion man kennt. Über den "großen" Platform Builder Catalog (Catalog Item View) kann man abgewählte Komponenten wieder hinzufügen. Zudem kann man sich dort die Abhängigkeiten der Module untereinander anzeigen lassen und erkennen, ob evtl. alternative Komponenten vorhanden sind (z.B. .NET CF 3.5 statt 2.0).

Catalog Items View

Den Katalog kann man über das Suchfeld oben im Toolfenster nach Einträgen und Sysgen-Variablen durchsuchen.
Ist ein Katalogeintrag markiert, kann man per F1 nähere Informationen aus der Onlinehilfe abrufen.

Ein grünes Häkchen vor einem Eintrag gibt an, daß er dem OS Design direkt zugefügt wurde.
Ein grün ausgefülltes Kästchen deutet darauf hin, daß dieser Eintrag automatisch als Abhängigkeit eines anderen Eintrags hinzugefügt wurde. Über das Kontextmenü kann man sich über die Gründe informieren. Ein Kontextmenüeintrag gibt auch Auskunft über die Abhängigkeiten von noch nicht in das OS Design aufgenommenen Einträgen.
Ein rotes Kreuz deutet darauf hin, daß dieser Eintrag nicht in das OS Design übernommen wurde. Auch hier kann über ein Menüeintrag der Grund für den Ausschluß abgefragt werden. So kann z.B. ein Eintrag abhängig vom Gebietsschema sein oder er wird erst dann übernommen, wenn ein anderer Eintrag deselektiert wird.

Der Eintrag Standard SDK for Windows Embedded CE sorgte in früheren Versionen von Windows CE dafür, daß eine genau definierte Teilmenge an Komponenten dem OS Design hinzugefügt wurde. Für diese Art Referenzplattform wurde auch ein Standard SDK veröffentlicht. Anwendungen, die mit diesem Universal SDK erstellt wurden, waren dann auf allen Plattformen mit dieser Option lauffähig. Da angeblich weder die Gerätehersteller diesen Katalogeintrag verwendet hatten noch die Anwendungsentwickler das SDK genutzt hatten, gibt es zu Windows Embedded CE 6.0 kein Standard SDK mehr.

Die Komponente Target Control Support (Shell.exe) fügt dem OS Design die Debug-Shell shell.exe hinzu. Über den Befehl "Target: Target Control" im Platform Builder kann man direkt auf sie zugreifen.

Die Firewall blockiert mit den Standardeinstellungen jeden eingehenden Netzwerkverkehr. Man sollte diese Komponente daher nicht sofort am Anfang mit einbinden.

Auch wenn das Gerät nur einen Netzanschluß besitzt, kann das Einbinden des Batterietreibers sinnvoll sein. Denn viele Drittprogramme für mobile Geräte greifen auf diese Programmierschnittstelle zu.

Man kann zwischen einer Datei- bzw. Hive-basierten Registry oder einer RAM-basierten Registry wählen. Zu Beginn des OS Designs oder zu Testzwecken sollte man die RAM-basierte Registry verwenden sowie auch das Dateisystem im Objektspeicher anlegen und nicht im Wurzelverzeichnis einer Disk bereitstellen. Denn nur dann ist sichergestellt, daß das OS rückstandsfrei bootet und nicht auf alte Konfigurationsdaten und bereits vorhandene Dateien zugreift.

Ein deutsches Tastaturlayout ist leider nicht als Katalogeintrag vorhanden. Dieses muß man sich selber erstellen. Dazu klont man z.B. das US-Layout und ersetzt dessen Dateien mit denen, die man mit dem "Keyboard Layout Generator Tool" erzeugt hat.

Gegenüber Windows CE 5.0 vermißt man noch die MFC, die File Viewers und die Inbox.

Solution Explorer

Im Projektmappen-Explorer werden alle Projekte und die entsprechenden Dateien in einer logischen Struktur dargestellt.

Unterhalb von "C:/WINCE600" werden die Wurzelverzeichnisse für die geräteabhängigen Dateien und Ordner (PLATFORM) sowie für den plattformunabhängigen Quellcode von Windows CE (PRIVATE, PUBLIC) angezeigt. Navigiert man durch den Hierarchiebaum, wird im Eigenschaften-Toolfenster der Objektname des Elementes angezeigt. So erkennt man einfacher ob es sich um eine Dirs-Datei, eine Sources-Datei oder eine Build-Datei handelt.
Ein Doppelklick auf eine Dirs- oder Sources-Datei öffnet diese in einem Dokumentenfenster. Über den Eintrag "Eigenschaften" des Kontextmenüs stehen aber auch spezielle Editoren für deren Verwaltung zur Verfügung.

Ordner, die man aktuell bearbeitet oder auf die man oft zugreift, kann man zum schnellen Zugriff im Favoriten-Ordner anzeigen lassen.

Im Wurzelverzeichnis der Projektmappe, im BSP des Ordners PLATFORM sowie in fast jedem Unterverzeichnis des Ordners PUBLIC befindet sich ein Ordner mit dem Namen "Parameter Files". Darin liegen Dateien mit den Erweiterungen "BIB", "DAT", "DB" und/oder "REG".
Über diese Dateien steuert man, welche Dateien/Module dem Runtime-Image hinzugefügt werden (.bib), wie das RAM-basierte Dateisystem organisiert wird (.dat), mit welchen Daten die Datenbanken im Objektspeicher initialisiert werden (.db) und mit welchen Einträgen die Registry vorbelegt wird (.reg).
Alle Dateien eines Typs werden beim Erstellen des Runtime-Images zusammengefügt. Bei doppelten Einträgen haben die Parameterdateien der Plattform (platform.*) bzw. die des Projektes (project.*) Vorrang gegenüber den allgemeinen Parameterdateien des Betriebssystems. So kann man alle Parameter überschreiben, ohne daß man Dateien im Ordner PUBLIC modifizieren muß.

String Replacement Files (.str), mit denen man Zeichenketten im Betriebssystem übersetzen kann, funktionieren ähnlich. Sie befinden sich im Ordner FILES\INTLTRNS\%LOCALE%.

Bei den Registrierungsdateien fallen die vielen als Kommentar getarnten Markierungen und Direktiven (Filter) auf:

; HIVE BOOT SECTION
[...]
; END HIVE BOOT SECTION

; @CESYSGEN IF CE_MODULES_BATTDRVR
[...]
; @CESYSGEN ENDIF CE_MODULES_BATTDRVR

Diese sind bei der Modifikation zu beachten. Genaue Informationen zum Format der Parameterdateien findet man in der Onlinehilfe.

Konfigurationseigenschaften

Solange man keine Fehler suchen muß, empfehle ich ein Release-Build zu erstellen (Projektmappenkonfiguration und Build type). Bei einem Debug-Build wird das Runtime-Image fast doppelt so groß. Das kann bei einem Emulator-Image zu Problemen führen, wenn es größer als 32 MB wird. Zudem wird die Ausführungsgeschwindigkeit durch die vielen Debug-Meldungen stark gedrosselt.

Ändert man die Default locale auf "Deutsch (Deutschland)", werden die Ländereinstellungen und die Standardsprache der Benutzeroberfläche auf Deutsch festgelegt. Um auch die Eingabesprache in Deutsch zu erhalten, muß man ein deutsches Tastaturlayout der Plattform hinzufügen (s.o.).

Soll das Runtime-Image eigenständig lauffähig sein, muß die Build-Option "Enable KITL" abgewählt sein. Man kann diese Option (auch mit einer Release-Konfiguration) aktivieren, wenn man das Gerät mit den "Remote Tools" untersuchen möchte. Es ist daher am besten, wenn man sich eine weitere Konfiguration "Ship" erstellt. In der Release-Konfiguration aktiviert man dann KITL und den Kernel Debugger. In der Ship-Konfiguration statt dessen "Enable ship build".
Die Option "Run-time Image Can be Larger than 32 MB" darf man nur aktivieren, wenn sich im Gerät genau 64 MB RAM befindet. Andernfalls muß eine entsprechend der RAM-Größe definierte Umgebungsvariable IMGRAMXXX definiert werden (z.B. IMGRAM256=1 bei 256 MB RAM). Auf dieses Variable wird in der Datei config.bib zugegriffen.

Mit den "Build Options" und den "Environment Variables" sollte man sich intensiver befassen.

Per "Custom Build Actions" kann man sich z.B. während der Stufe "Pre-Make Image" automatisch beliebige Dateien in den %_FLATRELEASEDIR%-Ordner kopieren lassen, die man dann per Binary Image Builder (.bib)-Datei mit in das Runtime-Image aufnehmen lassen kann.

Runtime-Image erstellen

Der Befehl "Erstellen: Projektmappe erstellen" bzw. "Build: Build Solution" erzeugt aus dem OS Design das Runtime-Image. Enthält die Projektmappe nur ein Projekt, führt der Befehl "<OS Design> erstellen" bzw. "Build <OS design>" zum selben Ergebnis. Beide Optionen entsprechen dem Platform Builder-Befehl "Sysgen".

Je nach Umfang des OS Designs dauert dieser Vorgang zwischen 20 und 30 Minuten. Danach sollte sich das Image nk.bin im Ordner %_FLATRELEASEDIR% befinden.
Warnmeldungen treten immer auf. Man sollte sich dennoch mit ihnen vertraut machen, um sie später von neuen und ggf. wichtigen Warnungen zu unterscheiden.
Tritt ein Fehler auf, muß man die Ursache oft über die Suchfunktion in der langen Protokolldatei ermitteln. Nicht immer ist der Grund für die Fehlermeldung sofort klar ersichtlich. Dann sollte man sich ein paar Zeilen davor genauer ansehen und das Modul bzw. den Ordner bestimmen, in dem der Fehler auftritt. Diesen Ordner öffnet man dann mit dem Explorer und durchsucht dann den Ast nach den Dateien "Build.log" und "Build.err". Hier sind oft detailliertere Informationen zur Ursache des Fehlers zu finden.

Der häufigste Fehler ist ein nicht gefundener Dateipfad oder eine fehlende Datei. Bei Drittprodukten ist oft der Dateipfad speziell "hartkodiert" oder die Struktur nur mit einem englischen Gebietsschema kompatibel. Evtl. wurde eine Komponente auch nur für eine Vorgängerversion von Windows CE erstellt. Dann werden einzelne Dateien nur in den Ordner %_FLATRELEASEDIR% kopiert. Unter Windows CE 6.0 müssen diese auch im Ordner %_PROJECTROOT%\cesysgen\oak\target\%_TGTCPU%\%WINCEDEBUG% vorhanden sein.

Sollte die Ursache für ein Fehler gar nicht einleuchten, hilft es oft, das Projekt neu zu erstellen ("Rebuild Solution" bzw. "Clean Sysgen").

Wer mit den diversen Build-Phasen noch nicht vertraut ist, weiß oft nicht genau, welche Build-Option bei welchen Änderungen notwendig ist, um das Betriebssystem ohne unnötig lange Wartezeiten zu erstellen. Michel Verhagen, eMVP, hat dazu einen Newsgroup-Beitrag veröffentlicht, den ich hier im Original wiedergebe:

Here's my when-to-build-what "build shortcut" list:

Change something in Platform Settings: do a makeimg
Change something in a driver in the BSP: Build the driver, do makeimg
Change several things in the BSP: Build the BSP, do makeimg
Change something in the BSP and/or the config files (eg platform.reg):
Build & sysgen the BSP, then Copy Files to RelDir, then Build All
Projects and Makeimg.
Change something in the workspace configuration (add or delete a
component): Sysgen the platform (and sometimes a clean sysgen is needed,
eg when changing from RAM based registry to Hive based Registry).

...and since we can't seem to repeat this enough...

*Never ever* do a build and sysgen on the build menu. Better yet, right
click the menu bar, choose Customize, then click the Build OS menu,
select Build & sysgen and *delete* that option from the build menu.

Update: Inzwischen hat Michel hierzu einen eigenen Blog-Artikel verfaßt: What to build when...

Nach der Erstellung des Betriebssystems verbleiben leider viele Dateien im Ordner %TEMP%. Diesen sollte man daher von Zeit zu Zeit überprüfen und bereinigen.

Übertragen des Runtime-Images auf das Gerät

Wie man das Gerät über Ethernet mit dem Platform Builder Entwicklungsrechner verbindet, wird im "eBox-4300 Windows Embedded CE 6.0 R2 JumpStart Guide" genau erklärt. Ab und zu schlägt bei mir allerdings der Befehl "Attach Device" fehl oder es dauert eine kurze Zeit bis der Download des OS Images beginnt.

Erstellung eines deutschen Tastaturtreibers für Windows Embedded CE 6.0

Auch wenn man ein deutschsprachiges OS Design erstellt, steht nur Englisch als Eingabesprache zur Verfügung. Man muß sich einen deutschen Tastaturtreiber selber erstellen. Dazu benötigt man keine Programmiererfahrungen. Mit dem "Keyboard Layout Generator Tool" kann man sich die notwendigen Quelltextdateien erstellen lassen.

Das Tool beschafft sich die Informationen aus einer Windows XP Tastatur Layout DLL. Den Namen dieser DLL für ein deutsches Layout findet man in der Windows XP-Registry unter folgendem Schlüssel:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layouts\00000407]
"Layout File"="KBDGR.DLL"

Die Datei befindet sich im Ordner "C:\WINDOWS\system32".
Das Keyboard Layout Generator Tool ruft man daher wie folgt auf:

"%_PUBLICROOT%\COMMON\OAK\BIN\I386\kbdgen.exe" "C:\WINDOWS\system32\kbdgr.dll" -o Kbdgr -i 00000407

Über den Suchbegriff "kbdgen.exe" findet man in der Onlinehilfe nähere Informationen zum Tool.
Anders als in der Hilfe angegeben, ist der Parameter -o erforderlich.

Mit der oben aufgeführten Kommandozeile werden die drei folgenden Dateien erstellt:

KbdgrDL.cpp (Device layout)
KbdgrIL.cpp (Input language)
Kbdgr.reg (Registry entries)

Mit diesen Dateien läßt sich ein deutsches Tastaturlayout für Windows CE erstellen.
Es gibt drei Möglichkeiten, dieses in das OS Design zu übernehmen:

1. Man erstellt eine separate DLL mit dem deutschen Tastaturlayout. Dieses sekundäre Layout kann dann in der Systemsteuerung ausgewählt und nach einem Softreset verwendet werden. Diese Methode kann daher nicht angewandt werden, wenn das Gerät kein Softreset unterstützt oder die Registry nicht persistent vorhält.
2. Man ergänzt die bestehende englische Tastatur Layout DLL um das deutsche Layout. Auch hier wählt man die Eingabesprache über die Systemsteuerung und kann sie nach einem Warmstart nutzen.
3. Man ersetzt die englische Tastatur Layout DLL durch die entsprechende deutsche DLL. Dadurch ist das neue Tastaturlayout sofort aktiv.

Nachfolgend wird Methode 3 beschrieben. Die Prozedur ist etwas aufwendiger als notwendig, läßt aber alle Dateien im PUBLIC-Ordner unberührt und man kann mit minimalen Änderungen auch die Methoden 1 und 2 umsetzen.

Tastaturtreiber klonen

Den Ordner "%_PUBLICROOT%\COMMON\OAK\DRIVERS\KEYBD" in den Ordner "%_TARGETPLATROOT%\SRC\DRIVERS" kopieren.
Die Dirs-Datei "%_TARGETPLATROOT%\SRC\DRIVERS\dirs" im Texteditor öffnen und um den neuen Ordner "KEYBD" erweitern.

Im Ordner "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD" alle Unterordner bis auf "DEVICELAYOUTS", "DLL" und "INPUTLANGS" löschen.
In der Dirs-Datei "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD\dirs" alle gelöschten Ordner entfernen.

Im Ordner "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD\DEVICELAYOUTS" alle Unterordner bis auf "PS2_AT" löschen.
In der Dirs-Datei "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD\DEVICELAYOUTS\dirs" alle gelöschten Ordner entfernen.

Im Ordner "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD\DEVICELAYOUTS\PS2_AT" alle Unterordner bis auf "00000409" löschen.
Den Ordner "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD\DEVICELAYOUTS\PS2_AT\00000409" in "00000407" umbenennen.
In der Dirs-Datei "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD\DEVICELAYOUTS\PS2_AT\dirs" alle gelöschten Ordner entfernen und den Ordner "00000409" in "00000407" umbenennen.

Im Ordner "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD\DLL" alle Unterordner bis auf "KBD8042US" löschen.
Den Ordner "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD\DLL\KBD8042US" in "KBD8042GR" umbenennen.
In der Dirs-Datei "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD\DLL\dirs" alle gelöschten Ordner entfernen und den Ordner "KBD8042US" in "KBD8042GR" umbenennen.

Im Ordner "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD\INPUTLANGS" alle Unterordner bis auf "0409" löschen.
Den Ordner "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD\INPUTLANGS\0409" in "0407" umbenennen.
In der Dirs-Datei "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD\INPUTLANGS\dirs" alle gelöschten Ordner entfernen und den Ordner "0409" in "0407" umbenennen.

Die Datei "%_PUBLICROOT%\COMMON\OAK\INC\kbdus.def" in den Ordner "%_TARGETPLATROOT%\SRC\INC" kopieren.
Die Datei "%_TARGETPLATROOT%\SRC\INC\kbdus.def" in "kbdgr.def" umbenennen.
Die Datei "%_TARGETPLATROOT%\SRC\INC\kbdgr.def" in einem Texteditor öffnen und wie folgt ändern:

LIBRARY LAYOUTMANAGER

EXPORTS
KeybdDriverInitializeEx
KeybdDriverPowerHandler
KeybdDriverGetInfo
KeybdDriverSetMode
KeybdDriverInitStates
KeybdDriverVKeyToUnicode
KeybdDriverMapVirtualKey

LayoutMgrGetKeyboardType
LayoutMgrGetKeyboardLayout
LayoutMgrGetKeyboardLayoutName
LayoutMgrGetKeyboardLayoutList
LayoutMgrLoadKeyboardLayout
LayoutMgrActivateKeyboardLayout

IL_00000407
PS2_AT_00000407

Die selbst erstellte Quellcodedatei "KbdgrDL.cpp" in den Ordner "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD\DEVICELAYOUTS\PS2_AT\00000407" verschieben und in "kbdgr.cpp" umbenennen.
Die Datei "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD\DEVICELAYOUTS\PS2_AT\00000407\kbdus.cpp" löschen.
Die Datei "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD\DEVICELAYOUTS\PS2_AT\00000407\kbdus.def" in einem Texteditor öffnen und den Inhalt wie folgt ändern:

LIBRARY kbdgr

EXPORTS
PS2_AT_00000407
IL_00000407

Die Datei "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD\DEVICELAYOUTS\PS2_AT\00000407\kbdus.def" in "kbdgr.def" umbenennen.
Die Sources-Datei "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD\DEVICELAYOUTS\PS2_AT\00000407\sources" in einem Texteditor öffnen und wie folgt ändern:

TARGETDEFNAME=kbdgr
TARGETNAME=$(TARGETDEFNAME)_lib
TARGETTYPE=LIBRARY

DEFFILE=$(TARGETDEFNAME).def

PREPROCESSDEFFILE=1
RELEASETYPE=PLATFORM
WINCEOEM=1

SOURCES=kbdgr.cpp

Die selbst erstellte Quellcodedatei "KbdgrIL.cpp" in den Ordner "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD\INPUTLANGS\0407" verschieben und in "il_0407.cpp" umbenennen.
Die Datei "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD\INPUTLANGS\0407\il_0409.cpp" löschen.
Die Sources-Datei "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD\INPUTLANGS\0407\sources" wie folgt ändern:

TARGETNAME=InputLang_0407
TARGETTYPE=LIBRARY

RELEASETYPE=PLATFORM
WINCEOEM=1

SOURCES=il_0407.cpp

Die Sources-Datei "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD\DLL\KBD8042GR\sources" wie folgt ändern:

DOSYSGEN=1

SYNCHRONIZE_DRAIN=1

DEFFILE=$(_TARGETPLATROOT)\SRC\INC\kbdgr.def

TARGETNAME=Kbd8042GR
TARGETTYPE=DYNLINK
DLLENTRY=DllMain

RELEASETYPE=PLATFORM
WINCEOEM=1

TARGETLIBS=\
   $(_SYSGENSDKROOT)\lib\$(_CPUINDPATH)\coredll.lib \
   $(_SYSGENOAKROOT)\lib\$(_CPUINDPATH)\ceddk.lib

SOURCELIBS=\
   $(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\PS2_8042_KbdCommon.lib \
   $(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\LayoutManager.lib \
   $(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\KeybdIst.lib \
   $(_TARGETPLATROOT)\lib\$(_CPUINDPATH)\kbdgr_lib.lib \
   $(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\NumPadRmp.lib \
   $(_TARGETPLATROOT)\lib\$(_CPUINDPATH)\InputLang_0407.lib

SOURCES=PDDList.cpp

Die selbst erstellte Registry-Datei "Kbdgr.reg" in den Ordner "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD" verschieben.
Die Datei "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD\Kbdgr.reg" in einem Texteditor öffnen und wie folgt ändern:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Layouts\00000407]
"Layout File"="Kbd8042GR.dll"
"Layout Text"="Deutsch"
"PS2_AT"="Kbd8042GR.dll"

[HKEY_CURRENT_USER\Keyboard Layout\Preload\1]
@="00000407"

Diese Registry-Datei wird nur dann in dieser Form benötigt, wenn der deutsche Tastaturtreiber als sekundärer Treiber konfiguriert wird und die Treiberdatei "Kbd8042GR.dll" zusätzlich zum englischen Treiber "kbdmouse.dll" in das Runtime-Image aufgenommen wird. Die deutsche Eingabesprache kann dann in der Systemsteuerung ausgewählt und nach einem Warmstart genutzt werden (siehe oben).

Tastaturtreiber in das OS Design einbinden

Damit der deutsche Tastaturtreiber als Standard-Eingabesprache geladen wird, muß im Registry-Schlüssel "HKEY_CURRENT_USER\Keyboard Layout\Preload" das Gebietsschema "00000407" als Standardeintrag konfiguriert sein. Über die Sprachdatei "%_PUBLICROOT%\COMMON\OAK\FILES\INTLTRNS\0407\common.str" wird der Eintrag jedoch immer auf "00000409" gesetzt.
Entweder modifiziert man die "common.str" oder legt im Ordner "%_TARGETPLATROOT%\FILES\INTLTRNS\0407" eine Textdatei mit dem Dateinamen "keybd.str" und folgendem Inhalt an:

// Setting up German as the default HKL.
#define LOC_HKL_DEFAULT "00000407"

Jetzt muß noch die "platform.reg" an das deutsche Gebietsschema angepaßt werden. Da wir in diesem Fall den originalen Treiber "kbdmouse.dll" ersetzen wollen, reicht es nicht aus, zusätzlich nur die oben genannte "Kbdgr.reg" in die "platform.reg" einzubinden.
Da auch im Schlüssel "HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\KEYBD" auf die Bibliothek "kbdmouse.dll" Bezug genommen wird ("DriverName") und dort weitere Parameter für die Tastatur definiert werden, sollte unser deutscher Treiber ebenfalls beim Einbinden in das Runtime-Image nach "kbdmouse.dll" umbenannt werden (siehe weiter unten). Dadurch bleibt die Konfigurationsdatei portabel, falls man das OS Design doch einmal wieder in Englisch erstellen möchte.
Da die Registry-Dateien sehr viel Direktiven aufweisen, ist es nicht einfach, die richtigen Einträge festzulegen. Am Besten, man fügt eine zusätzliche Direktive für $(LOCALE)==0407 ein. Aufgelöst sollte dann folgender Eintrag in der Registry stehen:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Layouts\00000407]
"Layout File"="kbdmouse.dll"
"Layout Text"="Deutsch"
"PS2_AT"="kbdmouse.dll"

Um den Treiber "Kbd8042GR.dll" als "kbdmouse.dll" in das Runtime-Image einzubinden, muß die "platform.bib" entsprechend geändert werden. Auch hier verwendet man am Besten eine Direktive, die je nach ausgewählter Sprache den englischen oder den deutschen Tastaturtreiber in das Runtime-Image übernimmt:

IF LOCALE=0407 !
; @CESYSGEN IF CE_MODULES_8042KEYBOARD
    kbdmouse.dll  $(_FLATRELEASEDIR)\Kbd8042US.dll  NK SHK
; @CESYSGEN ENDIF CE_MODULES_8042KEYBOARD
ENDIF LOCALE=0407 !
IF LOCALE=0407
; @CESYSGEN IF CE_MODULES_8042KEYBOARD
    kbdmouse.dll  $(_FLATRELEASEDIR)\Kbd8042GR.dll  NK SHK
; @CESYSGEN ENDIF CE_MODULES_8042KEYBOARD
ENDIF LOCALE=0407

Tastaturtreiber erstellen

Um die Erstellung des Tastaturtreibers zu testen, muß man nicht das gesamte OS Design neu erstellen (Sysgen). Es reicht, wenn man im Projektmappen-Explorer den Ordner "KEYBD" markiert und dann im Kontextmenü den Befehl "Build" oder (wenn notwendig) "Rebuild" ausführt.

Wurde der Treiber fehlerfrei erstellt, muß sich die Bibliothek "Kbd8042GR.dll" im Ordner "%_TARGETPLATROOT%\target\x86\<retail|debug>" befinden.
Mit dem Tool Dependency Walker kann dann überprüft werden, ob der Treiber tatsächlich die Funktionen "IL_00000407" und "PS2_AT_00000407" exportiert.
Falls nicht (oder wenn die Treiberdatei gar nicht erst erzeugt wurde) sollte man überprüfen, ob sich zumindest die statischen Bibliotheken "kbdgr_lib.lib" und "InputLang_0407.lib" im Ordner "%_TARGETPLATROOT%\lib\x86\<retail|debug>" befinden.

Bietet das neu erstellte Runtime-Image weiterhin nur das englische Tastaturlayout an, sollte man überprüfen, ob wirklich die richtige "kbdmouse.dll" ins Image übernommen wurde und ob alle Registry-Einträge korrekt sind.

Serielle ActiveSync-Verbindung zwischen Desktop-PC und CEPC

Auch nach Einbinden der ActiveSync-Komponente in das eigene OS-Design will eine ActiveSync-Verbindung über ein Nullmodem-Kabel oft nicht sofort gelingen.

Dies liegt in der Regel daran, daß bei vielen Plattformen der COM1-Port als Debug-Port konfiguriert ist und/oder daß das RS-232 Nullmodemkabel nicht korrekt beschaltet ist.

Normalerweise gibt Windows CE den seriellen Debug-Port frei, wenn man das System per loadcepc.exe /C:0 bootet, statt z.B. mit dem Parameter /C:1 den ersten COM-Port für die Debugausgabe zu aktivieren. Hat man jedoch nicht alle Updates installiert, kann der Debug-Port auf Grund eines alten Fehlers dennoch blockiert sein.

Ein Hinweis auf einen konfigurierten, seriellen Debug-Port erhält man durch einen Blick in die platform.reg. Normalerweise wird dem Kommunikationsanschluß COM1 die E/A-Basisadresse 03F8 und dem COM2-Port die E/A-Basisadresse 02F8 zugewiesen. Ist jedoch unter [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial] "IoBase"=dword:02F8 eingetragen und unter [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial2] "IoBase"=dword:03E8 vermerkt, wurde die Adresszuordnung der Ports verschoben. Statt COM1, COM2, COM3, COM4, usw. wurde "DEBUG", COM1, COM2, COM3, usw. registriert. In diesem Fall verwendet man einfach den zweiten COM-Port für die Verbindung zum Desktop-Rechner oder man modifiziert die Plattform, falls das Gerät nur eine serielle Schnittstelle besitzt.

Für die PC-Verbindung wird automatisch ein Eintrag `Desktop @ 19200` in das "Telefonbuch" des Gerätes eingetragen und standardmäßig für die Desktopverbindung verwendet (siehe Systemsteuerung/PC-Verbindungseigenschaften). Der Hardware-Port wird jedoch nicht mit gespeichert. Welcher Port tatsächlich verwendet wird (COM1: oder ggf. COM2:) kann nicht so einfach überprüft werden, da die Verbindung durch das Backquote nicht unter Netzwerk- und DFÜ-Verbindungen erscheint.
Konfiguriert man dort eine eigene PC-Direktverbindung, kann man jedoch erkennen, welches Gerät (Serielles Kabel an COM1: oder Serielles Kabel an COM2:) als Standardanschluß vorgegeben wird. Wie in der Onlinehilfe beschrieben, sollte man bei beiden Rechnern die gleiche Baudrate wählen. Bei einer zu hohen Übertragungsrate kommt ebenfalls keine Verbindung zustande.

ActiveSync verwendet die Trägersignalerkennung (Pin 1 - CD) der RS-232C-Schnittstelle. Bei vielen Nullmodemkabeln fehlen jedoch die dazu notwendigen Brücken zwischen den Pins 1 und 6 der beiden DB9-Buchsen. Das Kabel muß wie folgt beschaltet sein:

5 - 5 (Gnd - Gnd)
2 - 3 (RD - TD)
3 - 2 (TD - RD)
7 - 8 (RTS - CTS)
8 - 7 (CTS - RTS)
4 - 1, 6 (DTR - CD, DSR)
1, 6 - 4 (CD, DSR - DTR)

Da die beiden Pins 1 und 6 direkt übereinander liegen, kann man sie recht einfach miteinander verlöten. Wenn die Pins #9 miteinander verbunden sind, muß man sie nicht unbedingt trennen.

Hat man beide Rechner korrekt mit dem seriellen Kabel verbunden und sichergestellt, daß der verwendete COM-Port am Desktop PC für ActiveSync freigegeben ist, kann man eine Verbindung herstellen und eine Synchronisierungspartnerschaft einrichten. Mit dem hier beschriebenen Kabel startet der ActiveSync-Client automatisch.

Seltsam: Obwohl die Verbindung steht und genutzt werden kann, meldet ActiveSync gelegentlich nach kurzer Zeit einen Fehler (den man einfach wegklicken kann)...

Mit Hilfe der seriellen ActiveSync-Verbindung können jetzt auch die Remote Tools unabhängig vom Platform Builder über die Core Connectivity-Infrastruktur verwendet werden. Im Platform Manager wählt man dazu AvtiveSync als Startup Server und TCP/IP als Transport.

Tips und Tricks zur ICOP eBox-4300 mit Windows Embedded CE 6.0 R2

1. Standby aktivieren

Im Gegensatz zum Vortex86SX BSP der ICOP eBox-2300SX wurden im VIA BSP und damit auch im ICOP eBox-4300 BSP ein paar Power Management-Routinen (Standby/Ausschalten) implementiert.

In der Datei %_TARGETPLATROOT%\src\x86\COMMON\power\power.c kann man ganz oben zwischen "Suspend", "Power Off", und "Screen Off" wählen:

BOOL bPowerOff = 1; // 0 Suspend, 1 Power Off, 2 Screen Off

Setzt man bPowerOff auf 0, aktiviert man das Standardverhalten des CEPC. Hier wird lediglich die CPU angehalten. Der Wert 2 sorgt dafür, daß zusätzlich auch der Bildschirm ausgeschaltet wird. Weist man bPowerOff den Wert 1 zu, wird das System heruntergefahren und das Gerät schaltet sich aus.

Sollte weder der Standby-Modus noch das Ausschalten sauber funktionieren, hilft eventuell eine Aktualisierung der Datei %_TARGETPLATROOT%\SRC\X86\COMMON\OTHER\HALSCI.c aus dem neueren VX800 Board Support Package.

Update: Möglicherweise liegt es an den Variablen dwGPIOSTS und dwSusTo in dieser Datei, die beide ohne Initialisierung verwendet werden. In älteren Versionen dieser Datei befand sich dort noch der VIA WCE X86 System Control Interrupt (SCI) Handler for Persistent Registry & Power Management. Dessen Entfernung wurde leider sehr unsauber durchgeführt. Die Variablen sollten wie folgt vorbelegt werden:

WORD dwGPIOSTS = 0, dwSusTo = 0;
DWORD AutoConfig = 1, IrqSetting = 9, dwSLPBTN = 1;

Damit der Menüpunkt "Standbymodus" im Startmenü erscheint, muß man in der platform.reg den Wert des Eintrags "Suspend" im Registrierungsschlüssel [HKEY_LOCAL_MACHINE\Explorer] von 0 auf 1 ändern.

2. Optimale Bildschirmauflösung gemäß DDC

Aktiviert man in der platform.reg bzw. ddrawcle.reg den Eintrag "SetBestResolutionByDDC", ermittelt der Grafiktreiber anhand der vom Bildschirm übermittelten DDC-Werte die optimale Display-Auflösung und verwendet diese beim Booten von Windows CE. Unterstützt das Gerät kein Display Data Channel, verwendet der Treiber allerdings nur die Standardauflösung 640x480x16 60 Hz.

[HKEY_LOCAL_MACHINE\Drivers\Display\VIA]
"SetBestResolutionByDDC"=dword:1

3. Deutschsprachige Anzeige von USB-Massenspeicher im Explorer

In der platform.reg wurde für USB-Massenspeichergeräte ein eigener Name definiert. Leider nur in englischer Sprache. Um ihn auch in Deutsch zu erhalten, ändert man die platform.reg wie folgt:

[HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\USBHDProfile]
   "Name"="USB Hard Disk Drive"
#if $(LOCALE)==0407
   "Folder"="USB-Massenspeicher"
#else
   "Folder"="USB Storage"
#endif

4. Speicherort der Registry ändern

Im BSP der eBox wurde für die Hive-basierte Registrierungsdatei der Ordner "\Registry" vorgegeben. Will man für die Registry nicht unbedingt einen eigenen Ordner haben, kann man diese - wie üblich - in "Documents and Settings" anlegen lassen:

[HKEY_LOCAL_MACHINE\init\BootVars]
"SystemHive"="Documents and Settings\\system.hv"
"ProfileDir"="Documents and Settings"
"DefaultUser"="default"

Den Eintrag "DefaultUser" sollte man von "User" auf "default" zurücksetzen, da sonst das System bei aktiviertem Kennwortschutz nicht mehr aus dem Suspend zurückkehren kann. Hier handelt es sich um einen noch immer nicht behobenen Fehler in Windows CE.

5. Start- und Suchseite im Internet-Explorer ändern

In der platform.reg zur eBox wurde die Homepage der ICOP Tech. als Startseite definiert. Wer möchte, kann hier seine eigene Start- und Suchseite festlegen:

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
"Start Page"="http://www.wolfgang-rolke.de/"
"Search Page"="http://www.google.de/"

Alternativ kann man diesen Eintrag auch aus der platform.reg löschen und statt dessen der project.reg hinzufügen.

6. Benutzerdefinierte Einstellungen

Die project.reg ist der richtige Ort für benutzerdefinierte Einstellungen. Die hier vorgenommenen Einstellungen überschreiben die Standardwerte des Betriebssystems (common.reg, ie.reg, wceshellfe.reg, usw.), haben aber eine niedrigere Priorität als die Einträge in der platform.reg.

Die nachfolgenden Einstellungen habe ich z.B. für mein Projekt vorgenommen:

; Gerätename ändern
[HKEY_LOCAL_MACHINE\Ident]
;"Name"=LOC_DEFAULTDEVICENAME
;"Desc"=LOC_DEFAULTDEVICEDESC
"Name"="eBox4300"
"Desc"="ICOP eBox-4300"

; Statusleiste im Explorer anzeigen
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\StatusBar]
"ShowStatusBar"=dword:1

; Dateierweiterungen und Systemdateien anzeigen
[HKEY_LOCAL_MACHINE\Explorer]
"ShowSys"=dword:1
"ShowExt"=dword:1

; ClearType aktivieren
[HKEY_LOCAL_MACHINE\System\Gdi\ClearType]

; Verknüpfungen im Internet-Explorer immer unterstreichen
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
"Anchor Underline"="yes"

7. Desktop Farbschema für Windows XP ähnliches Skin

Hat man dem OS Design den Katalogeintrag "Windows XP-like Sample Skin" (SYSGEN_XPSKIN) hinzugefügt, wird auch das Farbschema entsprechend geändert.
Allerdings wird dieses Schema nicht in der Registry hinterlegt, so daß man es über die Systemsteuerung auswählen kann. Ändert man nun irgend etwas an den Anzeigeeigenschaften, wird wieder das normale, dunkelgraue Windows CE-Schema aktiviert.

Um das XP-Farbschema der Registry hinzuzufügen und als Standard festzulegen, ergänzt man die project.reg um folgende Einträge:

[HKEY_LOCAL_MACHINE\SYSTEM\GWE]
"SysColor"=hex:\
   00,00,00,00,80,80,80,00,00,00,00,00,00,00,00,00,EF,EB,DE,00,FF,FF,FF,00,\
   00,00,00,00,00,00,00,00,00,00,00,00,FF,FF,FF,00,C0,C0,C0,00,C0,C0,C0,00,\
   80,80,80,00,00,00,00,00,FF,FF,FF,00,EF,EB,DE,00,AD,AA,9C,00,80,80,80,00,\
   00,00,00,00,00,00,00,00,FF,FF,FF,00,73,6D,63,00,FF,FF,FF,00,00,00,00,00,\
   FF,FF,E1,00,EF,EB,DE,00,00,00,00,00

[HKEY_CURRENT_USER\ControlPanel\Appearance]
"Current"="Windows XP"

[HKEY_CURRENT_USER\ControlPanel\Appearance\Schemes\XPUI]
"Settings"=hex:\
   FF,FF,00,00,FA,FA,F8,00,80,80,80,00,00,00,80,00,80,80,80,00,EB,E9,DE,00,\
   FF,FF,FF,00,00,00,00,00,00,00,00,00,00,00,00,00,FF,FF,FF,00,EB,E9,DE,00,\
   EB,E9,DE,00,80,80,80,00,00,00,00,00,FF,FF,FF,00,EB,E9,DE,00,B1,AA,7E,00,\
   80,80,80,00,00,00,00,00,C0,C0,C0,00,FA,FA,F8,00,7D,77,4D,00,F5,F4,EF,00,\
   00,00,00,00,FF,FF,FF,00,EB,E9,DE,00,00,00,00,00,10,84,D0,00,B5,B5,B5,00
"DisplayName"="Windows XP"

Da ich eine graue Kachel als Hintergrundbild verwende, hat das oben aufgeführte Farbschema einen grauen Desktop und aktivierte Elemente erscheinen in Schwarz. Informationen über die Zusammensetzung des Eintrags SysColor findet man in der Onlinehilfe unter dem Titel "Customizing System Colors".

Das Hintergrundbild habe ich wie folgt als Standard definiert:

[HKEY_CURRENT_USER\ControlPanel\Desktop]
"Wallpaper"="\\Windows\\Tile.bmp"
"Tile"=dword:00000001

Damit die BMP-Datei dem Runtime Image hinzugefügt wird, habe ich sie im Ordner %_PROJECTOAKROOT%\files abgelegt und die project.bib entsprechend ergänzt:

FILES
;Name    Path                        Memory Type
;------- --------------------------- -----------
Tile.bmp $(_FLATRELEASEDIR)\tile.bmp NK

Die Dateien im Ordner %_PROJECTOAKROOT%\files werden automatisch in den Ordner %_FLATRELEASEDIR% kopiert.

8. MFC- und ATL-Bibliotheken dem OS Design hinzufügen

Damit die Bibliotheken in das Runtime Image übernommen werden, müssen diese vor dessen Erstellung in den Ordner %_FLATRELEASEDIR% kopiert werden und in der project.bib eingetragen sein.

Im Dialogfeld "OS Design Property Pages" des Platform Builders können benutzerdefinierte Aktionen zu bestimmten Zeitpunkten im Erstellungsprozess festgelegt werden. Für das Kopieren der DLL's ist "Pre-Make Image" der richtige Ort bzw. Zeitpunkt:

OS Design Property Pages: Custom Build Actions: Build step: Pre-Make Image

Hier kann man z.B. die folgenden Aktionen definieren:

copy "C:\Windows CE Tools\wce300\hpc2000\atl\lib\x86\atlce300.dll" %_FLATRELEASEDIR%\atlce300.dll
copy "C:\Windows CE Tools\wce300\hpc2000\mfc\lib\x86\olece300.dll" %_FLATRELEASEDIR%\olece300.dll
copy "C:\Windows CE Tools\wce300\hpc2000\mfc\lib\x86\mfcce300.dll" %_FLATRELEASEDIR%\mfcce300.dll
copy "C:\Windows CE Tools\wce300\hpc2000\mfc\lib\x86\l.deu\mfcce300i.dll" %_FLATRELEASEDIR%\mfcce300i.dll
copy "C:\Programme\Windows CE Tools\wce500\STANDARDSDK_500\Atl\Lib\x86\atlce400.dll" %_FLATRELEASEDIR%\atlce400.dll
copy "C:\Programme\Windows CE Tools\wce500\STANDARDSDK_500\Mfc\Lib\x86\olece400.dll" %_FLATRELEASEDIR%\olece400.dll
copy "C:\Programme\Windows CE Tools\wce500\STANDARDSDK_500\Mfc\Lib\x86\mfcce400.dll" %_FLATRELEASEDIR%\mfcce400.dll
copy "C:\Programme\Windows CE Tools\wce500\STANDARDSDK_500\Mfc\Lib\x86\L.deu\mfcce400i.dll" %_FLATRELEASEDIR%\mfcce400i.dll

Es ist darauf zu achten, die Pfade in Anführungszeichen zu setzen. Als Quelle wurden die Laufzeitbibliotheken aus dem HPC2000-SDK sowie dem Standard-SDK 5.0 verwendet. Die Einträge in der project.bib sehen dann wie folgt aus:

FILES
;Name         Path                             Memory Type
;------------ -------------------------------- -----------
atlce300.dll  $(_FLATRELEASEDIR)\atlce300.dll  NK
olece300.dll  $(_FLATRELEASEDIR)\olece300.dll  NK
mfcce300.dll  $(_FLATRELEASEDIR)\mfcce300.dll  NK
mfcce300i.dll $(_FLATRELEASEDIR)\mfcce300i.dll NK
atlce400.dll  $(_FLATRELEASEDIR)\atlce400.dll  NK
olece400.dll  $(_FLATRELEASEDIR)\olece400.dll  NK
mfcce400.dll  $(_FLATRELEASEDIR)\mfcce400.dll  NK
mfcce400i.dll $(_FLATRELEASEDIR)\mfcce400i.dll NK

Einfacher wäre es natürlich, wenn man die Bibliotheken als Komponente dem OS Design hinzufügen könnte. Mit dem Tool CEFileWiz von Mike Hall kann man sich selber eigene Katalogeinträge erstellen.
Sollte das Programm Windows Embedded CE 6.0 nicht als Betriebssystem anbieten, liegt dies evtl. an Installationsresten in der Registry, die von einer Vorgängerversion stammen (z.B. von einer Testversion von Windows CE 5.0).

9. Größe des Object Store festlegen

Nutzt man ein ROM-only Dateisystem mit Hive-basierter Registry, dateibasierten Datenbanken und einem dateibasierten Papierkorb, benötigt man für den Objektspeicher nur noch wenig Speicherplatz. Die Aufteilung zwischen Programmspeicher und Objektspeicher wird über die Variable FSRAMPERCENT definiert. Wie sich der Wert dieser Variablen zusammensetzt wird in der Onlinehilfe beschrieben.

Möchte man den Objektspeicher zugunsten des Programmspeichers auf ein Minimum reduzieren, kann man in den Konfigurationseigenschaften die Umgebungsvariable IMGTINYFSRAM=1 definieren. Diese findet sich in der Datei %_TARGETPLATROOT%\FILES\config.bib wieder und weist der Variablen FSRAMPERCENT den Wert 0x00000080 zu. Dies entspricht 1 MB RAM für den Object Store.

IF IMGPERSISTENTSTORAGE
   FSRAMPERCENT=0x00000010
ENDIF

IF IMGTINYFSRAM
   FSRAMPERCENT=0x00000080
ENDIF

10. Dateibasierten Papierkorb verwenden

Der Papierkorb für gelöschte Dateien befindet sich normalerweise im Objektspeicher. Mit dem folgenden Eintrag in die Registry werden die Informationen hingegen auf der Disk gespeichert:

[HKEY_LOCAL_MACHINE\Explorer]
"RecycleBinEnableDBFile"=dword:1
"RecycleBinFlush"=dword:1

11. Austausch des Runtime Images (nk.bin) auf der SSD der eBox

Möchte man die nk.bin auf der Solid State Disk durch eine eigene Version ersetzen und hat die Disk im OS Design als Wurzel im Dateisystem konfiguriert sowie die Registry als Hive angelegt, muß man vor dem Booten erst die Ordner und Dateien des alten Systems löschen. Andernfalls wird ggf. auf die alten, nicht mehr gültigen Daten (Dateien, Datenbanken, Registry) zugegriffen.

Mit den DOS-Befehlen DEL und RD ist dies jedoch eine Qual, da sehr viele Dateien und Ordner mit den Attributen "System", "Hidden" und "Readonly" versehen sind. Im Wurzelverzeichnis der SSD befindet sich jedoch das Utility DELTREE.EXE, mit dem man unabhängig von den Attributen ein Verzeichnis inklusive aller Unterverzeichnisse schnell und vollständig löschen kann. Es gibt nur eine Sicherheitsabfrage.

Ich habe mir eine Batchdatei cleanup.bat erstellt. Man könnte den Task aber auch in das Startmenü für den Boot Loader aufnehmen.

@ECHO OFF
DELTREE \WINDOWS \DOCUME~1 \ANWEND~1 \PROGRA~1 \MYDOCU~1 \TEMP
DEL \SYSTEM~1.LNK /P

Erstellung eines plattformspezifischen Software Development Kits

Mit Hilfe eines Software Development Kits (SDK) können Drittentwickler Software passend für die jeweilige Plattform entwickeln. Ein solches SDK enthält genau nur die API-Funktionen, die auch im dazugehörigen Runtime Image des Gerätes implementiert wurden.
Das SDK ermöglicht es zudem, selbst erstellte Programme auf das Gerät zu übertragen und zu testen. Steht die Hardware noch nicht zur Verfügung, kann man seine Programme innerhalb eines bereitgestellten Emulator Images ausführen.

Damit ein SDK angelegt und erstellt werden kann, muß ein fehlerfreies Release Build der Plattform vorliegen. Um dem SDK auch ein Runtime Image für den Geräteemulator beizufügen, ist eine zusätzliche Konfiguration im OS Design erforderlich.

Dazu fügt man dem OS Design das Board Support Package des Geräteemulators hinzu ("Catalog Items View", Option "Device Emulator: ARMV4I"). Dieses BSP steht nur bei installierter Ziel-CPU ARMV4I zur Verfügung. Es wird aber erst einmal vom OS Design ausgeschlossen (rotes Kreuz), da pro Konfiguration nur ein BSP aktiv sein kann. Jetzt darf man aber nicht den Fehler machen, das aktive BSP zu deaktivieren. Damit aktiviert man zwar das Emulator-BSP, löscht aber die Konfigurationseigenschaften des Geräte-BSP. Über die Projektmappenkonfiguration kann man hingegen bequem auf die Konfiguration "Device Emulator ARMV4I Release" umschalten. Jetzt erscheint beim Emulator-BSP das grüne Häkchen, während beim Geräte-BSP das rote Kreuz angezeigt wird.

Nun kann man die Konfigurationseigenschaften des Geräteemulators bearbeiten (Locale, Build Options, Environment, Custom Build Actions, usw.) und die "Parameter Files" editieren (project.bib, project.reg, usw.).
Der Geräteemulator erfordert keine speziellen Environment-Variablen. Bei den "Build Options" reicht die Option "Enable Ship Build". Im Falle der eBox4300-Plattform muß jedoch die ConMan_x86 Komponente vom Build ausgeschlossen werden. Dazu wählt man nicht etwa den entsprechenden Katalogeintrag ab. Denn dann würde man die Komponente auch aus der x86-Konfiguration des Gerätes herausnehmen. Statt dessen gibt es in der Kategorie OS Design Property Pages: Subproject Image Settings die Möglichkeit, ein Subproject von der Erstellung und der Aufnahme ins Image auszuschließen.

Das Geräteemulator-BSP enthält leider zwei Fehler, die das Autostartprogramm betreffen, welches die PC-Verbindung auf "Serial over DMA" konfiguriert. So wird die Verknüpfung zu diesem Programm nur dann im Autostartordner angelegt, wenn man eine Plattform für SmartPhone (IMGTPC) oder Pocket PC (IMGPPC) erstellt. Damit dies für alle Plattformen erfolgt, ändert man die Datei %_TARGETPLATROOT%\FILES\platform.dat wie folgt:

IF IMGPPC
{BEGIN MULTILANG}
Directory(LOC_%LANGID%_DIRWINDOWSSTARTUP):-File("DMAcnect.lnk","\Windows\DMAcnect.lnk")
{END MULTILANG}
ELSE
Directory(LOC_DIRWINDOWSSTARTUP):-File("DMAcnect.lnk","\Windows\DMAcnect.lnk")
ENDIF ; IMGPPC

Sobald das Programm gestartet wurde, wird die Verknüpfung wieder gelöscht. Damit dies auch in einem deutschsprachigen Emulator Image funktioniert, muß in der Datei %_TARGETPLATROOT%\SRC\APPS\DMACNCT\dmacnect.rc das in englischer Sprache hart kodierte Autostartverzeichnis entsprechend angepaßt werden.

Nach dem das Emulator Image erzeugt und getestet wurde, kann das SDK erstellt werden. Dies erfolgt in zwei Schritten. Über "Project: Add New SDK..." wird ein SDK dem OS Design hinzugefügt und konfiguriert und über "Build: Build All SDKs..." wird es schließlich erstellt.

Nachfolgend ein paar Hinweise zum Ausfüllen der SDK-Eigenschaftsseiten:

General

Der SDK-Name wird zur Anzeige des SDKs im Geräteemulator-Manager und in diversen Konfigurationsdialogfenstern verwendet. Auch der Installationsordner des SDKs wird so benannt. Der Produktname beschreibt das SDK bei der Installation, Deinstallation und erscheint in der EULA zum SDK. Die Produktversion und die Daten zum Unternehmen werden ebenfalls mit in die EULA übernommen.

Install

Hier kann man den Zielordner und den Dateinamen des SDK-Installationspaketes nach eigenen Wünschen festlegen.

CPU Families

Hier wählt man die CPU der Gerätekonfiguration und ARMV4I für die Geräteemulatorkonfiguration aus. Beim Übernehmen der Einstellungen kann es zu einer Fehlermeldung kommen, falls die Konfiguration einer CPU nicht genau spezifiziert wurde. In diesem Fall markiert man die entsprechende CPU und wählt nach Betätigen der Schaltfläche "Edit" die gewünschte Release-Konfiguration aus.

Development Languages

Hier wählt man beide Optionen aus (Native/Managed development support).

Emulation

Um das Emulator Image dem SDK hinzuzufügen, wählt man hier als Konfiguration "Device Emulator ARMV4I Release" aus. Dem Geräteemulator sollte mindestens 128 MB, besser 192 MB, Speicher zugeordnet werden. Die Bildschirmauflösung darf maximal 800x600x16 BPP betragen.

Schließt man das SDK-Eigenschaftsfenster mit OK, erscheint die Konfigurationsdatei im Projektmappen-Explorer unterhalb des Ordners "SDKs". Über das Kontextmenü kann das Software Development Kit jetzt erstellt werden.

Nach der Installation des SDKs steht die Plattform in Microsoft Visual Studio 2005, im Connectivity Manager und im Geräteemulator-Manager zur Verfügung.

Jedes Emulator-Image von Windows Embedded CE 6.0 läuft auf meinem Rechner übrigens mindestens um die Hälfte langsamer als ein Image, welches mit dem Device Emulator ARMV4I BSP unter Windows CE 5.0 erstellt wurde.

Ein kurzer Blick auf das Speicherabbild der ICOP eBox-4300

Mit Hilfe der Dateien config.bib, boot.bib und startup.asm kann man sich einen Überblick über das Speicherabbild einer Plattform verschaffen.

%_TARGETPLATROOT%\FILES\config.bib
%_TARGETPLATROOT%\SRC\BOOTLOADER\EBOOT\boot.bib
%_TARGETPLATROOT%\SRC\X86\COMMON\STARTUP\startup.asm

In der Binary Image Builder-Datei config.bib werden die Speicherbereiche des Kernels konfiguriert. In der boot.bib werden die Speicherbereiche des Bootloaders definiert. Und in der startup.asm wird festgelegt, wie physikalische Adressen auf virtuelle Adressen abgebildet werden.

Bei den MIPS- und SHx-Prozessoren erfolgt das Mapping zwischen physikalischen und virtuellen Adressen durch die CPU und den Kernel, bei den x86- und ARM-Prozessoren durch Einträge in die Tabelle OEMAddressTable:

_OEMAddressTable:
  dd  80000000h,  0  ; Mapping from 0x80000000 -> 0x00000000
  dd  20000000h      ; Size 512 MB
  dd  0,  0,  0      ; Last entry, all zeros

Für jeden Eintrag erzeugt der Kernel zwei virtuelle Adressbereiche. Im Falle des ICOP eBox4300 BSP wird der physikalische Adressbereich 0x00000000 bis 0x1FFFFFFF (512 MB) jeweils auf die virtuellen Kernel-Adressbereiche 0x80000000 bis 0x9FFFFFFF (cached) und 0xA0000000 bis 0xBFFFFFFF (non-cached) abgebildet. Achtung: Bei einer x86 CPU wird die Größe des Adressbereichs in Byte angegeben, bei einer ARM CPU hingegen in MB.

Die Datei config.bib definiert den Verwendungszweck der verschiedenen Speicherregionen einer Plattform. So kann man bestimmen, wie viel Speicher für das Betriebssystem verfügbar ist (RAMIMAGE), wieviel Speicher als Hauptspeicher zur Verfügung gestellt wird (RAM) und welche Speicherbereiche für spezielle Anwendungen reserviert werden (RESERVED).

MEMORY
; Name      Start     Größe     Typ
; -------   --------  --------  --------
  RAM       80C00000  1B000000  RAM       ; Hauptspeicher
  NK        80220000  009E0000  RAMIMAGE  ; Betriebssystemabbild
  EDBG_DMA  80200000  00020000  RESERVED  ; Ethernet DMA-Puffer
  BOOTARGS  801FFF00  00000100  RESERVED  ; Bootparameter
  REGRW     80150000  00012000  RESERVED  ; HDDREGSAVE
  DMA       80100000  00030000  RESERVED  ; Native DMA

CONFIG
  AUTOSIZE=ON

Hier wurde ab virtueller Adresse 0x80220000 (bzw. physikalischer Adresse 0x220000) 9,875 MB Speicher für das Betriebssystemabbild (nk.bin) festgelegt und diese Region als "NK" benannt. Der frei verfügbare Hauptspeicher "RAM" folgt ohne Lücke ab 0x80C00000 und ist 432 MB groß.
Um Flexibilität zu erhalten und den freien Speicher zu maximieren, kann die Grenze zwischen RAMIMAGE und RAM mit Hilfe des Schalters AUTOSIZE=ON automatisch an die Größe des Betriebssystemabbilds angepaßt werden. Der Hauptspeicher verringert sich dann bei größerem Betriebssystemabbild und umgekehrt.

Falls man die Größe des Hauptspeichers (hier 0x1B000000 = 432 MB) zu klein gewählt hat, könnte dennoch freies RAM ungenutzt bleiben. Diese Lücke nach oben ermittelt jedoch eine Funktion in der Datei %_TARGETPLATROOT%\SRC\X86\COMMON\MEMORY\memory.c und paßt die obere Speichergrenze entsprechend an. In der Debugausgabe wird dies wie folgt angezeigt:

OEM Extra DRAM Detected @ base = xBBC00000, size=4 MB
MainMemoryEndAddress = 0x9c000000

Auf die Speicherbereiche außerhalb von RAMIMAGE und RAM greift der Kernel nicht zu. Dennoch steht das Schlüsselwort RESERVED zur Verfügung, mit dem man zusätzliche Speicherbereiche definieren und somit organisieren kann. So kann z.B. vermieden werden, daß der gleiche Adressbereich für zwei verschiedene Anwendungen verwendet wird.
Im Beispiel oben werden für Native DMA 192 KB, für die Anwendung HDDRegSave 72 KB, für die Boot-Parameter 256 Byte und für den Ethernet DMA-Puffer 128 KB Speicher reserviert.

Für den Bootloader gibt es eine eigene Datei boot.bib.

MEMORY
; Name     Start     Größe     Typ
; -------  --------  --------  --------
  ETHDMA   00200000  00020000  RESERVED  ; Ethernet-Controller
  RAM      00150000  00070000  RAM       ; Bootloader RAM
  EBOOT    00130000  00020000  RAMIMAGE  ; Bootloaderabbild

; Total reserved area, which equals offset of the NK region in RAM
  dwReservedArea 00000000 00220000 FIXUPVAR

Da der Bootloader beim x86-Prozessor im Realmodus startet, werden hier physikalische Adressen verwendet. Der Aufbau und die Funktion der Datei ist darüber hinaus identisch mit der config.bib.

Um einen Gesamtüberblick zu erhalten, habe ich beide Speicherabbilder zusammengefügt:

Name      Start     Größe     Typ
-------   --------  --------  --------
RAM       80C00000  1B000000  RAM       ; Hauptspeicher
NK        80220000  009E0000  RAMIMAGE  ; Betriebssystemabbild
EDBG_DMA  80200000  00020000  RESERVED  ; Ethernet DMA-Puffer
ETHDMA    80200000  00020000  RESERVED  ; Ethernet-Controller
BOOTARGS  801FFF00  00000100  RESERVED  ; Bootparameter
REGRW     80150000  00012000  RESERVED  ; HDDREGSAVE
RAM       80150000  00070000  RAM       ; Bootloader RAM
EBOOT     80130000  00020000  RAMIMAGE  ; Bootloaderabbild
DMA       80100000  00030000  RESERVED  ; Native DMA

Wie man sieht, wurde der DMA-Puffer für den Ethernet-Controller in beiden BIB-Dateien an gleicher Adresse und mit gleicher Größe reserviert.
Die BOOTARGS-Region ist ein Speicherbereich, der für die Datenübertragung zwischen Bootloader und Kernel dient. Daher hätte ich ihn nicht nur in der config.bib eingetragen, sondern auch in der boot.bib.
Als nächstes fällt auf, daß sich der Speicherbereich für das VIA-Tool HddRegSave mit dem Bootloader RAM überschneidet. Würde man diese Komponente mit in das OS Design aufnehmen, müßte man prüfen, ob diese Überlappung wirklich so gewollt ist, unkritisch oder problematisch ist.
Die ersten 1024 KB von 0x80000000 bis 0x80100000 wurden nicht verplant.

Graphisch sieht die Memory Map so aus:

9BC0.0000 -+- 444 MB
           |
           | Hauptspeicher (432 MB)
           |
80C0.0000 -+ *auto-size*
           |
           | Betriebssystemabbild (10 MB)
           |
8022.0000 -+
           | Ethernet DMA-Puffer (128 KB)
8020.0000 -+
           | Bootparameter (256 B)
801F.FF00 -+
           | Bootloader RAM (448 KB)
8015.0000 -+
           | Bootloaderabbild (128 KB)
8013.0000 -+
           | Native DMA (192 KB)
8010.0000 -+
           |
8000.0000 -+- 0 MB

Mit diesen Informationen kann man das Speicherabbild optimieren, ein BSP von VIA portieren oder auch den in der Systemsteuerung angezeigten freien Hauptspeicher nachrechnen.

Beispiel: Zieht man von den 512 MB DDR2 RAM auf der Hauptplatine die 64 MB Bildschirmspeicher ab, erhält man die 448 MB Systemspeicher gemäß BIOS. Subtrahiert man davon die 2,125 MB (0x00000000-0x0021FFFF) für den Bootloader und den reservierten Speicherbereichen, verbleiben 445,875 MB für das Betriebssystemabbild und den freien Hauptspeicher. Bei einer nk.bin von z.B. 29,875 MB Größe würden dann 416 MB Hauptspeicher zur Aufteilung in Programm- und Objektspeicher mittels FSRAMPERCENT zur Verfügung stehen.

Unterstützung für Dateisynchronisierung auf externen Datenträgern

Befindet sich das Dateisystem nicht im Object Store, schlägt die Synchronisation von Dateien per ActiveSync (SYSGEN_AS_FILE) fehl, da auf einem externen FAT-Dateisystem die dazu notwendigen OID's nicht gespeichert werden. Erst nach Installation eines Dateisystemfilters werden die "Object identifier file mappings" in einer Datenbank (Replication Store) hinterlegt.

Mit den Variablen PRJ_ENABLE_FSEXTREPL und SYSGEN_FSREPLXFILT fügt man den Filter dem OS Design hinzu.
Zur Konfiguration steht folgender Registrierungsschlüssel zur Verfügung:

; HIVE BOOT SECTION
; @CESYSGEN IF CE_MODULES_FSREPLXFILT
[HKEY_LOCAL_MACHINE\System\StorageManager\Filters\fsreplxfilt]
  "ReplStoreHostVolume"=""
  "ReplStorePath"="\\Documents and Settings\\ReplStorVol"
  "ReplStoreName"="ReplStor"
  "ReplStoreDoImmaculate"=dword:0
  "ReplStoreCacheSize"=dword:0
  "NumDirsToExclude"=dword:6
  "DirsToExclude"=multi_sz:"\\Windows\\",\
  "\\Programme"\\,"\\Documents and Settings\\",\
  "\\Anwendungsdaten\\","\\Temp\\","\\Systemsteuerung.lnk"
; @CESYSGEN ENDIF CE_MODULES_FSREPLXFILT
; END HIVE BOOT SECTION

Mit dem Eintrag ReplStorePath wird der Dateipfad zum Replikationsspeicher festgelegt. Unter Windows CE kann nicht darauf zugegriffen werden. Über den Eintrag DirsToExclude soll man laut Doku einzelne Ordner oder Dateien von der Replikation ausschließen können. Im Beispiel oben werden z.B. alle Ordner bis auf "My Documents" ausgeschlossen, um die Größe des Replikationsspeichers klein und den Zugriff auf das Dateisystem kurz zu halten. Der Eintrag NumDirsToExclude gibt die Anzahl der per DirsToExclude ausgeschlossenen Ordner/Dateien an. In dieser Form werden bei mir dennoch alle Dateien und Ordner in den Replikationsspeicher aufgenommen.

Die Dateisynchronisierung funktioniert bei mir in beiden Richtungen. Lediglich bei aktiver ActiveSync-Verbindung werden Dateien auf dem Gerät nicht korrekt zum Desktop-Rechner übertragen. Dies wird dadurch gekennzeichnet, daß dem Dateinamen der erste Buchstabe fehlt. Erst nach Trennung der ActiveSync-Verbindung und erneuter Synchronisierung werden die Dateien korrekt aktualisiert.

Hintergrundthread für das Zurückschreiben der Registry

Das BSP der ICOP eBox-4300 wurde so konfiguriert, daß eine Hive-basierte Registry jedesmal vollständig auf den Datenträger zurückgeschrieben wird, sobald eine Änderung in ihr vorgenommen wurde (flush-on-close, aggressive flushing). Dadurch entsteht ein Verlust an Performance. So schließen sich einige Fenster erst nach kurzer Verzögerung.

Das automatische Zurückschreiben der Registry auf Disk läßt sich zwar abschalten. Dann muß eine Anwendung aber selber dafür sorgen, daß die Registry nach umfangreichen oder wichtigen Änderungen gesichert wird (was in der Regel nicht geschieht). Zudem muß der Neustart bzw. das Herunterfahren des Systems vom Power-Management veranlaßt werden, damit spätestens dann die Registry auf das Laufwerk zurückgeschrieben wird. Trennt man das Gerät vorher von der Stromversorgung, gehen Daten verloren.

Der folgende Registrierungsschlüssel steuert das Zurückschreiben einer Hive-basierten Registry:

[HKEY_LOCAL_MACHINE\init\BootVars]
"RegistryFlags"=dword:0

Der Wert 0 schreibt die Registry nicht deterministisch zurück. Der Wert 1 sorgt für aggressives Zurückschreiben und der Wert 2 deaktiviert das Sichern im Hintergrund. Durch Zuweisung des Wertes 0 und durch Setzen der Umgebungsvariablen PRJ_ENABLE_REGFLUSH_THREAD im OS Design wird ein Hintergrundthread aktiviert, der für das periodische Zurückschreiben der Registry auf den Datenträger sorgt.

Durchsucht man die common.reg nach PRJ_ENABLE_REGFLUSH_THREAD, findet man dort die Parameter zum Hintergrundthread (u.a. Priorität des Programmfadens, Anzahl der Änderungen und Zeitraum bis zum Zurückschreiben der Daten). Diese können bei Bedarf in der platform.reg oder project.reg überschrieben werden.

Die Funktion des Hintergrundthreads kann mit Hilfe der Datenträger-LED gut überprüft werden. Spätestens zwei Minuten nach einer Änderung in der Registry flackert sie für kurze Zeit auf und signalisiert so das Zurückschreiben der Daten auf Disk.

Auch für das Zurückschreiben der Datenbanken kann analog ein Hintergrundthread eingerichtet werden. Die Umgebungsvariable dafür lautet PRJ_ENABLE_DBFLUSH_THREAD.

Das Windows Embedded CE 6.0 Test Kit (CETK)

Beim Durchstöbern der Quelldateien von Windows CE fallen einem an vielen Stellen die Namen KITL, Tux und Kato auf. Den Kernel Independent Transport Layer lernt man schon sehr schnell als Debugging Service kennen. Tux Test Harness und die Kato Logging Engine gehören hingegen zum Windows Embedded CE Test Kit (CETK).

Das CETK besteht hauptsächlich aus vielen einzelnen Kommandozeilen-Tools, die von einer Desktop-Anwendung aus gesteuert werden können. Dieser CETK-Server nimmt auch die Testergebnisse entgegen. Darüber hinaus werden noch weitere Testprogramme bereitgestellt (u.a. Application Verifier, Windows Embedded CE Stress Tool, Resource Consumer, CPU Monitor).

Das Windows Embedded CE Test Kit kann unabhängig vom Platform Builder über das Startmenü von Windows aufgerufen werden. Über den Platform Manager kann auch sofort eine Verbindung zum Gerät hergestellt werden. Alle notwendigen Client-Dateien werden, sobald benötigt, automatisch auf das Gerät übertragen. Es ist nicht notwendig, daß das Run-Time Image mit dem Katalogelement des CETK (SYSGEN_WCETK) erstellt wurde. Mir ist noch nicht ganz klar, was beim Einbinden dieses Moduls erfolgt. Eine wcetk.dll gemäß Doku wird nicht erstellt. Ich konnte lediglich die wcetk.txt mit den Server-Parameter für das Tool clientside.exe im Ordner %_FLATRELEASEDIR% finden. Der CETK Client selbst wird aber nicht mit in das Image aufgenommen.

Nach dem die Verbindung steht, wird auf dem Zielgerät ein Fenster angezeigt, in dem Statusmeldungen durchlaufen (ClientSide). Im CETK-Fenster auf dem Desktop wird ein zur Plattform passender Testkatalog als Baumstruktur angezeigt. Wird im Symbol einer Kategorie ein Rufzeichen auf gelben Grund dargestellt, konnte auf dem Zielgerät kein entsprechendes Peripheriegerät ermittelt werden.

Über das Kontextmenü kann jeder Test einzeln konfiguriert (Edit Command Line) und gestartet werden (Quick Start). Im Kontextmenü sind immer nur die Ergebnisse der zuletzt ausgeführten Tests abrufbar (View Results). Der Ordner, in dem alle Testergebnisse gespeichert werden, kann über den Menüpunkt Server: Server Settings... festgelegt werden.

Wer jetzt willkürlich drauflostestet, ohne sich vorher in der Onlinehilfe genau über jeden einzelnen Test zu informieren, wird nicht weit kommen. Denn einzelne Tests verlangen Benutzereingaben am Zielgerät, erfordern zusätzliches Equipment (z.B. Lautsprecher und Mikrofon) oder benötigen mehrere Stunden Laufzeit.

Für den ungeduldigen SPARK Your Imagination Hobby-Entwickler, an den sich dieses Weblog ja richtet, sind dennoch einzelne Test nützlich und schnell durchgeführt. Am Besten man fängt mit folgenden Tests an: OAL IOCTL Tests, Serial Port Tests, NLED Tests und ggf. Battery API Test.

Die Zusatztools mit grafischer Oberfläche verstecken sich in einem Kontextmenü, das man per Rechtsklick auf das Zielgerät öffnen kann.

Der Application Verifier ist wie das CETK selbst auch einzeln erhältlich und wird hoffentlich von jedem Anwendungsentwickler verwendet, bevor er ein Programm veröffentlicht. Das Tool überprüft ein Programm zur Laufzeit und hilft bei der Ermittlung von Speicherlecks. Für die erzeugten Protokolldateien gibt es einen separaten Viewer. Es ist zu beachten, daß das Tool hin und wieder falsch positive Ergebnisse liefert. Es meldet auch einen Fehler, falls eine Ressource erst beim Terminieren des Programms durch das System freigegeben wird (z.B. bei LoadImage).

Damit der CPU Monitor funktioniert, muß auf dem Zielgerät manuell das Programm cetkperf.exe mit dem Hostnamen bzw. der IP-Adresse des Entwicklungsrechners als Parameter gestartet werden. Das Tool zeigt die Prozessor- und Speicherauslastung graphisch an und protokolliert deren Werte.

Mit dem Resource Consumer kann man die Systemressourcen Objektspeicher, Programmspeicher, Anzahl Prozesse und CPU-Auslastung bis zu deren Erschöpfung vereinnahmen.

Das Windows Embedded CE Stress Tool sorgt 14 Stunden lang für eine Dauerbelastung des Zielgerätes...

Im Programmordner des CETK findet man noch ein Kommandozeilentool, mit dem man lokal auf dem Gerät Bildschirmfotos anfertigen kann (prt_scrn.exe). Das in der Dokumentation beschriebene Scripting Host Tool liegt dem CETK jedoch nicht (mehr?) bei.

Neues VIA x86 Board Support Package, Version 3.44

VIA Technologies, Inc. hat das x86 BSP für Windows Embedded CE 6.0 aktualisiert, auf das auch das Board Support Package der ICOP eBox-4300 basiert.

Im neuen BSP wurde jetzt die Version 6.0.0.33 des Grafiktreibers übernommen, welcher schon seit längerem einzeln zur Verfügung stand. Ganz frisch ist hingegen die Version 1.3a des HD Audiotreibers. Darüber hinaus wurde auch der VIA Gigabit Ethernet Treiber aktualisiert. Dieser NE2000-basierte Treiber ist für Nutzer der eBox4300 jedoch uninteressant, da die eBox ein Realtek-Chipsatz enthält.

Die Bibliothek HDDRegSave (VIA WCE X86 Managing System Registry With IDE ATA Storage Device) wurde hingegen aus dem BSP entfernt.

Am Quellcode wurde nicht viel geändert. OEMInit() ruft eine neue Funktion DisableSataIrq() auf und die Datei HALSCI.c wurde zur Unterstützung des VX855-Chipsatzes erweitert. Die Fehler mit den nicht initialisierten Variablen in dieser Datei wurden allerdings nicht beseitigt...