PRAXIS

70 3.2012 www.dotnetpro.de

W indows Embedded Compact, in

diesem Artikel kurz „Compact“, ist

Microsofts kleinstes Betriebssys-

tem für Embedded Devices. Das echtzeitfähige

System wird für internetfähige Geräte und MP3-

Player und Kameras verwendet, aber auch für

Industrie-Controller, Medizintechnikprodukte

sowie in der Heimautomatisierung. In der aktu-

ellen Version 7 unterstützt es die CPU-Architek-

turen x86, MIPS und ARM (Version 5, 6 und 7)

sowie SMP (Symmetric Multiprocessing). Nicht

mehr unterstützt werden die ARM-Version 4i

und die CPU-Architektur SuperH.

Compact hat einen plattformunabhängigen

Betriebssystemkern, der bei einer Portierung

auf neue Hardware, also ein neues Board, nicht

geändert werden muss. Stattdessen sind die

Hardware-Abhängigkeiten im sogenannten

Board Support Package (BSP) gebündelt, sodass

bei einer Portierung des Betriebssystems nur

dort Änderungen anfallen. Der Betriebssystem-

kern greift niemals direkt auf die Hardware zu,

sondern immer über das BSP. Gleiches gilt für

die Dienste und Applikationen, die unter Com-

pact laufen.

Aufbauend auf dem eigentlichen Betriebssys-

tem liefert Microsoft eine Fülle von Bibliothe-

ken, Applikationen und Diensten. Diese sind in

einzelne Komponenten verpackt, die sich der

Entwickler nach seinem Bedarf passend zusam-

menstellen kann.

Ein BSP besteht aus den folgenden Blöcken:

◼ Bootloader,

◼ OEM Adaptation Layer (OAL),

◼ Gerätetreiber,

◼ Kernel Independent Transport Layer (KITL).

Der Bootloader lädt das Betriebssystem ins

RAM und startet es. Er ist also ein eigenständi-

ges Programm, das vor dem Start von Compact

und völlig unabhängig davon läuft.

Der OAL ist eine Codeschicht, die den Be-

triebssystemkern von Compact an eine be-

stimmte Hardware-Plattform anpasst, also vor

allem an den verwendeten Prozessor, Mikro-

controller oder System-on-a-Chip (SOC), aber

auch an den verwendeten Speicher und die auf

dem Board vorhandene Peripherie. OAL und

Betriebssystemkern sind über Funktionsaufrufe

und Variablen eng miteinander verzahnt.

Die Gerätetreiber machen von der Code-

menge her üblicherweise die Masse des BSP

aus, sind aber am einfachsten zu entwickeln:

Zum einen sich kann der Entwickler auf ein

vollständiges, laufendes Betriebssystem mit

komforta blen Möglichkeiten zum Debugging

stützen, zum anderen lassen sich die Geräte-

treiber einzeln einer nach dem anderen pro-

grammieren. Die Entwicklung von Bootloader

und OAL ist dagegen wesentlich trickreicher.

Der KITL sorgt für die Kommunikation zwi-

schen Entwicklungs-PC und Compact-Gerät

zum Zweck des Debuggings von Betriebssys-

temkern, Gerätetreibern oder Applikationen.

Für jeden Block gibt es wiederverwendbaren

Code oder Bibliotheken von Microsoft, die nur

um den plattformspezifischen Code ergänzt

werden müssen.

Um ein BSP zu entwickeln oder anzupassen,

ist Vertrautheit mit maschinennaher Program-

mierung die unabdingbare Voraussetzung. Die

Dokumentation zum Mikrocontroller und der

übrigen Hardware sollte natürlich auch verfüg-

bar sein. Zu Compact bietet Microsoft umfang-

reiche Referenzen, technische Artikel, Anleitun-

gen, Whitepapers et cetera. Während bei älteren

Versionen des Betriebssystems die Dokumenta-

tion noch in der MSDN-Bibliothek versammelt

war, findet sich hier für Compact 7 nur noch die

Referenz; technische Artikel und andere Doku-

mentationen befinden sich auf einer eigenen

Webseite [1]. Von besonderem Interesse ist hier

der Artikel The Basics of Bringing up a Hardware

Platform [2]. Mit Professional Windows Embed-

ded Compact 7 von Samuel Phung, David Jones

und Thierry Joubert ist kürzlich ein aktuelles

