11 USB - Universeller Serieller Bus
11.1 Allgemeine Eigenschaften, Vorteile, BedeutungBeim USB (engl. "Universal Serial Bus") handelt es sich um ein System, das es ermöglicht, bis zu 127 langsame und mittelschnelle Peripheriegeräte schnell, preiswert und problemlos an einen PC anzuschließen.11.1.1 BedeutungVor einigen Jahren setzten sich viele namhafte Firmen der Computer- und der Kommunikationsbranche (inzwischen über 300) an einen (symbolischen) Tisch. In einem inzwischen mehr als 5-jährigem Prozess brüteten sie ein System aus, mit dem sich so unterschiedliche Geräte wie Mikrofone und Drucker über einheitliche Schnittstellen an einen Rechner anschließen lassen.Die Fragestellung, die sie dazu brachte, kann man vereinfacht formulieren: "Wie bringt man ein Telefon in den PC?" Von dieser Seite erhoffen sich die Beteiligten auch den Schwung, um die bisherigen, längst nicht mehr zeitgemäßen PC-Schnittstellen durch ein einheitliches System zu ersetzen. Es ist sicher kein leichtes Vorhaben, wenn man bedenkt, dass USB weder auf Rechner- noch auf Peripherie-Seite mit den bisherigen Standards kompatibel ist. Die Liste der guten Eigenschaften ist lang. Die Einführung verlief trotzdem schleppend. USB gibt es derzeit in zwei Varianten: USB 1.1 als langsamere und USB 2.0 als schnellere Ausführung. Obwohl es für alle gängigen Eingabegeräte völlig ausreichend wäre, wird USB 1.1 aus Marketinggründen kaum noch angeboten. Dennoch möchte ich mich im Moment im vorliegenden Kapitel auf USB 1.1 beschränken und nur im letzten Abschnitt kurz die Änderungen beschreiben, die mit 2.0 eingeführt wurden. 11.1.2 Eigenschaften
11.1.3 GlossarDieses Kapitel kann nur eine Einführung in den USB geben, aber keinesfalls alle Einzelheiten darstellen. Zur Vertiefung empfehle ich die offizielle (englische) Spezifikation. Um den Umstieg zu erleichtern, sind in Tab. 11-1 die wichtigsten englischen Originalbegriffe erläutert. Englische und deutsche Begriffe werden in diesem Buch gleichberechtigt verwendet (z.B. Descriptor und Deskriptor), eingeklammerte deutsche Begriffe sind allerdings ungebräuchlich.Die Spezifikation legt keine Schreibweise zur Bezeichnung von Adressen, Port-Nummern, Transfers, Requests, Deskriptoren, Zuständen und Feldern fest. Trotzdem möchte ich mich hier so weit wie möglich an die gebräuchliche Schreibweise halten und diese nur ergänzen, wo es zur Verdeutlichung nötig ist. 11.2 Architektur, TopologieUSB wird zwar als Bus bezeichnet, hat aber physikalisch eine Baumstruktur (manchmal auch in Anlehnung an den englischen Begriff Tiered Star als Verzweigter Stern bezeichnet) (Abb. 11-2; rechts unten). An allen Verzweigungspunkten befinden sich sogenannte Hubs. An allen Zweigspitzen können Funktionen angeschlossen werden. Bis zu 127 Geräte (Hubs oder Funktionen) können über 7 bit-Adressen angesprochen werden. Eine weitere Unterteilung ist durch bis zu 31 Endpunkte pro Gerät möglich, die durch weitere 5 bit adressiert werden können. Der PC, der alle angeschlossenen Geräte überwacht und ihnen Adressen zuteilt, wird als Host bezeichnet. Die Funktionalität von Hubs und Funktionen kann weitgehend beliebig in physikalisch integrierten Geräten (Kombinationsgeräte; Compound Devices) kombiniert werden.Beispiele:
Abb. 11-3 zeigt ein Systembeispiel, bei dem 3 Geräte direkt an den Host angeschlossen sind:
11.3 Physikalische SchnittstelleDieses Unterkapitel beschreibt die mechanischen Eigenschaften und die Belegung von Kabeln und Steckern sowie die elektrischen Parameter von Versorgung und Datensignalen.11.3.1 VerbindungsphilosophieSteckverbindungen und Kabel (s. Abb. 11-3-2 und Abb. 11-4) sind so spezifiziert, dass der Anwender möglichst wenige Verbindungen erzeugen kann, die die Gesamtfunktion stören oder Teile sogar zerstören könnten. Dies wird erreicht durch...
Insbesondere sind "verboten":
11.3.2 KabelEs gibt zwei verschiedene Kabeltypen:
Beide Kabeltypen haben vier Adern mit folgender Belegung:
Der Aderquerschnitt der Signalleitungen beträgt AWG 28 (= 0.08 mm²), der Querschnitt der Versorgungsleitungen variiert je nach Kabellänge von AWG 20 (= 0.52 mm²) bis AWG 28 (= 0.08 mm² ). Das low-speed Kabel besteht aus vier unverdrillten Adern mit Kunststoffmantel, beim full-speed Kabel dagegen sind die zwei Signalleitungen verdrillt und alle vier Leitungen gemeinsam mit Alufolie und Kupfergeflecht abgeschirmt. Beide Kabeltypen dürfen zwischen zwei Geräten bestimmte Längen nicht überschreiten. In der Spezifikation 1.1 sind die Maximallängen indirekt definiert (in Version 0.9 war noch eine Maximallänge von 5 m direkt angegeben). Die Länge von full-speed Kabeln wird begrenzt durch...
Sind im Einzelfall doch längere Entfernungen zu überbrücken, bleibt als einziger "legaler" Ausweg die Zwischenschaltung eines Spezial-Hubs, der an seiner Downstream-Seite Host-Funktionalität aufweist. 11.3.3 SteckerIn einer Baumstruktur gibt es keine Querverbindungen. Um ein versehentliches Herstellen einer solchen Verbindung auszuschließen, verwendet USB zwei verschiedene Steckertypen: einen mit rechteckigem Querschnitt und einreihiger Anordnung der Kontakte (A-connector) und einen mehr quadratischen mit Anordnung der Kontakte im Viereck (B-connector)Alle Ports des Host und die in Richtung Endgeräte zeigenden Hub-Ports und Kabelanschlüsse werden nach der USB-Nomenklatur als "Downstream", alle in Richtung Host zeigenden Anschlüsse als "Upstream" bezeichnet. Unter Verwendung dieser Bezeichnungen wird festgelegt, dass alle Downstream-Ports mit Buchsen vom Typ A und alle Upstream-Ports mit Buchsen vom Typ B ausgestattet werden. Das verbindende Kabel enthält die entsprechenden Gegenstecker, also A-Stecker an der Upstream- und B-Stecker an der Downstream-Seite. Bei low-speed Verbindungen entfällt die B-Kombination, weil das Kabel fest am Gerät angebracht ist, bei full-speed Verbindungen kann sie entfallen. Abb. 11-4 zeigt die prinzipiellen Bauformen der beiden Steckertypen und ihre Belegungen. Die Stifte 1 und 4 zur Verbindung der Stromversorgung sind länger als die beiden anderen, um die Steckverbindung hot-plug fähig zu machen. Am Kabel sind die Stecker angespritzt, um die Herstellung eigener "wilder" Verbindungsleitungen zu erschweren. 11.3.4 VersorgungZwei speziell für USB eingeführte Begriffspaare erleichtern das Verständnis:
1 Unit Load = 100 mA
Sechs Geräte-Grundtypen sind vorgesehen:
11.3.5 GeschwindigkeitWie schon erwähnt, gibt es low-speed Geräte, die Daten mit 1.5 Mbps austauschen, und full-speed Geräte für eine Datenrate von 12 Mbps. Jedes Gerät wird über den passenden Kabeltyp angeschlossen.An den Downstream-Ports eines Hubs können wahlweise low-speed oder full-speed Geräte angeschlossen werden. Deshalb muss der Upstream-Port eines Hubs mit full-speed Treibern ausgestattet werden. Der Datenaustausch mit der nächsthöheren Ebene folgt den Signalkonventionen für full-speed bezüglich Polarität und Umschaltzeiten. Low-speed Geräte besitzen low-speed Treiber und tauschen Daten mit dem übergeordneten Hub nach low-speed Signalkonventionen aus. Die Downstream-Ports eines Hubs müssen umschaltbar sein, um beide Gerätetypen bedienen zu können. Um eine automatische Geschwindigkeitserkennung nach Reset zu ermöglichen, bekommen low-speed Geräte einen pull-up Widerstand (1.5 kOhm) von D- nach VBUS, full-speed Geräte dagegen von D+ nach VBUS. Im Downstream-Port sind beide Leitungen über pull-down Widerstände (15 kOhm) an GND angeschlossen. 11.3.6 SignalzuständeDie Kombination der beiden Signalleitungen D+ und D- kann vier Zustände annehmen. Die drei benutzten Zustände werden bezeichnet als
Diese werden, abhängig von der verwendeten Geschwindigkeits-Konvention, in logische Zustände umgesetzt. Einzelheiten zeigen die Abb. 11-5 und Abb. 11-6.
Zur Nutzdatenübertragung werden die Zustände J und K verwendet. Zur Verdeutlichung wird in den Abb. 11-5 und Abb. 11-6 noch unterschieden, woher die Zustände kommen, welcher Ausgangstreiber also gerade aktiv ist. Dabei stehen (D) für Downstream und (U) für Upstream. Durch OE(D)=L werden die Treiber Tx(D) des Downstream-Ports im Hub aktiviert. Sie erzeugen die Zustände J(D), K(D) und SE0(D). In der Gegenrichtung rufen die durch OE(U)=L aktivierten Upstream-Treiber des Gerätes die Zustände J(U), K(U) und SE0(U) hervor. Sind beide Richtungen inaktiv, herrscht der Zustand IDLE. Auf dem Bus ist er mit J gleichwertig. Folgende Buszustände werden für Sonderzwecke verwendet (Tab. 11-7): DISCONNECT Ist am Downstream-Port eines Hub kein Gerät angeschlossen, werden beide Leitungen D+ und D- durch die pull-down Widerstände im Hub auf LOW gezogen. Deaktiviert der Hub seine Treiber und erkennt dann 2.5 µs lang diesen Zustand, meldet er über den "Status-Change"-Mechanismus ein DISCONNECT-Ereignis an den Host. CONNECT Erkennt der Hub jedoch, dass nach vorausgegangenem DISCONNECT eine der beiden Leitungen 2.5 µs lang auf HIGH liegt, interpretiert er dies als CONNECT-Ereignis. Je nach Geschwindigkeitsklasse des Geräts führt D+ oder D- HIGH. RESET Erkennt das Gerät, dass der Hub beide Leitungen 2.5 µs lang auf LOW gelegt hat, beginnt es seine internen Reset-Aktivitäten. Es hat dazu maximal 10 ms Zeit. SOP (START OF PACKET) Der Partner, der mit dem Senden eines Pakets beginnen will, schaltet die beiden Leitungen vom (passiven) IDLE in den (aktiven) K-Zustand, wobei beide ihren Pegel wechseln. Damit beginnt ein SYNC-Feld, dessen Zustandsfolge [IDLE KJKJKJKK] der logischen Zustandsfolge 00000001 = 80h entspricht. (Zur Erinnerung: Im NRZI-Format gilt J-->K =0, K-->J =0, J-->J =1, K-->K =1 Die Übertragung beginnt mit dem least significant bit) EOP (END OF PACKET) Das Ende eines Pakets wird dadurch signalisiert, dass beide Leitungen zwei Bitzeiten lang auf LOW gelegt werden (Zustand SE0), danach eine Bitzeit auf J. Nach Beendigung der Sendeaktivität geht der Buszustand nahtlos in IDLE über. Liegt SE0 wesentlich länger an (nämlich >2.5 µs), muss es sich wohl um ein RESET handeln. 11.3.7 ÜbertragungsrahmenFür die Übertragung über die physikalische Schnittstelle werden die Daten der logischen Schicht in Rahmen der Länge 1 ms gepackt. Jeder Rahmen beginnt mit einem SOF ("Start of Frame"). Dabei handelt es sich um ein TOKEN Paket, das statt einer Geräte-Funktions-Adresse eine fortlaufende 11 bit Rahmennummer enthält.11.4 Aktivitäten11.4.1 Zustände eines USB-GerätsAbb. 11-8 zeigt das (vereinfachte) Zustandsdiagramm einer USB-Funktion.ATTACHED Zustand unmittelbar nach dem Anschließen. Eine der beiden folgenden Bedingungen reicht aus, um das Gerät in diesem Zustand zu halten:
Liegt Versorgung an und ist der übergeordnete Hub konfiguriert, nimmt das Gerät den Zustand POWERED an. DEFAULT Das Gerät wartet ab, bis es ein Reset-Signal erhält. Dann setzt es seine internen Voreinstellwerte und geht in den Zustand DEFAULT. Es ist jetzt über die Default-Adresse D0 ansprechbar. ADDRESS Nach Erhalt des Host-Requests SetDeviceAddress geht das Gerät in den Zustand ADDRESS. Es ist dann über seine persönliche Geräteadresse Dx (1 .. 127) ansprechbar. CONFIGURED Im darauffolgenden Konfigurations-Prozess werden mehrere Requests abgewickelt. Entscheidend ist jedoch der abschließende Request SetDeviceConfiguration, der das Gerät in den Zustand CONFIGURED versetzt. Es bekommt damit seine endgültigen Ressourcen zugeteilt und ist bereit für den Austausch von Nutzdaten. SUSPEND Damit bei kurzen Unterbrechungen der Busaktivität nicht alle Initialisierungsvorgänge wiederholt werden müssen, gibt es den "Schlafzustand" SUSPEND, der nach 3 ms ohne Datenverkehr auf dem Bus angenommen wird. Streng genommen handelt es sich um vier getrennte Zustände, denn Gerät und Host merken sich, wie weit der Initialisierungsprozess schon fortgeschritten war. Nach dem Aufwecken ("Resume") durch Wiederaufnahme der Busaktivität und damit Verlassen von SUSPEND setzen sie ihn dort wieder fort. 11.4.2 EnumerationUnter dem Begriff "Enumeration" (manchmal auch Attach Operation) fasst man alle Aktivitäten zusammen, die nach dem Anstecken eines USB-Geräts ablaufen, um dieses zu identifizieren und zu konfigurieren:Das Gerät wird an den Downstream-Port eines Hub angesteckt, der bereits konfiguriert ist und Versorgungsstrom bereitstellt. Der Gerätezustand ATTACHED wird deshalb übersprungen und das Gerät wartet im Zustand POWERED auf ein Reset-Signal. Der Hub erkennt bei einer regelmäßigen Abfrage, dass eine der Port-Signalleitungen D+ oder D- HIGH-Zustand angenommen hat (verursacht durch den pull-up Widerstand im Gerät). Der Port nimmt damit den Zustand PORT.DISABLED an. In diesem Zustand können noch keine Daten über den Port übertragen werden. Bei der regelmäßigen "Interrupt-Konferenz" meldet der Hub an den Host, dass es bei ihm eine Veränderung gegeben hat. Der Host fragt daraufhin gezielt nach Einzelheiten, z.B. nach der Art der Änderung und nach dem Geschwindigkeitstyp des angesteckten Geräts, der daran erkennbar ist, welche Signalleitung auf HIGH liegt. Der Host wartet ca. 100 ms, um das Ende des Steckvorgangs und eine stabile Versorgung sicherzustellen. Dann gibt er ein Reset-Kommando für den Port aus. Der Port geht damit in den Zustand PORT.RESETTING und legt für 10 ms ein Reset-Signal auf den Bus. Das Gerät nimmt in dieser Zeit seine Voreinstellungen vor. Nach Ablauf der Reset-Zeit geht der Port in den Zustand PORT.ENABLED und ist damit voll funktionsfähig. Das Gerät nimmt den Zustand DEFAULT an. Es hat jetzt den Mindeststrom von 100 mA zur Verfügung und ist über die Default-Adresse D0 ansprechbar. Der Host fragt dann den DEVICE_DESCRIPTOR ab und entnimmt ihm wichtige Informationen. Anschließend bringt er das Gerät in den Zustand ADDRESS. Für den weiteren Initialisierungsprozess ist es über seine zugeteilte Adresse Dx ansprechbar. Der Host fragt jetzt sämtliche Deskriptoren und Konfigurationen ab und wählt einen Software-Treiber aus. Mit dem Befehl zum Konfigurieren teilt er dem Gerät Versorgungsstrom und Bandbreite zu. Dieses ist jetzt im Zustand CONFIGURED und bereit für den Austausch von Nutzdaten. 11.4.3 Detach OperationWird ein Gerät vom Port entfernt, erkennt dies der Hub am Zustand LOW/LOW der Datenleitungen. Er meldet diese Änderung an den Host, der daraufhin den Port in den Zustand PORT.DISCONNECTED versetzt und nicht mehr benötigte Systemressourcen wie Adresse, Bandbreite und Versorgungsstrom freigibt.11.5 Datenfluss, Protokoll11.5.1 GrundstrukturAbb. 11-2 zeigt ein vereinfachtes Schichtenmodell für eine Kommunikation zwischen Host und Peripherieeinheit. Über der physikalischen Schicht gibt es nur noch eine Schicht, die Aufgaben der Transport- und der Sicherungsschicht übernimmt. Funktional wird sie weiter unterteilt in ein Verwaltungsmodul, das die Geräte über den Control-Endpunkt E0 anspricht, und ein Kommunikationsmodul, über das dann die eigentlichen Nutzdaten ausgetauscht werden. Die virtuellen Verbindungen zwischen den Modulen auf der Host-Seite und denen im Gerät werden als Pipes bezeichnet.Der Host ist die Koordinationseinheit für den gesamten USB. Er überwacht die Busstruktur, teilt Ressourcen zu, steuert das Protokoll, startet und steuert sämtliche Aktionen. USB benutzt "Polling", d.h. alle Aktionen werden vom Host eingeleitet. Es gibt jedoch einen Pseudo-Interruptmechanismus zur Erfassung von Zustandsänderungen. Dabei fragt der Host regelmäßig (in jedem Frame) die "Interrupt"-Endpunkte E1 aller angeschlossenen Hubs ab und erfährt dadurch, ob sich an ihren Ports etwas geändert hat. In diesem Fall fragt er über den Control-Endpunkt E0 nach Einzelheiten der gemeldeten Änderung und bearbeitet diese. Anschließend setzt er die Änderungsflags zurück. In der untersten, der physikalischen Schicht, werden die Daten in "Frames" gepackt, also Rahmen mit einer festgelegten Dauer von 1 ms. In einem Frame können daher im full-speed Modus 12000 bit, im low-speed Modus 1500 bit übertragen werden. Zur Synchronisation sendet der Host zu Beginn des Frames ein SOF-Token ("Start of Frame") im full-speed Modus. 11.5.2 EndpunkteJedes Gerät ist zu Anfang der Konfiguration über die Default-Adresse D0, anschließend über eine zugeteilte, mit 7 bit codierte Adresse 1 .. 127 ansprechbar. Innerhalb eines Geräts kann die Funktionalität weiter unterteilt werden in sogenannte Endpunkte. Jedes Gerät unterstützt dabei mindestens einen Endpunkt mit der Endpunkt-Adresse E0, der über die bidirektionale "Default-Control-Pipe" vom Host angesprochen wird. Endpunkte besitzen eine 4 bit-Adresse. Es sind also pro Gerät weitere 15 Endpunkte definierbar. Diese werden aber aus Sicht des USB-Protokolls noch einmal zweigeteilt in IN- und OUT-Endpunkte und über unidirektionale Pipes "angeschlossen".Bei manchen Geräten ist es sinnvoll, mehrere Endpunkte zusammenzufassen und sie gemeinsam anzusprechen. Diese Gruppen werden als "Interfaces" bezeichnet und dürfen nicht mit dem physikalischen Bus-Interface verwechselt werden. 11.5.3 PipesPipes sind logische Datenkanäle zwischen der Client-Software im Host und den Endpunkten in den Geräten. Über diese werden Daten-Transfers abgewickelt. Es gibt zwei verschiedene Typen:
11.5.4 Transfers, Transaktionen, PaketeDiese drei Begriffe definieren die hierarchische Struktur der Übertragung:
Tab. 11-10 zeigt die möglichen Formate bei Transfers. Hier stellt jedes Kästchen eine Transaktion dar. Grau hinterlegte Transaktionen werden vom Host gesendet, weiße vom Gerät. Control Transfers bestehen aus drei "Stages": Setup Stage, Data Stage und Status Stage. Bei bestimmten Requests kann die Data Stage entfallen. Bulk, Interrupt und Isochronous Transfers haben keine Setup- und Status-Stage, dafür immer eine Data Stage. Control, Bulk und Interrupt Transfers garantieren eine fehlerfreie Ablieferung der Daten. Beim Senden werden abwechselnd (0)- und (1)-Transaktionen erzeugt. Werden sie auch abwechselnd empfangen, kann der Empfänger erkennen, dass es sich um eine ungestörte Folge handelt. Empfängt er eine fehlerhafte Transaktion, meldet er dies per Handshake. Der Sender muss dann die Transaktion gleichartig wiederholen. Auch eine fehlende Transaktion kann dadurch erkannt werden, dass in einer aus Sicht des Empfängers scheinbar ungestörten Folge gleichartige Transaktionen aufeinanderfolgen. Jeder Transfer beginnt mit einer (0)-Transaktion. Darauf folgen abwechselnd (1)- und (0)-Transaktionen. Die Status Stage enthält immer eine (1)-Transaktion. Bei Isochronous Transfers entfällt diese Fehlerkorrektur. Sie bestehen deshalb nur aus (0)-Transaktionen. Tab. 11-11 zeigt die möglichen Formate von Transaktionen. Hier stellen die Kästchen Pakete dar. Zu Beginn jeder Transaktion sendet der Host ein Token-Paket, gefolgt von einem Datenpaket. Dieses entfällt, wenn keine Lesedaten verfügbar sind. Die Quelle der Daten und damit die Übertragungsrichtung hängt vom Inhalt des Token-Pakets ab. Die abschließende Handshake-Phase entscheidet darüber, ob die gesamte Transaktion wiederholt werden muss. Bei Isochronous Transfers gibt es keine Wiederholungen, das Handshake-Paket ist sinnlos und entfällt. Pakete (Tab. 11-12) können in vier Gruppen eingeteilt werden: TOKEN, DATA, HANDSHAKE und SPECIAL. Das SPECIAL-Paket PRE nimmt eine Sonderstellung ein. Alle vom Host ausgehenden Pakete mit low-speed Inhalt werden durch PRE (noch in full-speed) eingeleitet und ermöglichen den Hubs das Einschalten ihrer low-speed Downstream-Ports, die sie sonst vom full-speed Datenverkehr abschirmen. TOKEN-Pakete werden immer vom Host gesendet und leiten jede Transaktion ein. Sie bestimmen die Art der Transaktion (OUT, IN, SETUP) und in einer 11 bit-Adresse, mit welchem Endpunkt nachfolgend Daten ausgetauscht werden sollen. Auch SOF-Pakete (Start of Frame) werden unter TOKEN eingeordnet. Sie enthalten jedoch statt der Adresse eine fortlaufende 11 bit-Frame-Nummer und werden zu Beginn jedes Übertragungsrahmens gesendet, ohne eine Transaktion einzuleiten. Auf das TOKEN-Paket folgt in "normalen" Transaktionen ein DATA-Paket. DATA0 und DATA1 unterscheiden sich im Packet-Identifier (PID). Ihre abwechselnde Verwendung in aufeinanderfolgenden Transaktionen dient der Fehlerkorrektur. Die Transaktionen werden abgeschlossen durch ein HANDSHAKE-Paket: ACK bestätigt den fehlerfreien Empfang NAK bedeutet bei OUT-Transaktionen, dass die Daten nicht angenommen wurden und deshalb eine Wiederholung erforderlich ist, bei IN-Transaktionen, dass momentan keine Daten verfügbar sind. STALL signalisiert dem Host, dass der adressierte Endpunkt nicht verfügbar und eine Wiederholung deshalb sinnlos ist. Jedes Paket beginnt mit einem 8 bit-SYNC-Feld (immer 0000 0001). Die führenden Nullen dienen zur Taktsynchronisation, die Eins signalisiert den Beginn der eigentlichen Übertragung. Das nachfolgende 8 bit-PID(Packet-Identifier)-Feld besteht aus 4 bit, in denen der Paket-Typ codiert ist, und die dann zur Fehlererkennung invertiert wiederholt werden. Es folgt ein Datenteil, der bei TOKEN-Paketen die Endpunkt-Adresse bzw. Frame-Nummer enthält, und der durch eine 5 bit-CRC-Folge abgesichert wird. Bei DATA-Paketen enthält dieser Teil 0 .. 1023 Byte Nutzdaten und wird durch eine 16 bit-CRC-Folge abgesichert. Bei HANDSHAKE- und SPECIAL-Paketen entfällt dieser Datenteil. Alle Pakete (außer PRE) werden abgeschlossen durch ein EOP(End of Packet)-Feld, das zwei Bitzeiten lang eine asymmetrische Null (SE0 = Single Ended Zero) und eine Bitzeit J-Signal sendet. Durch Abschalten der Bustreiber geht der Bus in den von außen nicht unterscheidbaren Zustand IDLE über. 11.5.5 Klassen, Requests, DeskriptorenLaut USB-Spezifikation sind USB-Klassen Gruppen von Geräten oder Interfaces mit gemeinsamen Eigenschaften. Diese Gruppierung ermöglicht das Erstellen von Klassenspezifikationen und die Verwendung einheitlicher Host-Software für alle Geräte einer Klasse.Eine virtuelle Klasse "USB COMMON Class" beschreibt Standard-Requests (Tab. 11-13) und Standard-Deskriptoren, die von allen USB-Geräten unterstützt werden. Darüberhinaus gibt es derzeit folgende Klassen mit zusätzlichen klassenspezifischen Requests und Deskriptoren (weitere sind in Vorbereitung):
Jeder Request besteht aus 8 Byte, die in folgende Felder unterteilt werden:
Die einzelnen Standard-Requests haben folgende Bedeutung:
Um ein echtes Plug & Play zu verwirklichen, muss der Host ein neu an den USB angestecktes Gerät identifizieren können. Während der Enumeration fragt der Host dazu mit mehreren Standard-Requests GetDescriptor die Eigenschaften des Geräts in Form von Deskriptoren ab (s. Tab. 11-14). Es gibt fünf verschiedene Typen von Standard-Deskriptoren:
Nur drei davon, nämlich DEVICE, CONFIGURATION und STRING werden direkt abgefragt, die übrigen werden in den Antworten des Geräts automatisch mitgeliefert. Zuerst fragt der Host den DEVICE-DESCRIPTOR ab. Die Antwort enthält unter anderem, wieviele CONFIGURATION-Deskriptoren zur Verfügung stehen und ob das Gerät einen STRING-DESCRIPTOR anbietet. Der Host kann dann nacheinander alle CONFIGURATION-Deskriptoren abfragen. Bei jeder einzelnen Abfrage werden ohne weitere Aufforderung der eigentliche CONFIGURATION-DESCRIPTOR und alle zugehörigen INTERFACE- und ENDPOINT- Deskriptoren zurückgeliefert. CONFIGURATION- und INTERFACE-Deskriptoren können zugeordnete STRING- Deskriptoren besitzen. Jetzt ist dem Host auch bekannt, ob und wieviele STRING- Deskriptoren zur Verfügung stehen, die er anschließend abfragen kann. Eventuelle klassenspezifische Deskriptoren werden in die Hierarchie der CONFIGURATION-Deskriptoren eingebaut. 11.6 HubEin Hub ist die elektrische Schnittstelle zwischen Host und USB-Geräten. Die deutsche Übersetzung "Verzweigung" oder "Vermittlungsknoten" ist weniger treffend und konnte sich nicht durchsetzen.USB-Hubs bestehen aus zwei Hauptblöcken mit unterschiedlichen Aufgaben:
Abb. 11-15 zeigt das Zustandsdiagramm eines Downstream Ports, also die möglichen Zustände und nach welchen Ereignissen sie angenommen werden. Hub-spezifische Status- und Control-Befehle erlauben dem Host, den Hub zu konfigurieren und auf seine Downstream-Ports zuzugreifen (s. Tab. 11-16 und Tab. 11-17). Ein Hub kann drei Zustände annehmen
Über E1 wird die "Status Change Bitmap" des Hub auf anstehende Änderungen abgefragt. Liegen keine vor, antwortet der Hub mit NAK und der Host setzt seine üblichen Aktivitäten fort. Bei anstehenden Änderungen entnimmt der Host aus der Antwort, welche Einheiten betroffen sind (Hub, Downstream-Port n). Über einen Request GetHubStatus oder GetPortStatus fragt er dann gezielt nach Art und Richtung der Änderung. Mit einem abschließenden Request ClearHubFeature oder ClearPortFeature bestätigt und löscht er die Änderungsmeldung. Die Status-Change-Bitmap enthält 1 Bitposition für den Hub selbst und je 1 Position für alle vorhandenen Downstream-Ports (s. Abb. 11-18-1). Deren Anzahl kennt der Host aus der Konfigurations-Prozedur. Die Bitmap wird als Antwort auf den IN-Interrupt gesendet und dabei zu ganzen Bytes aufgefüllt (1 Byte bei max. 7 Ports, 2 Byte bei max. 15 Ports usw.). Für jede seiner Einheiten enthält der Hub außerdem ein 2 Byte Status-Register. Dieses enthält je 1 bit für diverse Zustände (PORT_...) und je 1 bit Information, ob sich dieser Zustand aktuell geändert hat (C_PORT_...) 11.7 Human Interface Devices (HID)11.7.1 BedeutungIn der Klasse HID werden Geräte zusammengefasst, die zur Steuerung von Computern dienen und hauptsächlich von Menschen bedient werden. Sie verwenden meist manuelle Eingabe (die Benutzung anderer Körperteile ist nicht ausgeschlossen) und können Elemente zur optischen, auditiven oder taktilen Rückmeldung besitzen.Daneben sind auch Geräte enthalten, die zwar nicht unbedingt von Menschen bedient werden, aber ähnliche Kommunikationsanforderungen an die Schnittstelle haben. Sie können deshalb denselben Klassentreiber verwenden. Nicht enthalten sind Monitore (Klasse "Display"), Mikrofone und Lautsprecher (Klasse "Audio") und Chipkartenleser (Klasse "Chip Card Interface Devices"; CCID). Beispiele für HID sind
Es gibt Geräte, die als Verbundgeräte gleichzeitig zu mehreren Klassen gehören und alle zugeordneten Klassentreiber verwenden. Beispielsweise kann ein Telefon die Klassen HID, Audio und Telephony benutzen. 11.7.2 KommunikationDer Datenaustausch erfolgt wie bei allen USB-Geräten in Form von Transfers. Bei der HID-Klasse haben diese jedoch eine spezielle Struktur und heißen "Reports".Die HID-Spezifikation verwendet einen eigenen "Dialekt" innerhalb der USB-"Sprache". Die wichtigsten Begriffe daraus sind in Tab. 11-19 aufgelistet. Es gibt sechs klassenspezifische Requests (plus zwei klassenspezifisch abgewandelte Standard-Requests) und drei klassenspezifische Deskriptoren. Die Klasse ist im Interface Deskriptor definiert, nicht im Device Deskriptor. Das ursprünglich vorgesehene Konzept der Unterklassen ("Subclasses") wurde bei HID wieder aufgegeben, weil es sich als zu restriktiv gezeigt hat. Protokolle werden stattdessen durch Report Deskriptoren erzeugt, die vom Entwickler modular aufgebaut werden können. Beim Booten eines Rechners sind Interaktionen des Bedieners erforderlich. Zu diesem Zeitpunkt sind aber weder das Betriebssystem geladen noch die USB-Klassentreiber aktiv. Die Daten werden deshalb zwischen BIOS und Gerät über spezielle Protokolle ausgetauscht. Geräte, die diese unterstützen, werden als Unterklasse "Boot Devices" bezeichnet. Es gibt zwei solche Protokolle: Tastatur- und Mausprotokoll.
Über die mit dem Endpunkt 0 verbundene Default-Control-Pipe können HID-Geräte auch Daten austauschen. Diese Methode ist aber vorbehalten für unregelmäßig anfallende kleine Datenmengen, also z.B. Geräteparameter. Zum regelmäßigen Einlesen von Tastenbetätigungen und Messwerten dient eine Interrupt-IN Pipe, eine Interrupt-OUT Pipe ist optional. Tab. 11-20 zeigt eine Übersicht über klassenspezifische Requests.
11.7.3 DeskriptorenEs gibt drei klassenspezifische Deskriptoren: (s. Tab. 11-21):
Report Deskriptoren enthalten Informationen über den Aufbau der Reports (s. Tab. 11-22). Üblicherweise gehört zu jedem Interface ein Report Deskriptor. Report und Report Deskriptor werden dann durch die Endpunkt-Nummer des Interface identifiziert. Sind mehrere Report Deskriptoren für ein Interface definiert, werden sie durch eine Report-ID unterschieden. Report Deskriptoren enthalten nicht Werte wie andere Deskriptoren, sondern bestehen aus "Items". Das sind Anweisungen zum Anlegen eines strukturierten Speicherbereichs, in dem später die Nutzdaten der Reports an den Gerätetreiber im Host übergeben werden können. Items haben Speicherverhalten und werden in einer Item-Status-Tabelle gespeichert. Die Anweisungen haben solange Gültigkeit, bis sie von einem anderen Item "überschrieben" werden. Es gibt drei Typen mit unterschiedlichem Speicherverhalten:
Tab. 11-23 verdeutlicht die Struktur der Items. In Anlehnung an die USB-Spezifikation ist die Darstellung so gewählt, dass die Daten in der Reihenfolge von rechts nach links übertragen werden. Es gibt Short Items und Long Items. Jedes Item beginnt mit einem Prefix von 1 Byte Länge. Darin sind die Anzahl der folgenden Parameter-Bytes ("Size") mit 2 bit, der Typ des Items ("Type") mit 2 bit und seine Funktion ("Tag") mit 4 bit enthalten. Short Items enthalten zusätzlich 0, 1, 2 oder 4 Byte Parameter-Information. Die Codierung des Tag ist abhängig vom Item-Typ. So definiert z.B. Tag=0 in einem Global Item die Usage Page, in einem Local Item dagegen die Usage. Tab. 11-22 beschreibt alle spezifizierten Item Tags. Tab. 11-28 enthält u.a. Beispiele für Report Deskriptoren für die beiden wichtigsten Eingabegeräte Tastatur und Maus. Die Spezifikation definiert außerdem noch ein Long Item, gekennzeichnet durch FE h im Byte 0. Die Länge wird dann in Byte 1, die Bedeutung in Byte 2 angegeben. Außerdem kann ein Long Item in den Bytes 3 .. 258 weitere Parameter enthalten. Long Items werden in der augenblicklich gültigen Spezifikation nicht verwendet. Usages definieren die Bedeutung der in den Reports übertragenen Informationen für die Anwendung. Sie werden mit 32 bit codiert und aus Gründen der Übersichtlichkeit in Usage Page (16 bit) und Usage-ID (16 bit) unterteilt. Notation: Usage(Usage Page : Usage ID) Tab. 11-22 enthält eine Auflistung wichtiger Usages. Vollständige Tabellen sind in der Spezifikation zu finden. Zur Vereinfachung der Beschreibung werden Usages außerdem in Gruppen eingeteilt: die "Usage Types" (s. Tab. 11-24). Dabei erhalten alle Usages, die sich gemeinsam beschreiben lassen, den gleichen Typ. Reports enthalten Felder mit Daten. Die Bezeichnung "item-data" in der Spezifikation halte ich für irreführend. Die Datenübertragung vom Gerät zum Host erfolgt standardmäßig in Form von IN-Transaktionen über eine Interrupt-IN-Pipe. Die Daten können aber auch durch einen GET_REPORT Request angefordert werden und benutzen dann die Control-Pipe. In beiden Fällen haben die Reports die gleiche Struktur, die durch den zugehörigen Report Deskriptor definiert ist. Jeder Report enthält Daten für alle definierten Felder. Der Treiber bzw. die Anwendung extrahieren die Daten entsprechend der Felder-Struktur. Felder können beliebige Länge haben und sind nicht an Byte-Grenzen gebunden. Der gesamte Report muss jedoch aus einer ganzen Anzahl von Bytes bestehen und wird gegebenenfalls durch "padding bits" aufgefüllt. Die Bitlänge eines Feldes ergibt sich aus Report Size * Report Count. Bei manchen Geräten gibt es pro Interface mehrere unterschiedliche Reports, die dann in einem zusätzlichen Byte 0 durch ein Report-ID gekennzeichnet werden. Folglich gibt es dann dafür auch mehrere Report Deskriptoren. 11.8 Beispiel: Tastatur mit Mausfunktion als USB-HID-GerätNach den stark komprimierten theoretischen Ausführungen (die allgemeine USB-Spezifikation hat über 280 Seiten, HID Class Definition und HID Usage Tables zusammen etwa 200 Seiten) folgt jetzt ein praktisches Beispiel, durch das die Abläufe beim Einschalten und im Betrieb hoffentlich noch etwas klarer werden.Angenommen wird eine Tastatur mit 105 Tasten im MF2-ähnlichen Layout mit deutscher Belegung (Abb. 11-25) und einer (im Layout nicht dargestellten) Mausfunktion, etwa in Form einer Rollkugel. Der Datenverkehr erfolgt im full speed Modus, die Tastatur benötigt maximal 100 mA. Der Anschluss erfolgt direkt am Rechner, also am Root Hub des Host. Tab. 11-26 zeigt alle für Tastaturen definierten Tasten-Usages mit Usage ID und Usage Name, (Abb. 11-27) die Zuordnung der Usage IDs auf die Tasten unserer Beispieltastatur. Der folgende beispielhafte Ablauf besteht aus drei Teilen, der Enumeration des Hub (1), der Enumeration der Tastatur (2) und dem eigentlichen Betrieb der Tastatur (3). (s. Tab. 11-28). 1.1Zunächst legt der Host ein SE0-Signal an seine Verbindung zum integrierten Root-Hub. Dieser leitet einen internen Reset ein, der maximal 10 ms dauern darf. Danach ist er bereit, über Default-Adresse 00 und den Control-Endpunkt E0 Befehle zu empfangen.1.2Der Host sendet einen Request GetDeviceDescriptor(Device) an HUB.E0 (=00.00). Die Antwort liefert den DEVICE_DESCRIPTOR und enthält unter anderem Informationen über
1.3Host sendet Request SetDeviceAddress und teilt dem Hub eine von Null verschiedene Geräte-Adresse zu (z.B. 01). Der weitere Dialog mit dem Hub benutzt dann diese Adresse. Die Default-Adresse 00 ist damit wieder frei für eine weitere Konfiguration (z.B. der Tastatur).1.4Zur Abfrage weiterer Hub-Eigenschaften dient der Request GetDeviceDescriptor(Configuration) an HUB.E0 (=01.00). Hätte der DEVICE_DESCRIPTOR mehrere Konfigurationen angekündigt, müsste dieser Befehl wiederholt ausgegeben werden. Die Antwort besteht aus mehreren Teilen:CONFIGURATION_DESCRIPTOR enthält
INTERFACE_DESCRIPTOR enthält
HUB_DESCRIPTOR (klassenspezifisch) enthält
ENDPOINT_DESCRIPTOR beschreibt den Endpunkt E1 ("Status_Change" Endpunkt) (E0 ist für alle USB-Geräte gleichartig vereinbart und benötigt deshalb keinen Deskriptor.) Er enthält
2.1Der Hub ist jetzt voll arbeitsfähig. Der Host beginnt damit, regelmäßig abzufragen, ob es Änderungen am Hub oder seinen Downstream-Ports gibt. Er benutzt dazu die INTERRUPT (IN) - Pipe zum Endpunkt E1. Der Hub meldet dabei z.B. eine Änderung an PORT1:
2.2Der Host gibt einen Request GetPortStatus(PORT1) an HUB.E0 aus. Er bekommt die Antwort, dass ein Gerät neu an Port 1 angeschlossen (bzw. neu entdeckt) wurde:
2.3Der Host quittiert dieses Ereignis mit einem Request ClearPortFeature(C_PORT_CONNECTION, PORT1) an den Hub. Dadurch werden die entsprechenden Status-Bits in den Hub-Registern gelöscht:
2.4Weil es sich um einen Hot-Plug Vorgang mit prellender Kontaktgabe handeln könnte, wartet der Host jetzt etwa 100 ms, bis er einen Request SetPortFeature(PORT_RESET, PORT1) an HUB.E0 ausgibt und damit einen Reset-Vorgang in der Tastatur auslöst, an dessen Ende das Enable-Flag gesetzt ist:
2.5Auch hier bekommt der Host Kenntnis vom Ende des Request-Vorgangs durch Polling von StatusChange und nachfolgendem Request GetPortStatus(PORT1).2.6Mit ClearPortFeature(C_PORT_ENABLE, PORT1) bestätigt er den Empfang und löscht die Bits
2.7Die folgende Inbetriebnahme der Tastatur beginnt mit einem Request GetDeviceDescriptor(Device) an den Endpunkt E0 der Geräteadresse 00, mit der augenblicklich die Tastatur angesprochen wird. Die Antwort enthält die gleichen Informationen wie beim Hub, aber mit den Klassen- und Unterklassen-Codes 00, weil diese erst im INTERFACE_DESCRIPTOR spezifiziert werden. Außerdem werden die Anfangsadressen der String Deskriptoren für Hersteller, Produkt und Seriennummer gemeldet.2.8Durch Zuteilung einer Geräteadresse (hier 02) wird die Default-Adresse wieder frei.2.9Jetzt werden Konfiguration und Geräteeigenschaften der Tastatur (bestehend aus "Keyboard" und "Mouse") abgefragt, eingeleitet mit einem Request GetDeviceDescriptor(Configuration) an TAST.E0 (= 02.00)CONFIGURATION_DESCRIPTOR enthält
INTERFACE_DESCRIPTOR (Keyboard) enthält
HID_DESCRIPTOR (Keyboard) (klassenspezifisch) enthält
ENDPOINT_DESCRIPTOR (Keyboard) enthält
INTERFACE_DESCRIPTOR (Mouse) enthält
HID_DESCRIPTOR (Mouse) (klassenspezifisch) enthält
ENDPOINT_DESCRIPTOR (Mouse) enthält
2.10Aus den bisher abgefragten Deskriptoren ist bekannt, dass für die Tastatur 2 Report Deskriptoren und 4 String Deskriptoren definiert sind. Auch deren Länge ist bereits bekannt. Diese müssen in getrennten Requests abgefragt werden.Der Host sendet den Request GetHIDDescriptor(Report, Keyboard). Als Antwort enthält der REPORT_DESCRIPTOR (Keyboard) die Definition für 2 Reports: Der IN Report zur Meldung der gedrückten Tasten (s. auch Beispiel Abb. 11-29) besteht aus 7 Byte:
Der OUT Report (1 Byte) definiert 5 Bitfelder zur Ansteuerung von LEDs und 3 Leerbits. 2.11Host sendet einen Request GetHIDDescriptor(Report, Mouse).Die Antwort REPORT_DESCRIPTOR (Mouse) definiert einen IN Report mit 3 Byte
2.12Zum Abschluss des Einschaltvorgangs werden die vier vereinbarten Strings abgefragt. GetDeviceDescriptor(String) als Request und STRING_DESCRIPTOR als Antwort wechseln sich ab.Der erste Deskriptor enthält Codes für alle Sprachen, die in den nachfolgenden Strings unterstützt werden, in unserem Beispiel nur deutsch. Die restlichen Strings enthalten den Herstellernamen, die Produktbezeichnung und die Seriennummer. 3.1Jetzt kann der eigentliche Betrieb der Tastatur beginnen. Der Host holt die Eingabedaten im Polling-Modus über Interrupt-IN-Pipes ab. Jeder Abfragezyklus beginnt mit dem Einlesen des Status von Hub und seinen Ports. Nur wenn keine Änderung vorliegt (Antwort NAK), werden anschließend die Reports von Keyboard und Mouse abgefragt.Abb. 11-29 zeigt beispielhaft den Inhalt der Reports bei zwei Tastenbetätigungs-Sequenzen. In der Regel löst jedes Drücken und jedes Loslassen (gekennzeichnet durch "/") einer Taste einen Report aus. Es können aber ohne Probleme beispielsweise auch mehrere losgelassene Tasten gleichzeitig gemeldet werden. 3.2Erfordert die Auswertung der Keyboard-Tasten eine Änderung der LED-Ansteuerung, wird dafür ein OUT-Report über die Control-Pipe ausgegeben.11.9 USB Version 2.0Seit April 2000 gibt es eine neue, erweiterte Version 2.0 von USB. Da die Hardware wesentlich komplexer und damit teurer ist, ist der Markterfolg bei den Eingabegeräten noch nicht gesichert, da hier die höhere Geschwindigkeit nicht benötigt wird.Deshalb möchte ich Änderungen und Erweiterungen gegenüber Version 1.1 in diesem kleinen Ergänzungskapitel beschreiben, statt den kompletten Abschnitt umzuschreiben. 11.9.1 AllgemeinesMit USB 2.0 wird eine weitere Übertragungsgeschwindigkeit eingeführt. Sie wird als "High-Speed" bezeichnet und beträgt 480 Mbit/s. Dies bringt drei Aspekte ins Spiel:
11.9.2 Physikalische SchnittstelleKabelDie bisherigen Full-Speed Kabel können auch für den High-Speed Betrieb eingesetzt werden. Die Tabelle für die Dämpfungscharakteristik wird jedoch mit 2 Werten ergänzt:
HardwareDie Transceiver-Bausteine werden wesentlich komplexer. Sie enthalten zusätzlich und parallel zu den bisherigen Full-Speed Treibern und Empfängern auch noch jeweils High-Speed Komponenten und weitere Spezial-Module. Zusätzlich müssen die im Full-Speed Betrieb benötigten Pullup-Widerstände im High-Speed Betrieb abgeschaltet werden.Der High-Speed Treiber speist einen Strom von nominal 17.78 mA in die D+ Leitung für ein J-Signal bzw. in die D- Leitung für ein K-Signal. Beide Seiten werden mit je 45 Ohm nach Masse abgeschlossen, wodurch sich ein nominaler Empfangspegel von 400 mV ergibt. DisconnectDer DISCONNECT-Zustand wird jetzt erkannt, wenn der Abschlusswiderstand der Gegenseite fehlt. Der Sendepegel erhöht sich dann nämlich auf nominal 800 mV, was durch einen speziell dafür vorgesehenen Empfänger-Baustein auf der Senderseite ausgewertet wird.EOPAuch das Ende eines Pakets (EOP) kann jetzt nicht mehr durch einen SE0-Zustand einer gewissen Mindestdauer erkannt werden, da dieser dem Idle-Zustand im High-Speed Betrieb entspricht. Vielmehr werden jetzt "Bit-Stuffing-Fehler" ausgewertet. Wenn also die für die Taktrückgewinnung regelmäßig eingestreuten 0-Signale fehlen, wird damit auf EOP geschlossen.11.9.3 Datenfluss, ProtokollµFrameEin Frame, der im Full-Speed Betrieb genau 1 ms lang ist, wird im High-Speed Betrieb in 8 Mikro-Frames ("µFrame") zu je 125 ms aufgeteilt. Ähnlich wie ein Frame durch einen SOF-Token ("Start Of Frame") eingeleitet wird, startet jeder µFrame mit einem µSOF. Die 11 bit breite Frame-Nummer bleibt jedoch für 8 µFrames gleich und wird erst dann erhöht.Pro µFrame können 60 kbit (brutto) übertragen werden. PINGWährend Bulk- oder Control-Transfers kam es unter USB 1.1 häufig vor, dass der Empfänger (noch) nicht bereit war, Daten anzunehmen und mit NAK antwortete. Der gesamte Datenblock musste dann noch einmal gesendet werden, was insgesamt zu einer hohen Busbelastung führen konnte. Dieses Problem wird bei USB 2.0 entschärft durch eine verbesserte Flusskontrolle. Zu diesem Zweck werden 2 neue PIDs eingeführt: PING und NYET. Diese werden allerdings nur im High-Speed Betrieb und nur für Bulk- und die Datenphase von Control-Transfers verwendet.
GeschwindigkeitseinstellungHigh-Speed Geräte melden sich zunächst als Full-Speed an. Während der Reset-Phase versucht das Gerät seinen darüberliegenden Hub mit einem speziellen High-Speed Signal ("Chirp") anzusprechen. Antwortet dieser innerhalb von 100 μs, schaltet das Gerät seinen Pullup-Widerstand ab und beide gehen in den High-Speed Betrieb. Klappt dieser Handshake jedoch nicht, bleiben beide im Full-Speed Betrieb.High-Speed fähige Geräte müssen auch von den Anwendungen als solche erkannt werden. Dazu geben sie sich in ihrem Device-Descriptor als 2.0 kompatibel zu erkennen. Darauf können weitere Einzelheiten über die zusätzlichen Deskriptoren "Device-Qualifier" und "Other-Speed-Configuration" vereinbart werden. 11.9.4 HubUSB 2.0 Hubs enthalten sogenannte "Transaction Translators" ("TT"). Dabei handelt es sich um intelligente Pufferspeicher, die es ermöglichen, Daten zwischen Host und Low-/Full-Speed Geräten in High-Speed vom Host zum Hub und entsprechend langsamer vom Hub zum Gerät zu übertragen, und so den High-Speed Bus vor der "Ausbremsung" durch langsame Geräte zu schützen.Protokollmäßig wird dies durch neu eingeführte SPLIT-Transaktionen bewerkstelligt. Diese laufen nur zwischen High-Speed Host und High-Speed Hub, wenn ein Low-/Full-Speed Gerät angesprochen wird. Der Host startet mit einer SSPLIT-Transaktion ("Start Split Transaction"), die im Falle einer OUT-Transaktion auch Daten enthält. Der Hub wickelt dann die weitere Kommunikation mit dem Endgerät über Low-/Full-Speed ab. Der Host kann sich in dieser Zeit mit anderen Hubs oder Geräten abgeben. Nach einiger Zeit holt er sich das Ergebnis über eine CSPLIT-Transaktion ("Complete Split Transaction") ab, gegebenenfalls wiederholt, wenn der Hub noch nicht fertig ist und deshalb mit NAK antwortet. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
Dateneingabe |