Wie ein BSP unter Windows Embedded Compact angepasst wird

Anbieter zum Thema

Data Modul AG

MicroConsult Academy GmbH

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

Microsoft Deutschland GmbH

Hi IT GmbH

Anpassung eines BSPs

Anpassung eines BSPs

Die BSP-Entwicklung wird beschleunigt, indem ein vorhandenes Referenz-BSP geklont wird, anstatt ein neues BSP zu erstellen. Die Entwicklungszeit verkürzt sich, da der hardwareunabhängige Code wiederverwendet werden kann. Außerdem wird die künftige Migration zu neuen Windows-Embedded-Versionen verkürzt. Das Migrieren eines proprietären BSP-Designs ist im allgemeinen schwieriger als das Migrieren eines auf PQOAL basierenden Designs, da das proprietäre BSP die PQOAL-Codesegmente nicht nutzen kann, die Microsoft als Teil einer neuen Betriebssystemversion implizit migriert und testet.

Klonen eines Referenz-BSPs

Klonen eines Referenz-BSPs

Der Platform Builder 8 umfasst einen Wizard zum Klonen eines Referenz-BSPs. Dieser Wizard kopiert den gesamten Quellcode des ausgewählten Referenz-BSP in eine neue Ordnerstruktur, damit das BSP für die neue Hardware angepasst werden kann, ohne dass das Referenz-BSP oder andere BSPs in der %_WINCEROOT%-Ordnerhierarchie beeinflusst werden.

Die BSP-Ordnerstruktur

Die BSP-Ordnerstruktur

Um die Wiederverwendbarkeit des Codes sicherzustellen, unterstützen PQOAL-basierte BSPs eine allgemeine Architektur und Ordnerstruktur, die für alle Prozessorfamilien konsistent ist. Aufgrund dieser allgemeinen Architektur können große Quellcodeabschnitte unabhängig von den hardwarespezifischen BSP-Anforderungen wiederverwendet werden.

Plattformspezifischer Quellcode

Plattformspezifischer Quellcode

Der wichtigste anzupassende, plattformspezifische Quellcode ist der Quellcode für den Boot Loader, der OAL und die Gerätetreiber. Der entsprechende Quellcode ist im Src-Ordner in folgenden Unterverzeichnissen gespeichert:

• Src\Boot loader: Enthält den Boot Loader-Code. Wenn der Boot Loader von BLCOMMON und den entsprechenden Bibliotheken abhängig ist, ist nur der hardwarespezifische Teil des Boot Loaders in diesem Verzeichnis gespeichert. Der wiederverwendbare Boot-Loader-Code ist im Ordner Public (%_WINCEROOT%\Public\Common\Oak\Drivers\Ethdbg) verfügbar und als Bibliothek mit dem BSP-Abschnitt gelinkt.
• Src\Oal: Enthält nur den Mindestcode für die Hardwareplattform. Der meiste OAL-Code, der sich in %_WINCEROOT%\Platform\Common befindet, ist in hardwareunabhängige Gruppen sowie in Gruppen spezifisch für die Prozessorfamilie, Chipsets und Plattformen aufgeteilt. Diese Codegruppen umfassen die meisten OAL-Funktionen und sind mit den plattformspezifischen Komponenten als Bibliotheken gelinkt.
• Src\Common und Src\Drivers: Enthält den Treiberquellcode, der in unterschiedlichen Kategorien organisiert ist, um die Verwaltung und Portabilität zu unterstützen. Die Kategorien sind normalerweise prozessor- und plattformspezifisch. Die prozessorspezifische Komponente ist im Verzeichnis Src\Common gespeichert und muss für die Anpassung an neue Hardware, die auf der gleichen Prozessorfamilie basiert, nicht geändert werden.

Die Speicherzuordnungen

Die Speicherzuordnungen

Die erste Aufgabe bei der Anpassung bezieht sich auf die Definition der Speicherzuordnungen für den Boot Loader. Die Standard-BSPs in Windows Embedded Compact 7 definieren die Speicherkonfiguration in einer .bib-Datei im Boot Loader-Unterverzeichnis, beispielsweise %_WINCEROOT%\Platform\CEPC\Src\Boot loader\Eboot\Eboot.bib.

Der StartUp-Einsprungspunkt

Der StartUp-Einsprungspunkt

Der StartUp-Einsprungspunkt des Boot Loaders muss sich im linearen Speicher an der Adresse befinden, an der die CPU beginnt, den auszuführenden Code aufzurufen, da diese Routine die Hardware initialisiert. Wenn die Anpassung auf einem Referenz-BSP für den gleichen Prozessor-Komponenten basiert, muss der meiste Code für die CPU und den Speichercontroller nicht geändert werden.

Die StartUp-Routine ruft die Main-Funktion des Boot Loaders auf. Wenn der Boot Loader auf BLCOMMON basiert, ruft diese Funktion die Funktion BootLoaderMain auf, die den Downloadtransport initialisiert, indem die OEM-Plattformfunktionen aufgerufen werden.

Serielle Debugausgabe initialisieren

Serielle Debugausgabe initialisieren

Bei der Anpassung des Boot Loaders ist das Initialisieren der seriellen Debugausgabe erforderlich (OEMDebugInit). Die Debugausgabe ist ein wichtiger Teil des Startprozesses, da diese dem Benutzer das Interagieren mit dem Boot Loader und dem Entwickler das Analysieren der Debugmeldungen ermöglicht.

Initialisieren der Plattform

Initialisieren der Plattform

Nachdem die CPU und die serielle Debugausgabe initialisiert wurden, lassen sich die anderen Aufgaben für die Hardwareinitialisierung ausführen. Die OEM-PlatformInit-Routine initialisiert die Echtzeit-Uhr, konfiguriert den externen Speicher oder Flashspeicher und initialisiert den Netzwerkcontroller.

Download über Ethernet

Download über Ethernet

Wenn die Hardwareplattform einen Netzwerkcontroller umfasst, kann der Boot Loader das Run-Time-Image über Ethernet herunterladen. Dann müssen Funktionen, wie OEMReadData, OEMEthGetFrame, OEMEthSendFrame und OEMEthGetSecs implementiert werden.

Flashspeicher-Unterstützung

Flashspeicher-Unterstützung

Nachdem Sie die Funktionen für die Netzwerkkommunikation implementiert wurden, muss der Boot Loader aktivierr werden, um das Run-Time Image auf die neue Hardwareplattform herunterzuladen. Das Run-Time-Image kann im Flashspeicher gespeichert werden. Die Funktionen (OEMPreDownload, OEMIsFlashAddr), die für den Download- und Flashspeicherunterstützung aufgeführt sind, müssen implementieren werden.

(ID:356758)