Buch zu Compact 7 erschienen [3].

Anders als bei anderen Produkten stellt Mi-

crosoft einen großen Teil des Quellcodes zur

Verfügung, damit die Funktionsweise der Mi-

crosoft-Komponenten besser verständlich wird.

Als weitere wichtige Hilfen sind zahlreiche BSPs

als Quellcodes verfügbar. Hilfreich kann auch

der Code anderer Betriebssysteme sein, die es

bereits für die Zielplattform gibt.

Die EntwicklungsumgebungDie Entwicklung eines BSP erfolgt in Visual Stu-

dio mit installiertem Platform-Builder-Plug-in.

Für Compact 7 ist mindestens Visual Studio 2008

Windows Embedded Compact portieren

KomponentenwerkstattDas Board Support Package (BSP) vermittelt zwischen den plattformunabhängigen Komponenten von Windows Embedded Compact und der Hardware. Es ist für jedes neue Board zu entwickeln.

Auf einen Blick

Matthias Kraaz beschäftigt sich bei Zühlke Engineering mit Windows Embedded Compact für Medizintechnikgeräte und andere Embedded-Systeme. Sie erreichen ihn über die Adresse matthias.kraaz@zuehlke.com.

Inhalt▸Das Entwicklungsumfeld für

ein Board Support Package.▸Bootloader und Systemstart.▸Windows Embedded Compact

für die Hardware konfigu-rieren.

▸ Die Rolle des OS-Designs.

Serie1. Käfer in Komponenten2. Komponentenwerkstatt

dnpCode A1203Embedded

PRAXIS

www.dotnetpro.de 3.2012 71

SP1 notwendig. Zusammen mit dem Plat-

form Builder wird ein mehrere Gigabyte

großer Verzeichnisbaum installiert, der

die Quellen und Komponenten von Win-

dows Embedded Compact enthält. Im

Verzeichnisbaum – normalerweise unter

C:\WINCE700\ – befinden sich dann fol-

gende Verzeichnisse:

◼ PUBLIC : Enthält den in Komponenten

aufgeteilten und vorkompilierten Code

des Systems. Teile, insbesondere Trei-

ber, werden als Quellcode ausgeliefert.

◼ PLATFORM : Enthält ein Unterverzeich-

nis pro BSP sowie ein Verzeichnis COM-

MON mit gemeinsamem Code für meh-

rere Hardware-Plattformen.

◼ PRIVATE : Hier ist ein Teil des Betriebs-

systems als Code abgelegt.

◼ OSDesigns : Enthält ein Unterverzeich-

nis pro OS-Design, also für die Art und

Weise, wie ein Gerät konfiguriert wird [4].

Bis das erste OS-Design erstellt wurde,

ist dieses Verzeichnis leer.

Nach der Installation des Platform Buil-

ders sollten noch die sogenannten QFEs

eingespielt werden – so nennt Microsoft

kleine Updates für Compact. Die QFEs

kommen monatlich pro unterstützte

Pro zessorfamilie heraus und sind inkre-

mentell. Am Jahresanfang erscheint ein

zusammenfassendes Update (Rollup) des

Vorjahres. Für einen aktuellen Platform

Builder muss also das Rollup vom Jahres-

anfang installiert werden plus alle folgen-

den monatlichen QFEs – und das für drei

Prozessorfamilien. Mit dem WEDU-Plug-

in (Windows Embedded Developer Up-

date) für Compact 7 lässt sich diese lästige

Arbeit aber automatisieren [5]. Auch den

Downgrade, also das Zurückgehen auf

einen älteren Stand, beherrscht das Tool.

Ein BSP kann von Grund auf neu er-

stellt werden; gängige Praxis ist aber, ein

vorhandenes BSP zu kopieren und anzu-

passen. Die Vorlage dafür kann sowohl

von Microsoft als auch von einem Dritt-

anbieter stammen. Dabei ist es natürlich

sinnvoll, ein BSP für einen möglichst ähn-

lichen Mikrocontroller zu verwenden, um

möglichst viel Code ohne Anpassung wie-

derverwenden zu können. Kopiert wird

ein solches BSP mit dem Cloning Wizard

des Platform Builders.

Aufgabe des BootloadersDie Implementierung eines BSP beginnt

beim Bootloader. Seine Hauptaufgabe ist

immer der Start eines Betriebssystems. Er

