Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded Hardware portierbar. Das Treiberframework ist ausserdem auf einem herkömmlichen Windows PC lauffähig. Gerätetreiber können deshalb auf einem Windows PC implementiert und getestet werden und werden im Treiberframework auf dem Windows PC zusammen mit einer Hardware Simulation ausgeführt. Gerätetreiber können dadurch in einer einheitlichen Struktur implementiert und getestet werden, ohne das die embedded Hardware vorliegen muss. Ein Gerätetreiber wird nach erfolgtem Test auf dem Windows PC für das Zielsystem recompiliert und im Treiberframework auf dem Zielsystem ausgeführt( Source Code Kompatibilität ). Author: Hubert Schorr, ConCurrent Software GmbH Web: www.concurrent-software.de Mail: hubert.schorr@concurrent-software.de
Inhalt 1. Einführung... 3 2. Architektur... 4 3. Portierung... 7 4. Windows basiertes Treiberframework... 8 5. Erstellung von Gerätetreibern für das Treiberframework... 11 6. Ausblick... 13
1. Einführung Dieses Dokument beschreibt die Grobstruktur eines Treiberframeworks für embedded Systeme. Das Treiberframework selbst stellt dabei eine Laufzeitumgebung für Gerätetreiber dar, die für die Peripherie Komponenten von embedded Geräten entwickelt und getestet werden müssen. Die Zielsetzung des Treiberframeworks ist es: Gerätetreiber mit einheitlicher Struktur zu entwickeln eine Laufzeitumgebung für diese Treiber zu Verfügung zu stellen die Laufzeitumgebung auf jede embedded Hardware portieren zu können die Laufzeitumgebung auf einem Windows PC verwenden zu können eine Hardwaresimulation auf einem Windows PC zu Verfügung zu stellen den Gerätetreiber im Treiberframework auf einem Windows PC testen zu können In embedded Systemen werden Gerätetreiber in der Regel mit unterschiedlichen Basisarchitekturen designed, die im jeweiligen Ermessen des einzelnen Software Ingenieurs liegen. Da die Problemstellungen unterschiedlich sind und jeder Software Ingenieur eine andere Sichtweise des jeweiligen Problems hat, weichen die Design Resultate hinsichtlich der Treiberarchitektur mitunter stark von einander ab. Das Treiberframework schreibt eine gemeinsame Basisarchitektur zwinged vor, so dass alle Gerätetreiber, die im Framework ablaufen, wesentliche gemeinsame Designmerkmale aufweisen. Treiber, die unterschiedliche Hardware unterstützen und im Kern verschiedene Implementierungen aufweisen, besitzen dennoch eine gemeinsame Basis, die es ermöglicht auch unterschiedliche Treiber leichter zu erweitern und zu warten. Das Treiberframework implementiert eine für alle Treiber gleiche Laufzeitumgebung, in die die Treiber eingebettet sind und darin laufen. Das Treiberframework implementiert dabei Funktionalitäten, die für alle Treiber benötigt werden und die jeder Entwickler für jeden neuen Treiber wieder neu implementieren müsste. Die Laufzeitumgebung selbst stellt auch eine Laufzeitkomponente zu Verfügung, mit der es Applikationen ermöglicht wird, in einheitlicher Weise mit jeder Art von Gerätetreibern innerhalb des Frameworks zu kommunizieren.
2. Architektur Im folgenden wird die Architektur des embedded Treiberframeworks auf einem embedded Zielsystem beschrieben. Hardware HAL EDF Core System OSAL Device Driver PAL EDF Core System DDI Subsystem Application Abbildung 1: Treiberframework Architektur : Kundenspezifische Komponenten : Komponenten des Treiberframeworks
Die Komponente EDF Core System stellt das eigentliche Framework dar, in dem alle vom Anwender implementierten Gerätetreiber eingebettet sind und darin ablaufen. Das Framework implementiert dabei generische Funktionalität, wie sie von jedem Gerätetreiber benötigt wird. Das Treiberframework stellt dabei Funktionen zu Verfügung, die auf Framework Objekten, die von einem Gerätetreiber erzeugt werden können, Operationen ausführen. Die Funktionalität des Frameworks lässt sich wie folgt definieren: Laden und Entladen von Gerätetreibern Zugriff auf die Hardware über Hardware Abstraction Layer(HAL) Kommunikation mit dem Betriebssystem über den Operating System Abstraction Layer(OSAL) Bereitstellung eines generischen Mechanismus für die Kommunikation zwischen Treiber und Applikation( I/O Request Handling Konzept ) Interrupthandling Konzept DMA Handling Konzept Runtime Type Checking von Framework Objekten(zu und abschaltbar zum Compile Zeitpunkt) Erzeugen von Trace und Event Log Ausgaben(zu und abschaltbar zum Compile Zeitpunkt) Der Hardware Abstraction Layer(HAL) abstrahiert die Kommunikation mit der Hardware und weisst deshalb eine Plattform spezifische Implementierung auf. Die Basisfunktionalität des Hardware Abstraction Layers ist: Zugriff auf Hardware Register Verwalten einer Interrupt Vektor Tabelle, in die Gerätetreiber die Interrupt Funktionen für die Behandlung von Device Interrupts einhängen Verwalten von Builtin DMA Controllern
Der Platform Adaptation Layer(PAL) stellt dem Treiberframework System spezifische Plattform Informationen zu Verfügung: Zentrale Einsprungsfunktion der im System vorhandenen Builtin Treibern Hardware Resourcen, die von den jeweiligen Builtin Treibern verwendet werden, z.b. Interrupt Id, Product Id, Vendor Id, etc. Das DDI Subsystem implementiert die Kommunikation zwischen den Applikationen und den jeweiligen Treibern, die im Treiberframework laufen. Dabei kommt ein generischer I/O Request Mechanismus zum Einsatz, der es jeder Applikation erlaubt mit jedem beliebigen Gerätetreiber zu kommunizieren. Das DDI Subsystem ermöglicht es Applikationen Gerätetreiber zu laden Devices zu öffnen Daten auf ein Device zu schreiben Daten von einem Device zu lesen I/O Control Requests zu einem Device zu senden Devices zu schliessen Gerätetreiber zu entladen Dabei ist es auch möglich, das mehrere Applikationen zeitgleich mit einem Device kommunizieren, z.b. Daten lesen und/oder schreiben. Das DDI sorgt zusammen mit dem Treiberframework für die serielle Abarbeitung aller I/O Requests, die zu einem entsprechenden Gerätetreiber gesendet werden. Die Applikation selbst muss keine Synchronisationsmechanismen implementieren oder verwenden um die Kommunikation mit einem bestimmten Gerätetreiber Thread save zu machen.
3. Portierung Das Treiberframework ist im Prinzip auf jede embedded Plattform portierbar. Für die Portierung müssen folgende Komponenten für die jeweilige Plattform eine Plattform spezifische Implementierung aufweisen: Hardware Abstraction Layer(HAL) Platform Adaptation Layer(PAL) Operating System Abstraction Layer(OSAL) Das Framework selbst, inklusive des DDI Subsystems muss nicht portiert werden. Alle Abhängigkeiten zur Plattform werden von den oben angegebenen Komponeten implementiert. Das Framework selbst muss lediglich für die jeweilige CPU Architektur compiliert werden. Um das Framework auf ein Zielsystem zu portieren, müssen die oben angegebenen Abstraction Layer für das entsprechende Zielsystem implementiert werden. Das Framework selbst, sowie die Gerätetreiber, die darin laufen, müssen nicht portiert werden. Durch entsprechende Implementierungen der Abstraction Layer auf Win32 Basis kann das komplette Framework auf einen Windows PC portiert und dort für die Treiber Entwicklung und den Treiber Test verwendet werden. Um Gerätetreiber auf einem Windows PC zu implementieren und zu testen, wird das komplette Framework in ein zusätzliches Laufzeitsystem integriert. Dieses Laufzeitsystem ist Windows spezifisch und ermöglicht einer graphischen Oberfläche mit diesem Laufzeitsystem zu kommunizieren.
4. Windows basiertes Treiberframework Das Treiberframework weisst eine Win32 spezifische Implementierung der Portierungskomponenten, HAL, PAL und OSAL auf. Somit ist das gesamte Treiberframework unter Windows lauffähig. Die folgende Abbildung zeigt die Architektur des auf Windows portierten Treiberframeworks. Abbildung 2: Auf Windows poriertes Treiberframework Die obige Abbildung zeigt die Architektur des auf Windows portierten Treiberframeworks. Lediglich die Komponenten HAL, PAL und OSAL weisen eine entsprechende Win32 basierte Implementierung auf. Das eigentliche Treiberframework sowie das DDI Subsystem werden in ihrer Implementierung nicht verändert, sondern nur für das Windows Zielsystem mit dem Microsoft Developer Studio compiliert.
Zusätzlich zu den bereits vorhandenen Komponenten des Treiberframeworks werden für die Windows basierte Version noch folgende Komponenten benötigt: EMDS GUI EDF Middleware Hardware Simulation Die graphische Oberfläche des Embedded Driver Studios(EMDS GUI) erlaubt das Erstellen von Testcases sowie das Testen von erstellten Gerätetreibern unter Windows. Abbildung 3: Graphische Oberfläche des Embedded Driver Studios(EMDS) Das EMDS stellt dabei die Funktionalität zu Verfügung die benötigt wird, um für das Treiberframework erstellte Gerätetreiber zu testen. Das EMDS ermöglicht es Gerätetreiber zusammen mit der Hardware Simulation zu testen, ohne dass die eigentliche Zielhardware vorhanden sein muss. Der Anwender kann im zu testenden Treiber entsprechende Trace Ausgaben implementieren, die während des Tests unter Windows vom EMDS in einem entsprechenden Fenster ausgegeben werden.
Das Treiberframework führt für Funktionen, die von Gerätetreibern aufgerufen werden, Laufzeitüberprüfungen durch. Wird bei einer solchen Überprüfung ein möglicher Fehler festgestellt, wird das EMDS darüber informiert und gibt eine entsprechende Meldung in einem Event Log Fenster aus. Auf diese Weise können z.b. Fehler in der Verwendung der Framework API während des Tests erfasst und vom Anwender korrigiert werden. Die EDF Middleware bildet das Interface zwischen der graphischen Oberfläche und dem Laufzeitsystem des Treiberframeworks. Die Hardware Simulation ist eine vom Anwender erstellte Win32 DLL, die eine vom Treiber zu steuernde Hardware auf Registerebene simuliert. Diese DLL muss eine enstprechende API implementieren, die von der EDF Middleware verwendet wird, wenn der Anwender über das EMDS einen Test initiiert. Bei der Implementierung der Hardware Simulation auf Register Ebene kann der Anwender auf den Hardware Abstraction Layer zurück greifen, der auch vom zu testenden Gerätetreiber verwendet wird. Die Implementierung des HAL enthält unter Windows ein entsprechendens Event System mit der Zugriffe auf Hardware Register mit dem Gerätetreiber synchronisiert werden. Das heisst, die Hardware Simulation läuft mit dem Gerätetreiber synchron. Schreibt z.b. ein Gerätetreiber auf ein Hardware Register, welches nur gelesen werden darf, generiert der HAL eine entsrpechende Fehlermeldung. Auf diese Weise werden bereits Hardware abhängige Fehlerquellen während des Tests unter Windows erkannt und behoben.
5. Erstellung von Gerätetreibern für das Treiberframework Bei der Erstellung von Gerätetreibern, die im Treiberframework ausgeführt werden sollen, muss wie folgt vorgegangen werden. Schritt 1: Nach erfolgtem Design wird der Gerätetreiber unter Windows als Win32 DLL implementiert. Die Implementierung muss dabei alle Event Handler beinhalten, die vom Treiberframework aufgerufen werden. Schritt 2: Für den späteren Test muss die Simulation für die Hardware implementiert werden, die der Gerätetreiber bedienen soll. Die Implementierung der Hardware Simulation erfolgt dabei als Win32 DLL. Wie detail getreu dabei die Implementierung ausfällt, liegt im Ermessen des Anwenders. Da es sich hierbei um eine Simulation auf Register Ebene handelt, können nur die jeweiligen Zugriffe auf die Register implementiert werden, die für den jeweiligen Testcase notwendig sind. Schritt 3: Um Daten von dem zu testenden Treiber zu lesen oder Daten zu schreiben, muss vom Anwender eine Test Applikation implementiert werden, die unter Verwendung des DDI Subsystems mit dem Gerätetreiber kommuniziert. Diese Test Applikation wird ebenfalls als Win32 DLL implementiert. Schritt 4: Der Gerätetreiber kann einem ersten Test unterzogen werden. Dabei wird durch das EMDS ein entsprechender Testcase erzeugt und ausgeführt. Bei der Ausführung des Testcases werden vom System alle vom Anwender erstellten Komponenten, der Gerätetreiber, die Hardware Simulation und die Test Applikation geladen und ausgeführt. Da es sich beim Test um einen iterativen Prozess handelt, werden nach Fehlerbehebungen im Gerätetreiber die entsprechenden Tests wiederholt, ggf. mit einer modifizierten Hardware Simulation und Test Applikation.
Schritt 5: Nachdem alle Tests unter Windows erfolgreich durchgeführt worden sind, wird der Gerätetreiber für das Zielsystem recompiliert und in das Targetimage eingebracht. Der Gerätetreiber läuft dann innerhalb des Treiberframeworks auf dem Zielsystem. Da der Gerätetreiber vom Treiberframework auf dem Zielsystem ausgeführt wird, müssen keine Änderungen mehr am Treiber Code vorgenommen werden(source Code Kompatibilität). Durch den Test auf dem Windows PC können Fehler im Treiber schneller erkannt und behoben werden. Ausserdem kann der Treiber entwickelt und unter Windows getestet werden, bevor überhaupt die Zielhardware zu Verfügung steht.
6. Ausblick Im nächsten Schritt wird im Treiberframework die Möglichkeit geschaffen, geschichtete Treiber Modelle zu implementieren. Das Treiberframework linkt die entsprechenden Treiber zu einem Treiberstack und ermöglicht die Kommunikation von Geräte Treibern untereinander innerhalb eines Treiberstacks. Abbildung 4: Device Driver Stack Die obige Abbildung zeigt ein Beispiel einer Treiber Implementierung als Device Driver Stack. Der Treiber besteht dabei aus einem High Level Teil und einem Low Level Teil. Algemeine Aufgaben werden dabei im High Level Treiber implementiert und Hardware nahe Teile im Low Level Treiber. Der Aufbau des Treiber Stacks sowie die Kommunikation der Treiber untereinander wird vom Treiberframework übernommen. Die Stack Architektur ist dabei nicht auf ein zwei geschichtetes Modell begrenzt.