Sensoransteuerung unter Windows Embedded Compact 7 und Kalibrierdatenerfassung am PC

Sensoransteuerung unter Windows Embedded Compact 7 und Kalibrierdatenerfassung am PC eingereicht am 24.04.2014 von Patrick Beutner | Aleksis-Kivi-Str...
Author: Claudia Lehmann
2 downloads 2 Views 3MB Size
Sensoransteuerung unter Windows Embedded Compact 7 und Kalibrierdatenerfassung am PC

eingereicht am 24.04.2014 von Patrick Beutner | Aleksis-Kivi-Str. 7 | 18106 Rostock Matrikel-Nr.: 210207788 Betreuender Hochschullehrer:

Betreuer:

Prof. Dr.-Ing. Dirk Timmermann

Dr.-Ing. Frank Papenfuss

Universität Rostock

und

Richard Wagner Straße 31

Dipl.-Ing. Philipp Gorski

18119 Rostock‐Warnemünde

Bachelorarbeit Fakultät für Informatik und Elektrotechnik | ET

Inhaltsverzeichnis Inhaltsverzeichnis

I

Abk¨ urzungsverzeichnis

III

¨ Uberblick

V

1 Einleitung

1

2 Grundlagen eingebetter Systeme 2.1 Definition . . . . . . . . . . . . . . . 2.2 Eigenschaften . . . . . . . . . . . . . 2.3 Treiber . . . . . . . . . . . . . . . . . 2.4 Betriebssysteme . . . . . . . . . . . . 2.4.1 Auswahlanforderungen . . . . 2.4.2 Minimale Betriebssysteme . . 2.4.3 QNX-Neutrino RTOS . . . . . 2.4.4 Windows Embedded Compact 2.4.5 Embedded Linux . . . . . . . 2.4.6 VxWorks . . . . . . . . . . . . 3 USB Grundlagen 3.1 Entwicklung des Standards 3.2 Geschwindigkeitsklassen . 3.3 Hardware Architektur . . 3.4 Software Architektur . . . 3.5 Kommunikationsprotokoll 3.6 Kommunikationsmodell . . 3.6.1 Transferarten . . . 3.6.2 Deskriptoren . . . 3.6.3 Device Requests . . 3.7 Enumerationsvorgang . . . 3.8 Ger¨ateklassen . . . . . . . 3.9 HID Eigenschaften . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . 7 . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

3 3 3 4 6 7 8 9 10 14 18

. . . . . . . . . . . .

20 20 21 21 23 24 27 28 29 30 32 33 34

4 Funktionalit¨ at des Sensor-API

37

5 Anforderungsanalyse

39

I

6 Entwurf 6.1 Realisierung als HID-Ger¨at . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Struktur der Softwarekomponenten . . . . . . . . . . . . . . . . . . . . . 6.3 Vergleich der Datenraten . . . . . . . . . . . . . . . . . . . . . . . . . . .

40 40 40 41

7 Implementierung 7.1 Dateiorganisation . . . . . . . . . . . 7.2 Klassen¨ ubersicht . . . . . . . . . . . 7.3 Sensoradaption und Konfiguration . . 7.4 Bereitstellung der Schnittstelle . . . . 7.5 Verwendung der Treiberkomponente . 7.6 Host-PC-Applikation . . . . . . . . .

49 49 50 51 55 56 57

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

8 Res¨ umee und Ausblick

60

Literaturverzeichnis

61

Abbildungsverzeichnis

64

Tabellenverzeichnis

65

Listingverzeichnis

66

Anhang A

67

Anhang B

67

II

Abku ¨rzungsverzeichnis ABS API CE CPU DIN DLL DSP EHCI eKon

-

ESP FTP GPL GUID GWES HAL HID I2C IO ISO JTAG MDD MMU NASA OHCI PDD RTOS SoC SOF SPS TELNET UHCI USB

-

Antiblockiersystem Application Programming Interface Compact Embedded, Compact Edition Central Processing Unit Deutsches Institut f¨ ur Normung Dynamic Link Library Digitaler Signalprozessor Enhanced-Host-Controller-Interface elektronische Bausachstandserfassung f¨ ur Konstruktions¨anderungen im schiffbaulichen Fertigungsprozess Elektronisches Stabilit¨atsprogramm File Transfer Protocol General Public License Globally Unique Identifier Graphics, Windowing and Events Hardware Abstraction Layer Human-Interface-Device Inter-Integrated Circuit Input/Output International Organization for Standardization Joint Test Action Group Model Device Driver Memory Management Unit National Aeronautics and Space Administration Open-Host-Controler-Interface Platform Dependent Driver Real-Time Operating System System-on-Chip Start-Of-Frame Speicher-Programmierbare-Steuerung Telecommunication Network Universal-Host-Controller-Interface Universal-Serial-Bus

III

¨ Uberblick Die vorliegende Arbeit widmet sich der Realisierung eines USB-Function-Treibers auf einem Windows Embedded Compact 7 System. Um einen Entwurf und eine anschließende Implementierung zu erm¨oglichen, werden die vorhandenen Hard- und Softwarekomponenten untersucht. Auf Basis der Untersuchungsergebnisse hinsichtlich ¨ ¨ Ubertragungsverhalten und Datenaufkommen wird ein Ubertragungsmechanismus unter Nutzung der Human-Interface-Device Klasse modelliert. Mit Verwendung, der in dieser Arbeit entwickelten Softwarekomponente, kann die zur Verf¨ ugung stehende Hardware als USB-Ger¨at an einem PC- oder Android-Sysstem genutzt werden. Die beabsichtigte Kalibrierdatenerfassung, der angeschlossenen Sensoren, kann PC-seitig erfolgen.

V

1 Einleitung F¨ ur die Realisierung des eKon-Projektes1 (elektronische Bausachstandserfassung f¨ ur Konstruktions¨anderungen im schiffbaulichen Fertigungsprozess) arbeiten die FORTecH Software GmbH, 3DInteraktive GmbH und Fraunhofer IGD seit dem 15.03.2012 zusammen. Der Bau eines Schiffes ist ein komplexer und langwieriger Fertigungsprozess. W¨ahrend dieses Prozesses ist es unerl¨asslich, regelm¨aßig den aktuellen Baufortschritt zu dokumen¨ tieren. Design¨anderungen w¨ahrend des Baus, aufgrund von Anderungen von Einzelteilen oder aus anderen praktischen Gr¨ unden m¨ ussen dokumentiert und in das Planungsmodell zur¨ uckgef¨ uhrt werden. Bisher muss der Bausachstand durch eine Ortsbegehung ermittelt werden. Dabei werden von Hand Geometriedaten mittels Laserscanner ermittelt und anschließend in die Planungsumgebung u ¨bertragen. Dieser Prozess des Begehens und nachtr¨aglichen Einpflegens ist sehr zeit- und somit kostenintensiv. Im Rahmen des 2 Jahre andauernden eKon-Projektes soll eine Hardware entwickelt werden, welche unmit¨ telbar bei der Begehung Geometriedaten erfasst und zus¨atzlich Anderungen, Bilder und Bemerkungen in das digitale Schiffmodell einf¨ ugt. Genutzt wird daf¨ ur ein Sensormodul welches an handels¨ ubliche Smartphones bzw. Tablet-PC angeschlossen wird und deren Funktionalit¨at erweitert. Die gr¨oßte Herausforderung des Projektes liegt in der genauen Positions- und Ortsbestimmung im Rumpf eines Schiffes. In der nicht pr¨aparierten Umgebung aus Stahl, welche wie ein Faradayscher K¨afig wirkt, m¨ ussen L¨osungen zur robusten Datenerfassung und m¨oglichst echtzeitf¨ahige Synchronisation mit dem digitalen Modell realisiert werden. Die zu entwickelnde Hardware soll somit Daten erfassen, f¨ ur die weitere Verwendung aufbereiten und m¨oglichst in Echtzeit die Daten auf dem u ¨bergeordneten System zur Verf¨ ugung stellen. Die im Ekon-Projekt zu entwickelnden L¨osungen finden ihre Einsatzm¨oglichkeiten nicht ausschließlich im Schiffbau. Wie im Schiffbau, trifft man in anderen Bereichen, wie im Anlagenbau, Großmaschinenbau oder allgemein in anderen Teilen der Bauwirtschaft auf ¨ahnliche Bedingungen. Im Bereich der Einzelanfertigung bzw. bei Großprojekten kann ein Assistenz System, wie es aus dem eKon-Projekt hervorgehen soll, zu einer stark verbesserten Zeit- und Kosteneffizienz f¨ uhren. ¨ Die Ubermittlung der Sensor- und Posendaten, von der Windows Embedded Compact 7 Plattform an andere Systeme, ist essentiell f¨ ur die Weiterentwicklung des Projektes. Durch die Einrichtung der Daten¨ ubertragung wird die Entwicklung eines Kalibiersystems f¨ ur die verwendeten Sensoren erm¨oglicht und die Verwertung der Posendaten auf der Android-Ger¨ateseite. Ziel dieser Arbeit ist die Realisierung eines ¨ Ubertragungsmechanismus f¨ ur die genannten Anwendungsf¨alle. Da das eKon-Project als Embedded-Platform umgesetzt wird, wird im ersten Abschnitt der Arbeit auf die ¨ Grundlagen von eingebetteten Systemen eingegangen und ein Uberblick u ugbare ¨ber verf¨ 1

F¨ ur weitere Informationen siehe http://www.3dmaritim.de/de/node/63

1

¨ Betriebssysteme im embedded-Bereich gegeben. Die Grundlagen der USB-Ubertragung werden im darauffolgenden Abschnitt erl¨autert, um ein besseres Verst¨andnis f¨ ur die weiteren Teile der Arbeit beim Leser aufzubauen. An die Grundlagen schließt sich die Analyse der vorhanden Komponenten und daraus resultierend der Entwurf der ben¨otigten Softwarekomponenten an. Darauf folgt die Darstellung, wie die entworfenen Komponenten umgesetzt und ins bestehende System integriert wurden. Abschließend erfolgt eine Betrachtung der umgesetzten Aufgaben und ein Ausblick auf die weitere Entwicklung.

2

2 Grundlagen eingebetter Systeme Die zu bearbeitende Aufgabe erfordert die Implementierung von Softwarekomponenten f¨ ur bzw. auf einem eingebetteten System. Im folgenden Abschnitt der Arbeit werden daher die wesentlichen Eigenschaften solcher Systeme kurz erl¨autert. Im Weiteren wird auf die verschiedenen Realisierungsm¨oglichkeiten, der aktuell verbreiteten eingebetteten Betriebsysteme, anhand von ausgew¨ahlten Beispielen eingegangen.

2.1 Definition Im Bereich der Hard- und Softwareentwicklung gibt es verschiedene Definitionen bzw. Definitionsversuche f¨ ur den Begriff des eingebetteten Systems. Eine einheitliche Definition laut DIN oder ISO gibt es nicht. Eingebettete Systeme werden oft durch ihre Eigenschaften und Anwendungsf¨alle charakterisiert. Die Autoren von Embedded Linux“ versuchen sich an einer Definition anhand der Ei” genschaften: Der Begriff des eingebetteten Systems bezeichnet einen Rechner (Mikro” controller, Prozessor, DSP, SPS), welcher dezentral in einem technischen Ger¨at, in einer technischen Anlage, allgemein in einem technischen Kontext eingebunden (eingebettet) ist. Dieser Rechner hat die Aufgabe, das eingebettete System zu steuern, zu regeln, zu u ur die vorlie¨berwachen oder auch Benutzerinteraktion zu erm¨oglichen und ist speziell f¨ gende Aufgabe angepasst“ [SGD09, S. 17]. Peter Marwedel gibt eine Definition in einem Satz: Embedded systems are information processing systems embedded into enclosing ” products“ [Mar10].

2.2 Eigenschaften Eingebette Systeme verrichten u.a. Funktionen, wie Steuerung, Regelung, Datenauswertung und Daten¨ ubertragung. Durch die Integration in das Gesamtsystem, bleiben dem Anwender die genauen Arbeitsabl¨aufe weitestgehend verborgen. Die Definition und Erkl¨arung eingebetteter Systeme erfolgt h¨aufig anhand ihrer Eigenschaften. Diese Eigenschaften ergeben sich aus ihrem Anwendungszweck bzw. durch die genaue Anpassung an ihre Aufgaben. Die wichtigsten Eigenschaften sind: ˆ Verl¨ asslichkeit ˆ Echtzeitf¨ ahigkeit ˆ Formfaktoren und Konzeption f¨ ur Massenproduktion ˆ Umweltbedingungen

3

Laut Marwedel ist die Verl¨asslichkeit eines der wichtigsten Merkmale eines eingebetteten Systems. Diese Eigenschaft l¨asst sich weiter in folgende Eigenschaften untergliedern: ˆ Zuverl¨ assigkeit: Wahrscheinlichkeit, dass kein Ausfall stattfindet. ˆ Wartbarkeit: Wahrscheinlichkeit, dass bei einem Ausfall innerhalb einer bestimm-

ten Zeit ein funktionierender Zustand wieder hergestellt werden kann. ˆ Verf¨ ugbarkeit: Wahrscheinlichkeit, dass das System korrekt arbeitet. ˆ Sicherheit: Die Eigenschaft, dass das System im Falle eines Ausfalls keinen Schaden

verursacht. Bedingt durch ihren Einsatzzweck, z.B. in sicherheitsrelevanten Anwendungen wie Antiblockiersystem (ABS) oder elektronischem Stabilit¨atsprogramm (ESP), werden zus¨atzlich zur Verl¨asslichkeit h¨aufig Echtzeitanforderungen an die Systeme gestellt. Im Weiteren wird f¨ ur Echtzeit vereinfacht angenommen, dass die Wechselwirkungen zwischen dem System und seiner Umwelt exakt vorhersagbar sind und es garantierte Antwortzeiten auf alle m¨oglichen Vorkommnisse gibt. F¨ ur eine detaillierte Erkl¨arung von Echtzeit und den einzelnen Teilfaktoren sei auf [WB05] verwiesen. Da eigebettete Systeme in vielen F¨allen f¨ ur den Massenmarkt2 konzipiert und in großer St¨ uckzahl produziert werden, spielen Kostenfaktoren eine große Rolle. Durch zunehmende Integration sind relativ große Einsparungen m¨oglich. Im Rahmen der Integration werden Prozessor, Speicher und Peripheriefunktionen auf einem Chip vereint. Diese Zusammenfassung, von Funktionen auf einem Chip, wird als System-on-Chip (SoC) bezeichnet [FK14]. Im Gegensatz zum Standard-PC werden eingebette Systeme bereits mit Abmessungen von wenigen Zentimetern hergestellt. Aufgrund der Einsatzumgebung der Systeme, z.B. im Automobil, Hochtemperatur f¨ uhrenden Industrieanlagen oder der Witterung ausgesetzt, ergeben sich spezifische Designanforderungen, um die bereits genannten Eigenschaften gew¨ahrleisten zu k¨onnen [Ber01, Mar10].

2.3 Treiber Ger¨atetreiber (Treiber) sind Softwarekomponenten, welche Schnittstellen zwischen dem Betriebssystem und einer oder mehrerer Hardwarekomponenten herstellen. In einfachen Systemen k¨onnen sie eine Liste von Funktionen darstellen, die einer Anwendungsapplikation zur Verf¨ ugung gestellt wird, um auf Hardwarekomponenten zuzugreifen.

2

Ausnahmen stellen Systeme von geringen St¨ uckzahlen, wie z.B. der Marsrover Opportunity der NASA dar.

4

In komplexeren Betriebssystemen werden Treiber oft als eigenst¨andige Programmteile realisiert, die vielf¨altige Aufgaben bearbeiten k¨onnen bzw. m¨ ussen. Ein Ger¨atetreiber kapselt die Hardwaredetails und stellt eine einheitliche Programmierschnittstelle f¨ ur alle Applikationen bereit. Die Einordnung eines Treibers ins Gesamtsystem ist in Abbildung 1 dargestellt [Abb11].

Abbildung 1: Treiberkomponente im Gesamtsystem Abh¨angig vom verwendeten System k¨onnen bzw. m¨ ussen folgende Aufgaben von einem Treiber bearbeitet werden. Eine Treiberkomponente muss eine Initialisierung vornehmen k¨onnen, d.h. Verarbeitungsvariablen mit Standardwerten belegen und Speicherpuffer im System reservieren um eingehende und ausgehende Daten weiter verarbeiten zu k¨onnen. Weiterhin sollte ein Treiber in der Lage sein festzustellen, ob die zu steuernde Hardwarekomponente angeschlossen und betriebsbereit ist. Zu den Hauptaufgaben z¨ahlt die Bearbeitung von Steuerungs-, Ein- und Ausgabeaufforderungen(Requests) und Weiterleitung der entsprechenden Daten, um den Zugriff auf die Hardware zu gew¨ahrleisten. Zus¨atzlich kann der Treiber auch eine Filteraufgabe u ultige Anweisungen an die angeschlossenen Komponenten weiter¨bernehmen, um nur g¨ ¨ zugeben. Eine weitere Aufgabe, w¨ahrend der Laufzeit, ist die Uberwachung des Ger¨ates. Dazu z¨ahlt das Feststellen der Zust¨ande, welche die Hardware annehmen kann und die Behandlung von Fehlerf¨allen und Time-Outs. Da eingebettete Systeme oft als mobile, akkubetriebene Ger¨ate realisiert sind, u ¨bernimmt der Treiber, in vielen F¨allen, das Power-Management. Wird die ben¨otigte Hardwarekomponente nicht verwendet, versetzt der Treiber diese in einen stromsparenden Modus bzw. schaltet diese aus. ¨ Um bei komplexen Aufgaben die Ubersicht zu wahren und die M¨oglichkeit der Wiederverwendbarkeit zu gew¨ahrleisten, werden Treiber modular aufgebaut und geschichtet. Man spricht dann von einem Treiberstapel, in dem jedes Modul spezielle Aufgaben abarbeitet und die Ergebnisse an das n¨achste Software-Modul weiterleitet [Can99]. In Abbildung 2 sind der Aufbau und die Integration ins Gesamtsystem des Treiberstapels dargestellt. Durch die Performancesteigerung, welche Multitasking und Multithreading durch die

5

Abbildung 2: gestapelte Treibermodule im Gesamtsystem Betriebsysteme bereitstellen, ergibt sich die Anforderung nach der Threadsicherheit von Treibern. Unter Threadsicherheit wird verstanden, dass 2 oder mehr Threads parallel auf die gleiche Softwarekomponente zugreifen k¨onnen, ohne dass ein unerwartetes Verhalten auftritt [Rou14]. Ob ein Treiber threadsicher realisiert werden muss oder nicht, h¨angt von seiner sp¨ateren Verwendung ab. Wird der Treiber nicht threadsicher realisiert, ist die verwendende Anwendung daf¨ ur zust¨andig, dass keine Datenkonflikte und ¨ Uberlagerungen auftreten.

2.4 Betriebssysteme F¨ ur einfache eingebettete Systeme wird im Normalfall kein eigenes Betriebssystem genutzt. Stattdessen wird eine Firmware entwickelt, welche die ben¨otigten Funktionen abdecken kann. Diese Firmware wird als Hardware Abstraction Layer(HAL) bezeichnet. Die HAL stellt Schnittstellen f¨ ur angeschlossene Hardware bereit (f¨ ur weitere Aufgaben der HAL vergl. [NET14, S. 23]). Die Verwaltung der vorhandenen Resourcen sowie die anwendungsspezifische Funktion sind nicht voneinander getrennt [Jor04]. Mit gr¨oßer werdender Komplexit¨at, der zu bew¨altigenden Aufgabe, wird der Einsatz eines Betriebssystems sinnvoll. Muss ein System Eingaben, Ausgaben, Verarbeitung von Messwerten und externe Interrupts bearbeiten wird die Entwicklung einer eigenst¨andigen Software f¨ ur den Hersteller unwirtschaftlich. Firmware ist speziell auf eine Hardware¨ konfiguration ausgelegt. Anderungen und Portierungen auf andere Hardware gestalten sich aufwendig. Anstelle von starrer Firmware, kann auf die Grundfunktionen eines Betriebssystems zur¨ uckgegriffen werden, welches zumindest f¨ ur Standardanforderungen, definierte L¨osungen bereitstellt. Diese L¨osungen umfassen unter anderem die Zuteilung von

6