ist sehr klein und passt in den winzigen

Speicher, der direkt nach dem Start eines

Mikrocontrollers zur Verfügung steht.

Die Größe dieses Speicherbereichs va-

riiert je nach Hardware-Architektur. Bei

manchen Architekturen ist er zu klein,

sodass erst ein noch kleinerer First-Stage-

Loader (XLDR) nötig ist. Dieser initiali-

siert die CPU so weit, dass der Speicher-

bereich des eigentlichen Bootloaders

zugänglich wird, und startet diesen dann.

Der Bootloader implementiert zudem

den Download des Betriebssystems in den

Flash-Speicher oder ins RAM über USB,

Ethernet oder serielle Schnittstelle. Diese

Funktion benutzt der Platform Builder,

wenn er ein neu gebautes Betriebssystem-

Image auf das Gerät lädt.

Der genaue Funktionsumfang des Boot-

loaders ist variabel und hängt von den An-

forderungen an das zu entwickelnde Gerät

ab. Um den Loader selbst auf das Gerät zu

bringen, sind Tools des Prozessor- oder

Board-Herstellers oder zum Beispiel ein

JTAG-Programmieradapter [6] nötig. Nor-

malerweise wird der Bootloader in nicht-

flüchtigen Speicher wie zum Beispiel Flash

geschrieben.

Bei der Entwicklung des Bootloaders

stellt sich auch die Frage, ob es einem

(technisch versierten) Benutzer möglich

sein soll, seine eigene Software auf das

Gerät zu bringen. Um das zu verhindern,

muss ein gehärteter, ein „Secure Boot-

loader“ entwickelt werden, der nur noch

Images lädt und startet, die der Hersteller

digital signiert hat. Microsoft liefert hierfür

eine Reihe von Hilfsbibliotheken, Anlei-

tungen und bewährte Praktiken.

Das Bootloader-FrameworkFür das Erstellen eines Bootloaders bie-

tet Microsoft das Bootloader-Framework

BLCOMMON. Es sorgt dafür, dass für ein

neues BSP nur plattform- und anwen-

dungsspezifische Teile des Bootloaders

entwickelt werden müssen. Andere, wie-

derverwendbare Teile des Bootloaders de-

cken die folgenden Hilfsbibliotheken ab:

◼ Die EBOOT-Bibliothek implementiert

die für den Download per Ethernet nö-

tigen Protokolle DHCP, TFTP und UDP.

◼ Die BOOTPART-Bibliothek stellt den

Zugriff auf die Partitionen eines Spei-

chers, etwa Flash, zur Verfügung.

◼ Die Ethernet-Debug-Bibliotheken sind

eine Sammlung von Treibern für eine

Vielzahl gängiger Ethernet-Controller.

Bei Compact 7 ist das neue Bootloader-

Framework CE Boot [7] hinzugekommen.

Es soll das ältere BLCOMMON ablösen

und bietet bessere Schnittstellen zwi-

schen dem wiederverwendbaren Boot-

loader-Kern und dem plattformspezifi-

schen Code. Insbesondere vereinfacht es

die Implementierung neuer Firmware.

Außerdem ersetzt Compact 7 die Hilfsbi-

bliotheken von BLCOMMON durch eine

Vielzahl separater Treiber mit einheitli-

cher Schnittstelle.

So ausführlich wie zu BLCOMMON ist

die Dokumentation für CE Boot allerdings

noch nicht. Doch aufgrund der besseren

Struktur des Frameworks hilft auch ein

Blick in die (komplett verfügbaren) Quel-

len des Frameworks inklusive Treiber.

Die meisten BSPs von Microsoft ver-

wenden BLCOMMON. Ein Beispiel für ei-

nen Bootloader auf Basis von CE Boot fin-

det sich im BSP für die CEPC-Plattform.

Sie dient dazu, Compact – emuliert in

Virtual PC – auf dem PC laufen zu lassen.

Schritt für Schritt zum BootloaderUnter How to Develop a Boot Loader [8]

befindet sich in der MSDN-Bibliothek

eine schrittweise Anleitung zum Aufbau

eines Bootloaders. Durch die hier ange-

gebene Reihenfolge lässt sich nach fast

jedem Schritt prüfen, ob der neue Code

funktioniert. Bei vielen Schritten gibt es

auch Tipps zur Fehlersuche für den Fall,

