Persönliches Knowledge Blog von Wolfgang Rolke

Navigation

Navigation

Kategorien

Suche


Syndication

Integration des Windows SDK für Windows 7 in Visual Studio 2005

Das Microsoft Windows SDK für Windows 7 kann mit Hilfe des Windows SDK Configuration Tools in Microsoft Visual Studio 2005 integriert werden.
Unter einer deutschen Version von Microsoft Windows XP kann jedoch folgende Fehlermeldung angezeigt werden:
"Your system does not have Visual Studio 2005 or Visual Studio 2008 installed."

In dem Artikel Windows SDK Configuration Tool May Report an Error When OS Display Format is not English aus dem Microsoft Windows SDK Blog werden zwei Lösungen für dieses Problem beschrieben.
Bei mir war lediglich die zweite Methode erfolgreich. Erst nachdem ich in den Regions- und Sprachoptionen die Regionalen Einstellungen auf "Englisch (USA)" geändert hatte, konnte das Windows SDK Configuration Tool fehlerfrei ausgeführt werden. Danach sind die C++-Verzeichnisse des neuen SDK's im Visual Studio eingetragen.

Mit dem Manager für die kombinierte Visual Studio 2005 Hilfe bindet man die neue Windows SDK-Dokumentation in die Visual Studio 2005-Hilfe ein.
Verursacht der Manager einen Skriptfehler, hilft evtl. der Knowledge Base-Artikel KB919755 weiter. Nach Aktualisierung der Datei dv_vscccommon.hxs listet der Collection Manager alle kompatiblen Dokumentationen zur Integration auf.

20:31:18 am 24.08.2009 von Electron - Software - Kommentare

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...

18:12:19 am 20.06.2009 von Electron - Embedded - Kommentare

Installation der Windows 7 Beta mit Virtual PC 2007 SP1

Wer das Betriebssystem Microsoft Windows 7 Beta testen möchte, dafür aber keinen passenden Rechner zur Verfügung hat, kann es als Gast in einen von Microsoft Virtual PC 2007 SP1 bereitgestellten virtuellen Computer einrichten und ausführen.

Hat man Virtual PC 2007 bereits installiert, muss man sicherstellen, dass man auch die Version mit Service Pack 1 nutzt. Andernfalls ist das Gastbetriebssystem nach Installation der Virtual Machine Additions nicht mehr nutzbar (Blue Screen).
Microsoft Virtual PC 2007 mit Service Pack 1 hat die Versionsnummer 6.0.192.0.

Brian Keller, Technical Evangelist for Team System, hat in einem Blog-Artikel die Einrichtung der Windows 7 Beta mit Virtual PC 2007 SP1 beschrieben, so dass ich hier nicht weiter darauf eingehe.

Die Installation der Windows 7 Beta hat bei mir recht lange gedauert, lief aber ohne Fehler durch. Allerdings konnte ich mich mit dem von mir vergebenen Kennwort nicht anmelden (Benutzername oder Kennwort ungültig). Nach einem Neustart des Systems wurde mir dann kein Konto mehr zur Anmeldung angeboten.

Möglicherweise lag dies am von mir gewählten Kontonamen "Benutzer". Dieser wurde zwar vom System akzeptiert, kollidiert aber möglicherweise mit einem Standardkonto oder einem Ordnernamen...

Erst über den abgesicherten Modus und die Anmeldung über das dann verfügbare Administrator-Konto konnte ich mit der Benutzerkontensteuerung ein Benutzerkonto anlegen und nutzen.

18:13:10 am 01.03.2009 von Electron - Software - Kommentare

WR-Tools CPULoad in neuer Version 0.7

Das Tool CpuLoad für das Betriebssystem Microsoft Windows CE wurde aktualisiert. Es zeigt die Auslastung der CPU als Balken im Infobereich der Taskleiste an. Der Verlauf der Prozessorauslastung wird in einem Diagramm dargestellt.

CpuLoad

Über den Eintrag TopMost in der Registry kann jetzt vorgegeben werden, ob das Dialogfenster von CpuLoad immer im Vordergrund angezeigt werden soll.
Weist man dem Eintrag MemLoad einen Wert ungleich 0 zu, wird im Diagramm zusätzlich die Speicherauslastung in Prozent angezeigt.

[HKEY_CURRENT_USER\SOFTWARE\WR-Tools\CpuLoad]
"TopMost"=dword:1 ; 1 = Dialogfenster immer im Vordergrund
"MemLoad"=dword:0 ; 0 = Speicherauslastung wird nicht angezeigt


Das Programm steht hier zum Download zur Verfügung.

18:51:56 am 07.09.2008 von Electron - Software - Kommentare

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.

Windows Embedded CE Test Kit

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).

Application Verifier

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.

CPU Monitor

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

Resource Consumer

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

Windows Embedded CE Stress

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.

15:00:24 am 23.08.2008 von Electron - Embedded - Kommentare

Hintergrundthread für das Zurückschreiben der Registry

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

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

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

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


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

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

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

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

14:54:06 am 17.08.2008 von Electron - Embedded - Kommentare

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

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

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

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


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

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

23:55:00 am 16.08.2008 von Electron - Embedded - Kommentare

Ein kurzer Blick auf das Speicherabbild der ICOP eBox-4300

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

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


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


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

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


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


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

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

CONFIG
  AUTOSIZE=ON


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

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

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


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


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

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

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


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


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

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


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

Graphisch sieht die Memory Map so aus:

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



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

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

21:01:05 am 08.08.2008 von Electron - Embedded - Kommentare

Erstellung eines plattformspezifischen Software Development Kits

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

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

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

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

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

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


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

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


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

General

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

Install

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

CPU Families

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

Development Languages

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

Emulation

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


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

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

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

19:58:08 am 20.07.2008 von Electron - Embedded - Kommentare

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

1. Standby aktivieren

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

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

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

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

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

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

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


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


2. Optimale Bildschirmauflösung gemäß DDC

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

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



3. Deutschsprachige Anzeige von USB-Massenspeicher im Explorer

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

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



4. Speicherort der Registry ändern

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

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


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


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

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

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


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


6. Benutzerdefinierte Einstellungen

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

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

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

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

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

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

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



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

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

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

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

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

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


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

Das Hintergrundbild habe ich wie folgt als Standard definiert:

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


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

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


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


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

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

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

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

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

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


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

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


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


9. Größe des Object Store festlegen

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

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

IF IMGPERSISTENTSTORAGE
FSRAMPERCENT=0x00000010
ENDIF

IF IMGTINYFSRAM
FSRAMPERCENT=0x00000080
ENDIF



10. Dateibasierten Papierkorb verwenden

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

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



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

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

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

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

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

01:00:46 am 06.07.2008 von Electron - Embedded - Kommentare
< September 2017 >
MonDieMitDonFreSamSon
    123
45678910
11121314151617
18192021222324
252627282930 

Links