Rechenzeit f¨ ur verschiedene Prozesse, die Verwaltung des Arbeitsspeichers und die Bereitstellung eines Dateisystems. Viele Betriebssysteme sind nach Aspekten modelliert, welche Erweiterbarkeit, Skalierbarkeit, Robustheit und Sicherheit garantieren [KIT14]. Weiterhin definiert ein Betriebsystem die Schnittstellen, u ¨ber welche auf die angeschlossene Hardware zugriffen werden kann. Dies vereinfacht die Implementierung eines hardwarespeziefischen Treibers. Die Vielzahl der Anwendungsgebiete, mit unterschiedlichen Anforderungen an die Systeme, spiegelt sich in der Anzahl der verf¨ ugbaren Betriebssysteme wieder. Die folgende (unvollst¨andige) Auflistung einiger Betriebssysteme verdeutlicht diese Aussage. QNX, VxWorks, Nucleus, freeRTOS, Osek, Os-9, RTEMS, eCos, NetBSD, Windows CE/ Embedded Compact, Windows 7 Embedded, Windows Automotive und Symbian sind nur ein geringer Anteil der verf¨ ugbaren und genutzten eingebetteten Betriebssysteme3 . Wie im Desktop-PC Bereich werden die Betriebssysteme als Grundlage genutzt, um auf diesen eine Anwendung zur Bearbeitung des jeweiligen Problems bereitzustellen. Entsprechend der Anforderungen an eingebettete Systeme, gelten diese f¨ ur deren Betriebsysteme. Anhand der Anforderungen, welche an ein eingebettetes Betriebssystem gestellt werden, unterscheidet sich dieses deutlich von einem standard Desktop-PC Betriebssystem [Yag03]. 2.4.1 Auswahlanforderungen Eine Hauptanforderung bzw. Hauptkriterium f¨ ur die Auswahl eines Betriebssystems ist dessen Konfigurierbarkeit. Nicht ben¨otigte Komponenten sollten entfernt werden k¨onnen, um Ressourcen einzusparen. Andere Komponenten die ben¨otigt werden, sollten auf unkomplizierte Weise zum System hinzugef¨ ugt werden k¨onnen. Aufgrund der Einsatzgebiete eingebetteter Systeme wird f¨ ur deren Betriebssysteme h¨aufig, wie f¨ ur das Gesamtsystem, eine Echtzeitf¨ahigkeit gefordert. Um diese F¨ahigkeit bereitzustellen, muss das Betriebssystem bestimmten Anforderungen gen¨ ugen. Der Nachweis f¨ ur diese Echtzeitf¨ahigkeit erfolgt nach verschiedenen Kriterien und Zertifizierungsans¨atzen (vergl. [WB05]). Mit zunehmender Komplexit¨at der Systeme kann es notwendig werden, mehrere Prozesse quasi parallel ablaufen zu lassen und innerhalb eines Prozesses verschiedene Aufgaben gleichzeitig zu bearbeiten. Durch die Verwendung mehrerer Rechenkerne, kann eine echte parrallele Abarbeitung mehrerer Tasks erfolgen. Diese Eigenschaften werden als Multitasking und Multithreading bezeichnet [TI14]. Durch die Entwicklung von Multitastking und Multithreading sollte die Kontrolle von Hardware zentral erfolgen, um Daten- und Kontrollkonflikte zu verhindern. Um eine zentralisierte Hardwarekontrolle zu realisieren gibt es nach A. Kcholi zwei M¨oglichkeiten. Die erste M¨oglichkeit besteht 3

Weitere Informationen zu den einzelnen Betriebsystemen, siehe Anhang A.

7

darin, zu einem Zeitpunkt, nur einer einzigen Anwendung Zugriff auf die Hardware zu erlauben. Die zweite M¨oglichkeit besteht darin, dass das Betriebssystem die komplette Verwaltung der Zugriffe f¨ ur alle Anwendungen und Prozesse u ¨bernimmt [Kch11]. Eine weitere Anforderung ist die Unterst¨ utzung von Peripherieger¨aten und die Bereitstellung von Standardtreibern, um eine einfache Erweiterung des Gesamtsystems erm¨oglichen zu k¨onnen. Wird die Ansteuerung eines externen Ger¨ates bzw. einer Hardwarekomponente nicht durch die Grundfunktionen des Betriebssystems abgedeckt, muss eine entsprechende Treibersoftware bereitgestellt werden, um die ben¨otigten Funktionen zu nutzen. 2.4.2 Minimale Betriebssysteme Eingebette Systeme im Comsumer-Bereich werden oft in sehr großen St¨ uckzahlen produziert. Ein Mehraufwand in den Entwicklungskosten kann durch die Verminderung der Fertigungskosten kompensiert werden. F¨ ur einfache Systeme und deren Funktion reichen minimale Hardwareresourcen aus, abh¨angig von der Anwendung. Daher verwenden diese oft einen einzelnen, g¨ unstigen Microcontroller. Auf einem Microcontroller ist die Verwendung eines ressourcenhunrigen Unix oder Windows basiertem Betriebsystems nicht m¨oglich bzw. nicht n¨otig. Aufgrund der Anforderungen werden angepasste Firmwarevarianten verwendet, welche die Grundfunktionen bereitstellen. Bei diesen Minimalbetriebssystemen wird nicht zwischen Systemkomponenten(wie Treibern) und Anwendungskomponenten unterschieden. Die vom Betriebssystem bereitgestellte Funktionalit¨at ist oft auf die Anforderung bestimmter Kriterien angepasst. Zu diesen Kriterien z¨ahlen Unterst¨ utzung bestimmter Prozessoren, Einhaltung harter Echtzeitbedingungen, Prozess- und Eventmanaging. Aufgrund des geringeren Softwareumfangs ist es m¨oglich, Zeit- und Sicherheitsanforderungen nachweislich pr¨ ufen zu lassen und somit die verwendete Software zu zertifizieren. Diese Zertifizierung ist notwendig, um die entsprechende Produkte in bestimmten Anwendungsbereichen, wie z.B. im medizinischen Bereich oder der Luftfahrt, betreiben zu d¨ urfen [Jor04, exp14]. ¨ Ubliche Betriebssystemfunktionen, wie die Bereitstellung von Kommunikationsschnittstellen zur Hardwareansteuerung, werden von diesen Betriebssystemen nicht mitgeliefert. Zur Erweiterung der Betriebssystemfunktionalit¨at wird das Anwendungsprogramm genutzt. Die Hardwareansteuerung erfolgt direkt im Anwendungsprogramm auf Registerebene ohne die Nutzung eines Treibers. Einige Hersteller bieten zu ihren Hardwareprodukten Bibliotheken an, die das Ansprechen der Peripherie vereinfachen. Je nach Funktionsumfang und herstellerabh¨angig, werden diese Bibliotheken ebenfalls Treiber genannt (vergl. [Ins14, STM14a]). Beispiele f¨ ur Minimalbetriebsyssteme sind freeRTOS, 4 openRTOS und CMX-RTX . THREADX von expresslogic ist ein weiteres Beispiel, gliedert sich aber aufgrund der Modul- und Schnittstellenunterst¨ utzung zwischen Firmware 4

Weitere Informationen zu den einzelnen Betriebsystemen, siehe Anhang A.

8

Abbildung 3: QNX Microkernel Architektur und eingebettetem Betriebssystem ein [exp14]. 2.4.3 QNX-Neutrino RTOS QNX-Neutrino RTOS ist ein echtzeitf¨ahiges eingebettetes Betriebssystem mit dem erkl¨artem Designziel, die POSIX5 Schnittstelle auf einer robusten und skalierbaren Softwaregrundlage f¨ ur verschiedene Anwendungen zur Verf¨ ugung zu stellen [QNX14b]. Die Grundlegende Architektur eines QNX Systems basiert auf der Verwendung eines Microkernels. Ein Microkernel ist ein strukturierter Kernel, der nur die unbedingt notwendigsten Servicekomponenten enth¨alt. Diese Komponenten werden optionalen Prozessen zur Verf¨ ugung gestellt, welche die weiteren Funktionen des Betriebssystems zur Verf¨ ugung stellen. Zu den fundamentalen Komponenten des Mircokernels z¨ahlen Thread-Services, SignalServices, Synchronisationsverwaltung, Ressourcen-Zuteilung, Timer-Services und das Prozessmanagement. Komponenten, wie Filesysteme oder Treiber, sind nicht im Microkernel enthalten. Die optionalen Prozesse, wie Treiber- und Filesystemverwaltung, werden durch den Microkernel koordiniert. Die Microkernel-Architektur ist nicht in hierarchischen Schichten strukturiert. Der Microkernel bildet das Zentrum des Betriebssystems und koordiniert gleichpriorisierte Prozesse und deren Kommunikation [QNX14a]. In Abbildung 3 wird das System aus zentralem Microkernel und optionalen Prozessen verdeutlicht. Aufgrund der Mikrokernel-Architektur werden Treiberkomponenten nicht in den Betriebssystemkernel eingebunden. Stattdessen agieren sie als User-Prozesse und k¨onnen dynamisch ge- und entladen werden. In der Terminologie von QNX wird anstelle des Treibers der Ausdruck Rescource-Manager verwendet, um die Unabh¨angigkeit vom Kernel hervorzuheben. So wie Treiber in anderen Betriebssystemen, dienen Resource-Manager der Schnittstellenbereitstellung zur Kommunikation und Steuerung der Hardware. 5