dass der neue Code nicht wie erwartet

funktioniert.

Außerdem legt die Anleitung Wert dar-

auf, möglichst früh Möglichkeiten zum

Debuggen zu schaffen, um die folgenden

Schritte zu vereinfachen. Zum Beispiel wird

die sogenannte Debug-Serielle in Betrieb

genommen – dies ist eine zeichenbasierte

Schnittstelle, über die sich Fortschritts- und

Fehlermeldungen ausgeben lassen. Auch

wenn Probleme mit einem übernommenen

Bootloader auftreten, lassen sich Fehler in

dieser Schrittfolge überprüfen.

Die Anleitung ist für Windows Embed-

ded CE 6.0 geschrieben, passt aber auch für

Compact 7, solange das alte BLCOMMON-

Framework verwendet wird.

Der Startcode für den BootloaderEgal welches Framework den Vorzug er-

hält, die Ausführung beginnt immer in

gleicher Weise: Beim Reset des Prozessors

springt dieser automatisch den Startcode

(Startup Code) des Bootloaders an. Dieser

Code initialisiert die Hardware so weit,

dass die Ausführung von C-Code möglich

wird. Daher ist der Startcode auch zwin-

gend in Assembler zu schreiben.

72 3.2012 www.dotnetpro.de

PRAXIS _Windows Embedded Compact portieren

Der Code muss:

◼ die Interrupts sperren,

◼ die beim Speicherzugriff beteiligten

Hardware-Komponenten konfigurieren,

◼ eventuell Uhren initialisieren

◼ und den Bootloader aus dem Boot-Medi-

um (meistens Flash) ins RAM kopieren.

Damit ist die Hardware so weit vorberei-

tet, dass der Assembler-Teil seine Aufgabe

erfüllt hat und der Startcode seine Arbeit

mit einem Sprung in die in C geschriebene

Hauptprozedur beenden kann. Diese ruft

dann das Bootloader-Framework auf:

BootloaderMain() bei BLCOMMON und

BootMain() bei CE Boot.

Das Framework steuert nun den wei-

teren Ablauf und ruft dabei vom BSP-

Entwickler implementierte Funktionen

auf, um etwa einen Ethernet-Controller

und Flash-Speicher zu initialisieren, ein

Betriebssystem-Image per Ethernet in

den Flash-Speicher zu laden und dann zu

starten.

Der Bootloader muss oft Informatio-

nen an das zu startende Betriebssystem

weitergeben, zum Beispiel die per DHCP

erhaltene IP-Adresse oder andere vom

Benutzer eingegebene Parameter. Dafür

gibt es einen reservierten physikalischen

Speicherbereich namens „Boot Args“,

über dessen Position und Struktur Boot-

loader und OAL Bescheid wissen. Boot

Args sind meistens eingebettet in einen

größeren Speicherbereich, der wiederum

als „Driver Globals“ bezeichnet wird und

der zur Kommunikation zwischen Geräte-

treibern und OAL dient [9].

Der Start des BetriebssystemsBeim Sprung des Bootloaders ins Betriebs-

system-Image beginnt die Ausführung mit

einem weiteren Startcode, dem „OAL Start-

up Code“. Er muss die vom Bootloader vor-

genommene Hardware-Initialisierung fort-

setzen, damit sich der Betriebssystemkern

aktivieren lässt. Dazu gehört die Initialisie-

rung von Prozessor, Speicher, Interrupts,

GPIOs und so weiter.

Nach der Hardware-Initialisierung

übergibt der OAL-Startcode durch den

Aufruf von KernelStart() die Kontrolle an

den Betriebssystemkern. Alle weiteren

Funktionen des OAL werden dann vom

Betriebssystemkern aufgerufen.

Weitere Aufgaben des OALNeben seinem Startcode muss der OAL

dem Betriebssystemkern folgende Diens-

te zur Verfügung stellen:

◼ Das Speicherlayout, also die Verwen-

dung des physikalischen Speichers.

Dieses legt der OAL über eine Konfigu-

rationsdatei fest. Die Abbildung virtuel-

ler auf physikalische Speicheradressen

erfolgt über Datenstrukturen.

◼ Funktionen zum Abfragen und Setzen

einer Echtzeituhr.

◼ Funktionen, um den Cache zu steuern.

Für zahlreiche CPU-Familien liefert Mi-

