http://wolfgang-rolke.de/system-cgi/blog/ Persönliches Knowledge Blog von Wolfgang Rolke en-us Nucleus CMS v3.21 © Weblog http://backend.userland.com/rss http://wolfgang-rolke.de/system-cgi/blog//nucleus/nucleus2.gif http://wolfgang-rolke.de/system-cgi/blog/ http://wolfgang-rolke.de/system-cgi/blog/index.php?itemid=1410 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.]]> Software http://wolfgang-rolke.de/system-cgi/blog/index.php?itemid=1410 Mon, 24 Aug 2009 20:31:18 +0200 http://wolfgang-rolke.de/system-cgi/blog/index.php?itemid=1388 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...]]> Embedded http://wolfgang-rolke.de/system-cgi/blog/index.php?itemid=1388 Sat, 20 Jun 2009 18:12:19 +0200 http://wolfgang-rolke.de/system-cgi/blog/index.php?itemid=1332 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.]]> Software http://wolfgang-rolke.de/system-cgi/blog/index.php?itemid=1332 Sun, 01 Mar 2009 18:13:10 +0100 http://wolfgang-rolke.de/system-cgi/blog/index.php?itemid=1266 Black Mirror, The Moment of Silence, The Longest Journey, usw.) und Action-Adventures (u.a. Tomb Raider, LEGO Star Wars, Psychonauts). Logikfehler und unfaire Bosskämpfe sorgen dabei hin und wieder für Frust.
Dem Fun-Racer TrackMania von Nadeo sagt man unendlichen Spielspaß nach. Jetzt bin ich endlich einmal dazu gekommen, das Rennspiel auszuprobieren. Und es macht wirklich süchtig! Da man mit dem enthaltenen Editor sehr einfach eigene Strecken erstellen kann, stehen unzählige davon online zur Verfügung.

Auch ich habe inzwischen ein paar "Tracks" gebaut. Diese möchte ich Euch nicht vorenthalten:

Fire on Ice
Khardung La
SandBoxRally SE
LeavingGreenVillage
DirtAutoCross
TickTrickTrack
TickTrickTrack 2
TickTrickTrack III



Das Spiel in der Variante TrackMania Nations Forever mit Beschränkung auf die Umgebung Stadion ist gratis! Man kann es sich hier herunterladen.]]> Games http://wolfgang-rolke.de/system-cgi/blog/index.php?itemid=1266 Sun, 26 Oct 2008 16:13:35 +0100 http://wolfgang-rolke.de/system-cgi/blog/index.php?itemid=1232 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.



Ü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.]]> Software http://wolfgang-rolke.de/system-cgi/blog/index.php?itemid=1232 Sun, 07 Sep 2008 18:51:56 +0200 http://wolfgang-rolke.de/system-cgi/blog/index.php?itemid=1225 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.]]> Embedded http://wolfgang-rolke.de/system-cgi/blog/index.php?itemid=1225 Sat, 23 Aug 2008 15:00:24 +0200 http://wolfgang-rolke.de/system-cgi/blog/index.php?itemid=1219
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.]]> Embedded http://wolfgang-rolke.de/system-cgi/blog/index.php?itemid=1219 Sun, 17 Aug 2008 14:54:06 +0200 http://wolfgang-rolke.de/system-cgi/blog/index.php?itemid=1218
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.]]> Embedded http://wolfgang-rolke.de/system-cgi/blog/index.php?itemid=1218 Sat, 16 Aug 2008 23:55:00 +0200 http://wolfgang-rolke.de/system-cgi/blog/index.php?itemid=1214 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.]]> Embedded http://wolfgang-rolke.de/system-cgi/blog/index.php?itemid=1214 Fri, 08 Aug 2008 21:01:05 +0200 http://wolfgang-rolke.de/system-cgi/blog/index.php?itemid=1192 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.]]> Embedded http://wolfgang-rolke.de/system-cgi/blog/index.php?itemid=1192 Sun, 20 Jul 2008 19:58:08 +0200