-
Die
vorliegende Erfindung bezieht sich auf ein Busanschluss-System,
und insbesondere auf eine Vorrichtung, die mit elektronischer Ausrüstung in
einem Buskommunikationssystem verwendet werden kann, um es der Ausrüstung zu
ermöglichen,
mit einem Host innerhalb des Systems zu agieren.
-
Das
Universal Serial Bus (USB-) Kommunikationssystem wird in immer größerem Umfang
eingesetzt.
-
In
einem USB-System ist es möglich,
viele Elemente elektronischer Ausrüstung, zum Beispiel Personal
Computer, Scanner, Mobiltelefone, Drucker, usw. miteinander zu verbinden.
In jedem System wird ein Element der Ausrüstung immer als USB-Host bezeichnet,
der Verbindungen zu allen anderen Elementen, oder USB-Geräten, steuert.
Personal Computer verfügen
typischerweise über
die Hardware und Software, die benötigt wird, um ihnen zu erlauben,
als USB-Host zu agieren, aber andere Element sind typischerweise
nicht mit der erforderlichen Hardware und Software ausgestattet
und können
daher nur als USB-Geräte
agieren.
-
Es
gibt jedoch Situationen, in denen es für ein Ausrüstungselement nützlich wäre, als
USB-Host agieren zu können,
ohne dass größere Modifikationen
an der Ausrüstung
erforderlich sind.
-
In
dem Dokument
US 5.784.581 wird
ein Gerät
beschrieben, das als ein USB-Slave-Gerät agieren kann, wenn ein USB-Host
an einen privilegierten Port angeschlossen ist, oder alternativ
als USB-Host für
ein mit einem zweiten Port verbundenes Slave-Gerät agieren kann, wenn kein USB-Host
mit dem privilegierten Port verbunden ist.
-
Gemäß einem
Aspekt der vorliegenden Erfindung wird eine Busstation geschaffen,
vorzugsweise in der Form eines Hardware-Dongles, der mit dem Buskommunikationsport
eines Buskommunikationsgeräts
verbunden werden kann, um es ihm zu ermöglichen, als Bus-Host zu agieren.
In bevorzugten Ausführungsformen der
Erfindung arbeitet die Busstation in dem USB-System, obwohl die
Erfindung auch auf andere Buskommunikationssysteme anwendbar ist.
-
Insbesondere
sieht ein Aspekt der vorliegenden Erfindung eine Busstation vor,
die, wenn sie feststellt, dass ein Bus-Host mit einem ersten Buskommunikationsport
hiervon verbunden ist, als ein Transceiver agiert, um herkömmliche
Buskommunikationen zwischen dem genannten Bus-Host und einem mit
einem zweiten Buskommunikationsport hiervon verbundenen Bus-Gerät zu erlauben;
und die, wenn sie feststellt, dass ein Bus-Gerät
mit geeigneter Software mit dem ersten Buskommunikationsport hiervon
verbunden ist, als ein alternativer Host agiert, um Buskommunikationen
zwischen dem genannten, mit dem ersten Buskommunikationsport verbundenen
Bus-Gerät
und einem mit einem zweiten Buskommunikationsport verbundenen Bus-Gerät zu erlauben.
-
Die
Erfindung ist in den unabhängigen
Ansprüchen
1, 4 und 5 beschrieben.
-
1 zeigt
ein schematisches Blockschaltbild eines Buskommunikationssystems.
-
2 zeigt
ein Blockschaltbild der Hardware und Software in dem System aus 1.
-
3 zeigt
einen Ablaufplan, der ein Verfahren gemäß einem Aspekt der vorliegenden
Erfindung darstellt.
-
1 zeigt
ein schematisches Blockschaltbild eines erfindungsgemäßen Buskommunikationssystems.
-
Das
System 2 umfasst ein erstes USB-Gerät 4 mit einem USB-Port 6,
ein zweites USB-Gerät 8 und einen
Dongle 10.
-
In
dieser dargestellten Ausführungsform
ist das erste USB-Gerät 4 ein
Personal Digital Assistant (PDA), es versteht sich jedoch, dass
die Erfindung auf jedes USB-Gerät anwendbar
ist, zum Beispiel auf eine Mobilkommunikationsvorrichtung, eine
Digitalkamera oder einen Personal Organizer.
-
Das
zweite USB-Gerät 8 kann
jegliches USB-Gerät
sein, unter anderem ein Drucker, eine Maus, eine Festplatte oder
ein Modem.
-
Der
Dongle 10 umfasst einen eingebetteten USB-Host/Geräte-Controller 12 mit
einem ersten Host-Port H1 und einem zweiten Host-Port H2, und eine
Mikrocontroller-Einheit
(MCU) 14 mit niedriger Verlustleistung.
-
Der
erste Host-Port H1 des Dongles 10 kann, wie in 1 dargestellt,
mit dem USB-Port 6 des PDA 4 verbunden sein. Wenn
der erste Host-Port H1 des Dongles 10 mit dem USB-Port 6 des
PDA 4 verbunden ist, wird das PDA wirksam in die Lage versetzt,
als USB-Host zu agieren, und der zweite Host-Port H2 des Dongles 10 funktioniert
dann wirksam als Host-Port des PDA 4. Auf diese Weise kann
das PDA 4 die Kommunikation mit jedem USB-Gerät steuern,
das mittels eines USB-Bus 15 mit dem zweiten Host-Port
H2 des Dongles 10 verbunden ist.
-
Es
ist zu beachten, dass obwohl der erste Host-Port H1 und der zweite
Host-Port H2 hier
als mit dem gleichen USB-Host/Geräte-Controller 12 verbunden
dargestellt sind, es für
die MCU 14 auch möglich
wäre, über zwei
unabhängige
USB-Host/Geräte-Controller mit dem
ersten Host-Port H1 und dem zweiten Host-Port H2 zu kommunizieren,
wobei der erste speziell für
die Kommunikation mit dem PDA 4 vorgesehen ist und der zweite
speziell für
die Kommunikation mit dem oder den angeschlossenen USB-Gerät(en) 8.
-
Damit
das PDA 4 als ein USB-Host agieren kann, wenn es mit dem
Dongle 10 verbunden ist, benötigt das PDA 4 ein
Treiber-Update.
-
Das
Treiber-Update ist speziell für
das betreffende verwendete USB-Gerät vorgesehen und dient dazu,
einen Virtual Hardware Abstraction Layer (VirtualHAL) Softwaretreiber
hinzuzufügen,
der zusätzlich
zu der vorhandenen USB-Gerätehardware
in dem PDA 4 läuft.
-
2 zeigt
ein Blockschaltbild der Hardware und Software in dem System aus 1.
-
Wie
es üblich
ist, hat das USB-Gerät 4 ein
Betriebssystem 18, einen Host-Stack 20 und Geräte-Stack und
Geräte-Hardware 22.
Um als USB-Host agieren zu können,
läuft auf
dem PDA 4 auch die VirtualHAL-Treibersoftware 16.
Wenn die VirtualHAL-Treibersoftware 16 auf
dem USB-Gerät 4 läuft, wird
es hier gelegentlich als HostOnDevice bezeichnet.
-
Der
Dongle 10 umfasst Host-Hardware 12 (d.h. den USB-Host-Controller),
MCU 14 und SoftHost Firmware 24.
-
Die
SoftHost-Protokollschicht, die nachfolgend ausführlicher beschrieben wird,
steuert die Kommunikation zwischen dem Gerät 4 und dem Dongle 10 über den
Dongle-Anschluss 28.
-
3 zeigt
einen Ablaufplan für
den Betrieb des Dongles 10 unter der Steuerung der MCU 14.
Nach dem Einschalten bei Schritt 32 in 3 fragt
die MCU den ersten Host-Port H1 in Schritt 34 zyklisch
ab, um festzustellen, ob eine Verbindung hierzu besteht. Ist keine
Verbindung vorhanden, endet der Prozess bei Schritt 36.
-
Ist
eine Verbindung vorhanden, bestimmt die MCU in Schritt 38,
ob ein USB-Host mit dem ersten Host-Port H1 verbunden ist. Ist ein
USB-Host mit dem ersten Host-Port H1 verbunden, fährt der
Prozess mit Schritt 40 fort, bei dem der Dongle 10 als
ein USB-Transceiver agiert. Das bedeutet, er leitet die Kommunikation
direkt zwischen dem ersten Host-Port H1 und dem zweiten Host-Port
H2 weiter, und ermöglicht
es damit dem angeschlossenen USB-Host, die Kommunikation mit jedem
USB-Gerät
(oder allen USB-Geräten)
zu steuern, das (die) auf herkömmliche
Weise mit dem zweiten Host-Port H2 verbunden ist bzw. sind.
-
Wenn
die MCU in Schritt 38 feststellt, dass ein USB-Gerät und kein
USB-Host mit dem
ersten Host-Port H1 verbunden ist, fährt der Prozess mit Schritt 41 fort,
in dem ermittelt wird, ob ein USB-Host mit dem zweiten Host-Port
H2 verbunden ist. Ist dies der Fall, wirkt in Schritt 42 der
USB-Gerätekern
innerhalb des USB Host/Geräte-Controllers 12 darauf
hin, eine herkömmliche
USB-Kommunikation zwischen dem mit dem ersten Host-Port H1 verbundenen
USB-Gerät
und dem mit dem zweiten Host-Port H2 verbundenen USB-Host zu ermöglichen.
-
Wenn
ein USB-Gerät
mit dem zweiten Host-Port H2 verbunden ist, enummeriert die MCU 14 das
mit dem ersten Host-Port H1 verbundene USB-Gerät in Schritt 43 und
prüft,
ob es sich um ein Gerät
handelt, auf dem VirtualHAL läuft.
Wenn die MCU in Schritt 43 feststellt, dass auf dem angeschlossenen
Gerät 4 VirtualHAL nicht
läuft,
wird sie das Gerät 4 in
Schritt 44 deaktivieren und zum Beispiel eine blinkende
LED auslösen,
die signalisiert, dass das angeschlossene Gerät 4 VirtualHAL nicht
unterstützt.
-
Wenn
die MCU in Schritt 42 feststellt, dass auf dem angeschlossenen
Gerät 4 VirtualHAL
läuft,
(d.h. dass es einen VirtualHAL-Treiber 16 hat), wird die
MCU 14 in Schritt 46 in eine Betriebsart wechseln
und es dem Dongle 10 (zusammen mit dem Gerät 4)
ermöglichen,
als alternativer USB-Host zu agieren. In dieser Betriebsart, die
nachstehend ausführlicher
beschrieben wird, kann der Dongle 10 die Kommunikation
mit jedem USB-Gerät (oder
allen USB-Geräten)
steuern, das (die) mit dem zweiten Host-Port H2 verbunden ist bzw.
sind.
-
Bei
einem herkömmlichen
System, wo ein Personal Computer ein USB-Host ist, greift ein Host-Stack über die
HostHAL auf die zugrunde liegende USB-Hardware zu. Auf ähnliche
Weise greift in einem herkömmlichen
PDA USB-Gerät
ein Geräte-Stack über eine
DeviceHAL auf die zugrunde liegende USB-Hardware zu.
-
In
dem SoftHost-System kommuniziert jedoch erfindungsgemäß der Host-Stack, wenn er (oder
die Host-Station-Treibersoftware) 20 auf die Host-Hardware 12 zugreifen
muss, die Details für
die Zugriffsoperation an den VirtualHAL-Treiber 16. Der
VirtualHAL-Treiber 16 verpackt diese Details für die Zugriffsoperation
in einem vorgegebenen SoftHost-Protokoll. Das SoftHost-Protokollpaket
wird durch die vorhandene USB-Gerätehardware 22 gesendet,
wenn der SoftHost-Dongle 10 sie nach ausstehenden SoftHost-Protokollpaketen fragt.
-
Die
VirtualHAL-Treibersoftware 16 emuliert somit die Anwesenheit
eines Host-Controllers gegenüber der
Host-Station-Treibersoftware. Das bedeutet, dass sich die Kommunikation
mit dem VirtualHAL-Treiber 16 aus der Sicht des Host-Stack 20 nicht
von der Kommunikation mit einer HostHAL in einem herkömmlichen
System unterscheidet. Der Host-Stack 20 wird eine tatsächliche
Host-Hardware durch den VirtualHAL-Treiber 16 sehen.
-
Umgekehrt
emuliert die VirtualHAL-Treibersoftware 16 die Anwesenheit
eines Geräte-Controllers
gegenüber
dem Geräte-Controller
(oder Geräte-Stack) 22.
Die VirtualHAL-Treibersoftware 16 überträgt somit die Kommunikation
zwischen der Host-Station-Treibersoftware 20 und
dem Geräte-Controller.
-
Das
SoftHost-Protokoll liefert die folgenden Zugriffsfunktionen:
Lesen
eines Registers in der Dongle Host-Hardware 12
Schreiben
eines Registers in der Dongle Host-Hardware 12
Lesen
eines Pufferspeichers in der Dongle-Host-Hardware 12
Schreiben
in einen Pufferspeicher in der Dongle-Host-Hardware 12.
Weiterführende Funktionen
könnten
hinzugefügt
werden, um die Systemleistung zu verbessern, zum Beispiel eine Funktion,
die ein Register liest, es über
UND/ODER mit einem Wert verknüpft
und den geänderten
Wert in das Register zurückschreibt.
-
Das
SoftHost-Protokoll definiert das Verfahren, mit dem der Host-Stack 20,
der auf VirrtualHAL läuft, unter
Verwendung der Geräte-Controller-Hardware
auf die Hardware des Host-Controllers 12 zugreifen kann. Das
SoftHost-Protokoll wird nachstehend ausführlicher beschrieben. In dieser
Beschreibung wird der Ausdruck „HostDongle" verwendet, um den
Dongle 10 zu bezeichnen, während der Ausdruck „HostOnDevice" verwendet wird,
um das Gerät 4 zu
bezeichnen, nämlich
ein eingebettetes System mit USB-Gerätehardware 22, das
einen Host-Stack 20 auf VirtualHAL 16 ausführt.
-
Das
SoftHost-Protokoll beginnt am Ende von 3, an dem
Punkt, wo der HostDongle 10 das angeschlossene Gerät 4 enummeriert
hat und das angeschlossene Gerät 4 als
ein HostOnDevice bestätigt
wurde.
-
In
der Betriebsart richtet die MCU 14 eine Unterbrechungspipeline
ein und fragt den VirtualHAL-Treiber 16 jede Millisekunde
nach Daten ab. Daten, die zwischen dem Gerät 4 und dem Dongle 10 gesendet
werden, werden mit Hilfe des SoftHost-Protokolls in Form von SoftHost-Paketen
gesendet. Wenn der Host-Stack 20 auf dem PDA 4 eine
Hardware-Zugriffsanforderung über
den VirtualHAL-Treiber 16 gesendet hat, wird der VirtualHAL-Treiber 16 die
Anforderung als ein SoftHost-Paket senden, wenn der erste Host-Port
H1 des Dongles 10 es über
die Unterbrechungspipeline abfragt.
-
Die
MCU 14 wird dieses SoftHost-Paket aus dem Pufferspeicher
des eingebetteten USB-Host-Controllers 12 abrufen und den
Hardware-Zugriff entsprechend ausführen. Wenn es Daten zurückzusenden
gibt (Leseoperationen), wird die MCU 14 die entsprechenden
Daten über
Host 1 senden.
-
Verkehr
-
Der
HostDongle 10 und das HostOnDevice 4 kommunizieren
unter Verwendung einer speziellen bidirektionalen Bulk-Pipeline.
Es gibt vier Arten von Nutzinformationen.
- HRU
- (HostDongle Request
Unit)
Gesendet durch HostDongle 10
Ein Bulk-Paket
von 8 Bytes Nutzinformation
Verwendet zum Abfragen des HostOnDevice 4
Kann
Unterbrechungsinformationen enthalten (HRU_IRQ)
HostDongle 10 sendet
IMMER ein Bulk-in von 64 Bytes nach dem Senden der HRU.
HostOnDevice 4 würde über dieses
Bulk-in mit NOB oder CRP antworten.
- NOB
- (No Outstanding Business)
Gesendet
durch HostOnDevice 4
Ein Bulk-Paket von 8 Bytes Nutzinformation
Gesendet,
wenn es keine ausstehenden Transaktionen gibt
- CRP
- (Common Request Packet)
Gesendet
durch HostOnDevice 4
Ein Bulk-Paket von 16–64 Bytes
Enthält die Ergebnisse
der zuvor empfangenen CRP-Befehle und einen optimalen Datensatz
- APR
- (As Per Requested)
Gesendet
durch HostDongle 10
Ein Bulk-Paket von 16–64 Bytes
-
Der Ablauf
-
Wie
bei allen USB-System beginnen Transfers mit einer Aktion durch den
Host. Im Fall des SoftHost-Protokolls ist der SoftHost Dongle 10 immer
der Host. Alle SoftHost-Transferzyklen beginnen mit einer HRU, wie
oben definiert. Der aktuelle Transferzyklus muss abgeschlossen sein,
bevor der HostDongle 10 den nächsten Transferzyklus startet.
-
Poll-Nothing Cycle: HRU-NOB
-
- HostDongle 10 fragt das HostOnDevice 4 nach
ausstehenden Befehlssätzen
ab. Wenn es keine ausstehenden Befehlssätze gibt, antwortet das HostOnDevice 4 mit
NOB.
-
Transaktionen:
-
- HostDongle 10 sendet BULK-OUT
- HostDongle 10 sendet DATA (HRU)
- HostOnDevice 4 sendet ACK
-
- HostDongle 10 sendet BULK-IN
- HostOnDevice 4 sendet DATA (NOB)
- HostDongle 10 sendet ACK
-
Poll-Something Cycle:
HRU-CRP-APR
-
- HostDongle 10 fragt das HostOnDevice 4 nach
ausstehenden Befehlssätzen.
- HostOnDevice 4 sendet ausstehenden Befehlssatz durch
CRP. HostDongle 10 führt
den Befehl aus und sendet die Ergebnisse durch APR zurück.
-
Transaktionen:
-
- HostDongle 10 sendet BULK-OUT
- HostDongle 10 sendet DATA (HRU)
- HostOnDevice 4 sendet ACK
-
- HostDongle 10 sendet BULK-IN
- HostOnDevice 4 sendet DATA (CRP)
- HostDongle 10 sendet ACK
-
- HostDongle 10 sendet BULK-OUT
- HostDongle 10 sendet DATA (APR)
- HostOnDevice 4 sendet ACK
-
Unterbrechungszyklus:
HRU_IRQ-CRP-APR
-
- HostDongle 10 warnt das HostOnDevice 4 bzgl.
ausstehender Hardware-Unterbrechungen.
- HostOnDevice 4 entscheidet über die geeigneten Befehlssätze und
sendet sie durch CRP.
- HostDongle 10 führt
die Befehle aus und sendet die Ergebnisse durch APR zurück.
- HostOnDevice 4 MUSS die ausstehende Unterbrechung löschen oder
die Erzeugung von HRU_IRQ deaktivieren, oder der HostDongle 10 würde kontinuierlich
HRU_IRQ senden.
-
Transaktionen:
-
- HostDongle 10 sendet BULK-OUT
- HostDongle 10 sendet DATA (HRU_IRQ)
- HostOnDevice 4 sendet ACK
-
- HostDongle 10 sendet BULK-IN
- HostOnDevice 4 sendet DATA (CRP)
- HostDongle 10 sendet ACK
-
- HostDongle 10 sendet BULK-OUT
- HostDongle 10 sendet DATA (APR)
- HostOnDevice 4 sendet ACK
-
Paketformate
-
HRU-Format
-
Die
HRU enthält
die folgenden Informationen:
- Aktuelle Rahmennummer
- HcInterruptStatus des Host Controllers 12 im HostDongle 10
- Interrupt-Status des Geräte-Controllers 22
-
NOB-Format
-
- Keine speziellen Informationen erforderlich
-
CRP- und APR-Format
-
- Aktives Bit im Kopfteil ist 1 für CRP und 0 für APR.
- CRP kann eine Größe von 16–64 Bytes
haben. Die Gesamtgröße setzt
sich zusammen aus
- Einer Anzahl von Befehlssätzen
(jeweils 8 Bytes)
- Einem optionalen Datensatz
- Die maximale Anzahl von Befehlssätzen in einer CRP ist 8.
- Die maximale Größe des Datensatzes
ist 64-(8 * Anzahl von Befehlssätzen).
-
Die
mehreren Befehlssätze
in einem einzelnen Befehlsanforderungspaket ermöglichen die Kommunikation einer
Sequenz von Hardware-Zugriffen in einem einzigen Paket und reduzieren
damit den Latenztransfer.
-
Befehlssatz-Format
-
Der
Befehlssatz hat eine 8-Byte-Datenstruktur. Er enthält die folgenden
Informationen:
- Befehlssatz-Kopfteil (1 Byte)
- Befehlssatz-Index (2 Bytes)
- Befehlssatz-Daten (4 Bytes)
- Befehlssatz Aux (1 Byte)
-
-
-
Die
Virtual Hardware Abstraction Layer (VirtualHAL) schafft daher kompletten
Zugriff auf die Ziel-Hardware auf dem angeschlossenen Dongle unter
Verwendung der USB-Gerätehardware.
Mit anderen Worten, die existierende USB-Gerätehardware wird als asynchroner
Mikroprozessor-Schnittstellenbus benutzt, damit der USB-Host-Treiber
auf die Ziel-Hardware zugreifen kann.
-
Die
Verwendung von VirtualHAL bietet die Vorteile, dass der Hardware-Dongle die USB-Software
nicht zu handhaben braucht, so dass der Dongle kostengünstig sein
kann und die Host-Software durch das eingebettete System auf dem
USB-Gerät
gehandhabt werden kann.
-
Aus
diesem Grund ist in bevorzugten Ausführungsformen der Erfindung
ein Hardware-Dongle vorgesehen, der es einem USB-Gerät erlaubt,
die Fähigkeit
des USB-Host zu
erlangen, ohne die existierende Hardware zu ändern. Um dies zu erreichen,
führt das
USB-Gerät
Emulations-Software aus, die durch das eingebettete System auf dem
USB-Gerät gehandhabt
werden kann. Dies bietet die Vorteile, dass der Hardware-Dongle die
USB-Software nicht zu handhaben braucht, wodurch der Dongle kostengünstig sein
kann.
-
Die
Erfindung wurde bis zu diesem Punkt unter Bezugnahme auf ein System
beschrieben, in dem die VirtualHAL-Treibersoftware dem USB-Gerät erlaubt,
in Verbin dung mit dem Dongle 10 als ein USB-Host zu fungieren.
Es könnte
jedoch ähnlich
strukturierte VirtualHAL-Treibersoftware verwendet werden, um mehrere Schnittstellen/Funktionen
zu einem System mit der Fähigkeit
eines USB-Geräts
hinzuzufügen.
Die Treibersoftware könnte
es zum Beispiel dem USB-Gerät
erlauben, über
Bluetooth, IrDA, USB-OTG oder andere Kommunikationsprotokolle zu
kommunizieren.
-
Text in der
Zeichnung
-
1
-
- PDA – PDA
- USB PORT – USB
PORT
- MCU – MCU
- USB HOST/DEVICE CONTROLLER – USB-Host/Geräte-Controller
- DONGLE – Dongle
- USB DEVICE – USB-Gerät
-
2
-
- Device – Gerät
- Operating System – Betriebssystem
- Host stack – Host-Stack
- VirtualHAL Driver – VirtualHAL-Treiber
- Device Stack and Device Hardware – Geräte-Stack und Geräte-Hardware
- SoftHost Protocol Layer – SoftHost
Protokollschicht
- Dongle – Dongle
- MCU – MCU
- SoftHost Firmware – SoftHost
Firmware
- Host Hardware – Host-Hardwäre
-
3
-
- Start – Start
- Connection to H1? – Verbindung
mit H1
- No – Nein
- Yes – Ja
- End – Ende
- USB Host Connected? – USB-Host
angeschlossen?
- Act as USB Transceiver – Als
USB-Transceiver agieren
- USB Host connected to H2? – USB-Host
mit H2 verbunden?
- Act als USB Device – Als
USB-Gerät
agieren
- USB device with virtual HAL? – USB-Gerät mit VitualHAL
- Disable device – Gerät deaktivieren
- Act as alternate USB Host – Als
alternativer USB-Host agieren