crosoft hierfür bereits Code.

◼ Den „System-Tick“: eine hochaufge-

löste Systemzeit, die zum Beispiel der

Scheduler verwendet. Die entsprechen-

de Schnittstelle zwischen OAL und Be-

triebssystemkern besteht aus mehreren

Funktionen auf beiden Seiten plus eini-

gen Variablen im Betriebssystemkern.

◼ Stromregulierung: Der OAL muss Funk-

tionen für das Aktivieren von und das

Aufwachen aus verschiedenen Energie-

spar-Modi implementieren.

◼ Die Debug-Serielle: Funktionen für die

Ein- und Ausgabe über eine zeichen-

basierte Schnittstelle zur Fehleranalyse,

vor allem für Meldungen des OAL und

des Betriebssystemkerns.

◼ Funktionen für den Umgang mit Inter-

rupts für das Sperren, Freigeben und

Registrieren von Interrupt-Handlern

et cetera. Für zahlreiche CPU-Familien

liefert Microsoft hierfür bereits Code.

Produktionsqualität mit weniger AufwandEin OAL hat Produktionsqualität, wenn sich

mit ihm guten Gewissens massenweise Ge-

räte produzieren lassen. PQOAL (Produc-

tion-Quality OAL) ist eine Sammlung von

Quellcodedateien für einen OAL, die von

Microsoft mitgeliefert und gepflegt wer-

den. Dadurch muss der Entwickler weniger

OAL-Code selbst schreiben und kann mehr

von schon getestetem Code verwenden.

Die PQOAL-Quellcodes sind auf folgende

Unterverzeichnisse von PLATFORM\Com-

mon\Src\ aufgeteilt (die in Spitzklammern

gesetzten Namen sind variabel):

◼ Common\ : allgemein verwendbarer,

nicht Hardware-spezifischer Code,

◼ SOC\<SOC>\: Code für ein System-on-

a-Chip,

◼ <Cpu-Architektur>\Common\: Code für

alle Prozessoren einer Architektur, bei-

spielsweise ARM,

◼ <Cpu-Architektur>\<Cpu>\: Code für

einen bestimmten Prozessor.

Auch neue Quellcodes, so sie denn

wiederverwendbar sind, sollten in dieser

Struktur abgelegt werden. Es empfiehlt

sich auch, hier nach vorhandenem Code

von Microsoft oder Drittanbietern zu su-

chen, um sich Entwicklungsaufwand zu

sparen.

Code, der spezifisch für eine Hardware-

Plattform ist, sollte unter PLATFORM\

<Bsp>\Src\ liegen.

Kommunikation zwischen IDE und GerätDer vom KITL implementierte Kommu-

nikationsweg (siehe oben) dient nicht

nur dem Platform Builder zum Debuggen

des Betriebssystems. Auch viele Analyse-

werkzeuge (Remote File Viewer, Remote

Registry Editor, Remote Kernel Tracker et

cetera) kommunizieren darüber mit dem

Gerät. Größtenteils besteht diese Trans-

portschicht aus der Implementierung des

Kommunikationsprotokolls. Dieser Teil

befindet sich fix und fertig in einer Biblio-

thek unter Platform\Common\. Lediglich

die Initialisierung und die Ansteuerung

der Kommunikations-Hardware sind

noch zu ergänzen. In der ausgelieferten

Konfiguration sollte die KITL-Komponen-

te aus Sicherheitsgründen natürlich nicht

enthalten sein.

Die GerätetreiberWenn OAL und KITL fertig sind, umfasst

das System einen lauffähigen Kern mit

RAM-basiertem Dateisystem und De-

bugging per Ethernet. Damit bleiben als

letzter Brocken die Gerätetreiber. Ihre

Entwicklung gestaltet sich so kunterbunt

wie die Vielzahl von Geräten, die der Her-

steller eventuell anbinden möchte: Audio,

Display, Flash, Netzwerk, serielle Gerä-

te und viele mehr. Daher nur ein kurzer

Überblick an dieser Stelle.

Die Gerätetreiber sind bei Compact

dynamisch gelinkte Bibliotheken (also

DLLs), die einen vorgeschriebenen Satz

von Funktionen als Schnittstelle imple-

mentieren. Je nach Gerätetyp sind andere

Schnittstellen vorgesehen.

Zu den gängigen Gerätetypen stellt Mi-