POSIX ist ein Softwarestandard der definiert, wie Schnittstellen zwischen Betriebsystemen und Anwendung implementiert werden sollen (vergl. http://www.opengroup.org/austin/papers/posix_ faq.html).

9

Um Anwendungsprogrammen die Funktionalit¨at eines Recource-Managers bereitzustellen wird der Mechanismus des pathname-space-mapping verwendet. Dabei wird dem Prozessmanager des Kernels ein spezifischer Pfad und Index mitgeteilt, u ¨ber welche die Hardware ansprechbar ist. Das QNX Treibermodell gibt eine Unterteilung der ResourceManager in Device-Resource-Manager und Filesystem-Resource-Manager vor [QNX14a]. Device-Resource-Manager stellen einen einzigen Eintrag im System f¨ ur die entsprechende Hardware zur Verf¨ ugung. Jeder Eintrag wird dem Prozessmanager zur Identifikation u ¨bergeben und repr¨asentiert ein Ger¨at. Ein Eintrag setzt sich aus einer Pfandangabe und dem Namensk¨ urzel des Ger¨ates zusammen. Nach der Registrierung kann die Hardware u ¨ber den Dateisystempfad angesprochen werden. Eine serielle Schnittstelle ist z.B. unter /dev/ser1 erreichbar. Devie-Resource-Manager er¨offnen dem Benutzer die vordefinierten POSIX Schnittstellen zur Verwendung der Hardware [QNX14a]. Filesystem-Resource-Manager stellen dem Prozessmanager einen Einstiegspunkt zur Verf¨ ugung. Dieser Einstiegspunkt ist ein Teil des Pfades unter dem die eigentliche Hardware registriert wird. Die verbleibenden Anteile des Pfades nach dem Einstiegspunkt werden vom Filesystem-Resource-Manager selbst verwaltet. Der komplette registrierte Pfad einer Komponente k¨onnte wie folgt gestaltet sein: /mount/verz/hardware. Dabei stellt /mount/ den Einstiegspunkt des Prozessmanagers dar und verz/hardware den Teil des Pfades, den der Filesystem-Resource-Manager selbst verwaltet [QNX14a]. 2.4.4 Windows Embedded Compact 7 Windows Embedded Compact, ehemals Compact Edition, ist ein kompaktes und energieeffizientes Betriebssystem von Microsoft. Entwickelt wurde es f¨ ur Kleinstcomputer und eingebettete Systeme mit dem Anspruch einer hohen Funktionssicherheit. W¨ahrend der Entwicklung des eingebetteten Betriebssystems und Ver¨offentlichungen der verschiedenen Versionen, wurde die Namensgebung mehrfach ge¨andert. Am Anfang stand die Bezeichnung Windows CE f¨ ur Windows Compact Edition und wurde sp¨ater in Compact Embedded ge¨andert. In der aktuellen Version betitelt Microsoft das Betriebssystem mit Embedded Compact 2013. Die erste Version von Windows CE wurden speziell f¨ ur mobile Organizer mit kleinen Displays und Tastaturen in den fr¨ uhen 1990er Jahren entwickelt und basierte auf Windows 95. Mit der Weiterentwicklung der Hardware wurde CE auf Minilaptops eingesetzt. Das Windows-Mobil Betriebssystem, welches 2002 f¨ ur Smartphones erschien, basierte auf einer fr¨ uhen Version von Windows CE. Mitte der 2000er erschien Windows CE 3.0 mit Optimierungen im Kernel f¨ ur bessere Echtzeit Unterst¨ utzung, gr¨oßeren Umfang von Threadpriorit¨aten und verbesserten Interrupt Service Routinen. Die gr¨oßten Neuerungen in der CE Geschichte wurden mit der Einf¨ uhrung von Windows CE 6.0 getroffen. Der Kernel wurde komplett neu konstruiert. Anstatt von 32 , vor CE 6.0, sind 32000 Prozesse

10

m¨oglich. Die Gr¨oße des virtuellen verf¨ ugbaren Speichers wurde von 32 MB auf 2GB pro Prozess erh¨oht [Bol10]. Die Struktur des Kernels wurde in den nachfolgenden Versionen Embedded Compact 7 und Embedded Compact 2013 beibehalten. Neuerungen in diesen Versionen betrafen haupts¨achlich die Unterst¨ utzung weiter Funktionen und Bibliotheken oder die Abschaffung veralteter Schnittstellen und Funktionen [Mic14a]. Im Folgenden werden die Systemarchitektur und die Treibermodelle f¨ ur die Embedded Compact Betriebssysteme ab Version 6.0 von Microsoft dargestellt und Wege der Treiberentwicklung aufgezeigt. Ab Version 6.0 der Windows Embedded Compact Systeme basieren diese auf einer monolithischen Struktur. Abh¨angig von den verwendeten CPUs, unterst¨ utzen diese verschiedene Priorit¨atslevel, f¨ ur die ausgef¨ uhrten Prozesse. In einer monolithischen Systemarchitektur ist der Kernelprozess der einzige Prozess, welcher die h¨ochste Priorit¨atsstufe annimmt bzw. zugeteilt bekommt. Betriebssystemkomponenten die in einer MikrokernelArchitektur als User-Mode-Prozess laufen, werden in der monolithischen CE Architektur dem Kernel als Dynamic Link Library (DLL) hinzugef¨ ugt. Die vereinfachte Struktur einer solchen Architektur ist in Abbildung 4 dargestellt. Zu beachten ist, dass die Servicekomponenten f¨ ur die Treiberverwaltung (GWES.DLL und DevMgr.DLL) ebenfalls als dynamische Bibliotheken im Kernel vorhanden sind [Kch11].

Abbildung 4: Windows CE Systemarchitektur ab Version 6.0 Windows CE enth¨allt ein flexibles Treibermodell in dem die jeweiligen Treiber nach verschiedenen Aspekten charakterisiert werden k¨onnen. Bevor das Treibermodell mit den einzelnen Aspekten genauer untersucht wird, erfolgt eine Darstellung der wichtigsten Systemkomponenten f¨ ur die Treiberentwicklung aus Abbildung 4. Erkl¨arungen zu den einzelnen Treiberarten werden in den nachfolgenden Abschnitten gegeben. ˆ GWES.DLL: GWES steht f¨ ur Graphical Windowing and Event Subsystem. Die-

11

ses Modul ist zust¨andig f¨ ur das Laden und Entladen nativer Treiber. Zus¨atzlich verwaltet es die Schnittstellen eines geladen nativen Treibers [Kch11, Mic14b]. ˆ DEVMGR.DLL: Der DeviceManager ist zust¨ andig f¨ ur das Laden und Entladen von

Kernel-Mode-Stream-Treibern. Zus¨atzlich ist er zust¨andig f¨ ur die Auswahl eines zu ladenden Treibers anhand einer Globally Unique Identi er (GUID) [Kch11]. ˆ FSDMGR.DLL: Der Filesystemmanager-Treiber ist zust¨ andig f¨ ur das Laden von

Partitionstreibern und das Laden des Filesystems in den Windows Storage-Manager [Kch11]. ˆ Networking DLLs: Diese Systemkomponenten stellen die Funktionalit¨ at f¨ ur Netz-

werkverbindungen und Kommunikation zur Verf¨ ugung [Kch11]. ˆ UDEVICE.EXE: Dieser Prozess ist daf¨ ur zust¨andig Ger¨atetreiber als User-Mode-

Treiber zu laden [Kch11]. In der Treiberstruktur wird in Windows CE zwischen nativen und Stream-Treibern unterschieden. Unabh¨angig von dem tats¨achlichen Ger¨at, welches der Treiber repr¨asentiert, liefert ein Stream-Treiber immer eine vordefinierte Programmierschnittstelle f¨ ur den Zugriff auf das Ger¨at. Die Besonderheit ist, dass Stream-Treiber die Funktionen des Ger¨ates als Funktionen des File-System-APIs repr¨asentieren. Dadurch ist es m¨oglich, die angeschlossene Hardware wie eine Datei zu behandeln [Mic14c]. Damit ein Stream-Treiber geladen und verwendet werden kann , muss dieser Entry-Points zur Verf¨ ugung stellen. Dies sind Funktionen, welche der Device-Manager aufrufen kann, um mit dem Treiber zu kommunizieren. Zu beachten ist, dass einige dieser Funktionen implementiert sein m¨ ussen, damit der Treiber geladen werden kann und wieder andere nur optional unterst¨ utzt werden k¨onnen. Eine vollst¨andige Liste der unterst¨ utzten Funktionen ist unter [Mic14c] zu finden. Typischerweise werden Stream-Treiber f¨ ur den Zugriff auf Speichermedien, Audioger¨ate oder serielle Schnittstellen verwendet. Laut Microsoft sind native Treiber, alle Treiber die ein anderes Interface f¨ ur Steuerung und Kommunikation verwenden als Stream-Treiber. Je nach Anwendung implementiert ein nativer Treiber Funktionen, welche ger¨atespezifisch sind, und stellt sie dem GWES zur Verf¨ ugung. Abgesehen von den exportierten Funktionen unterscheidet sich ein nativer Treiber in seinem Verhalten nicht von einem Stream-Treiber. Typische Beispiele f¨ ur native Treiber sind Treiber f¨ ur Displays und Eingabeger¨ate wie Tastatur oder Maus. Eine Kombinaton aus Stream und nativen Treibern ist ebenfalls m¨oglich [Kch11]. Beide Treibervarianten, native und Stream-Treiber, k¨onnen monolithisch oder geschichtet (layered) realisiert werden. Im Fall eines monolithischen Treiber, wird die gesamte

12

Treiberfunktionalit¨at in einer einzelnen DLL implementiert. Diese DLL stellt das Interface f¨ ur die Hardwarebenutzung f¨ ur Betriebssystem und Anwendungsapplikationen ¨ bereit. Zus¨atzlich enth¨alt diese die gesamte Logik die zur Steuerung und Uberwachung der angeschlossenen Hardware notwendig ist. Abbildung 5 zeigt den schematischen Aufbau eines monolithisch strukturierten Ger¨atetreibers.

Abbildung 5: Struktur monolithischer Treiber Ein geschichteter Treiber besteht aus einem model-device-driver (MDD) und einem platform-device-driver (PDD). Der PDD Teil eines solchen Treibers realisiert die Hardwarespezifischen Funktionen und stellt die Funktionalit¨at dem MDD zur Verf¨ ugung. Der MDD Teil exportiert Funktionalit¨aten die f¨ ur eine bestimmte Gruppe von Ger¨aten gleich sind. So ist es m¨oglich, denselben MDD Treiber f¨ ur verschiedene, aber ¨ahnliche Hardware, in Kombination mit einem angepassten PDD zu verwenden. Der Aufbau eines geschichteten Treibers ist in Abbildung 6 dargestellt.

Abbildung 6: Aufbau geschichteter Treiber aus MDD und PDD Der Vorteil eines geschichteten Treibers besteht in der Widerverwendbarkeit des MDD f¨ ur gleiche Ger¨ateklassen, was die Entwicklung von Ger¨atetreibern deutlich beschleunigen kann. Der Nachteil besteht im Performanceverlust gegen¨ uber einem monolithischem Treiber, aufgrund der zus¨atzlichen Interaktion zwischen MDD und PDD [Kch11]. Durch die verwendete monolithische Struktur k¨onnen Treiber im Kernel-Mode oder im User-Mode arbeiten. Kernel-Mode bedeutet, dass die Treiberkomponente Zugriff auf

13

Kernelressourcen hat und im Kerneladressbereich operieren kann. Kernel-Mode-Treiber k¨onnen auf kernelspezifische Datenstrukturen und Kernelschnittstellen zugreifen. KernelMode-Treiber k¨onnen sehr schnell ablaufen und werden zum Kernelprozess (nk.exe) gebunden. Aufgrund dieser Zugriffsrechte m¨ ussen Kernel-Mode-Treiber besonders robust implementiert sein. Ein Fehler im Zugriff auf den Kerneladressbereich kann andere Kernelkomponenten beeinflussen und zum Totalausfall des Gesamtsystems f¨ uhren. User-Mode bedeutet, dass die Treiberkomponente keinen Zugriff auf Kernelschnittstellen und deren Datenstrukturen hat. User-Mode-Treiber werden von einem speziellen UserMode-Prozess (udevice.exe) verwaltet. An die entsprechenden Prozesse sind voneinander getrennte Adressr¨aume gekoppelt. Durch die Verwendung von User-Mode-Komponenten kann die Ausfallsicherheit des Gesamtsystems erh¨oht werden. Da diese keinen Zugriff auf Kernelkomponenten haben, kann im Fehlerfall der Treiber gestoppt und neugeladen werden, ohne dass ein Neustart des gesamten Systems n¨otig ist. Im User-Mode sind die Softwarekomponenten voneinander isoliert und beeinflussen sich nicht gegenseitig. Ein Ausfall eines User-Mode-Treibers beeinflusst die Funktionsf¨ahigkeit eines anderen unabh¨angigen Treibers nicht. Es wird nur der Prozess des jeweiligen fehlerhaften Treibers beendet und gegebenenfalls neu gestartet [ES09]. Wie und wann die jeweiligen Treiber geladen werden h¨angt vom jeweiligen Treiber-Typ ab. Der Ger¨atemanager (DEVMGR.DLL) und das Graphical Windowing and Event Subsystem werden beim Systemstart geladen. Diese Komponenten laden dann die weiteren Treiber ins System nach. Alle Treiberarten k¨onnen entweder direkt beim Systemstart oder w¨ahrend der Laufzeit des Systems geladen werden. F¨ ur das Laden und Entladen u ¨bernimmt die Registry wichtige Aufgaben. G. Atlas beschreibt die die Registry folgendermaßen: Unter Windows 98, Windows CE, Windows NT und Windows 2000 eine ” zentrale, hierarchische Datenbank, in der wichtige Informationen u ¨ber Systemkonfiguration, Benutzer, Anwendungen und Hardwareger¨ate abgelegt sind“ [ATL03]. In der Registry werden Informationen zu den jeweiligen Treibern gespeichert. Diese Informationen umfassen Angaben zum Laden des Treibers, wie den Namen der jeweiligen DLL. Weiterhin enth¨alt die Registry Optionen (Flags), wie der Treiber geladen werden ¨ soll. Uber die Einstellung der Flags ist es m¨oglich, einen Treiber im User-Mode bzw. im Kernel-Mode zu laden. Ein weiter Optionspunkt in der Registry ist das Prefix. Diese aus drei Großbuchstaben bestehende Zeichenkette vermittelt dem Betriebssystem welches Interface zu welchem Treiber geh¨ort. 2.4.5 Embedded Linux Linux bezeichnet einen Betriebssystemkern (Kernel), welcher in den fr¨ uhen 1990er Jahren von Linus Torwald entwickelt und ver¨offentlicht wurde. Seit der Ver¨offentlichung

14

steht dieser als Open-Source-Projekt unter der GPL zur Verf¨ ugung und wurde von freiwilligen Programmierern weiterentwickelt. Dieser Kernel, der die Grundfunktionen des Betriebssystems bereitstellt, in Verbindung mit Anwendungsprogrammen wird als ¨ Linux-Distribution bezeichnet [Yag03]. Eine Ubersicht zu den verschiedenen LinuxDistributionen und deren Beschreibung ist unter [SS14] zu finden. Einzug in den Embedded-Bereich hielt Linux ab 1999. Erste Konsortien zur Einbindung von Linux Betriebssystemen in Embedded-Anwendungen wurden gegr¨ undet und die Entwicklung eines echtzeitf¨ahigen Linux-Systems angek¨ undigt. Aufgrund des freiverf¨ ugbaren Quelltextes entwickelten Hersteller linuxbasierende Betriebssysteme ihren Anforderungen entsprechend. Einige der entwickelten Systeme sind frei verf¨ ugbar, andere werden kommerziell vermarktet. Embedded Linux Distributionen nutzen keinen anderen bzw. neu entwickelten Kernel. Der Standardkernel ist modular aufgebaut. Nicht ben¨otigte Komponenten k¨onnen entfernt und ben¨otigte hinzugef¨ ugt werden. Aufgrund der Modularit¨at kann der StandardKernel f¨ ur verschiedene Anwendungen, wie Desktop-PCs, Serveranwendungen und im Embedded-Bereich eingesetzt werden [RLN05]. Die grundlegende Systemarchitektur ist f¨ ur alle Linux-Systeme gleich. Eine abstrahierte 3-Schichten Darstellung der Architektur ist in Abbildung 7 dargestellt. In der untersten Schicht liegt die Hardware. Um die Hardware mit einer Linux Distribution nutzen zu k¨onnen, m¨ ussen Minimalanforderungen erf¨ ullt sein. Zu diesen Anforderungen z¨ahlen das Vorhandensein einer 32-bit CPU, welche eine Memory-Management-Unit (MMU) beinhaltet6 und ausreichende Verf¨ ugbarkeit von RAM f¨ ur das jeweilige System.

Abbildung 7: Linux Systemarchitektur 6

Eine Ausnahme bildet uClinux welches ohne MMU lauff¨ahig ist. (Vergl. http://www.uclinux.org/)

15

In der zweiten Ebene liegt der Kernel mit den grundlegenden Funktionen des Betriebssystems. Wie Windows CE ab Version 6.0, ist dieser als monolithischer Kernel aufgebaut. Dieser enth¨alt das Filesystem, Low- und Highlevel Schnittstellen und eine Protokollkomponente. Die Lowlevel Schnittstelle dient zur Kommunikation und Steuerung der verwendeten Hardware. Weiterhin er¨offnet diese den weiteren Kernelkomponenten u ¨ber definierte Schnittstellen Zugriff auf diese Hardware. Die dar¨ uber liegende Highlevel Schnittstelle bildet die Standardkomponenten aller Linuxsysteme ab. Zu diesen Standardkomponenten z¨ahlen das Prozessmanagement, die Speicherverwaltung, Ger¨ate- und Netzwerkmanagement. Im Gegensatz zur Lowlevel Komponente, welche hardwareabh¨angig ist, ist die Highlevel Schnittstelle universal f¨ ur verschiedene Prozessorarchitekturen einsetzbar. Das Filesystem und die Protokollkomponente erm¨oglichen es dem Kernel, Daten bzw. Datenstrukturen von verschiedensten Peripherieger¨aten zu interpretieren und mit diesen Ger¨aten zu interagieren. Die oberste Ebene des Architekturmodells beinhaltet Bibliotheken und Anwendungsprogramme. Bibliotheken enthalten h¨aufig verwendete Funktionen und Zugriffsm¨oglichkeiten um mit Kernelkomponenten zu interagieren. Sie sind nicht Teil der jeweiligen Applikation und werden w¨ahrend der Programausf¨ uhrung in den Anwendungsspeicherbereich geladen. Dies erm¨oglicht den Zugriff auf dieselbe Instanz der Bibliothek f¨ ur verschiedene Anwendungsprogramme, ohne dass diese eine eigene Kopie der Bibliotheksfunktionen ben¨otigen [Yag03]. Christopher Hallinan zufolge ist eine fundamentale Absicht des Embedded Linux Treiberkonzepts, Benutzeranwendungen vollst¨andig von kritischen Kerneldatenstrukturen zu isolieren. Der direkte Hardwarezugriff soll f¨ ur eine User-Anwendung nicht m¨oglich sein. Weiterhin sollen Treiber die eigentliche Funktion und Komplexit¨at der angeschlossenen Hardware vor dem Anwendungsentwickler verbergen. Die Treiberkomponente u ¨bernimmt Hardwarezugriffe und stellt einer Benutzeranwendung konsistente Schnittstellen zur Verf¨ ugung. Konsistenz folgt dabei aus der Unix/Linux Konvention, dass alle Komponenten als Datei repr¨asentiert werden sollen [Hal10]. Im Treibermodell wird dies so umgesetzt, dass Ger¨ate unter Linux als virtuelle Dateien betrachtet werden. Auf diese k¨onnen Lese- und Schreibzugriffe und sonstige Dateioperationen, vorausgesetzt sie wurden implementiert, ausgef¨ uhrt werden. Sollen Daten an ein angeschlossenes Ger¨at u ¨bertragen bzw. von diesem gelesen werden, wird eine Schreib- bzw. Leseoperation auf die virtuelle Datei ausgef¨ uhrt. Der Treiber, der dieser virtuellen Datei entspricht, hat genaue Kenntnis der Hardware und deren Funktionen. Nach Interpretation des jeweiligen Schreib- oder Lesebefehls, f¨ uhrt der Treiber die Hardwareoperation durch [SGD09]. Nach A. Rubini werden Ger¨ate in einem linuxbasiertem System in drei Ger¨ateklassen unterteilt. Diese Unterteilung erfolgt in Zeichenund Blockger¨ate und Netzwerkschnittstellen [RC02].

16

Zeichenger¨ate sind Hardwarekomponenten, die ihre Daten in Form eines Datenstroms (Stream) zur Verf¨ ugung stellen. Der zugeh¨orige Zeichenger¨ate-Treiber implementiert dieses Stromverhalten und stellt Systemaufrufe wie open(), close(), read() und write() zur Verf¨ ugung. Durch die Nutzung eines Zeichenger¨ate-Treibers kann auf die Hardware unter dem Dateisystemknoten zugegriffen werden. Der relevante Unterschied im Zugriff auf eine normale Datei und einem Zeichenger¨at ist, dass in Dateien an jede beliebige Stelle gesprungen werden kann. Zeichenger¨ate sind normalerweise als Datenkanal ausgelegt und bilden keinen Datenbereich ab, weshalb nur sequentiell auf diese zugegriffen werden kann. Beispiele f¨ ur Zeichenger¨ate sind die Textkonsole, seriellen Schnittstellen und Tastaturen [RC02]. Blockger¨ate sind dadurch charakterisiert, dass sie die zu u ¨bertragenden Daten nicht als Datenstrom liefern, sondern als Datenpakete organisieren [Hal10]. Diese Ger¨ate sind in der Lage, ein Filesystem aufzunehmen und erm¨oglichen, durch die Organisation der Daten in Bl¨ocke, beliebig viele Bytes in einem Pakettransfer zu ¨ u ¨bertragen (abh¨angig von der verwendeten Ubertragungstechnologie). Der Zugriff auf Blockger¨ate erfolgt analog dem Zugriff auf Zeichenger¨ate. Demnach kann auf die entsprechende Hardware u ¨ber den Dateisystemknoten zugegriffen werden. Der wesentlichen Unterschiede zwischen Zeichenger¨at und Blockger¨at bestehen darin, wie die Ger¨atedaten intern im Kernel organisiert werden und in den Schnittstellen, u ¨ber welche Kernel und Treiber kommunizieren. Zus¨atzlich zu den Zeichenger¨ateschnittstellen nutzt ein Blockger¨ate-Treiber spezifische Blockger¨ate-Schnittstellen um Funktionen, wie das Einh¨angen eines Filesystems, zu erm¨oglichen. F¨ ur den Nutzer ergeben sich keine Unterschiede in der Handhabung zwischen Blockger¨at und Zeichenger¨at. Beispiele f¨ ur Blockger¨ate sind unter anderem Festplatten oder CD-ROMs. Eine Netzwerkschnittstelle hat die Aufgabe Datenpakete zu senden und zu empfangen. ¨ Dabei ist es f¨ ur den Schnittstellentreiber unerheblich, welche Ubertragungsmechanismen auf die zu u ¨bertragenden Datenpakete angewendet werden. Beispielsweise arbeiten die ¨ Ubertragungsprotokolle TELNET7 und FTP8 auf Basis eines Datenstroms. F¨ ur das Ger¨at ist dieser Datenstrom nicht vorhanden, stattdessen nimmt es die Daten als Datenpakete auf. Netzwerkschnittstellen sind im System nicht im Dateisystemverzeichnis abgebildet und somit nicht u ¨ber einen Dateisystemknoten erreichbar. Der Netzwerkschnittstelle wird ein eindeutiger Name zugewiesen, u ¨ber welchen die Kommunikation mit dem Ger¨at erfolgt. F¨ ur die Kommunikation zwischen Kernel und Netzwerk-Schnittstellen Treiber werden spezielle Paket¨ ubertragungsfunktionen verwendet, anstelle von open(), close(), read() und write(). Der gr¨oßte Unterschied zwischen Block und Netzwerk-Schnittstellen Treibern ist die 7

TELNET ist ein netzwerkbasiertes Kommunikationsprotokoll und wird u.a. zur Fernsteuerung von Computern genutzt. 8 FTP ist ein netzwerkbasiertes Protokoll zur Datei¨ ubertragung.

17

M¨oglichkeit der Interaktion der Ger¨ate. Blockger¨ate Treiber arbeiten ausschließlich, wenn der Kernel eine entsprechende Anforderung an das Ger¨at bzw. den Treiber abgesetzt hat. Netzwerksschnittstellen empfangen asynchron Daten und erfragen beim Kernel, ob die Daten weitergeleitet werden k¨onnen [RC02]. Seit der Kernelversion 2.6 unterst¨ utzt Linux ein Ger¨atemodel, um eine generelle Abstraktion des Systems zu erreichen. Diese Abstraktion ist n¨otig, um die komplizierter werdenden Topologien und Anforderungen neuer Systeme einheitlich und einfacher zu bearbeiten. Durch das Ger¨atemodel werden Aufgaben wie das Power-Management, Kommunikation von Kernelkomponenten mit dem User-Space, Verwaltung von Hot-PlugableDevices9 , Einordnung der Hardware in Ger¨ateklassen und Subklassen und die Organisation des Lebenszyklus von Objekten abstrahiert und k¨onnen im Kernel bearbeitet werden. F¨ ur eine genauere Betrachtung und Erkl¨arung der einzelnen Komponenten des Ger¨atemodels sei auf [Kum14] und [RC02] verwiesen. Neben den Linux Derivaten, welche den Standard-Kernel verwenden wurden parallel Betriebssysteme entwickelt, welche einen modifizierten Kernel verwenden. Hauptbestandteile der Modifikation sind die Verbesserung der zeitlichen Aufl¨osung der internen Timer und Optimierung des SchedulingVerfahrens. Vertreter solcher Betriebsysteme mit modifiziertem Kernel sind die Derivate RTLinux, RTAI10 , KURT11 und OSADL12 . 2.4.6 VxWorks VxWorks RTOS von WindRiver ist ein Echtzeit-Betriebssystem basierend auf Linux. WindRiver erwarb 2007 die Rechte am RTLinux-Projekt von FSM Labs. RTLinux(RealTime-Linux) entstand 1996 mit dem Ziel Mechanismen in den Linux-Kernel einzubringen, welche deterministische Antwortzeiten des Systems garantierten. WindRiver entwickelte dieses Projekt weiter und vertreibt es kommerziell in Verbindung mit einer Entwicklungsumgebung, welche auf Eclipse basiert, aber speziell auf VxWorks angepasst ist [YMBYG08]. Urspr¨ unglich wurde im VxWorks System keine Unterscheidung zwischen Betriebssystem und Anwendungsprogrammen vorgenommen. Alle Prozesse und Aufgaben wurden in der h¨ochsten Priorisierungsstufe ausgef¨ uhrt. Diese Struktur wurde ab der Version 6.0, zugunsten von Sicherheitsaspekten, aufgegeben. Die neue Struktur sieht eine strikte Trennung zwischen Betriebssystem und Anwendungsprogrammen vor. Hardwarezugriff und Treiberentwicklung erfolgen, aufgrund der Linuxbasis, wie in einem standard Linuxsystem. Unterschiede ergeben sich in den bereitgestellten Funktionen und den Schnittstellen, welche ein VxWorks-Treiber bereitstellen muss. Die unter Linux u ¨bliche Vorgehensweise, 9

Hardware die w¨ ahrend des Systembetriebs hinzugef¨ ugt und entfernt werden kann. https://www.rtai.org/ 11 http://www.ittc.ku.edu/kurt/ 12 https://www.osadl.org/Realtime-Linux.projects-realtime-linux.0.html 10

18

Hardware als virtuelle Datein abzubilden, bleibt erhalten. Eine Besonderheit stellt die Behandlung von Treiber in VxWorks dar. In Unix/Linux basierten Systemen k¨onnen Treiber u ¨blicherweise nicht preemptiv sein. Unter VxWorks sind Treiberkomponenten an die sie aufrufenden Anwendungen gebunden, wodurch eine preemptive Behandlung m¨oglich wird [Riv14a, Riv14b].

19

3 USB Grundlagen Die Umsetzung der gestellten Aufgabe erfordert die Benutzung und Steuerung des Universal-Serial-Bus(USB). Zum besseren Verst¨andnis der nachfolgenden Abschnitte wird an dieser Stelle auf die Grundlagen dieses Bussystems eingegangen. Dabei liegt der Fokus auf der USB Spezifikation Version 2.0. Die Neuerungen der Spezifikation 3.0 sind f¨ ur die Umsetzung der Aufgabe nicht relevant, da diese durch die verwendete Hard¨ ware nicht unterst¨ utzt wird. Im wesentlichen wird ein Uberlick u ¨ber die softwareseitigen Eigenschaften gegeben. F¨ ur die elektrischen und mechanischen Eigenschaften sei auf die Spezifikation, [UI00] ab S.85, verwiesen.

3.1 Entwicklung des Standards Der USB wurde als Alternative zu existierenden Anschlussm¨oglichkeiten von Peripherie an PC-Systeme entwickelt. Die Firmen Intel, IBM, Compaq, DEC und Microsoft entwickelten Mitte der 1990er Jahre die erste Version des USB-Standards und gr¨ undeten das 13 USB Implementers Forum . Diese Organisation ist f¨ ur die Ver¨offentlichungen und Pflege der USB-Spezifikationen und als Supportdienstleister f¨ ur Entwickler zust¨andig. 1996 wurde die erste Version USB 1.0 ver¨offentlicht. Zwei Jahre sp¨ater folgte die Einf¨ uhrung des USB 1.1 Standards, welche Fehler und Unklarheiten in der Version 1.0 korrigierte. Grunds¨atzliches Ziel bei der Entwicklung des USB-Standards war, die Nachteile von bereits existierenden Anschlusskonzepten zu beseitigen. Gleichzeitig sollten Kosten und Aufwand bei der Verbindung von Ger¨aten vermindert werden. Die wichtigsten Neuerungen die mit USB gemacht wurden sind die Vereinheitlichung der Anschl¨ usse, Vereinfachung der Erweiterung bestehender Systeme und die M¨oglichkeit Erweiterungskomponenten im laufendem Betrieb anzuschließen(sogn. Hot-Plug-and-Play). Durch diese M¨oglichkeiten der einfachen Handhabung wird dem Anwender ein hohes Maß an Komfort geboten im Vergleich zu konventionellen seriellen oder parallelen Schnittstellen. Auch f¨ ur Entwickler bietet das USB Konzept Vorteile gegen¨ uber klassischen Anschlusskonzepten. Im klassischen Konzept werden die Input/Output-Register der anzuschließende Hardware in den I/O-Adressraum der CPU abgebildet und Interrupt-Leitungen zugeordnet. Zunehmender Bedarf an Ressourcen, bei Erweiterung des Gesamtsystems, kann zu Engp¨assen und Ressourcenkonflikten f¨ uhren. Verbindungen u ¨ber USB kommen ohne zus¨atzliche Systemressourcen wie I/O-Adressen oder Interruptleitungen aus. An einen USB-Host k¨onnen, ohne großen Aufwand, bis zu 127 USB-Ger¨ate angeschlossen werden [Kel03].

13

http://www.usb.org/about

20

3.2 Geschwindigkeitsklassen Mit der Einf¨ uhrung des USB 1.0 Standards wurden zwei Geschwindigkeitsklassen f¨ ur USB-Ger¨ate unterst¨ utzt. Zu diesen z¨ahlen die Low-Speed-Ger¨ate, welche eine theoretische Datenrate von 1,5 MBit/s und die Full-Speed-Ger¨ate, welche eine theoretische Datenrate von 12 MBit/s erreichen. Mit der Erweiterung des Standards auf Version 2.0, im Jahr 2000, erfolgte die Einf¨ uhrung der High-Speed-Ger¨ate, welche eine theoretische Datenrate von 480 MBit/s erreichen. Ende 2008 wurde vom USB-Implementers-Forum die USB-Spezifikation 3.0 ver¨offentlicht. Dieser Standard enth¨alt die Geschwindigkeitsklasse der Super-Speed-Ger¨ate, welche theoretische Datenraten von 4000 MBit/s erreichen.

3.3 Hardware Architektur Die Hardwarearchitektur eines USB-Systems entspricht physikalisch einer Baumstruktur. Die angeschlossenen Funktionsger¨ate bilden die Blattknoten eines Baumes. F¨ ur Verzweigungsknoten werden Hubs eingesetzt. Diese Verteiler erm¨oglichen den Anschluss von bis zu 127 Ger¨aten an einem Strang. Die Wurzel des Baumes bildet der der USB-Host. In Abbildung 8 ist diese Baumstruktur bestehend aus Host-Controller, HUB und USB Ger¨aten dargestellt.

Abbildung 8: physikalische USB Struktur Logisch betrachtet entspricht ein USB-System einer Sternstruktur. Alle USB-Ger¨ate sind

21

sternf¨ormig mit dem Host verbunden. Im USB-System ist der Host der einzige Busmaster. Jedes Ger¨at kann vom Host direkt u ¨ber eine eindeutige Adresse angesprochen werden. Diese Adresse wird dem Ger¨at w¨ahrend der Enumerationsphase zugewiesen. Nach Adressvergabe besteht zwischen Host und Ger¨at eine Punkt-zu-Punkt Verbindung. Als Busmaster geht jede Interaktion auf dem Bus vom Host aus. Er bestimmt zu welchem Zeitpunkt mit welchem Ger¨at kommuniziert wird. In Abbildung 9 ist diese logische Struktur dargestellt.

Abbildung 9: logische USB Struktur Jede Daten¨ ubertragung wird von der hostseitigen Software kontrolliert. Der Host setzt sich aus dem USB-Host-Controller und dem USB-Root-Hub zusammen. Der USBHost-Controller hat die Aufgabe alle Transaktionen auf dem Bus zu initiieren, der Root-Hub verteilt die Anschlussm¨oglichkeiten f¨ ur USB-Ger¨ate auf mehrere Hardwareanschl¨ usse(Ports). Innerhalb des Host-Controllers werden in der Host-Software Schreib- und Lesezugriffe auf die angeschlossenen Ger¨ate organisiert. Datenstrukturen und Speicherbereiche werden bereitgestellt und die jeweiligen Anforderungen an den USB-Root-Hub weitergeleitet, welcher die entsprechenden Datenpakete u ¨ber den Bus sendet. Der RootHUB ist außerdem f¨ ur die Steuerung der Stromzufuhr, das Freischalten und Sperren der Anschlussports und der Verbindungs- und Statuserkennung am USB zust¨andig. In der USB 1.1 Spezifikation sind zwei USB-Controller-Designs spezifiziert. Zu diesen geh¨oren das Open-Host-Controller-Interface(OHCI) Design und das Universal-HostController-Interface(UHCI) Design. Mit der USB 2.0 Spezifikation werden diese um das Enhanced-Host-Controller-Interface(EHCI) Design erweitert. Die UHC Spezifikation wurde von Intel entwickelt und sieht zwei Anschlussports f¨ ur USB-Ger¨ate vor. Die OHCI Spezifikation wurde von den Firmen Compaq, Microsoft und National Semiconductor entwickelt und sieht mehrere Anschlussports f¨ ur Ger¨ate vor. Die wesentlichen ¨ Unterschiede beider Controller Varianten bestehen in der Ubertragungsreihenfolge und

22

der zeitlichen Aufteilung verschiedener Transfertypen bei Interaktionen auf dem Bus. Die Erweiterung um EHCI ist n¨otig, um den in der USB 2.0 Spezifikation beschriebenen High-Speed-Transfer zu erm¨oglichen. In USB 2.0 Host-Controllern werden EHCI und UHCI bzw. OHCI parallel verwendet. UHCI bzw. OHCI werden f¨ ur die Anforderungen von Low- und Full-Speed Ger¨ate verwendet. F¨ ur High-Speed kompatible Ger¨ate wird ein zus¨atzlicher Host-Controller verwendet, welcher auf das EHCI zugreift. F¨ ur detaillierte Informationen zu den Spezifikationen von UHCI, OHCI und EHCI vergl. [Cor96, Com99, Cor02]. Zus¨atzlich zum Root-Hub k¨onnen in einem USB-System weitere Hubs auftreten. Diese dienen als Mehrfachverteiler, um die Zahl der Anschlussm¨oglichkeiten zu erh¨ohen. Dem Anwendungsfall entsprechend k¨onnen Hubs als eigenst¨andiges Ger¨at oder als Teil eines anderen USB-Ger¨ates realisiert werden. Hat ein USB-Ger¨at neben seiner eigentlichen Funktion(z.B. Tastatur oder Drucker) eine Hubfunktionalit¨at, bezeichnet man dieses als Compound-Device. Wie in Abbildung 8 zu erkennen ist, k¨onnen Hubs geschichtet bzw. in Kaskadenstruktur zusammengeschaltet werden. Laut Spezifikation ist die Schichtung von Hubs bis zu einer Tiefe von 5 Schichten gestattet. Bei der Verwendung von Hubs muss weiterhin ber¨ ucksichtigt werden, ob es sich um ein Ger¨at mit eigener Stromversorgung (Self-Powered) handelt oder die Stromversorgung u ¨ber das USB-Anschlusskabel(BusPowered) realisiert wird. Im Falle einer Bus-Powered Realisierung ist die Anzahl der m¨oglichen Ports auf 4 beschr¨ankt, da der Hub selbst und die angeschlossenen Ger¨ate mit Strom versorgt werden m¨ ussen. Ab der USB Spezifikation 2.0 sind Hubs f¨ ur die Geschwindigkeitskonfiguration und Verwaltung zwischen Low- und High-Speed Ger¨aten zust¨andig [UI00].

3.4 Software Architektur Damit ein USB Ger¨at an einem Host verwendet werden kann, muss dieser die USB Spezifikationen unterst¨ utzen. Von vielen Betriebssystemen wird USB standardm¨aßig unterst¨ utzt. Die Kommunikation des Host mit einem angeschlossenen USB Ger¨at findet u ¨ber entsprechende Treiberkomponenten statt. Die Struktur der einzelnen Treiberkomponenten ist in Abbildung 10 dargestellt. Der USB-Host-Controller-Treiber ist f¨ ur die Organisation der einzelnen Transaktionen zust¨andig. Zu diesem Zweck erstellt dieser Transaktionslisten f¨ ur die am Bus angeschlossenen Ger¨ate. Diese Listen definieren die Reihenfolge und zeitliche Abfolge der, u ¨ber den Bus, zu u ¨bertragenden Informationen. Diese Organisation der zeitlichen Abl¨aufe wird als Scheduling bezeichnet. Die genaue Abarbeitung der Listen ist von den jeweiligen Ger¨ateeigenschaften, der zu verwendenden Transferart und der momentanen Busbelas¨ tung abh¨angig. Die eigentliche Ubertragung wird u uhrt. Der ¨ber den Root-Hub ausgef¨ ¨ Root-Hub u uhrt, entsprechend der aufgebauten Listen, die Ubertragung der einzel¨berf¨

23

Abbildung 10: USB-Treiber Struktur nen Kommandos auf eine niedrigere USB-Protokoll Ebene und legt diese als Signale auf den Bus. Der USB-Ger¨ate-Treiber dient dem Erzeugen von Anfragen(Requests) an den USB-BusTreiber. F¨ ur einen Request werden strukturierte Datenpakete verwendet. Diese Datenpa¨ kete werden als I/O-Requests-Packets(IRP) bezeichnet. Uber diese I/O-Requests-Packets k¨onnen Aktionen ausgel¨ost werden, die dem Steuern oder Auslesen der angeschlossenen Hardware dienen. So werden u.a. Interrupts ausgel¨ost oder der Empfang von Daten initialisiert. Weiterhin muss der USB-Ger¨ate-Treiber einen Puffer-Speicher f¨ ur Daten bereitstellen, welche von dem Ger¨at erhalten werden. Als Schnittstelle zwischen dem USB-Host-Controller und dem USB-Ger¨atetreiber dient ¨ der USB-Bustreiber. Dem Bustreiber sind die spezifischen Ubertragungseigenschaften der angeschlossenen Ger¨ate bekannt. Diese Informationen, wie z.B. die zu u ¨bertragene Datenmenge und die zeitlichen Abst¨ande des Erhalts neuer Daten, verwendet der Treiber ¨ zum Aufbau von ger¨atespezifischen Ubertragungen.

3.5 Kommunikationsprotokoll Der Transport von Daten wird im USB-Protokoll in strukturierten Paketen vollzogen. Die USB-Spezifikation unterteilt USB-Pakete in vier Kategorien. Diese Kategorien bestehen aus Token-, Daten-, Handshake- und Spezial-Packets. Zu Beginn eines Datentransfers sendet der Host ein Token-Packet. Diese dienen der Mitteilung, welche Art von ¨ Ubertragung folgen wird. Der entsprechende Aufbau ist in Abbildung 11 dargestellt.

Abbildung 11: Aufbau eines Token-Packets Ein Token-Packet besteht aus einem 8-Bit-Sync Feld(32-Bit f¨ ur Highspeed), einem Packet-

24

Identifier(PID), einer Address- und Endpoint-Angabe, einem Pr¨ uffeld(CRC) und einem End-Of-Packet Feld. Das Sync-Feld garantiert eine sichere Abtastung des seriellen Datenstroms in Verbindung mit der NRZI-Codierung14 . Das 4-Bit Packet-Identifier-Feld enth¨alt die Information, welche Art von Token-Packet u ur Token¨bertragen wird. F¨ Packets kann die Unterscheidung in IN-, OUT-, Setup und Start-Of-Frame-Packets(SOF) getroffen werden. Anhand dieser Information werden die nachfolgenden Daten entsprechend interpretiert. Mit der Information aus Address- und Endpoint-Feld erkennt das USB-Ger¨at, f¨ ur wen die nachfolgenden Daten bestimmt sind. Die Informationen im Cyclic-Redundancy-Check(CRC)-Pr¨ uffeld erm¨oglichen die Fehlererkennung bei falschen Werten von Addresse und Endpointnummer. Das Ende eines Pakets wird durch das End-Of-Packet(EOP) Feld abgeschlossen. Im Aufbau unterscheiden sich Start-Of-Frame-Packets geringf¨ ugig von den restlichen Token-Packets. Sie enthalten nicht die Angabe u ¨ber Ger¨ateadresse und Endpointnummer, da sie von allen angeschlossenen USB-Ger¨aten verarbeitet werden. Stattdessen enthalten sie einen Frame-Counter, der die Nummer des aktuellen Frames enth¨allt. Daten zwischen Host und Ger¨at werden in Daten-Paketen u ¨bertragen. Der Aufbau der Daten-Packets ist in Abbildung 12 dargestellt. Diese bestehen aus einem Sync- und PID-Feld. Darauf folgen die Nutzdaten im Data-Feld, ein CRC- und das EOP-Feld. Nutzdaten die die maximale Paketgr¨oße u ussen in mehrere Pakete auf¨berschreiten, m¨ ¨ geteilt werden. Zur Ubertragung dieser Daten wechselt die PID des Data-Packets, nach jedem u ¨bertragenen Paket, zwischen DATA0 und DATA1, bis die Nutzdaten vollst¨andig u ur High-Speed-Transfers stehen zus¨atzlich die Paket-Typen DATA2 ¨bertragen sind. F¨ ¨ und MDATA zur Verf¨ ugung. Diese Pakete werden nur bei isocronen Ubertragungen ben¨otigt.

Abbildung 12: Aufbau eines Daten-Packets Die dritte Paket-Gruppe bilden die Handshake-Packets. Der Aufbau dieser besteht aus Sync-, PID-, und EOP-Feld(vergl. Abbildung 13. Handshake-Packete dienen der Quittierung von Datentransfers. Konnten Daten erfolgreich u ¨bertragen werden, meldet ein ¨ USB Ger¨at dies dem Host, durch Ubertragung eines Acknowlege(ACK) im PID-Feld. Ein ¨ NOT-Acknowlege(NAK) wird gesendet, falls die Ubertragung von Daten nicht erfolgreich war. Das Senden eines STALL-Packets signalisiert dem Host einen schwerwiegenden Fehler des Ger¨ates, der nur durch weitere Aktionen des Hosts beseitigt werden kann(z.B. durch Ausl¨osen eines Resets). 14

Non-Return-To-Zero-Invert

25

Abbildung 13: Aufbau eines Handshake-Packets Die letzte Kategorie bilden die Spezial-Packets. Zu diesen z¨ahlen die PRE- und SplitPackets. In einem USB-System mit Low- und Full/Highspeed-Ger¨aten muss die Kommunikationsaufnahme des Hosts mit einem Low-Speed-Ger¨at an den entsprechenden Hubs angemeldet werden. Diese schalten daraufhin die entsprechenden Low-Speed-Ports f¨ ur die Daten¨ ubertragung frei. Die Ank¨ undigung f¨ ur die Low-Speed-Kommunikation u ¨berfolgt durch ein PRE-Packet. Dieses besteht aus einem Sync-Feld und der PRE-ID. Ein End-Of-Packet-Feld ist nicht notwendig. Split-Packets dienen ebenfalls der Organi¨ sation der Ubertragung bei Mischungen von Low-,Full- und High-Speed-Ger¨aten. Durch ihre Verwendung ist es m¨oglich, Daten von Low- und Full-Speed Ger¨aten mit HighSpeed zwischen Hub und Host zu transportieren. Dadurch entsteht eine Entkopplung der verschiedenen Geschwindigkeitsklassen und der Vorteil, dass langsamere Ger¨ate die Kommunikation zwischen Host und High-Speed-Ger¨aten nicht ausbremsen. ¨ Die Ubertragung von Daten auf dem USB zwischen Host und USB-Ger¨at erfolgt in 3 aufeinanderfolgenden Phasen. In der ersten Phase wird ein Token-Packet gesendet. Dieses signalisiert die Art(SETUP) bzw. Richtung(IN oder OUT) des folgenden Transfers. In der zweiten Phase werden die Nutzdaten mittels Daten-Packets u ¨bertragen. In der dritten ¨ Phase wird der Erfolg oder Misserfolg des Datentransfers durch das Ubermitteln eines Handshake-Packets signalisiert. In Abbildung 14 sind die Phasen mit den ensprechenden Paketen f¨ ur einen erfolgreiche Datentransfer vom Ger¨at zum Host(inkl. Beispielwerten) dargestellt.

Abbildung 14: Phasen eines erfolgreichen Datentransfers vom USB-Ger¨at zum Host F¨ ur die Aufteilung der Bandbreite, wird die Belegung des Busses in Zeitabschnitte(Frames) aufgeteilt. Im Low- und Fullspeed-Modus entspricht ein Frame einer Millisekunde. F¨ ur Highspeed-Ger¨ate erfolgt die Unterteilung eines Frames in 8 Micro-Frames zu 125 Mikrosekunden. Um die Frame-Einteilung des Busses allen Ger¨aten mitzuteilen, sendet der Host zu beginn jedes Frames ein SOF-Token. Low-Speed-Ger¨ate werden durch Hubs

26

vom High-Speed-Transfer abgekoppelt, dadurch erhalten diese keine SOF-Packets. Stattdessen erzeugt der Hub an den Low-Speed-Ports ein Low-Speed-Keep-Alive Signal mit eintreffen eines SOF-Packets. Dadurch bleiben diese Ger¨ate aktiv am Bus und k¨onnen den Start eines neuen Frames registrieren. F¨ ur High-Speed Betrieb, werden entsprechend der Einteilung in Micro-Frames, Micro-Start-Of-Frame(µSOF) verwendet um den n¨achsten Frame zu signalisieren. Die enthaltene Framenummer wird dabei nur f¨ ur jedes achte empfangene µSOF erh¨oht.

3.6 Kommunikationsmodell Auf der physikalischen Ebene besteht die Verbindung zwischen Host und USB-Ger¨at aus den beiden Datenleitungen D+ und D-. Auf der logischen Ebene basiert der USB auf einem Pipe-Endpoint-Kozept. Die Pipes entsprechen dabei logischen Datenkan¨alen. Jede Pipe ist mit dem Host und einem Endpoint auf dem USB-Ger¨at verbunden. Ein USB-Ger¨at kann mehrere Endpoints besitzen und somit mehrere Informationskan¨ale zu einem Host unterst¨ utzen. Ein Endpoint entspricht physikalisch einem FIFO-Speicher u ¨ber den Daten mit dem Host ausgetauscht werden k¨onnen. Endpoints sind unidirektional ausgerichtet, dass heißt die Richtung des Datentransfers ist f¨ ur jeden Endpoint festgelegt. Die einzige Ausnahme bildet der Control-Endpoint EP0. Dieser ist bidirektional und muss von jedem USB-Ger¨at ¨ unterst¨ utzt bzw. implementiert sein. Uber diesen k¨onnen Daten empfangen und gesendet werden. Die Adressierung des Datenstroms zu einem entsprechendem Ger¨at und ¨ Endpoint erfolgt durch Ubermittlung der Ger¨ateaddresse und einer eindeutigen Endpointnummer, welche implizit die Richtung des zu bearbeitenden Datenstroms enth¨alt. Neben dem Control-Endpoint kann ein USB-Ger¨at IN- und OUT-Endpoints besitzen. INEndpoints dienen nur dem Datentransfer vom USB-Ger¨at zum Host. OUT-Endpoints dienen nur dem Datentransfer vom Host zum USB Ger¨at. Neben dem Endpoint EP0 darf jedes USB-Ger¨at bis zu 15 weitere IN- und OUT-Endpoints unterst¨ utzen. Dieses Pipe-Endpoint-Konzept erm¨oglicht die Realisierung verschiedener Funktionen innerhalb eines USB-Ger¨ates, die gleichzeitig genutzt werden k¨onnen. Eine beispielhafte Darstellung eines solchen Ger¨ates mit unabh¨angigen logischen Funktionen und verschiedenen Endpoints ist in Abbildung 15 abgebildet. Das USB Pipe-Endpoint-Konzept unterscheidet die logischen Datenkan¨ale in Streamund Message-Pipes. Stream-Pipes dienen dem Transfer von nicht n¨aher definierten Datenstr¨omen, d.h. u ¨ber diese k¨onnen beliebige Daten transportiert werden. Message-Pipes u ¨bertragen Daten welche eine definierte Struktur aufweisen. Der Firmware der entsprechenden Empf¨angerseite wird somit die M¨oglichkeit gegeben, die empfangenen Daten direkt zu interpretieren. Ob der Empf¨anger die empfangen Daten korrekt empfangen und interpretieren konnte, muss dieser dem Empf¨anger durch eine Best¨atigung mittei-

27

Abbildung 15: USB Kommunikations-Modell len. Message-Pipes werden immer durch Control-Transfers realisiert. Stream-Pipes werden, abh¨angig vom Anwendungsfall, durch Interrupt-, Bulk- oder Isochronous-Transfers realisiert. 3.6.1 Transferarten Wie bereits erw¨ahnt, stehen nach der USB Spezifikation die Transferarten Control-, Interrupt-,Bulk- und Isochronous-Transfer zur Verf¨ ugung. Abh¨angig von den Eigenschaften der zu u ¨bertragenden Daten und Anforderungen an Fehlerkorrektur oder einzuhal¨ ¨ tenden Ubertragungsintervallen muss die richtige Ubertragungsweise ausgew¨ahlt werden. Zur Konfiguration und der grundlegenden Steuerung eines USB-Ger¨ates dienen die ¨ Control-Transfers. Diese Transfers sind die einzigen, die eine bidirektionale Ubertragung von Daten erm¨oglichen, da sie immer mit dem Control-Endpoint EP0 in Verbindung stehen. Laut USB Spezifikation werden dem Control-Transfer bis 10% der gesamten Busbandbreite reserviert um sicherzustellen, dass die Daten in jedem Fall den Empf¨anger erreichen. Zus¨atzlich verf¨ ugen Control-Transfers u ¨ber Fehlererkennungsmechanismen und ein doppeltes Handshakeverfahren zur Sicherstellung des korrekten Datentransfers. ¨ Interrupt-Transfers dienen der Ubertragung kleiner Datenmengen, welche nicht periodisch auftreten k¨onnen. Die Bezeichnung Interrupt sollte an dieser Stelle nicht falsch aufgefasst werden. USB ist ein Single-Master-System und nur der Host kann Transaktionen auf dem Bus ausl¨osen. F¨ ur einen Interrupt-Transfer wird im Ger¨at eine feste Periode ¨ eingestellt, mit der der Host zyklisch abfragt, ob Daten zur Ubertragung vorhanden sind. ¨ Ist dies der Fall, wird die Ubertragung durch den Host initiiert, andernfalls wird weiter zyklisch der Status abgefragt. Ein Beispiel f¨ ur die Nutzung von Interrupt-Transfers ist ¨ die Ubertragung von Tastenanschl¨agen einer USB-Tastatur zum Host-PC. ¨ Die Bulk-Transfers dienen der Ubertragung von zeit-unkritischen, großen Datenmengen.

28

Da es sich um zeit-unkritische Daten handelt, wird kein Anteil der Busbandbreite f¨ ur ¨ diese Ubertragungsart reserviert. Bulk-In-Transfers, also Datentransfers vom USB-Ger¨at zum Host, werden normalerweise durch das Ger¨at u ¨ber einen Interrupt-Endpoint, welcher den Status ob Bulk-Daten vorhanden sind enth¨alt, beim Host angemeldet. Wird ein Bulk-Transfer in Richtung Host zu USB-Ger¨at durchgef¨ uhrt, findet dieser Transport ohne vorherige Anmeldung statt. Bulk-Transfers sind, wie Control- und Interrupt-Transfers, u ¨ber Fehlererkennungsmechanismen abgesichert. Dadurch wird sichergestellt, dass die Daten garantiert fehlerfrei u ¨bertragen werden, aber ohne einen zeitlichen Rahmen zu ga¨ rantieren. Als Beispiel f¨ ur die Ubertragung mittels Bulk-Transfer ist der Datenaustausch mit USB-Massenspeichermedien zu nennen. Die Isochronous-Transfer Art erm¨oglicht den Transport von Daten, welche eine konstante Bandbreite erfordern. Zusammen mit den Interrupt-Transfers stehen f¨ ur diese ¨ Ubertragungsm¨ oglichkeit 90% der gesamten Busbandbreite zur Verf¨ ugung. Insochrone Datentransfers werden nicht durch Fehlererkennungsmechanismen u ¨berwacht. Auf die Nutzung eines Handshakeverfahrens zur Best¨atigung der Datenannahme wird verzich¨ ¨ tet. Wichtig bei dieser Art der Ubertragung ist die garantierte periodische Ubertragung der Daten. Die Korrektheit der einzelnen Bits erh¨alt eine untergeordnete Priorit¨at. Typi¨ sche Anwendungsf¨alle f¨ ur den Isochronous-Transfer ist die Ubertragung von Audio- oder Videodaten. 3.6.2 Deskriptoren Als Descriptor wird ein Container oder eine Struktur bezeichnet, welche die wesentliche Eigenschaften eines USB-Ger¨ates enth¨alt. F¨ ur ein USB-Ger¨at existieren entsprechend der logischen Komponenten und verinnerlichten Funktionen unterschiedliche Descriptoren. F¨ ur den erfolgreichen Betrieb muss ein USB-Ger¨at einen Device-, Configurations-, Interface- und Endpoint-Descriptor besitzen. Diese Strukturen werden als StandardDescriptoren bezeichnet und von jedem USB-Ger¨at unterst¨ utzt. Abh¨angig von der Ger¨ateklasse m¨ ussen weitere klassenspezifische Descriptoren eingerichtet sein. Aus Komfortgr¨ unden ist die Nutzung Optionaler Descriptoren wie String-Descriptoren m¨oglich. ¨ Uber die Informationen die u ¨ber die Descriptoren an den Host weitergeleitet werden, kann dieser ein Ger¨at eindeutig identifizieren. Der Device-Descriptor enth¨allt allgemeine Informationen u ¨ber das Ger¨at wie Ger¨ateklasse und Typ. Die Anzahl der m¨oglichen Konfigurationen und die Gesamtgr¨oße der weiteren vorhanden Descriptoren wird ebenfalls im Device-Descriptor festgelegt. Weiterhin stellt er die Information f¨ ur die Default-Communication-Pipe, die w¨ahrend der Erkennung des Ger¨ates genutzt wird, zur Verf¨ ugung. Wie bereits erw¨ahnt kann ein USB-Ger¨at, abh¨angig von der Verwendung, verschiedene Konfigurationen und Funktionen annehmen. Der Konfigurations-Descriptor enth¨allt An-

29

gaben dar¨ uber, wie das Ger¨at in der jeweiligen Konfiguration mit Strom versorgt wird (Self-Powered oder Bus-Powered) und wie hoch der eventuelle Strombedarf ist. Weiterhin enthalten die Konfigurations-Descriptoren die Angabe welches Interface f¨ ur welche Konfiguration g¨ ultig ist. Ein Beispiel f¨ ur zwei Konfigurationen eines USB-Ger¨ates zeigt sich wenn dieses an einem Bus-Powered-Hub betrieben wird. Abh¨angig von dessen Funktion muss das Ger¨at dann in einer stromsparenden Konfiguration betrieben werden k¨onnen. Eine Konfiguration eines USB-Ger¨ates kann eine oder mehrere Schnittstellen zur Verf¨ ugung stellen, u ¨ber welche die eigentlichen Funktionen bedienbar sind. Mittels der Interface-Descriptoren werden diese Schnittstellen beschrieben. Die wesentlichen Informationen im Interface Descriptor sind die Angabe der Ger¨ateklasse und die Angabe mit welchen Endpoints die jeweilige Funktion zusammenh¨angt. Anhand der u ¨bermittelten Ger¨ateklasse kann ebenfalls ein passender USB-Driver auf der Host Seite ausgew¨ahlt werden. Die Endpoints stellen die tats¨achlichen Datensenken und Datenquellen des USB-Ger¨ates dar. Ihre Descriptoren enthalten die Transferart welche auf ihnen ausgef¨ uhrt werden kann und die Gr¨oße der von ihnen bereitgestellten Pufferspeicher. Optional k¨onnen String-Descriptoren an verschiedenen Stellen z.B. im Device- oder Interface-Descriptor mit angegeben werden, um Informationen direkt in Textform zu ¨ u von Ger¨atenamen, Herstellerangaben und ¨bertragen. Typische sind die Ubertragung Versionsnummern der verwendeten Hardware. Abh¨angig von der verwendeten Ger¨ateklasse kann es n¨otig sein, weitere klassenspezifische Descriptoren zur Verf¨ ugung zustellen. Deren Aufbau und Informationsinhalt kann aus den jeweiligen Klassenspezifikationen entnommen werden. 3.6.3 Device Requests Requests dienen der Steuerung des USB-Ger¨ates. Die USB-Spezifikation beschreibt die USB-Device-Requests. Eine Untermenge dieser definierten Anfragen bilden die StandardDevice-Requests welche von allen USB-Ger¨aten bearbeitet werden m¨ ussen. Ein USBDevice-Request besteht immer aus 8 Byte. Der Aufbau aller Standard-Requests ist in Abbildung 16 dargestellt. Im Feld bmRequestType wird die Richtung, der Request-Typ und der Empf¨anger des Requests festgelegt. bRequest enth¨alt die explizite Angabe, welcher Request ausgef¨ uhrt werden soll. Im Feld wValue und wIndex werden Optionen f¨ ur den jeweiligen Request mitgeliefert. Erfolgt die Aufforderung an ein USB-Ger¨at Daten zum Host zu senden, enth¨alt das Feld wLength die Angabe, wie viele Byte auf der Hostseite angenommen werden k¨onnen. Alle USB-Device-Requests werden u ¨ber ControlTransfers auf dem Endpoint EP0 verarbeitet. Zu den Standard-Device-Request, auf welche jedes USB-Ger¨at reagieren k¨onnen muss, z¨ahlen GetStatus, ClearFeature, Setfeature, SetAddress, GetDescriptor, GetConfiguration, SetConfiguration, GetInterface und

30

SetInterface. Optional k¨onnen noch die Requests SetDescriptor und SynchFrame implementiert werden.

Abbildung 16: Standard-USB-Request Aufbau Mittels des GetStatus-Requests ist der Host in der Lage, Statusinformationen des USBGer¨ates zu erhalten. Dadurch stehen dem Host Informationen u ¨ber die Stromversorgung und ob das Ger¨at u utzt zur ¨ber weitere Funktionen, wie z.B. Remote-Wake-Up, unterst¨ ¨ Verf¨ ugung. Uber GetStatus ist es dem Host ebenfalls m¨oglich, den Zustand eines Endpoints zu erfragen, um festzustellen ob Daten mit diesem ausgetauscht werden k¨onnen. Mit den Requests SetFeature und ClearFeature k¨onnen Eigenschaften von USBGer¨aten aktiviert und deaktiviert werden. In der Standard-Spezifikation werden zwei Eigenschaften unterst¨ utzt, welche mit Set- und ClearFeature beeinflusst werden k¨onnen. Zu diesen geh¨oren das Ein- und Abschalten der RemoteWakeUp Funktion(DEVICE REMOTE WAKEUP) und das Blockieren eines Endpoints(ENDPOINT STALL). Der SetAddress-Request dient dazu, einem USB-Ger¨at eine eindeutige Adresse auf dem Bus zuzuteilen. Diese Adresse vergibt der Host w¨ahrend der Enumerationsphase eines Ger¨ates. Um die Descriptoren, welche die ger¨atespezifischen Informationen beinhalten, anzufordern nutzt der Host den GetDiscriptor-Request. Dieser Request enth¨alt Angaben dar¨ uber, welcher Descriptor vom Ger¨at ausgelesen werden soll. Dieser StandardRequest unterst¨ utzt nur die direkte Anforderung der Device-, Configurations- und StringDescriptoren. Die Informationen zu den vorhanden Interfaces und Endpoints werden immer zusammen mit dem Configurations-Descriptor angefordert. Welche Art von Descriptor angefordert wird, ist im Feld wValue festgelegt. Die Codierung 0x01 entspricht dem DeviceDescriptor, 0x2 dem Configurations-Descriptor und 0x03 der Aufforderung einen StringDescriptor zu erhalten. Optional kann der Request SetDescriptor in einem USB-Ger¨at ¨ implementiert sein. Dieser dient dem nachtr¨aglichen Andern von Informationen, die in ¨ den Descriptoren enthalten sind. Typischerweise wird dieser Request f¨ ur das Andern der Seriennummer oder Herstellerangaben in den String-Descriptoren genutzt. Der GetConfiguration-Request dient dazu, dem Host mitzuteilen mit welcher Konfiguration das Ger¨at momentan arbeitet. Sind dem Host alle Konfigurationsm¨oglichkeiten des Ger¨ates bekannt, kann dieser u ¨ber den SetConfiguration-Request die Konfiguration ¨ zuweisen, mit welcher das Ger¨at betrieben werden soll. Uber Get- und SetConfiguration wird auch die Stromaufnahme eines USB-Ger¨ates u ¨berwacht. Ein nicht konfiguriertes

31

Ger¨at ist in der Stromaufnahme auf 100mA begrenzt. Nach Auswahl einer Konfiguration d¨ urfen bis zu 500mA vom Bus entnommen werden. Innerhalb einer Konfiguration k¨onnen mehrerer Interfaces definiert sein, welche das Ger¨at unterst¨ utzt. Diese Interfaces k¨onnen Einstellungen aufweisen, die sich gegenseitig beeintr¨achtigen w¨ urden. Von diesen Einstellungen darf dann nur eine aktiviert sein. Welche dieser Einstellung aktiviert ist, wird u ¨ber den Request GetInterface ermittelt, welcher den Wert des AlternateSettings zur¨ uckliefert. Dieses AlternateSetting ist die Angabe der gerade aktivierten Einstellung. Mittels SetInterface kann die zu benutzende Eigenschaft aktiv vom Host gesetzt bzw. ge¨andert werden. Der optionale Request SynchFrame ist nur auf isochrone Endpoints, welche den PatternSynchronisationsmechanismus verwenden, nutzbar. Host und USB-Ger¨at m¨ ussen sich auf einen Frame einigen, f¨ ur welchen die Synchronisation durchgef¨ uhrt wird. Durch den SynchFrame Request ermittelt der Host die Start-Framenummer mit welcher die Synchronisation beginnen kann.

3.7 Enumerationsvorgang W¨ahrend des Vorgangs des Enumeration wird das angeschlossene USB-Ger¨at von Host identifiziert und konfiguriert. Dieser Prozess unterteilt sich in weitere Unterprozesse. Im ersten Prozessabschnitt wird die Verbindung eines neuen Ger¨ates durch das Anstecken der Anschlusskabel durch den Hub erkannt. Der Hub ermittelt dann in welche Geschwindigkeitskategorie das Ger¨at eingeordnet werden kann und meldet der HostSoftware welcher Ger¨atetyp verbunden wurde. Die weiteren Schritte der Enumeration werden anschließend von der Host-Software kontrolliert. Die Hostsoftware beginnt mit einem ersten Kommunikationsversuch durch senden eines Standard-Device-Requests, um die Meldung des Hubs u ufen. ¨ber ein neues Ger¨at zu pr¨ ¨ Wird dieser vom Ger¨at beantwortet, wird die Ubertragung vom Host abgebrochen und ein Reset des Ger¨ates vom Host initiiert. Dieser versetzt das USB-Ger¨at in einen definierten Ausgangszustand und macht es f¨ ur den Host unter der Defaultaddresse 0 ansprechbar. An diese Defaultadresse sendet der Host den Standard-Request SetAdress. Mittels SetAdress wird dem Ger¨at eine eindeutige Adresse gegeben unter der es f¨ ur k¨ unftige Requests erreichbar ist. Ist die Addressierung des Ger¨ates abgeschlossen, wird vom Host der Device-Descriptor abgefragt. Durch die erhaltenen Informationen ist dem Host bekannt, wie viele Konfigurationen f¨ ur das Ger¨at m¨oglich sind. F¨ ur alle Konfigurationen werden im Anschluss die entsprechenden Configurations-Descriptoren angefordert. Zu den entsprechenden Configurations-Descriptoren werden die zugeh¨origen Interface- und Entpoint-Descriptoren mit u ¨bertragen. Klassenspezifische Descriptoren werden ebenfalls mit dem Configurations-Descriptoren vom Ger¨at zum Host u ¨bertragen. Die Anfrage nach den Device- und Configuration-Descriptoren erfolgt, abh¨angig von der Implementierung

32

der Host Treiber, mehrfach. Diese Mehrfachabfrage ist n¨otig, da auf der Host Seite die ben¨otigten Treiberschichten dynamisch nachgeladen werden. Jeder neugeladenne Treiber ben¨otigt die Information zu den Eigenschaften des Ger¨ates. Zwischen den einzelnen Treiberschichten werden die Informationen aus den Descriptoren nicht zwischengespeichert und stehen so nicht global f¨ ur alle Treiberschichten zur Verf¨ ugung. Nach der Descriptorenabfrage sind dem Host alle Informationen u ¨ber das Ger¨at bekannt. Anhand der VendorID und ProduktID aus dem Device-Descriptor w¨ahlt der Host einen passenden Treiber f¨ ur das entsprechende Ger¨at aus. Ist kein passender Treiber vorhanden, wird die Treibersuche ausgeweitet und mit den Informationen zum Klassen-, Subklassen- und Protokoll-Code eine erneute Treibersuche begonnen. Ist diese Suche nicht erfolgreich muss der Treiber f¨ ur das entsprechende Ger¨at vom Nutzer manuell nachinstalliert werden. Ist ein passender Ger¨ate-Treiber ausgew¨ahlt und aktiviert, entscheidet der Host, abh¨angig von der Gesamtauslastung des Busses, welche Konfiguration auf dem Ger¨at verwendet werden soll. Mittels des SetConfiguration Request wird die ausgew¨ahlte Konfiguration aktiviert und die entsprechenden Interfaces und Endpoints initialisiert. Klassenspezifische Descriptoren werden nach der Konfiguration vom Host angefordert und die, f¨ ur die endg¨ ultige Konfiguration n¨otigen, Klassen-Requests ausgef¨ uhrt. Anschließend ist die Enumerierung abgeschlossen und das Ger¨at kann verwendet werden.

3.8 Ger¨ ateklassen Die Definition von USB-Ger¨ate-Klassen erleichtert Hardwareherstellern die Entwicklung neuer Ger¨ate. F¨ ur Ger¨ate mit a¨hnlichen Eigenschaften gibt es festgelegte Klassen. Kann ein Ger¨at unter den Rahmenbedingungen einer USB-Klasse entwickelt werden, ist die Entwicklung eines hostseitigen Treibers oft nicht n¨otig. Auf der Host-Seite werden die ben¨otigten Softwarekomponenten f¨ ur die Kommunikation mit dem Ger¨at durch das ¨ Betriebssystem bereitgestellt. Tabelle 1 zeigt eine Ubersicht u ultigen ¨ber die derzeit g¨ USB-Klassen. Einzelheiten zu diesen Klassen sind im Entwickler-Bereich15 des USBImplementers-Forum einsehbar. In den jeweiligen Klassenspezifikationen sind die Anforderungen gegeben, welche Bedingungen vom Ger¨at und dessen Firmware erf¨ ullt werden m¨ ussen. Zu diesen z¨ahlen maßgeblich die Bereitstellung von klassenspezifischen Descriptoren und die Unterst¨ utzung klassenspezifischer Requests. Die verwendete Klasse wird als Information im Device- oder Interface-Descriptor des Ger¨ates u ¨bergeben und dient der Identifizierung und Treiberauswahl w¨ahrend der Enumeration (vergl. 3.7 auf Seite 33).

15

http://www.usb.org/developers/defined class

33

Klassencode 0x00 0x01 0x02 0x03 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0D 0x0E 0x0F 0xCD 0xDC 0xFH 0xEF 0xFE 0xFF

Bezeichnung Basis, falls Interfaces eigene Klassencodes besitzt Audio Communication und CDC HID - Human Interface Device Physical Image Printer Mass-Storage Hub CDC-Data Smart-Card Content Security Video personal Healthcare Audio/Video Diagnostic Wireless Controller Miscellaneous Application Specific Vendor Specific Tabelle 1: USB-Ger¨ate-Klassen

3.9 HID Eigenschaften Aufgrund der Bedeutung im sp¨ateren Teil der Arbeit wird an dieser Steller genauer auf die Human-Interface-Device(HID) Ger¨ate-Klasse, deren Eigenschaften und Anforderungen, eingegangen. Die HID-Klasse enth¨alt die Rahmenbedingungen f¨ ur Ger¨ate, mit denen die Steuerung von Hardware durch den Benutzer erm¨oglicht wird. Beispiele f¨ ur typische HID-Ger¨ate sind u.a. Tastatur, PC-Maus, Joysticks und Gamepads. Auch f¨ ur Anwendungen, die keine Interaktion des Benutzers voraussetzen, ist die HID-Klasse gedacht, wenn die Daten die vom Ger¨at geliefert werden in einem ¨ahnlichen Format vorliegen, wie in den obigen Beispielen. Somit k¨onnen z.B. Bar-Code-Scanner und Messger¨ate als HID-Ger¨at betrieben werden. Durch die Nutzung der HID-Klasse kann ein Ger¨at relativ einfach realisiert werden. Aus dieser Einfachheit folgt aber auch eine Limitierung f¨ ur die Ger¨ate selbst. Ger¨ate der HIDKlasse k¨onnen nur Control- und Interrupt-Transfers nutzen. Die maximale EndpointGr¨oße und Pollingperiode ist begrenzt. Durch diese Begrenzungen ist die theoretisch m¨ogliche Datenrate begrenzt. Die Anzahl der Endpoints ist ebenfalls festgelegt. Ein HIDGer¨at muss den Control-Endpoint EP0 und einen Interrupt-IN-Endpoint bereitstellen. Ein Interrupt-Out-Endpoint ist optional. Die wesentlichen HID Eigenschaften f¨ ur die USB-Geschwindigkeitsklassen sind in Tabelle 2 zusammengefasst.

34

Geschw.-Klasse Low-Speed Full-Speed High-Speed16

max. Datenrate 800 Byte/s 64 KByte/s 8 MByte/s

Nutzdaten/Transferframe min. Intervall 8 Byte 1 ms 64 Byte 1 ms 1024 Byte 125 µs

¨ Tabelle 2: Ubersicht der HID Limitierung

In der HID-Spezifikation sind drei Discriptor-Typen beschrieben, die zus¨atzlich zu den Standard-Descriptoren unterst¨ utzt werden k¨onnen bzw. m¨ ussen. Die Eingliederung dieser Descriptoren in die Gesamt-Descriptor-Struktur ist in Abbildung 17 dargestellt. HIDund Report-Descriptor m¨ ussen von dem Ger¨at bereitgestellt werden. Der HID-Descriptor enth¨allt Informationen u ¨ber die Anzahl, Art und Gr¨oße der ihm folgenden Descriptoren. Der Datenempfang bzw. Austausch mit einem HID-Ger¨at erfolgt u ¨ber definierte Strukturen. Diese Strukturen werden Reports genannt. Der Report-Descriptor enth¨alt die Informationen wie diese Reports aufgebaut sind. Der Physical-Descriptor ist optional. Er beinhaltet Informationen, welches menschliche K¨orperteil in Verbindung mit dem Ger¨at steht bzw. mit einem Teil des Ger¨ates. So kann z.B. der Tastendruck eines zus¨atzlichen Tasters an einer PC-Maus mit dem Daumen der rechten Hand in Verbindung gebracht werden.

Abbildung 17: USB-HID Descriptptor Struktur Neben den klassenspezifischen Descriptoren muss ein HID-Ger¨at die klassenspezifischen Requests bearbeiten k¨onnen. Die HID Spezifikation 1.11 gibt sechs zus¨atzliche Requests vor. Zu diesen z¨ahlen GetReport, SetReport, GetIdle, SetIdle, GetProtocol und Set¨ Protocol. Mittels GetReport kann der Host die Ubertragung eines bestimmten Reports ¨ initiieren. Aqivalent dazu kann der Host mittels SetReport einen Report an das Ger¨at ¨ schicken. Uber den Request GetIdle, kann der Host das eingestellte Intervall herausfinden mit dem neue Reports erzeugt werden und somit der Endpoint gepollt werden soll. Mit SetIdle ist der Host in der Lage, diese Intervallzeit nachtr¨aglich anzupassen. Get16

Unterst¨ utzt der Host High-Bandwidth-Endpoints, kann die Datenrate bis zu 23,4 MByte betragen. In diesem Fall kann der Enpoint 3 mal pro Microframe gepollt werden (vergl. [UI00] S. 56 ).

35

und SetProtocol erm¨oglichen es dem Host herrauszufinden welche Protokolle vom Ger¨at unterst¨ utzt werden und die entsprechenden, bei Bedarf, zu aktivieren [UI01].

36

4 Funktionalit¨ at des Sensor-API Die Sensoreinheit der eKon-Hardware beinhaltet die folgenden Sensoren: ˆ 3-achsiger Beschleunigungssensor ˆ 3-achsiger Drehratensensor ˆ 3-achsiger Magnetfeldsensor ˆ Luftdrucksensor

Diese Sensoren sind u ¨ber eine I2C-Verbindung auf der Windows Embedded Compact 7 Platform ansprechbar. Zur Konfiguration und zum Auslesen der Sensordaten, m¨ ussen die internen Register jedes Sensors einzeln angesprochen werden. Aufgrund der Komplexit¨at der Sensoren, ihren unterschiedlichen Funktionen und der variierenden internen Registerstruktur unterscheidet sich die direkte Steuerung der 4 Sensoren stark voneinander. Um das Ansprechen und Konfigurieren der Sensoren zu vereinfachen, wurde in einem an die Bachelorarbeit vorangegangenen Praktikum, ein Application-ProgrammingInterface(API) entwickelt. Dieses API kapselt die logischen Funktionen der Sensoren und vereinheitlicht deren Ansteuerung. Dass die Kommunikation mit den Sensoren u ¨ber den I2C-Bus erfolgt, bleibt vor dem Nutzer verborgen. Dieser kann auf einheitliche, vordefinierte Funktionen zur¨ uckgreifen und muss sich nicht mit den n¨otigen I2C-Protokollen und einzustellenden Registerbelegungen der einzelnen Sensoren auseinandersetzen. Das Sensor-API stellt Funktionen zur Konfiguration der Sensoren(Datenquellen) und die Implementierung zum Erhalt der Sensordaten(Datensenke) bereit. Durch den Aufruf von Factory-Methoden k¨onnen Software-Objekte erstellt werden, welche den realen Sensoren ¨ entsprechen. Uber definierte Schnittstellen(Interfaces) kann auf den jeweiligen Sensor zugegriffen werden. In Tabelle 3 sind die, durch das Sensor-API, bereitgestellten Grundfunktionen mit ihrer Beschreibung dargelegt. Funktionsname Open() Close() Start() Stop() Reset() Unbind() Destroy()

Beschreibung Stellt Verbindung mit dem Sensor her Schliesst die Verbindung zum Sensor Startet die Datenerfassung Beendet die Datenerfassung Stellt definierten Ausgangszustand des Sensors her Trennt die Verbindung zur Datensenke Gibt das Sensor-Object frei

Tabelle 3: Grundfunktionen der Sensoren

37

F¨ ur die individuellen Einstellungsm¨oglichkeiten, wird f¨ ur jeden Sensor eine Schnittstel¨ le zur Verf¨ ugung gestellt, um dessen spezifische Konfiguration vorzunehmen. Uber diese Schnittstellen ist beispielsweise die Konfiguration der Datenrate, des Aufl¨osungsverm¨ogens und verschiedener Filtereigenschaften m¨oglich. Eine Gesamtauflistung aller m¨oglichen Konfigurationsfunktionen ist in der Sensorschnittstellen-Spezifikation auf der beigelegten CD in \Sensor-API\peripherals.pdf gegeben. F¨ ur jeden der vier genannten Sensoren wird, intern in der Sensorimplementierung, ein Thread gestartet. Innerhalb dieser Threads erfolgt die Pr¨ ufung auf neu-verf¨ ugbare Messwerte. In der derzeitigen Version des Sensor-APIs erfolgt diese Pr¨ ufung, in Abh¨angigkeit von der eingestellten Datenrate der Sensoren. Abh¨anhgig von der eingestellten Datenrate werden die entsprechenden Statusregister der Sensoren gepollt. Ist ein neuer Datenwert vorhanden, wird dieser an die entsprechende Sensor-Datensenke weitergeleitet und kann dort verarbeitet werden. Es erfolgt keine Pr¨ ufung, ob Datenwerte verarbeitet werden oder nicht. Mit Eintreffen neuer Sensordaten, werden die alten Daten unwiderruflich u ¨berschrieben.

38

5 Anforderungsanalyse Die Anforderungen an die zu entwickelnden Softwarekomponenten resultieren maßgeblich aus den Anwendungsszenarien der zur Verf¨ ugung stehenden Hardware. Anwendungsfall eins tritt w¨ahrend der Entwicklung des eKon-Systems auf. Aufgrund von Fertigungstoleranzen der Sensoren und dem Aussetzung von Stress(Hitze, mechanische Belastung) w¨ahrend der Platinenherstellung weisen Messwerte der Sensoren Abweichungen von der Realit¨at auf. Um diese Abweichungen zu kompensieren bzw. Fehlereinfl¨ usse zu minimieren ist eine Kalibrierung der einzelnen Sensoren notwendig. Die Kalibriermaßnahmen sollen unter Zuhilfenahme eines PCs durchgef¨ uhrt werden k¨onnen. Weiterhin sollen zu Testzwecken die Daten der Kamera u ¨bertragen werden k¨onnen. Der zweite Anwendungsfall entspricht dem sp¨ateren Einsatzszenario. Die auf der Windows Embedded Compact Plattform, aus den Sensordaten, errechneten Posen m¨ ussen auf das Android-Tablet u ¨bertragen werden. Auf dem Tablet kann dann die Weiterverarbeitung und/oder Visualisierung erfolgen. F¨ ur die Entwickler der Positionsbestimmungssoftware ist die Verf¨ ugbarkeit der Sensordaten auf der PC-Seite hilfreich. Anhand der Daten kann eine Charakterisierung des Sensordatenstroms(Zeitintervalle, Messbereiche usw.) erfolgen, welche in Modelle, Berechnungen und Simulationen mit einbezogen werden. Die einzige, standardm¨aßig vorhandene, gemeinsame Schnittstelle der drei einzelnen Systeme Windows-PC, Windows Embedded Compact 7 Platform und Android-Tablet ist ¨ die USB-Schnittstelle. Deswegen soll die Ubertragung von Sensor- und Posendaten u ¨ber USB erfolgen. Aus den geschilderten Anwendungsf¨allen ergibt sich die Forderung, dass bei Verwendung der zu entwickelnden Softwarekomponenten, das Cadun-Board17 als USB-Ger¨at von einem Host erkannt und verwendet werden kann. Durch die beabsichtigte Nutzung verschiedener Host-Systeme(Android-Tablet und Windows-PC) sollte das Ger¨at keine ger¨atespezifischen Treiber auf den Host-Systemen ben¨otigen, um den Ent¨ wicklungsaufwand m¨oglichst gering zu halten. Um die Ubertragung von Sensor-, Posenund Kameradaten parallel nutzen zu k¨onnen, muss das Ger¨at als Composite-Device konfiguriert werden, um die verschiedenen Funktionen u ¨ber einen USB-Anschluss realisieren zu k¨onnen.

17

Entwicklungsboard des eKon-Projektes der Firma Emtrion. F¨ ur weitere Informationen vergl. http://www.emtrion.de/dimm base cadun de.php

39

6 Entwurf ¨ Der folgende Abschnitt gibt einen Uberblick, wie die entwickelten Softwarekomponenten ins vorhandene System integriert werden. Der strukturelle Aufbau und die Verbindung zwischen den Einzelkomponenten wird dargelegt und erkl¨art. Die spezifischen Eigenschaften der Sensor- und USB-Komponenten werden untersucht und in die Planung des ¨ Ubertragungsmechanismus mit einbezogen.

6.1 Realisierung als HID-Ger¨ at Aus den, in der Anforderungsanalyse, genannten Anwendungsszenarien und Bedingungen folgt die Entscheidung, die eKon-Hardware als HID-Ger¨at einzurichten. Die Realisierung als HID-Ger¨at bringt den Vorteil, dass HID-Ger¨ate von Windows automatisch unterst¨ utzt werden(bereits seit der Version Windows 98SE). Mit Einf¨ uhrung der Version 3.1 kann auch auf dem Android-Betriebssystem auf USB-Host Funktionalit¨at zur¨ uckgegriffen werden (vergl. [Dev14]). Beispielapplikationen zur Steuerung und zum Datenaustausch mit HID konformen Ger¨aten sind verf¨ ugbar (vergl. [Lav14]). Durch die Nutzung der HID-Klasse kann hostseitig der Entwicklungsaufwand gering gehalten werden, da keine spezifischen Ger¨atetreiber entwickelt werden m¨ ussen.

6.2 Struktur der Softwarekomponenten Das eKon-Projekt verwendet als Basis ein Entwicklungsboard, auf welchem Windows Embedded Compact 7 als Betriebsystem verwendet wird. Durch die Nutzung dieses Betriebsystems ist eine Grundlage f¨ ur die Daten¨ ubertragung u ¨ber USB bereits vorhanden. In Abbildung 18 ist schematisch dargestellt, welche Komponenten an der Kommunikation u ¨ber USB, auf der Ger¨ateseite, beteiligt sind.

Abbildung 18: Struktur der USB-Komponenten auf Ger¨ateseite

40

Die Softwarekomponente f¨ ur die direkte Hardwareansteuerung(USB-Controller-Treiber) 18 wird von Freescale , dem Hersteller des Chipsatzes, zur Verf¨ ugung gestellt. Der USBBus-Treiber wird durch das Betriebsystem bereitgestellt. Die zu ladende Function-TreiberKomponente wird, durch den USB-Bus-Treiber, im Betriebssystem unter einer entsprechenden Adresse registriert. Die zu implementierende USB-HID-Function Komponente stellt die ben¨otigte HIDKlassenfunktionalit¨at bereit. Dazu m¨ ussen die entsprechenden Descriptoren und die ben¨otigten HID-Class-Requests umgesetzt werden (vergl. 3.9). Weiterhin wird in dieser Komponente die Konfiguration und Steuerung der Sensoren u ¨bernommen und die erhaltenen Daten f¨ ur den Transfer u ¨ber den USB vorbereitet. Um anderen Softwarekomponenten Zugriff auf die Treibersoftware zu erm¨oglichen, muss ein Interface definiert und implementiert werden. Durch dieses Interface ist es dem USB-Function-Treiber m¨oglich, die HID-Komponente im System zu registrieren. Die grundlegenden Funktionen der HIDTreiber-Komponente sind in Abbildung 19 dargestellt.

Abbildung 19: Funktionen der USB-HID-Komponente

6.3 Vergleich der Datenraten Um eine Absch¨atzung zu treffen wie der Datentransfer u ¨ber USB erfolgen kann, wird nachfolgend das Datenaufkommen untersucht. Der Fokus liegt hierbei auf dem Anwen¨ dungsszenario der Sensordaten¨ ubertragung zur Sensorkalibrierung. Uber die Datenraten der, im zweiten Anwendungsfall, zu u ¨bertragenen Posendaten liegen keine Informationen vor. Es ist aber davon auszugehen, dass die Datenraten f¨ ur Poseninformation kleiner oder maximal gleich den Sensordatenraten sind, da die Posendaten aus den Sensordaten berechnet werden.

18

http://www.freescale.com/

41

Sensor Accelerometer Magnetometer Gyroskop Barometer

Bezeichnung max. Datenrate LSM303DLHC 1344Hz / 5376Hz19 LSM303DLHC 220 Hz L3G4200D 800 Hz LPS331AP 25 Hz

Tabelle 4: Maximale Datenraten der verwendeten Sensoren

F¨ ur die theoretische Betrachtung wird davon ausgegangen, dass alle Sensoren mit den maximal m¨oglichen Datenraten Sensordaten liefern. Eine Auflistung dieser ist in Tabelle 4 gegeben. Die angegebenen Werte entsprechen den Angaben aus den entsprechenden Datenbl¨attern der Sensoren(vergl. [STM14d, STM14c, STM14b]). Aus den Angaben folgt, dass theoretisch pro Sekunde 2389 (bzw. 6421 bei Nutzung des Low-Power-Modes) Datens¨atze anfallen, welche per USB an den jeweiligen Host u ussen. Die praktisch erreichbare Datenrate liegt aus verschiedenen ¨bertragen werden m¨ Gr¨ unden unterhalb der theoretisch M¨oglichen. Alle Sensoren sind an dem selben I2C-Bus angeschlossen. Der verwendete I2C-Controller unterst¨ utzt I2C-Fast-Mode20 und somit einen theoretisch maximalen Bustakt von 400000 Hz. Da sich die I2C-Bustaktrate auf der verwendeten Hardware von einem u ¨bergeordneten Taktgeber ableitet und dadurch nur bestimmte Frequenzen m¨oglich sind, betr¨agt die maximale praktisch einstellbare Taktrate 343750 Hz21 . Die Sensoren Accelerometer, Magnetometer und Gyroscope liefern Messwerte f¨ ur jeweils 3 Achsen(x,y und z). Jeder Messwert einer Achse setzt sich aus 16Bit zusammen. Ein kompletter Datensatz eines Sensors setzt sich somit aus 48 Bit zusammen. Der Messwert des verwendeten Barometer wird als 24Bit Wert repr¨asentiert. ¨ Die Abbildung 20 gibt einen Uberblick, wie ein kompletter Messdatensatz eines Sensors(Accelerometer, Magnetometer oder Gyroskop) u ¨ber den I2C-Bus erfolgt. Weiter22 hin ist in der Abbildung der Protokoll-Overhead und die f¨ ur eine Daten¨ ubertragung ben¨otigten Taktzyklen zu erkennen. Mit der Annahme, dass die Signale f¨ ur die Start- und Stop-Erkennung und die KontrollDaten f¨ ur ein Master-Ackknowlege jeweils einen Takt ben¨otigen folgt, dass insgesamt ¨ 84 Takte f¨ ur die Ubertragung eines Sensordatensatzes ben¨otigt werden. F¨ ur den Ba¨ rometersensor ergeben sich ¨aquivalent 60 Takte. Momentan wird vor der Ubertragung eines entsprechenden Datenwertes ein Statusregister gepr¨ uft, ob ein neuer Datenwert vorhanden ist. Diese Statuspr¨ ufung ben¨otigt zus¨atzlich bei jedem Lesevorgang 40 Takte. 19

Bei Verwendung des Low-Power-Modes kann eine Datenrate von 5376Hz erreicht werden. F¨ ur weiterf¨ uhrende Informationen zu den I2C-Moden und den entsprechenden Eigenschaften vergl. [NXP14] 21 F¨ ur Informationen zur I2C-Taktgenerierung vergl. [Fre14][S. 1885]. 22 Als Protokoll-Overhead werden die Daten bezeichnet, die f¨ ur die Kommunikation auf dem Bus ben¨ otigt werden, aber keine Nutzdaten widerspiegeln.

20

42

Abbildung 20: Datentransfer eines Sensordatensatzes u ¨ber Fast-Mode I2C Ausgehend von 343750 maximal m¨oglichen Taktzyklen und 124 n¨otigen Takten f¨ ur den Erhalt eines Sensordatenwertes ergibt sich eine maximale Datenrate aller Sensoren zu 343750Hz/124Hz = 2772 Sensordatens¨atzen pro Sekunde.

Abbildung 21: I2C-Transaktion auf Busebene Eine weitere Einschr¨ankung der maximal zu erhaltenen Sensordatens¨atze zeigt sich bei ¨ der Uberpr¨ ufung der I2C-Busgeschwindigkeit. Bei der softwareseitigen Untersuchung der Dauer eines Registerlesevorgangs ergaben sich Diskrepanzen zwischen den theoretischen und den gemessenen Zeiten. Bei einer eingestellten Taktrate von 343750Hz entspricht die Dauer eines Taktes 2.91us. Die Dauer eines Registerlesevorganges ergibt sich zu 116us. In der praktischen Messung ben¨otigte das Auslesen eines Registers im Durchschnitt 233us und damit doppelt so lange, wie theoretisch n¨otig. Zur Kl¨arung dieser Unterschiede wurde die I2C-Kommunikation auf Hardwareebene mit Hilfe eines Logic-Analyzers untersucht. In Abbildung 21 ist ein Screenshot der Ausgabe des I2C-Logic-Analyzers Logic-Port23 der Firma Intronix dargestellt. Zu Testzwecken wurden direkt aufeinanderfolgend Datenregister der Sensoren ausgelesen. Im Bereich T=-300 bis T=-90 und T=+300 bis T=+210 ist das Auslesen von 3 Registern des Barometersensors dargestellt. Es zeigt sich, dass die I2C-Treiberkomponente, welche im Windows Compact Embedded 7 Systsem vorhanden ist, nach jeder abgeschlossenen Transaktion einen Zeitraum von ca. 85 Takten ben¨otigt, bis ein erneuter Datentransfer initiiert werden kann. Somit sinkt die 23

http://www.pctestinstruments.com/deutsch

43

m¨ogliche Datenrate, mit welcher Sensordaten vom I2C-Bus bereitgestellt werden k¨onnen, auf 343750Hz/(124Hz + 85Hz) = 1644Hz. Das zyklische Abfragen der Sensoren in jeweils einzelnen Threads ist so implementiert, dass pro Sensor nur einmal pro Millisekunde ein neuer Datenwert erhalten werden kann. Somit sinkt die maximal m¨ogliche Datenrate pro Sensor auf 1000Hz. Diese Einschr¨ankung ist nur f¨ ur den Accelerometersensor relevant, da nur dieser Datenraten gr¨oßer 1000Hz unterst¨ utzt. F¨ ur die weiteren Betrachtungen wird davon ausgegangen, dass Optimierungen an der Sensoransteuerung und der Datenbeschaffung vorgenommen werden. Es ist denkbar, das die Pollingmethode und die damit verbundene zus¨atzliche I2C-Busbelastung ersetzt werden. W¨ urden, die von den Sensoren zur Verf¨ ugung gestellten, Hardware-Interrupt und Data-Ready-Signale genutzt werden, k¨onnte eine Statusregisterpr¨ ufung entfallen. Die Busbelastung w¨ urde somit auf 84 Takte pro auszulesenden Sensordatensatz sinken. Pro Sekunde k¨onnten somit 323750Hz/84Hz = 409224 Sensordatens¨atze bereitgestellt werden. Das Sensor-API u ¨bernimmt neben der Sensoransteuerung und Datenbeschaffung, die Skalierung der, aus den einzelnen Registern gelesenen Werte. Diese Skalierung erfolgt auf die in der Schnittstellen-Spezifikation25 angegebenen Einheiten. F¨ ur die Sensoren Accelerometer, Magnetometer und Gyroscope erfolgt die Ausgabe der Messwerte pro Achse als 32Bit vorzeichnen behafteten Integerwert. Der Messwert des Barometers wird ebenfalls als 32Bit vorzeichenbehafteter Integer geliefert. Ausgehend von den 3-achsigen Sensoren fallen pro Sekunde 3 ∗ 32Bit ∗ 4092Hz = 392832Bit/s bzw. 49104 Byte/s (˜50KByte/s) an. Zus¨atzlich zu den Nutzdaten, soll f¨ ur jeden Messwert ein Zeitstempel u ¨bertragen werden. Dieser Zeitstempel wird durch einen 40 Bit Intergerwert repr¨asentiert. In Verbindung von Sensordaten und Zeitstempel ergibt sich eine Datenrate von (3 ∗ 32Bit + 40Bit) ∗ 4092Hz = 556512Bit/s bzw. 69564Byte/s. Bei der Nutzung der HID-Klasse ergeben sich Einschr¨ankungen wie sie unter 3.9 bereits erl¨autert wurden. Die theoretische Daten¨ ubertragungsrate von 8 MByte/s26 ist ausreichend, um die anfallenden 50KByte/s anfallenden Daten zu u ¨bertragen. Bei der praktischen Umsetzung ergeben sich weitere Einschr¨ankungen. Der Verwendete USB-Controler auf der eKon Hardware beschr¨ankt die maximale Endpoint-Gr¨oße auf 512Byte27 . Damit ergibt sich eine maximal m¨ogliche Datentransferrate von 512Byte/M icrof rame = 4096Byte/ms = 4M Byte/s. ¨ Die Uberpr¨ ufung der praktisch erreichbaren Datenraten wurde mit dem USB-Analyzer 24

Barometer wird vernachl¨ assigt aufgrund der geringen Datenrate Die Spezifikation befindet sich auf der beigelegten CD im Verzeichnis \Sensor-API\peripherals.pdf 26 Die maximal m¨ oglichen ˜24MByte/s werden vernachl¨assigt, da das Android-Betriebsystem momentan keine High-Bandwidth-Endpoints unterst¨ utzt (vergl. [Dev14]) 27 vergl. [Fre14, S. 454]

25

44

Beagle-USB-48028 durchgef¨ uhrt. In Tabelle 5 sind die Ergebnisse der Testmessungen dargestellt. Mess.-Nr. Ø SOF zwischen 2 Transfers Ø Zeit zwischen 2 Transfers [ms] max. SOF zwischen 2 Transfers max. Zeit zwischen 2 Transfers [ms] min. SOF zwischen 2 Transfers min. Zeit zwischen 2 Transfers [ms] Ø SOF zwischen 2 Transfers 10 SOF

1 2 3 4 5 Ø 9.73 9.14 9.10 9.14 9.12 9.25 1.22 1.14 1.14 1.14 1.14 1.16 43.00 29.00 30.00 28.00 36.00 33.20 5.38 3.63 3.75 3.50 4.50 4.15 2.00 2.00 2.00 1.00 2.00 1.80 0.25 0.25 0.25 0.125 0.25 0.23 2.65 2.61 2.68 2.65 2.67 2.65 0.33 0.33 0.34 0.33 0.33 0.33 16.64 15.66 15.51 15.63 15.53 15.79 2.08 1.96 1.94 1.95 1.94 1.97

Tabelle 5: Tabellenname

¨ Aus der Auswertung der Daten29 geht hervor, dass eine Ubertragung von Daten nicht ¨ in jedem Microframe erfolgen kann. Nach jeder zweiten initiierten Ubertragung folgt ein relativ langes Intervall, indem keine Daten u ¨bertragen werden k¨onnen. Die Ursache f¨ ur das Auftreten der relativ kurzen Pausen(im Durchschnitt 0.33ms) ist dadurch begr¨ undet, dass der Host die gesamt verf¨ ugbare Bandbreite auf alle angeschlossenen USB-Ger¨ate aufteilt. Die Ursache f¨ ur die relativ langen Pausen(im Durchschnitt 1.97ms) liegt im verwendeten USB-Controller bzw. im verwendeten Controller-Treiber welcher diesen ansteuert. Dieser verwendet intern einen Puffermechanismus und ist nicht in der Lage, den entsprechenden Puffer bzw. die entsprechenden Register innerhalb des 125µs ¨ Intervalls zu u ur die Ubertragung bereitzustellen. ¨berschreiben und die neuen Daten f¨ ¨ Bezogen auf den Mittelwert ist somit eine Ubertragung von Datenpaketen in Abst¨anden von 1.16ms m¨oglich, was neun Microframes entspricht. Durch die begrenzenden Faktoren ergibt sich die verf¨ ugbare Bandbreite f¨ ur die Sensordaten¨ ubertragung per USB zu 512Byte/(9 ∗ 125us) = 455111Byte/s. Die praktisch zur Verf¨ ugung stehende Bandbreite ist somit um ein Vielfaches(um den Faktor 16) kleiner als theoretisch m¨oglich. Im Vergleich zur ben¨otigten Bandbreite, von rund 70KByte/s zur Sensordaten¨ ubertragung, um den Faktor sieben gr¨oßer und somit ausreichend. Aufgrund der begrenzten Anzahl von Transfers pro Sekunde ist es m¨oglich, dass neue Sensordaten eintreffen, bevor ein a¨lterer Sensordatensatz per USB u ¨bertragen werden ¨ konnte. Um das Uberschreiben eines Sensordatenwertes zu verhindern, wird ein Puffer¨ mechanismus implementiert, indem die Sensordaten vor der Ubertragung auf dem USB zwischengespeichert werden. 28 29

http://www.totalphase.com/products/beagle-usb480/ Die protokollierte Messdaten der USB-Analyse befinden sich auf der beigelegten CD im Verzeichnis \Messdaten\USB-Analyse\.

45

Die Realisierung eines Puffer zum Verhindern des Datenverlustes basiert auf dem DoubleBuffer-Prinzip. In Abbildung 22 ist der Puffermechanismus dargestellt.

Abbildung 22: Zwischenspeicherung der Sensordaten Es existieren zwei Puffer, welche die Funktion eines Sendepuffers und Datenpuffers u ¨bernehmen. Die Gr¨oße jedes Puffers entspricht der maximalen Endpointgr¨oße. Nach jeder durchgef¨ uhrten Transaktion tauschen die beiden Puffer ihre Funktion. Mittels der Datensenken der Sensoren, werden die Sensorwerte in den Datenpuffer geschrieben. Ist der USB-Controller in der Lage Daten u uft, ob Da¨ber den USB zu verschicken wird gepr¨ ten im Datenpuffer vorhanden sind. Ist dies der Fall, wird dieser zum Sendepuffer und ¨ f¨ ur das Uberschreiben durch die Sensorsenken gesperrt. Der USB-Controller stellt die ¨ Daten f¨ ur die Ubertragung auf dem USB bereit. Die Sensorsenken erhalten gleichzeitig eine Referenz auf den zweiten verf¨ ugbaren Puffer, in welchen die neu anfallenden Daten ¨ zwischengespeichert werden. Ist die Ubertragung des Sendepufferinhaltes abgeschlossen, erfolgt die Pr¨ ufung auf vorhandene Daten im zweiten Puffer. Ist dies der Fall, erfolgt erneut der Austausch der beiden Zwischenspeicher in der beschriebenen Abfolge. Wie in Kapitel3.9 beschrieben, erfolgt der Datenaustausch f¨ ur HID-Ger¨ate u ¨ber Reports. Die Eigenschaften dieser Reports m¨ ussen dem Host w¨ahrend der Enumeration mitgeteilt werden. Da der verwendete Pufferspeicher bei geringen Sensordatenraten nur wenige Messwerte bzw. nur einen Messwert enth¨alt, muss dieser nicht komplett u ¨bertragen werden. Um nur die tats¨achlichen Nutzdaten zu u ¨bertragen werden Reports verschiedener Gr¨oßen vorgesehen f¨ ur verschiedene Anzahl von Messwerten. F¨ ur die nutzbaren 512Byte der maximalen Paketgr¨oße wurden 9 Reportstrukturen festgelegt. Die Skalierung dieser Reports ist in Tabelle 6 dargestellt. Die Einteilung der Gr¨oße erfolgte unter Ber¨ ucksichtigung der anfallenden Daten der Sensoren und des enthaltenen ProtokollOverheads.

46

Report-ID 1 2 3 4 5 6 Gr¨oße in Byte 12 25 37 49 97 145

7 8 9 289 433 512

Tabelle 6: Skalierung der Reportgr¨oßen

Anhand der Anzahl an enthaltenen Messwerten im Sendepuffer wird der entsprechend zu versendende Report bzw. die entsprechende Report-ID ausgew¨ahlt. Ohne die Verwendung eines Puffermechanismus w¨ urde ein kompletter Sensorwert in jeweils einem Paket u ¨ber den USB transportiert werden k¨onnen. Mittels der ReportID k¨onnte festgelegt werden, von welchem Sensor die u ¨bertragenen Daten stammen. Durch die Verwendung des Double-Buffering kann ein Nutzdatenpaket mehrerer Datenwerte unterschiedlicher Sensoren enthalten. Um die Weiterverarbeitung der versendeten Daten gew¨ahrleisten zu k¨onnen, wird ein minimalistisches Protokoll vorgesehen, durch welches die enthaltenen Daten in einem u ¨bertragenen Paket einem Sensor zugeordnet werden k¨onnen. Aus diesem Grund wird jedem Sensor eine feste Sensor-ID zugeordnet, welche mit den Messwerten und den Zeitstempeln u ¨bertragen werden muss. Der Aufbau der zu u ¨bertragenden Reports ist byteweise orientiert. Das erste Byte eines Reports ist durch die Vorgaben der USB-Spezifikation mit der jeweiligen Report-ID belegt. An zweiter Stelle folgt die Anzahl der enthalten Messwerte im Paket. Anschließend folgen die Sensor-ID, der Zeitstempel und die entsprechenden Sensordaten. Direkt daran kann der n¨achste Sensorwert, beginnend mit SensorID und Zeitstempel, angef¨ ugt werden. Der grunds¨atzliche Aufbau dieser Reportstruktur ist beispielhaft f¨ ur einen Report, welcher 2 Messwerte enth¨alt in Abbildung 23 dargestellt.

Abbildung 23: Aufbau eines Report mit 2 enthaltenen Messwerten(3-achsiger Sensor + Barometer) ¨ Die Ubertragenen Sensordaten m¨ ussen auf der Host Seite empfangen und ausgewertet werden. Durch die Nutzung der HID-Klasse muss kein ger¨atespezifischer Treiber entwickelt bzw. verwendet werden. Auf dem Windows Host-System erfolgt eine generische Unterst¨ utzung von HID-Ger¨aten. Eine statische Bibliothek(HIDLib) zur Kommunikation mit HID-Ger¨aten ist vorhanden. Zum Erhalt der Sensordaten wird eine Applikation ben¨otigt, welche die HIDLib nutzt, um die vom eKon-System versendeten Reports zu er-

47

halten und die enthaltenen Informationen auszuwerten. Durch das eingef¨ uhrte Protokoll, wie ein Report aufgebaut ist, k¨onnen die Informationen auf der Hostseite interpretiert werden.

48

7 Implementierung Im folgenden Abschnitt der Arbeit wird darauf eingegangen, wie die im Kapitel 6 besprochenen Softwarekomponenten, f¨ ur das eKon-System und das Windows-Hostsystem, umgesetzt werden. Als Ausgangspunkt f¨ ur die Implementierung der USB-HID Komponente wird auf einen existierenden USB-Treiber, welcher eine Schnittstelle f¨ ur die Nutzung eines seriellen Modems bildet, zur¨ uckgegriffen. Diese Software-Komponente liegt als Quelltext ohne Dokumentation vor. Dieser Ausgangsquelltext enth¨alt Funktionen f¨ ur die USB-Grundfunktionalit¨at und die notwendigen Funktionen zum Bedienen der seriellen Schnittstelle. Die wesentliche USB-Grundfunktionalit¨at f¨ ur die USB-Kommunikation wird u ur die seriel¨bernommen und um die HID-spezifischen Funktionen erweitert. Die f¨ le Kommunikation ben¨otigten Funktionen werden entfernt und die ben¨otigte Sensoransteuerung hinzugef¨ ugt.

7.1 Dateiorganisation Die Umsetzung der Programmieraufgaben erfolgte unter Zuhilfenahme der Entwicklungsumgebung Microsoft Visual Studio30 in der Version 2008 f¨ ur die embedded-seitige Entwicklung und Version 2010 f¨ ur die Entwicklung der Host-PC Applikation. Visual Studio unterst¨ utzt die Organisation von Quelltextdateien und anderen Ressourcen in Solutions und Projekten. Solutions dienen als Projektmappen und kapseln thematisch zusammengeh¨orige Projekte. Projekte enthalten alle ben¨otigten Datein und Konfigurationseinstellungen, um eine Softwarekomponente zu u ¨bersetzten und zu debuggen. In Abbildung 24 ist die Organisationsstruktur f¨ ur die Softwarekomponenten der eKon-Platform und der Host-PC Applikation dargestellt.

Abbildung 24: Organisation der Softwarekomponenten Die USB-Solution enth¨alt alle Komponenten, f¨ ur die Realisierung der USB-HID und Sensor-Funktionalit¨at der eKon-Hardware. Diese enth¨alt das HID-Projekt mit den ben¨otigten Funktionen f¨ ur Enumeration und Datentransfer. Das Projekt Sensoradapter stellt eine statische Bibliothek f¨ ur den Zugriff auf die Sensordaten und die M¨oglichkeit der Konfiguration bereit. Diese wird vom HID-Projekt verwendet. Das project HIDTester enth¨allt Unit-Tests um die Funktion der entwickelten Komponenten zu testen. 30

http://www.visualstudio.com/

49

Die TestApp-Solution enth¨allt ein Project(TestApp) welches die Softwarekomponenten f¨ ur den hostseitigen Datenempfang beinhaltet.

7.2 Klassen¨ ubersicht Die Realisierung der Softwarekomponenten f¨ ur die Sensor- und USB-Funktionalit¨at erfolgt durch Implementierung von C++ Klassen f¨ ur die durchzuf¨ uhrenden Aufgaben. Eine ¨ Ubersicht u ¨ber die relevanten Klassen ist in Abbildung 25 dargestellt.

Abbildung 25: Klassen¨ ubersicht der USB Solution Die Klasse CUSBFn enth¨allt die grunds¨atzliche Funktionalit¨at f¨ ur USB-Ger¨ate. Sie u ¨bernimmt die Initialisierung des Ger¨ates und die Beantwortung der Standard-Request. Weiterhin werden die ben¨otigten Descriptor-Strukturen und Descriptoreigenschaften festgelegt. Die Klassen CUSBFuncPipe und CUSBFuncTransfer enthalten die Funktio-

50

nalit¨at die Kommunikation u ¨ber USB zu erm¨oglichen und werden von CUSBFn verwendet. CUSBFuncPipe realisiert die Transfer-Pipe und die, durch die USB-Spezifikation, vorgeschriebenen Methoden, die auf diese ausgef¨ uhrt werden k¨onnen. CUSBFuncTransfer implementiert die notwendige Funktionalit¨at Daten u ¨ber eine eingerichtete Pipe zu transferieren. Diese Komponenten wurden aus dem zur Verf¨ ugung stehendem Treiber u ¨bernommen. Die Klasse CUSBHIDFn beerbt CUSBFn und erweitert die Funktionalit¨at um die HID-Spezifischen Requests und den Transport der Sensordaten, durch Nutzung der UsbSensorLib. In der UsbSensorLib werden Funktionen, welche f¨ ur alle Sensoren gleich sind, durch die Klasse CSensorAdapter bereitgestellt. F¨ ur die individuell zu implementierenden Funktionen werden virtuelle Funktionsdeklarationen vorgegeben, welche von Sensoradapterklassen implementiert werden m¨ ussen. Weiterhin wird eine Schnittstelle(ISensorAdapter) zur Verf¨ ugung gestellt, u ¨ber welche die Sensor-Adapter Zugriff auf die Sensor-Senken und somit auf die gelieferten Sensor-Daten erhalten. Die Klasse CConfigurationMap beinhaltet Hilfsfunktionen f¨ ur die Konfiguration der Sensoren. Die Klassen CReportBuffer und CReportDoubleBuffer stellen die ben¨otigten Funktionen f¨ ur das bef¨ ullen des Sende- und Daten-Puffers bereit.

7.3 Sensoradaption und Konfiguration Die Funktionalit¨at des Sensor-API wird von der HID-Treiberkomponente adaptiert. Um die Benutzung innerhalb der USB-Komponente zu vereinfachen, wurde ein Projekt in der USB-Solution erstellt, aus welchem die statische Bibliothek UsbSensorLib hervorgeht. Diese Bibliothek kapselt die Funktionalit¨at des Sensor-API und nutzt dieses zur Konfiguration der Sensoren. Die UsbSensorLib exportiert die Funktionen Bind(), Configure(), Start() und Stop() f¨ ur jeden der Sensoren und stellt die Schnittstelle f¨ ur den Datenerhalt bereit. Durch Nutzung von Configure() werden f¨ ur den entsprechenden Sensor alle unterst¨ utzten Einstellungen vorgenommen die durch das Sensor-API m¨oglich sind. Welche Konfigurationswerte eingestellt werden, wird aus den entsprechenden Eintr¨agen der Registry gelesen. F¨ ur jeden Sensor existiert ein spezifischer Key mit dessen Konfigurationseigenschaften. Tabelle 7 zeigt exemplarisch die Konfigurationsm¨oglichkeiten mit ¨ Beispielwerten f¨ ur den Accelerometer Sensor. Eine Ubersicht u ¨ber alle Sensoren und den m¨oglichen Konfigurationseinstellungen ist in Anhang B gegeben. Die Konfiguration der Sensoren erfolgt durch Abgleich der in der Registry eingestellten Werte mit den in der Schnittstellenspezifikation gegebenen Angaben. F¨ ur die einfachere Handhabung und eine geringere Fehleranf¨alligkeit aufgrund von Tippfehlern wurden die Bezeichnungen der Sensor-Optionen und deren Werte ge¨andert. Zum Abgleich m¨ ussen die Registry Werte auf die f¨ ur das Sensor-API g¨ ultigen Werte abgebildet werden. Realisiert wird die Abbildung durch Schaffung einer Struktur(Map-Struktur), die Sensor-Interface

51

Bezeichnung FullScale PowerMode FifoMode HighPassMode ODR OnOff EnableFIFO EnableHighResolution

Beispielbelegung 2g normal Bypass NormaleMode 400Hz on FALSE FALSE

Beschreibung Messbereichsauswahl Powermode Option Sensor FIFO Einstellung Hochpass-Option Output-Data-Rate Sensor aktivieren/ deaktivieren Sensor-FIFO aktivieren/ deaktivieren hohe Aufl¨osung aktivieren / deaktivieren

Tabelle 7: Beispielkonfiguration des Accelerometers u ¨ber die Registry

und Registry-Konfiguration miteinander verbindet. Das folgende Listing 1 zeigt diese Abbildung f¨ ur die m¨oglichen Output-Data-Rates des Accelerometer Sensors.

1

const CConfigurationMap : : SConfigurationEntry CAccelerometerAdapter←: : s_ODRValues [ ] =

2

{

3

{ L"1Hz" , AccODR_1Hz } ,

4

{ L"10Hz" , AccODR_10Hz } ,

5

{ L"25Hz" , AccODR_25Hz } ,

6

{ L"50Hz" , AccODR_50Hz } ,

7

{ L"100 Hz" , AccODR_100Hz } ,

8

{ L"200 Hz" , AccODR_200Hz } ,

9

{ L"400 Hz" , AccODR_400Hz } ,

10

{ L"1620 Hz_lp " , AccODR_1620Hz_lp } ,

11

{ L"1344 Hz_n" , AccODR_1344Hz_n } ,

12

{ L"5376 Hz_lp " , AccODR_5376Hz_lp }

13

};

Listing 1: Accelerometer ODR-Konfigurationseinstllungen (AccelerometerAdapter.cpp) Listing 2 zeigt einen Ausschnitt der Configure()-Funktion des Accelerometer-Adapters. Diese erh¨allt als Parameter die Pfadangabe f¨ ur den Registry-Key mit den Konfigurationsinformationen. Durch Nutzung der Hilfsfunktion IsEnabled() wird gepr¨ uft, ob das Accelerometer aktiviert werden soll. Ist dies der Fall, wird dessen Konfiguration durchlaufen. Dazu werden die ben¨otigten Parameter aus der Registry gelesen und anschließend, mittels der statischen Funktion s ODRMap.LookUp() gepr¨ uft, ob der erhaltene Wert in der Map-Struktur vorhanden ist. Ist dieser vorhanden erfolgt die R¨ uckgabe des, durch das Sensor-API definierten, einzustellenden Wertes f¨ ur die entsprechende Eigenschaft des Sensors. Sollte der in der Registry eingetragene Wert nicht in der Vergleichsstruktur auf-

52

gefunden werden, wird ein voreingestellter Default-Wert zur¨ uckgegeben und der Sensor mit diesem konfiguriert.

1 2

void CAccelerometerAdapter : : Configure ( const wchar_t * pwcsKey ) {

3

CSensorAdapter : : Configure ( pwcsKey ) ;

4

if ( ! IsEnabled ( ) ) return ;

5 6

// t h e a c c e l e r o m e t e r i s enabled , c o n f i g u r e i t

7

CReg regSensor ( HKEY_LOCAL_MACHINE , pwcsKey ) ;

8 9

// ODR

10

const wchar_t * pwcsSetting = regSensor . ValueSZ ( s_pwcsODRValue ) ;

11

unsigned int uValue = s_ODRMap . LookUp ( pwcsSetting ) ;

12

m_pAccelerometer−>ConfigureODR ( ( EAccelerometerODR ) uValue ) ;

13

// . . .

}

Listing 2: Acclerometer Konfiguration (AccelerometerAdapter.cpp) Zus¨atzlich zur Konfiguration der Sensoren, stellt die UsbSensorLib die ben¨otigte Funktionalit¨at des Puffer-Mechanismus bereit. Die Hauptaufgabe der DoubleBuffer Komponente ist das Bereitstellen des Daten- und Sende-Puffers und der Austausch dieser nach jeder Daten¨ ubertragung von Sensordaten per USB. Weiterhin enth¨allt die Klasse der Doublebuffer Implementierung die Funktionalit¨at die bereitgestellten Puffer mit der SensorID, dem ben¨otigten Timestamp und den erhaltenen Sensordaten zu f¨ ullen. Zum Schuzt vor Datenverlust, durch gleichzeitiges Zugreifen auf die Puffer von verschieden Threads, sind ¨ Lock() und Unlock() Funktionen implementiert. Tabelle 8 gibt einen Uberblick u ¨ber die 31 durch die ReportDoubleBuffer Klasse bereitgestellten Funktionen . Funktion bool Initialize() void LockBuffer() void UnlockBuffer() bool WriteHeader()

bool WriteI32()

Beschreibung reserviert Speicher f¨ ur 2 Puffer Sch¨ utz Puffer vor Zugriff gibt Puffer f¨ ur weitere Verwendung frei Pr¨ uft ob gen¨ ugend Speicher f¨ ur n¨achsten Sensorwert vorhanden ist und schreibt im Erfolgsfall SensorID und TimeStamp in den Puffer Schreibt erhalten Sensorwert in den Puffer

Tabelle 8: Beispielkonfiguration des Accelerometers u ¨ber die Registry

Die Kapselung der Sensor- und Puffer-Funktionen in einer Bibliothek bietet den Vorteil, 31 ¨

¨ Ubergebene Parameter sind aus Gr¨ unden der Ubersichtlichkeit nicht mit angegeben

53

dass die ben¨otigten Funktionen auf einfache Weise in der USB-HID-Klasse verwendet werden k¨onnen ohne die Komplexit¨at und Umfang des USB relevanten Quellcodes weiter zu erh¨ohen. Die Verwendung der Sensoren erfolgt durch Anlegen von Sensor-Objekten welche an eine Datensenke gebunden werden. Durch die von der UsbSensorLib bereitgestellte Funktionalit¨at erfolgt die Konfiguration der Sensoren automatisch mit dem Laden der HID-Komponente. Das Starten und Stoppen der Sensoren ist in die Funktionen f¨ ur die Benachrichtigung, ob das USB-Kabel verbunden oder getrennt wurde, integriert. Listing 3 zeigt ausschnittsweise die Verwendung der, durch die UsbSensorLib, bereitgestellten Funktionen in den USB-HID-Komponente.

1

void CUSBHIDFn : : CableDetached ( ) { // . . .

2

StopI2CSensors ( ) ;

3

// . . .

4 5

}

6

void CUSBHIDFn : : CableAttached ( ) {

7

// . . .

8

StartI2CSensors ( ) ;

9

// . . .

10

}

11

DWORD WINAPI CUSBHIDFn : : UsbWriteThreadProc ( ) {

12

bool bStayInLoop = true ;

13

HANDLE hHandles [ 2 ] ;

14

hHandles [ 0 ] = m_hShutdownEvent ;

15

hHandles [ 1 ] = m_ReportBuffer . GetDataAvailableEvent ( ) ;

16 17

while ( bStayInLoop )

18

{

19

DWORD dwWaitResult = WaitForMultipleObjects ( _countof ( hHandles ) ←, hHandles , FALSE , INFINITE ) ;

20 21

if ( WAIT_OBJECT_0 == dwWaitResult )

22

{ // r e q u e s t s t e r m i n a t i o n // . . .

23 24

}

25 26

if ( WAIT_OBJECT_0+1 == dwWaitResult )

27

{ // g e t data t o t r a n s m i t

28

PBYTE pBuffer ;

29

WORD wLength ;

54

bool bDataAvailable = m_ReportBuffer . GetReport(&pBuffer , &←-

30

wLength ) ; 31 32

if ( bDataAvailable )

33

{ // t r a n s m i t r e p o r t

34

DWORD dwLength = wLength ;

35

EnterCriticalSection(&csTransmitSection ) ;

36

if ( NULL != m_pInterruptIn ) m_pInterruptIn−>WriteData ( ←pBuffer , &dwLength ) ; LeaveCriticalSection(&csTransmitSection ) ;

37

}

38

}

39 40

}

41

// . . .

42

}

Listing 3: Verwendung der Sensoren in den USB-Komponenten(CUSBHIDFn.cpp) Das Hauptelement der USB-HID Funktion bildet der Transport-Thread. Dieser wird unmittelbar nach der Enumeration des USB-Ger¨ates gestartet und f¨ uhrt die Funktion UsbWriteThreadProc() aus. Innerhalb dieser Funktion wird durchgehend gepr¨ uft, ob eine USB-Verbindung besteht. Sollte die Verbindung getrennt sein, wird die Schleife verlassen und der Thread beendet. Ist die USB-Verbindung vorhanden, wird gepr¨ uft ob Daten von ¨ den Sensoren zur Verf¨ ugung stehen und gegebenenfalls die Ubertragung eingeleitet. Der zu u ¨bertragende Puffer wird dabei vor Schreibzugriff durch die Sensorthreads durch die ¨ Ausf¨ uhrung der Ubertragung in einer Critical-Section gesch¨ utzt.

7.4 Bereitstellung der Schnittstelle Wie im Grundlagenkapitel 2.4.4 zu Windows Embedded Compact 7 besprochen, erfolgt die Einteilung der Treiber in Stream- und Native-Treiber. Der Ausgangspunkt der USB-HID-Komponente ist als Stream-Treiber implementiert. Diese Struktur wird beibehalten. Damit der Treiber verwendet werden kann, muss daher ein Stream-Interface zur Verf¨ ugung gestellt werden. Dieses Stream-Interface exportiert Funktionen, durch welche die Treiberkomponente von anderen Softwarekomponenten, verwendet werden kann. Die Deklaration der Interface-Funktionen erfolgt im HID-Project in der Datei StreamInterface.h. Damit die Treiberkomponente erfolgreich geladen werden kann, werden folgende Funktionen exportiert: at ˆ HID Init : initialisiert das Ger¨ ˆ HID Deinit : deinitialisiert das Ger¨ at

55

ˆ HID IOControl : Ein- und Ausgabesteuerung des Ger¨ ates

offnet das Ger¨at ˆ HID Open : ¨ ˆ HID Close : schließt das Ger¨ at

Weitere optionalen32 Stream-Interface Funktionen werden nicht exportiert, da deren Funktionalit¨at nicht ben¨otigt wird.

7.5 Verwendung der Treiberkomponente Zur Nutzung der Treiberkomponente, muss die aus dem HID-Projekt resultierende DLL dem Betriebsystem zur Verf¨ ugung gestellt werden. Dazu wird die HID.Dll, w¨ahrend der Erzeugung, in das Windows Embedded Compact 7 Image eingef¨ ugt. Damit diese DLL vom Device-Manager geladen und vom Betriebssystem verwendet werden kann, wird in der Registry ein Key erzeugt der die ben¨otigten Informationen zum Laden der Treiberkomponente enth¨allt. Die ben¨otigten Angaben f¨ ur die Konfiguration des HID-Treibers ist in 9 dargestellt. Da es sich um einen USB-Function Treiber handelt, m¨ ussen die Einstellungen im Registry-Pfad [HKEY LOCAL MACHINE\Drivers\USB\FunctionDrivers\HID] hinterlegt werden. Bezeichnung idVendor idProduct Dll DeviceName Prefix bcdDevice FriendlyName

Wert 0x45E 0x0FF HID.dll eKon HID HID 0 eKon HID

Beschreibung Ger¨atehersteller-ID Product-ID Name der zu ladenden Treiberkomponente Name des USB-Ger¨ates Prefix der Treiberkomponente Versionsnummer des USB-Ger¨ates im BCD-Format FriendlyName des USB-Ger¨ates

Tabelle 9: HID Registry Konfiguration

Der HID-Treiber baut auf bereits vorhandene Treiberschichten des Windows Embedded Compact Systems auf und wird von diesen verwaltet. Um der entsprechenden Komponente mitzuteilen, dass der HID-Treiber verwendet werden soll, muss dies in der Registry konfiguriert werden. Da die eKon-Hardware als Composite-Device auf dem Host-PC erscheinen soll muss der Composite-Treiber als DefaultClientDriver ausgew¨ahlt werden. Im Registry-Key des Composite-Treibers k¨onnen anschließend in einem Listenfeld alle USB-Funktionen eingetragen werden, die nach der Enumeration f¨ ur den Host verf¨ ugbar sein sollen. In der folgenden Auflistung sind die Pfade und Keys mit den erforderlichen Einstellungen aufgelistet. 32

optionale Funktionen: HID PreClose, HID PowerUp, HID PreDeinit

HID Read,

56

HID Write,

HID Seek,

HID PowerDown,

ˆ PFAD: [HKLM\Drivers\FunctionDrivers]

- > KEY: DefaultClientDriver=CompositeFN ˆ PFAD: [HKLM\Drivers\FunctionDrivers \CompositeFN]

- > KEY: ClientDriverList=HID Sind die beschriebenen Registry-Einstellungen durchgef¨ uhrt und die HID.Dll im Windows Embedded Compact 7 Image vorhanden, kann die eKon-Hardware als USBComposite-Device betrieben werden. Bei der in Tabelle 9 angegebenen Vendor-ID handelt es sich um eine Vendor-ID von Microsoft. Diese darf w¨ahrend der Prototypenentwicklung genutzt werden. Mit der Fertigstellung eines eigenen Produktes muss ein Hersteller eine eigene Vendor-ID vom USB-IF33 erwerben.

7.6 Host-PC-Applikation F¨ ur den Datenempfang auf dem Host-PC wurde zur Demonstration der erfolgreichen Daten¨ ubertragung eine Applikation(TestApp) in C# entwickelt. Die Entwicklung eines API zum erhalt der Sensor-Daten war nicht notwendig. Durch die zur Verf¨ ugung stehende Bibliothek HIDLib k¨onnen die empfangen USB-Reports direkt erhalten und ausgewertet werden. Die Verbindung zu einem bestimmten USB-Ger¨at wird in der Test-Applikation durch den Vergleich der ProduktID und VendorID durchgef¨ uhrt. Wird ein Ger¨at mit den entsprechenden IDs im System gefunden, wird eine Daten-Senke erstellt, in welcher die eintreffenden Reports verarbeitet werden k¨onnen. In Listing 4 ist die Schnittstellenimplementierung f¨ ur den Erhalt der Reports aufgef¨ uhrt.

1

public void InputReportReceived ( IHid sender , byte reportId , byte [ ] ←inputReport )

2

{ // . .

3 4

while ( nCounter < nMeasurements )

5

{

6

nCounter++;

7

SensorID = inputReport [ nBufferIndex ] ;

8

switch ( SensorID )

9

{

10 11

case BarometerSensorID : // Barometer

12

// . . . 33

http://www.usb.org/developers/vendor/

57

myWriter . WriteLine ( " {0};{1};;;;;;;;;;{2} " , ←-

13

Math . Round ( nTimestamp , 0 ) , nPressure , ←reportIdentifier ) ; nBufferIndex += BarometerReportlength ;

14 15 16

case AccelerometerSensorID : // A c c e l e r o m e t e r

17

// myWriter . WriteLine ( "←-

18

{0};;{1};{2};{3};;;;;;;{4} " , Math . Round ( ←nTimestamp , 0 ) , AccX , AccY , AccZ , ←reportIdentifier ) ; nBufferIndex += OtherSensorReportLength ;

19 20

// . . .

21

}

22 23

}

Listing 4: Sink Implementierung zur Reportauswertung (TestApp/HidSink.cs) ¨ Die Ubermittlung des Reports findet als Byte-Array statt. Anhand der Anzahl an Messwerten, die im Report selbst mit u ¨bertragen wird und immer an zweiter Stelle zu finden ist, wird eine Schleife durchlaufen, bis alle Messwerte verarbeitet wurden. Anhand der Sensor-ID wird entschieden von welchem Sensor der folgende Messwert ist. Timestamp und Messwert werden aus dem Bytearray extrahiert und in Integer-Werte umgewandelt. Anschließend werden Timestamp und Messwert, unter Einhaltung einer festen Struktur, in eine Textdatei geschrieben. Diese Struktur ist wie folgt vorgesehen: Timestamp;Baro;AccX;AccY;AccZ;MagX;MagY;MagZ;GyroX;GyroY;GyroZ;Report-ID Jede Zeile der Textdatei entspricht einem Sensordatensatz eines Sensors. F¨ ur die 3achsigen Sensoren werden die Werte der einzelnen Achsen und f¨ ur das Barometer der Messwert f¨ ur den Luftdruck gespeichert. Durch die Separierung der Daten durch Semikolon und der Angabe u ¨ber den Auftrittszeitpunkt der Messwerte, lassen sich diese leicht mit einem Tabellenkalkulationsprogramm, wie z.B. Microsoft Excel auswerten. Die von einer Testmessung34 erhaltenen Werte des Accelerometers sind in Abbildung 26 dargestellt. Anhand des Diagramms l¨asst sich die erfolgreiche Daten¨ ubermittlung der Beschleunigungssensorwerte erkennen. Die Erdbeschleunigung wirkt nur in einer Achse des Sensors(Z-Achse) mit rund 1000mG. Die beiden anderen Achsen weisen Werte um den Null-Punkt auf. Abweichung von Idealwerten, sowie Schwankungen, sind darauf 34

Daten sind auf der CD im Verzeichnis \Messdaten \TestMessung.xlsx enthalten

58

Abbildung 26: Darstellung der erhaltenen Accelerometer Sensordaten zur¨ uckzuf¨ uhren, dass es sich um einen nicht kalibrierten Sensor handelt. Unter Zuhilfenahme der u ¨bertragbaren Daten, kann eine Sensorkalibrierung erfolgen. Die Auswertung der Report-IDs der u uhrt. ¨bertragenen Messwerte ist in Tabelle 10 aufgef¨ Es zeigt sich, dass zu mehr als 99% die Report-Ids 1 und 2 verwendet wurden. Diese Reports enthalten jeweils einen Sensordatensatz35 . Trotz der geringen Nutzung der gr¨oßeren Reports erweist sich deren Implementierung als n¨otig. Ohne diese w¨aren die Sensordatens¨atze, welche u ¨ber die Reports der IDs 3 und 4 geliefert wurden unwiderruflich verloren. Mit der Voraussicht auf eine Optimierung des Sensor-API und damit die Erh¨ohung der Sensordatenraten, wird die Verlagerung zur Nutzung der gr¨oßeren Reports notwendig werden. Report-ID Anzahl %-Anteil

1 2 3 4 5 6 1151 45576 96 34 0 0 2.45 97.26 0.20 0.07 0 0

7 8 9 0 0 0 0 0 0

Tabelle 10: Auftrittsh¨aufigkeit der Reports

35

Reports mit der ID 1 k¨ onnen nur einen Barometer-Datensatz aufnehmen. Reports mit der ID 2 k¨onnen einen Datensatz eines beliebigen Sensors aufnehmen.

59

8 Resu ¨mee und Ausblick ¨ Ziel der vorliegenden Arbeit war die Ubertragung von Sensor und Posendaten von, der im eKon-Project, verwendeten Hardware zu einem PC- bzw. Android-System. ¨ Als Ubertragungsmedium wurde die USB-Schnittstelle ausgew¨ahlt. Aufgrund der Verf¨ ugbarkeit und einfachen Handhabbarkeit auf der Window-PC Seite wurde als Basis der Daten¨ ubertragung die HID-Klasse verwendet. Um den USB-Datentransport realisieren zu k¨onnen wurde ein USB-HID-Treiber entwickelt, welcher die notwendige Funktionalit¨at f¨ ur die Verwendung der eKon-Hardware als USB-HID-Ger¨at gew¨ahrleistet. Zur Demonstration der erfolgreichen Daten¨ ubertragung und einfachen Handhabung wurde eine Beispiel-Applikation geschrieben, welche die erhalten Daten verwerten und strukturiert in eine Textdatei speichern kann. F¨ ur die Sensoren Accelerometer, Barometer, Magnetometer und Gyroskop konnte die ¨ geforderte Daten¨ ubertragung implementiert werden. Die Ubertragung der Daten des Bluetooth-Schrittsensors und der monochromen Board-Level-Kamera konnten nicht durchgef¨ uhrt werden. Aktuell sind diese Komponenten nicht u ¨ber die eKon-Hardware ansprechbar. Da derzeit nicht klar ist, in welcher Form die Daten von diesen Komponenten bereitgestellt werden, konnte keine Implementierung vorbereitet werden. F¨ ur die Inbetriebnahme und Daten¨ ubertragung des Schrittsensors ist es denkbar, dass die bisherige ¨ Report-Struktur und Ubertragungsmechanismen ausreichend sind. Durch die Erweiterung des Report-Protokolls um eine weitere Sensor-ID f¨ ur den Bluetooth Sensor soll¨ te eine Erweiterung problemlos durchgef¨ uhrt werden k¨onnen. F¨ ur die Ubertragung der Bilder der Board-Level-Kamera ist die Realisierung einer weiteren Treiberkomponente denkbar. Dadurch w¨ urde, unter Nutzung des Composite-Treibers der Windows Embedded Compact 7 Platform, die Funktionen der I2C-Sensoren und der Kamera parallel auf den Host-Systemen zu Verf¨ ugung stehen. Im Hinblick auf die weitere Entwicklung an dem HID-Treiber ist eine Umstrukturierung des Quellcodes sinnvoll. Zur Verbesserung der Wiederverwendbarkeit, Wartbarkeit und Lesbarkeit sollten die einzelnen Teilfunktionen voneinander getrennt und gekapselt werden. Eine Umstrukturierung k¨onnte die USB-Grundfunktionen, die HID-Funktionalit¨at und Sensoransteuerung als eigenst¨andige Komponenten bzw. Bibliotheken hervorbringen, welche gezielt in anderen Anwendungen genutzt werden k¨onnen. Im Zuge dieser Aufteilung, sollte die Sensorfunktionalit¨at komplett von der USB-Funktionalit¨at getrennt werden. Anstatt die Funktionen der Sensoradaption direkt in der Treiberkomponente zu verwenden, sollte eine Zwischenschicht implementiert werden, welche die Daten¨ ubertragung u ¨ber das Stream-Interface des HID-Treibers realisiert.

60

Literaturverzeichnis [Abb11]

D. Abbott. Linux for Embedded and Real-time Applications. Embedded Technology. Elsevier Science, 2011.

[ATL03]

G.I. ATLAS. Computer Lexikon Mit Fachw¨orterbuch: Deutsch-englisch, Englisch-deutsch. Microsoft Press Deutschland, 2003.

[Ber01]

A.S. Berger. Embedded Systems Design: An Introduction to Processes, Tools, and Techniques. CMP Books. Taylor & Francis, 2001.

[Bol10]

D. Boling. Programming Windows rence. Microsoft Press, 2010.

[Can99]

C. Cant. Writing Windows WDM device drivers. R&D, 1999.

[Com99]

Compaq, Hewlett-Packard, Intel, Lucent, Microsoft, NEC, and Philips. Universal Serial Bus Revision 2.0 specification, 1.0a edition, April 1999.

[Cor96]

Intel Corp. Universal Host Controller Interface (UHCI) Design Guide. Intel, 1.1 edition, March 1996.

[Cor02]

Intel Corp. Enhanced Host Controller Interface Specification for Universal Serial Bus. Intel, 1.0 edition, March 2002.

[Dev14]

Android Developers. http://developer.android.com/guide/topics/ connectivity/usb/host.html, 20.03.2014.

[ES09]

Ralf Ebert and Rudi Swointek. Das ger¨atetreibermodell von windows embedded ce 6.0 r2. Electronic, 21:38–44, 2009.

[exp14]

expresslogic. http://rtos.com/products/threadx/, 10.01.2014.

[FK14]

Rainer Fehr and J¨ urgen Kern. http://www.computerautomation.de/steuerungsebene/industrie-pc/artikel/101294/, 26.01.2014.

[Fre14]

Freescale. i.mx 6dual/6quad applications processor reference manual, http://www.freescale.com/webapp/sps/site/prod summary.jsp?code=i.mx6q, 04.2014.

[Hal10]

C. Hallinan. Embedded Linux Primer: A Practical Real-World Approach. Prentice Hall Open Source Software Development Series. Pearson Education, 2010.

[Ins14]

Texas Instruments. http://www.ti.com/tool/msp430ware, 10.01.2014.

® Embedded CE 6.0 Developer Refe-

61

[Jor04]

E. Jordan. Embedded Systeme mit Linux programmieren.: GNUSoftwaretools zur Programmierung ARM-basierender Systeme. Franzis PC und Elektronik. Franzis Verlag GmbH, 2004.

[Kch11]

A. Kcholi. Pro Windows Embedded Compact 7: Producing Device Drivers. Apressus Series. Apress, 2011.

[Kel03]

H.J. Kelm. USB 2.0 Das Praxisbuch. Franzis, 2003.

[KIT14]

KIT. http://os.ibds.kit.edu/downloads/ln kapitel-03 ueberblick-uebersysteme.pdf, 26.01.2014.

[Kum14]

Vijay Kumar. Linux 2.6 device model, 10.01.2014.

[Lav14]

Ihor Lavrynuk. https://github.com/452/usbhidterminal, 20.03.2014.

[Mar10]

P. Marwedel. Embedded System Design: Embedded Systems Foundations of Cyber-Physical Systems. Embedded systems. Springer, 2010.

[Mic14a]

Microsoft. msdn.microsoft.com/en-us/library/dn269456.aspx, 06.01.2014.

[Mic14b]

Microsoft. http://msdn.microsoft.com/enus/library/ee483089(v=winembedded.60).aspx, 07.01.2014.

[Mic14c]

Microsoft. 10.01.2014.

[NET14]

NETBSD. http://www.netbsd.org/docs/hardware/machines/arc/riscspec.pdf, 26.01.2014.

[NXP14]

NXP. I2c-bus specification and user manual http://www.nxp.com/documents/user manual/um10204.pdf, 16.04.2014.

[QNX14a]

QNX. http://fusion.qnx.com/6/11966/sys arch.pdf, 10.01.2014.

[QNX14b]

QNX. http://www.qnx.de/products/neutrino-rtos/index.html, 10.01.2014.

[RC02]

A. Rubini and J. Corbet. Linux-Ger¨atetreiber. O’Reilly Vlg. GmbH & Company, 2002.

[Riv14a]

Wind River. http://www.windriver.com/products/vxworks/, 19.01.2014.

[Riv14b]

Wind River. Vxworks kernel programmers guide 6.2, 19.01.2014.

[RLN05]

P. Raghavan, A. Lad, and S. Neelakandan. Embedded Linux System Design and Development. Taylor & Francis, 2005.

http://msdn.microsoft.com/en-us/library/jj674871.aspx,

62

[Rou14]

Margaret Rouse. 27.01.2014.

http://whatis.techtarget.com/definition/thread-safe,

[SGD09]

J. Schr¨oder, T. Gockel, and R. Dillmann. Embedded Linux:. Springer, 2009.

[SS14]

Diana Saft and Marcel Saft. http://www.lidux.de/linux.html, 11.01.2014.

[STM14a]

STMicroelectronics. 10.01.2014.

[STM14b]

STMicroelectronics. http://www.st.com/st-webui/static/active/en/resource/technical/document/datasheet/cd00265057.pdf, 16.04.2014.

[STM14c]

STMicroelectronics. http://www.st.com/web/catalog/sense power/fm89/ sc1316/pf251601, 16.04.2014.

[STM14d]

STMicroelectronics. http://www.st.com/web/catalog/sense power/fm89 /sc1449/pf251940, 16.04.2014.

[TI14]

TI. http://www.ni.com/white-paper/6424/de/, 26.01.2014.

[UI00]

USB-IF. Universal Serial Bus Revision 2.0 specification. Compaq, HewlettPackard, Intel, Lucent, Microsoft, NEC, and Philips, 2.0 edition, April 2000.

[UI01]

USB-IF. Device Class Definition for Human Interface Devices (HID). USBImplementers-Forum, 1.11 edition, June 2001.

[WB05]

H. W¨orn and U. Brinkschulte. Echtzeitsysteme: Grundlagen, Funktionsweisen, Anwendungen. EXamen. press Series. Springer, 2005.

[Yag03]

K. Yaghmour. Building Embedded Linux Systems. O’Reilly Media, 2003.

http://www.st.com/web/en/catalog/tools/fm147,

[YMBYG08] K. Yaghmour, J. Masters, G. Ben-Yossef, and P. Gerum. Building Embedded Linux Systems. O’Reilly Media, 2008.

63

Abbildungsverzeichnis 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

Treiberkomponente im Gesamtsystem . . . . . . . . . . . . . . . . . . gestapelte Treibermodule im Gesamtsystem . . . . . . . . . . . . . . QNX Microkernel Architektur . . . . . . . . . . . . . . . . . . . . . . Windows CE Systemarchitektur ab Version 6.0 . . . . . . . . . . . . . Struktur monolithischer Treiber . . . . . . . . . . . . . . . . . . . . . Aufbau geschichteter Treiber aus MDD und PDD . . . . . . . . . . . Linux Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . physikalische USB Struktur . . . . . . . . . . . . . . . . . . . . . . . logische USB Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . USB-Treiber Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . Aufbau eines Token-Packets . . . . . . . . . . . . . . . . . . . . . . . Aufbau eines Daten-Packets . . . . . . . . . . . . . . . . . . . . . . . Aufbau eines Handshake-Packets . . . . . . . . . . . . . . . . . . . . Phasen eines erfolgreichen Datentransfers vom USB-Ger¨at zum Host . USB Kommunikations-Modell . . . . . . . . . . . . . . . . . . . . . . Standard-USB-Request Aufbau . . . . . . . . . . . . . . . . . . . . . USB-HID Descriptptor Struktur . . . . . . . . . . . . . . . . . . . . . Struktur der USB-Komponenten auf Ger¨ateseite . . . . . . . . . . . . Funktionen der USB-HID-Komponente . . . . . . . . . . . . . . . . . Datentransfer eines Sensordatensatzes u ¨ber Fast-Mode I2C . . . . . . I2C-Transaktion auf Busebene . . . . . . . . . . . . . . . . . . . . . . Zwischenspeicherung der Sensordaten . . . . . . . . . . . . . . . . . . Aufbau eines Report mit 2 enthaltenen Messwerten(3-achsiger Sensor Barometer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organisation der Softwarekomponenten . . . . . . . . . . . . . . . . . Klassen¨ ubersicht der USB Solution . . . . . . . . . . . . . . . . . . . Darstellung der erhaltenen Accelerometer Sensordaten . . . . . . . .

64

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . + . . . . . . . .

5 6 9 11 13 13 15 21 22 24 24 25 26 26 28 31 35 40 41 43 43 46 47 49 50 59

Tabellenverzeichnis 1 2 3 4 5 6 7 8 9 10

USB-Ger¨ate-Klassen . . . . . . . . . . . . . . . . . . . . . ¨ Ubersicht der HID Limitierung . . . . . . . . . . . . . . . Grundfunktionen der Sensoren . . . . . . . . . . . . . . . . Maximale Datenraten der verwendeten Sensoren . . . . . . Tabellenname . . . . . . . . . . . . . . . . . . . . . . . . . Skalierung der Reportgr¨oßen . . . . . . . . . . . . . . . . . Beispielkonfiguration des Accelerometers u ¨ber die Registry Beispielkonfiguration des Accelerometers u ¨ber die Registry HID Registry Konfiguration . . . . . . . . . . . . . . . . . Auftrittsh¨aufigkeit der Reports . . . . . . . . . . . . . . .

65

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

34 35 37 42 45 47 52 53 56 59

Listingverzeichnis 1 2 3 4

Accelerometer ODR-Konfigurationseinstllungen (AccelerometerAdapter.cpp) 52 Acclerometer Konfiguration (AccelerometerAdapter.cpp) . . . . . . . . . 53 Verwendung der Sensoren in den USB-Komponenten(CUSBHIDFn.cpp) . 54 Sink Implementierung zur Reportauswertung (TestApp/HidSink.cs) . . . 57

66

Anhang A Weitere Informationen zu den Betriebssystemen sind auf den offiziellen Projekt- bzw. Herstellerseiten zu finden. QNX: - http://www.qnx.de/ VxWorks: - http://www.windriver.com/products/vxworks/ Nucleus: - http://www.mentor.com/embedded-software/nucleus/ freeRTOS: - http://www.freertos.org/ openRTOS: - http://www.wittenstein-us.com/Embedded-RTOS/OPENRTOS.html Osek: - http://opensek.sourceforge.net/ OS-9: - http://www.radisys.com/products/microware-os-9/ RTEMS: - http://www.rtems.com/ eCos: - http://ecos.sourceware.org/ NetBSD: - http://www.netbsd.org/ Windows CE/embedded Compact: - http://www.microsoft.com/windowsembedded/de-de/ windows-embedded-compact-2013.aspx Windows 7 embedded: - http://www.microsoft.com/windowsembedded/de-de/ windows-embedded-enterprise-7.aspx Windows Automotive: - http://www.microsoft.com/windowsembedded/de-de/ windows-embedded-automotive-7.aspx Symbian: - http://licensing.symbian.org/ CMX-RTX: - http://www.cmx.com/rtx.htm

67

68

Eidesstattliche Erklärung Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbstständig und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe. Die aus den Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht. Die Arbeit hat mit gleichem bzw. in wesentlichen Teilen gleichem Inhalt noch keiner anderen Prüfungsbehörde vorgelegen.

_________________ Ort, Datum

_________________ Unterschrift

Suggest Documents