Embedded Betriebssysteme Wie ein BSP unter Windows Embedded Compact angepasst wird

Mit der Echtzeit-Version von Windows Embedded Compact 7 (Community Technology Preview) können Programmierer ihre Embedded Geräte individuell entwerfen. Es lassen sich animierte Benutzeroberflächen mit Silverlight generieren oder es werden mehrere CPUs (Multi-Core) unterstützt. Außerdem lassen sich BSPs an die zugrundeliegende Hardware anpassen.

Anbieter zum Thema

MicroConsult Academy GmbH

E.E.P.D. Electronic Equipment Produktion & Distribution GmbH

Eurocircuits GmbH

Microsoft Deutschland GmbH

Hi IT GmbH

Typischerweise werden die Standard-BSPs von den jeweiligen CPU-Herstellern auf den Plattformen x86, MiPS, ARM und SHx oder von Microsoft selbst sowie den Board-Herstellern angepasst und zur Verfügung gestellt. OEMs benötigen jedoch ein BSP, um Windows Embedded Compact 7 auf eine neue Hardwareplattform zu portieren.

Windows Embedded Compact 7 umfasst eine PQOAL-Architektur (Production Quality OEM Adaptation Layer), um die Wiederverwendung von Code basierend auf OAL-Bibliotheken zu unterstützen, die nach Prozessormodell und OAL-Funktion organisiert sind. Ein BSP - Board Support Package - (Bild 1) ist ein Bindeglied zwischen der Hardware und dem Betriebssystem. Dort werden die jeweiligen Betriebssystemaufrufe an die zu Grunde liegende Hardware angepasst.

Dieser Beitrag zeigt eine bewährte Vorgehensweise, wie man ein vorhandenes BSP klont und dann an vorhandene Anforderungen anpasst, um die getesteten und bewährten Features für die Energieverwaltung und die Leistungsoptimierung ausnutzt.

Außerdem beschreibt der Artikel die PQOAL-Architektur, einschließlich das Klonen von BSPs und die Funktionen, die der OEM-Treiberentwickler implementieren muss, um Windows Embedded Compact 7 an neue Hardwarearchitekturen und Modelle anzupassen. Auch wird mit verschiedenen Aspekten der BSP-Anpassung vertraut gemacht. Die BSP-Anpassung umfasst auch das Ändern des Startprozesses und das Implementieren der Kernelinitialisierungsroutinen.

Anpassen und konfigurieren eines BSPs

Die Entwicklung eines BSPs (Bild 2) für eine neue Hardwareplattform beginnt normalerweise nach den funktionellen Hardwaretests unter Verwendung eines BOOT-Monitors und umfasst das Klonen eines entsprechenden Referenz-BSPs, beispielsweise CEPC für die x86-Familie, sowie das Implementieren eines Boot Loaders und der OAL-Basisfunktionen, um den Kernel zu unterstützen. Idealerweise würden sich hier auch Werkzeuge der Firma Lauterbach eignen, um ein angepasstes Image zu laden und zu testen.

Ein grundsätzlich anzustrebendes Ziel ist es, mit nur geringen Codeanpassungen ein startbares System zu erstellen. Anschließend können die Gerätetreiber und andere OS-Features zum BSP hinzugefügt oder auch entfernt werden.

Ein BSP besteht aus den folgenden Komponenten:

• Der Boot Loader wird beim Starten oder Zurücksetzen des Geräts ausgeführt. Er ist für das Initialisieren der Hardwareplattform und des Betriebssystems verantwortlich.
• Der OEM Adaptation Layer (OAL) Repräsentiert das Herzstück des BSP und die Schnittstelle zwischen dem Kernel und der Hardware. Da das BSP direkt mit dem Kernel gelinkt ist, ist es in einem CE Run-Time Image Teil des Kernels. Einige der Basiskernelkomponenten hängen für die Hardwareinitialisierung vom OAL ab, beispielsweise für die Interrupt- und Zeitgeberverarbeitung für den Threadscheduler.
• Die Gerätetreiber verwalten die Funktionen eines Peripheriegeräts und bilden die Schnittstelle zwischen der Gerätehardware und dem Betriebssystem. Windows Embedded Compact 7 unterstützt mehrere Gerätearchitekturen basierend auf den vorhandenen Schnittstellen.
• Die Konfigurationsdateien enthalten die zum Steuern des Buildprozesses und für das Design des Betriebssystems erforderlichen Informationen. Typische Konfigurationsdateien in einem BSP sind Sources-, Dirs-, Config.bib-, Platform.bib-, Platform.reg-, Platform.db-, Platform.dat- und Katalogdateien (*.pbcxml).

(ID:356758)