crosoft jeweils den plattformunabhängi-

gen Teil als „Model Device Driver“ (MDD)

zur Verfügung. Für dessen Schnittstelle

muss der „Platform Dependent Driver“

(PDD) entwickelt werden, der mit dem

MDD zusammen den kompletten Treiber

ergibt: Der MDD übernimmt die komple-

xeren Aufgaben, während der PDD eher

einfach gestrickt ist. Dadurch lässt sich

ein funktionierender Treiber recht schnell

erstellen mit dem Bonus, dass er größten-

www.dotnetpro.de 3.2012 73

PRAXIS

teils bereits vielfach erprobt und dement-

sprechend fehlerarm ist.

Die Schnittstelle zwischen MDD und

PDD hängt vom Gerätetyp ab. Bei einigen

Gerätetypen, zum Beispiel Flash-Speicher,

gibt es auch verschiedene Schnittstellen-

versionen, weil sich die alte Schnittstelle

als ungenügend für neue Arten von Flash

erwiesen hat.

Treiber für weniger gängige Gerätetypen

verwenden meist die Stream-Schnittstelle

und lassen sich auf diese Weise von der

Applikation verwenden; die Schnittstel-

le ab strahiert das Gerät als Byte-Strom,

den die Applikation lesen und schreiben

kann [10]. Jede Treiber-Schnittstelle kann

außerdem noch durch sogenannte IOCTLs

erweitert werden, die den Austausch be-

liebiger Datenstrukturen zwischen Treiber

und Applikation erlauben.

Das OS-DesignMit einem OS-Design schneidert der Ent-

wickler Compact auf einen bestimmten

Anwendungszweck zu. Das muss sein,

denn für alle verfügbaren Komponenten

hätten die meisten Geräte gar nicht genug

Platz. Die Komponenten von Compact

und dem BSP bietet der Platform Builder

im sogenannten Katalog an. Das OS-De-

sign enthält:

◼ die ausgewählten Compact-Kompo-

nenten,

◼ das BSP,

◼ die Auswahl der BSP-Komponenten,

sprich der Gerätetreiber (ein OS-Design

muss also nicht immer alle Gerätetrei-

ber eines BSPs nutzen),

◼ die von Compact unterstützten Spra-

chen,

◼ weitere Einstellungen wie etwa, ob das

Debugging des Betriebssystemkerns

möglich sein soll.

Angelegt wird ein OS-Design mit einem

Assistenten. Dieser bietet Schablonen an,

zum Beispiel Small Footprint Device oder

Mobile Handheld. Je nach Schablone sind

mehr oder weniger Compact-Komponen-

ten ausgewählt. Diese Vorauswahl lässt

sich aber anschließend ändern.

Build-ProzessWenn das OS-Design festgelegt ist, kann

das Betriebssystem gebaut werden. Der

Platform Builder verwendet dazu ein ei-

genes Build-System, bestehend aus einer

Fülle von Hilfsprogrammen, Batch-Skrip-

ten und Makefiles. Dieses Build-System

stammt noch aus der ersten Version von

Windows CE und hat sich seitdem nicht

grundlegend geändert.

Der Platform Builder bietet vier Build-

Kommandos an, um den Übersetzungs-

prozess in verschiedenen Varianten zu

starten. Für eine komplette Neuerstellung

sorgt zum Beispiel Clean Sysgen. Außer-

dem lassen sich auch einzelne Kompo-

nenten bauen und bestimmte Schritte des

Build-Prozesses direkt aufrufen.

Nur der Modus Clean Sysgen stellt si-

cher, dass jedwede mögliche Änderung

berücksichtigt wird – dies beansprucht

aber viel Zeit. Nach den meisten Ände-

rungen kann der Entwickler eines der we-

sentlich schnelleren Build-Kommandos

oder eine Kombination von diesen ver-

wenden. Im Dokument Improving Your

Build Process erläutert Microsoft die Vari-

anten [2] [11] [12].

Seltsamerweise werden auch die bei-

den Build-Kommandos Build and Sysgen

und Rebuild and Clean Sysgen angeboten,

die Binaries unter PUBLIC unwieder-

bringlich löschen; anschließend ist eine

Neuinstallation des Platform Builders fäl-

lig! Gängige Praxis ist daher, diese Build-

Kommandos aus dem Menü zu entfernen.

