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...
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...
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.
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.
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:
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 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:0Der 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.
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:
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.
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 SECTIONMit 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.
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.
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:
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).
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:
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.
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:
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:
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.
%_TARGETPLATROOT%\FILES\config.bib
%_TARGETPLATROOT%\SRC\BOOTLOADER\EBOOT\boot.bib
%_TARGETPLATROOT%\SRC\X86\COMMON\STARTUP\startup.asmIn 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 zerosFü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=ONHier 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 = 0x9c000000Auf 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 FIXUPVARDa 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 DMAWie 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 MBMit 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.
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:
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.
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 ; IMGPPCSobald 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.
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:
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:
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.
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:
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:
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:
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:
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:
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:
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:
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:
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:
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.
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:
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.
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 OffSetzt 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:13. 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"
#endif4. 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:00000001Damit 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 NKDie 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.dllEs 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 NKEinfacher 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
ENDIF10. 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:111. 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
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:
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.
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.
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:
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:
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:
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:
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:
Die Sources-Datei "%_TARGETPLATROOT%\SRC\DRIVERS\KEYBD\DLL\KBD8042GR\sources" wie folgt ändern:
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:
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:
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:
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:
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.
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_00000407Die 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_00000407Die 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.cppDie 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.cppDie 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.cppDie 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=0407Tastaturtreiber 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.
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:
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:
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.
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_BATTDRVRDiese 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.