Sie sind nur für die wenigen Auserwählten

gedacht, die den kompletten Quellcode

von Compact besitzen.

Hardware-Design für CompactAngenehm für die Arbeit mit Compact ist,

wenn das Hardware-Design noch ein paar

Kleinigkeiten berücksichtigt. Dazu gehört

beispielsweise, dass die Kommunikation

zwischen Debugger und Gerät über seri-

elle Schnittstelle, über Ethernet oder USB

stattfinden kann. Ideal ist wegen Latenz

und Durchsatz eine USB-Schnittstelle,

die aber ansonsten nicht verwendet wird.

Fast genauso schnell, aber einfacher zu

implementieren ist hingegen eine Ether-

net-Schnittstelle. Die serielle Schnittstelle

ist nur eine Notlösung.

Für die Debug-Serielle ist wegen der

Einfachheit der Ansteuerung ein norma-

ler UART (Universal Asynchronous Recei-

ver Transmitter) am besten geeignet. Bei

den ersten Schritten der Portierung sind

außerdem eine oder mehrere einfach an-

steuerbare LEDs sehr hilfreich.

Auch die endgültige Produktionsver sion

der Hardware sollte diese Debug-Hilfs-

mittel noch bieten. Um dem Zwang zum

Sparen bei der Herstellung zu genügen,

haben sich zum Beispiel eine optionale

Bestückung, ein Erweiterungsmodul oder

ein Debug-Adapter als hilfreich erwiesen.

FazitDas BSP passt Compact an eine Hardware-

Plattform an. Es besteht aus Bootloader,

einer Schicht zwischen Betriebssystemkern

und Hardware (dem OAL), einer Kommuni-

kationsinfrastruktur zum Debuggen (dem

KITL) und den Gerätetreiber.

Üblicherweise dient ein kopiertes BSP

für eine ähnliche Hardware-Plattform als

Ausgangspunkt und reduziert dadurch den

Aufwand bis zum laufenden Compact, un-

ter Umständen sogar fast bis auf null. Wahr-

scheinlich müssen aber noch das Speicher-

layout angepasst und einige Gerätetreiber

geschrieben werden. Danach wird Com-

pact mit einem OS-Design auf den Anwen-

dungszweck zugeschnitten.

Die Entwicklung eines Board Support

Packages setzt umfangreiche Kenntnisse

über Microsofts Embedded-Betriebssys-

tem voraus. Ein Artikel wie dieser oder

der vorausgegangene kann nur einen Ein-

stieg und Überblick bieten. Vertiefende

Einblicke bieten die MSDN-Bibliothek,

Dokumentationen auf der Windows-Em-

bedded-Website, Bücher und die – meist

einwöchigen – Schulungen. Speziell zum

Thema Qualitätssicherung sei noch ein-

mal auf den Artikel Käfer in Komponenten

in der vorigen Ausgabe der dotnetpro ver-

wiesen [4]. [jp] [1] Developing with Windows Embedded Com-

pact, www.dotnetpro.de/SL1203Embedded1 [2] Windows Embedded Compact 7 Top Task:

BSP Development: Board Support Packages, www.dotnetpro.de/SL1203Embedded2

[3] Samuel Phung, David Jones, Thierry Joubert, Professional Windows Embedded Compact 7, ISBN 978-1-118-05046-0

[4] Matthias Kraaz, Käfer in Komponenten, Qualitätssicherung in Windows-Embedded-Compact-Projekten, dotnetpro 2/2012, S. 72ff., www.dotnetpro.de/A1202Embedded

[5] Windows Embedded Developer Update 1.1, www.dotnetpro.de/SL1203Embedded3

[6] JTAG, www.dotnetpro.de/SL1203Embedded4 [7] CE Boot Framework,

www.dotnetpro.de/SL1203Embedded5 [8] MSDN, How to Develop a Boot Loader,

www.dotnetpro.de/SL1203Embedded6 [9] MSDN, Creating Driver Globals and Boot Args,

www.dotnetpro.de/SL1203Embedded7[10] MSDN, Stream Interface Drivers,

www.dotnetpro.de/SL1203Embedded8[11] MSDN, Sysgen Variables,

www.dotnetpro.de/SL1203Embedded9[12] MSDN, Miscellaneous Environment Variables

(Windows Embedded Compact 7), www.dotnetpro.de/SL1203Embedded10