-
Die
Erfindung bezieht sich auf das technische Gebiet der Datenkommunikation
in einem Netzwerk verteilter Stationen, insbesondere ein Heimnetzwerk.
-
Hintergrund der Erfindung
-
Durch
ein Heimnetzwerk werden die verschiedensten Geräte miteinander verbunden. Solche Geräte können aus
dem Bereich der Unterhaltungselektronik stammen, wie z. B. Fernsehgerät, Videorekorder,
DVD-Spieler, Satelliten-Empfänger,
CD-Spieler, MD-Spieler,
Verstärker,
Radio, Camcorder usw. In diesem Zusammenhang wird auch ein Personal-Computer
erwähnt,
der heute ebenfalls als Gerät der
Unterhaltselektronik angesehen werden kann. Mittlerweile sind aber
auch Heimnetzwerke bekannt, in denen auch andere Geräte integriert
sind. Als Beispiel werden Geräte
der weißen
Ware erwähnt,
wie Waschmaschine, Elektroherd, Mikrowellenherd, Kühlschrank,
Geschirrspüler,
usw.
-
Für die Vernetzung
von Geräten
aus dem Unterhaltungselektronikbereich wurden von der Industrie
entsprechende Kommunikationssysteme entwickelt. Gedacht ist dabei
in erster Linie an die drahtgebundene Vernetzung der Geräte mit Hilfe
des sogenannten IEEE-1394-Bussystems, mit dem es möglich ist,
Daten mit sehr hoher Datenrate zwischen den einzelnen Netzwerkteilnehmerstationen,
nachfolgend kurz Netzwerkstation genannt, auszutauschen. In dem
ursprünglichen
IEEE-1394-1995-Standard sind die Datenübertragungsgeschwindigkeiten
S100, 5200 und 5400 spezifiziert. Diese entsprechen Datenübertragungsraten
von 100 Mbit/s, 200 Mbit/s und 400 Mbit/s. Mittlerweile wurde der
ursprüngliche Standard
erweitert und in der jetzigen Fassung IEEE-1394b sind noch höhere Datenübertragungsgeschwindigkeiten
S800, S1200 und S1600 spezifiziert.
-
Solch
hohe Datenraten werden insbesondere bei Übertragungen zwischen Unterhaltungselektronikgeräten benötigt. Dies
liegt daran, dass die typische Anwendung des Datenaustausches zwischen Unterhaltungselektronikgeräten darin
besteht, dass bei einer Video- oder Audioquelle ein Titel abgespielt wird,
entweder Videofilm oder Musikstück,
und der zugehörige
Datenstrom an ein weiteres Unterhaltungselektronikgerät bzw. mehrere
weitere Unterhaltungselektronikgeräte übertragen wird. Für diesen Anwendungsfall
wird zwischen den betreffenden Geräten, die miteinander Daten
austauschen, eine Datenverbindung eingerichtet. Über diese Datenverbindung werden
dann regelmäßig Datenpakete übertragen.
Diese Form der Datenübertragung
ist in dem IEEE-1394-Standard
als isochrone Datenübertragung
bezeichnet, bei der regelmäßig, in
bestimmten Zeitabständen,
Datenpakete von der Datenquelle zu der Datensenke bzw. den Datensenken übertragen werden.
-
Darüber hinaus
findet im IEEE-1394-Netzwerk auch asynchrone Datenübertragung
statt. Hier werden Datenpakete quasi nach Bedarf übertragen. Wie
viele solche asynchronen Datenpakete über den Bus geschickt werden,
richtet sich nach dem anfallenden Datenaufkommen. Asynchrone Datenübertragung
wird vorwiegend für
die Erkennung und Steuerung eines Gerätes im Netzwerk seitens eines
anderen im Netzwerk vorhandenen Gerätes benutzt.
-
Der
IEEE-1394-Standard enthält
hinsichtlich der Topologie des IEEE-1394-Netzwerkes nur wenige Einschränkungen.
Die zugelassene Bustopologie entspricht einer Baumstruktur. Je nach
Anwendungsfall kann die Baumstruktur aber unterschiedlich ausfallen.
Das Netzwerk kann diesbezüglich
sehr variable gestaltet sein.
-
Ein
weiteres herausragendes Merkmal des IEEE-1394-Bussystems ist, dass
das An- und Abklemmen von Geräten
im laufenden Betrieb des Netzwerkes möglich ist. Dies ist im Fachjargon
auch als „Life-Insertion-Feature" bekannt. Jedes Mal
nach An- oder Abklemmen eines Gerätes wird ein Busrücksetzvorgang
ausgelöst.
Im Anschluss an jeden Busrücksetzvorgang
findet eine Selbstkonfigurierungsphase des Netzwerkes statt. Darin
sendet jede IEEE-1394-Netzwerkstation eine Selbst-ID-Information (im Standard "Self-ID-Packet" genannt) an die anderen
Netzwerkstationen. Hierdurch wird sicher gestellt, dass jede Netzwerkstation
darüber
informiert ist, welche anderen Netzwerkstationen in dem Netzwerk
angeschlossen sind. Die Selbst-ID-Information dient jeder Netzwerkstation
dazu, sich selbst gegenüber
den anderen Netzwerkstationen des Netzwerks zu identifizieren. Mit
Hilfe der von den jeweils anderen Netzwerkstationen empfangenen
Selbst-ID-Informationen
ist jede Netzwerkstation in der Lage, eine sogenannte Knotenliste
zu erstellen und in einer der Netzwerkstation zugeordneten Speichereinrichtung zu
speichern.
-
Erfindung
-
Diese
gespeicherte Information wird dann von einem Treiberprogramm in
der Netzwerkstation dazu benutzt, noch genauere Informationen über jede
Netzwerkteilnehmerstation zu erfragen. Diese genaueren Informationen
stellt das Treiberprogramm in einer sogenannten „Node-Information"-Tabelle zusammen. Dazu ist im IEEE-1394-Standard
vorgeschrieben, dass jede Netzwerkstation in einem eigens dafür reservierten
Speicherbereich namens „Configuration
ROM" stationsspezifische
Informationen über
die Eigenschaften und Fähigkeiten
der Netzwerkstation vorhalten muss. Aus zeitoptimierenden Gründen versucht
die anfragende Netzwerkstation die gewünschten Informationen aus dem „Configuration
ROM" im Block zu
lesen. Dies geschieht mit einer sogenannten Block-Leseoperation.
Dabei sind die Erfinder auf folgende Schwierigkeit gestoßen.
-
Entsprechend
der IEEE-1394-Spezifikation muss eine IEEE-1394-Schnittstelle minimal nur sogenannte
Quadlet-Leseoperationen
für den
Zugriff auf das eigene "Configuration
ROM" unterstützen. Dabei
ist ein Quadlet ein Datenwort bestehend aus vier Bytes. Diese vier
Bytes sind nach Speicherorganisation des "Configuration ROM"s unter einer reservierten Adresse abgelegt.
Es kann also vorkommen, dass die Netzwerkstation die angeforderte
Blockleseoperation nicht unterstützt.
In diesem Fall sollte sie der anfragenden Station einen Zugriffstyp-Fehlerkode
zurücksenden.
Hier kommen die im IEEE-1394-Standard spezifizierten Fehlerkodes „ack_type_error" bzw. „resp_type_error" in Frage.
-
In
der Praxis hat sich gezeigt, dass einige Geräte mit IEEE-1394-Schnittstelle, die nur Quadlet-Leseoperationen
unterstützen,
bei einem Block-Lesezugriff einen falschen Fehlerkode, nämlich z.B.
den Adressfehlerkode, „resp_address_error" (bzw. ab IEEE-1394a-Standard
auch „ack_address_error") zurückgeben.
Dieser Fehlerkode bedeutet nach IEEE-1394-Standard eigentlich, dass
gar kein „Configuration
ROM" unter der dafür reservierten
Adresse vorhanden ist. Bei standardkonformer Interpretation dieses
Fehlerkodes kann also das Treiberprogramm die so antwortende Netzwerkstation
nicht in die „Node-Information"-Tabelle aufnehmen.
-
Gemäß der Erfindung
ist es doch möglich, bei
einer solchen Netzwerkstation die notwendigen Einträge im „Configuration
ROM" zu erfragen.
Dies geschieht so, dass nach Empfang des Adressfehlerkodes die anfragende
Netzwerkstation das Auslesen der stationsspezifischen Informationen
im „Configuration
ROM" mit Wortlesezugriffen,
d.h. im Spezialfall mit Quadlet-Lesezugriffen erneut versucht. War
der Adressfehlerkode tatsächlich
fehlerhaft erzeugt worden, werden jetzt die Lesezugriffe ordnungsgemäß bestätigt und
die stationsspezifischen Informationen können mit aufeinanderfolgenden
Wortlesezugriffen eingesammelt werden. So lassen sich dann vermeintlich
fehlerhafte Netzwerkstationen doch noch in die Node-Information
Tabelle aufnehmen.
-
Wird
ein Wortlesezugriff erneut mit dem Adressfehlerkode beantwortet,
so ist das „Configuration
ROM" tatsächlich nicht
an der reservierten Adresse vorhanden und die Netzwerkstation kann nicht
in die Node-Information Tabelle eingetragen werden.
-
Der
Wortlesezugriff wird auch dann durchgeführt, wenn als Ergebnis des
Blocklesezugriffs der Zugriffstyp-Fehlerkode zurückgegeben wird. Dieser Fehlerkode
ist speziell zu diesem Zweck in dem IEEE-1394-Standard vorgesehen
worden und soll dann generiert werden, wenn die Netzwerkstation keinen
Blocklesezugriff unterstützt.
-
Die
Erfindung ist in den unabhängigen
Ansprüchen
1 und 9 allgemein beansprucht. Vorteilhafte Maßnahmen und weitere Verbesserungen
sind in den abhängigen
Ansprüchen
enthalten.
-
Zeichnungen
-
Die
Erfindung wird nachfolgend anhand von Zeichnungen näher erläutert. Diese
zeigen in:
-
1 die Struktur eines beispielhaften IEEE-1394
Netzwerkes;
-
2 das allgemeine Format
des „Configuration
ROM";
-
3 die Struktur des „Bus_Info_Blocks" innerhalb des „Configuration
ROMs";
-
4 das Format des „Module_Vendor_ID" Eintrages innerhalb
des „Root_Directories" im „Configuration
ROM"; und
-
5 die sogenannte Protokoll-Architektur eines
IEEE-1394-Knotens gemäß IEEE-1394-1995-Standard;
-
6 ein Beispiel eines Ablaufdiagramms für ein Programm,
das zur Abfrage der stationsspezifischen Informationen einer Netzwerkstation
in dem „Node-Controller" der abfragenden
Netzwerkstation abgearbeitet wird.
-
Ausführungsbeispiele der Erfindung
-
1 zeigt ein beispielhaftes IEEE-1394-Netzwerk
mit fünf
Netzwerkteilnehmerstationen. Diese sind in einer Baumstruktur zusammengeschaltet.
Dabei wird jeweils ein Knoten mit einem weiteren über ein
separates IEEE-1394-Netzwerkkabel
miteinander verbunden. Die Anzahl der Kabelanschlüsse („Ports") kann von Knoten
zu Knoten variieren. Im gezeigten Beispiel ist die Station 13 mit
einem sogenannten 3-Port-Physical-Layer-Baustein ausgerüstet, die
beiden Netzwerkknoten 12 und 10 mit jeweils einem
2-Port-Physical-Layer-Baustein, die Station 11 mit einem
7-Port-Physical-Layer-Baustein und die Station 14 mit einem
1-Port-Physical-Layer-Baustein.
-
Nach
einem Busrücksetzvorgang
findet die Businitialisierung in zwei Phasen statt. Diese sind „Tree Identification", und „Self Identification". Während der
Phase „Tree
Identification" wird
die aktuelle Busstruktur durch Analyse der Belegung der Ports bei
den Netzwerkstationen ermittelt. In dieser Phase wird auch bestimmt,
welche Netzwerkstation die Root-Funktion übernimmt. Während der Phase „Self Identification" identifiziert sich
jede Netzwerkstation selbst und liefert gleichzeitig auch die Information welche Übertragungsgeschwindigkeit
sie unterstützt. Dies
geschieht durch Absendung von Selbst-ID-Informationspaketen in einer
durch die Busstruktur festgelegten Reihenfolge.
-
In 1 ist angegeben, in welcher
Reihenfolge die Netzwerkknoten während
der Businitialisierungsphase ihre Selbst-ID-Informationspakete absenden.
Die Station mit Bezugszahl 11 bekommt aufgrund der gezeigten
Baumstruktur zuerst den Bus zugeteilt. Sie ist damit der Knoten
mit der niedrigsten Knotennummer (node ID, #0). Dementsprechend wird
der Bus im weiteren Verlauf in folgender Reihenfolge den einzelnen
Knoten zugeteilt: Knoten 12, Knoten 14, Knoten 13,
Knoten 10. Nachdem alle Netzwerkstationen ihre Selbst-ID-Informationspakete
ausgesendet haben, kann in allen Netzwerkstationen die Knotenliste
durch Analyse aller Selbst-ID-Informationspakete aufgebaut werden.
Beide Phasen der Businitialisierung sind in dem IEEE-1394-1995-Standard
genau beschrieben.
-
Nach
der Businitialisierung findet der Aufbau der Node-Information Tabelle
statt, indem genauere Informationen über die einzelnen Netzwerkstationen abgefragt
werden. Diese Phase wird nachfolgend genauer beschrieben. Nachdem
die Knotenliste in der Selbstinitialisierungsphase nach einem Busrücksetzvorgang
erstellt worden ist, findet in der darauffolgenden Phase die Abfrage
weiterer stationsspezifischer Informationen statt. Dabei senden
alle Knoten am Bus Leseoperation auf das „Configuration ROM" aller Knoten am
Bus. Dieser Vorgang kann beispielsweise auch gleichzeitig erfolgen.
Diese Phase ist abgeschlossen, wenn jede Netzwerkstation die stationsspezifischen
Informationen aller Netzwerkstationen abgefragt hat und die „Node-Information"-Tabelle mit den
stationsspezifischen Informationen erstellt wurde.
-
2 zeigt das allgemeine Format
des „Configuration
ROM" gemäß IEEE-1394-Standard. Wie
dargestellt, ist das "Configuration
ROM" in Datenworte
zu 32 Bit entsprechend 4 Byte eingeteilt. Jedes 32 Bit-breite Datenwort
kann einzeln adressiert werden. Es ist auch im IEEE-1394-Standard
festgelegt, unter welcher Adresse das "Configuration ROM" eingerichtet werden muss. Das wird üblicherweise
so gemacht, dass im frei belegbaren RAM-Speicher der Netzwerkstation
der entsprechende Speicherbereich für das "Configuration ROM" reserviert wird (allokiert wird). Das
erste Quadlet des "Configuration
ROM" enthält die Information über die
Länge des "Configuration ROM", die CRC-Länge, sowie
den eigentlichen CRC-Prüfkode
für das "Configuration ROM". Daran schließt sich
der sogenannte „bus_info_block" an. Weitere Einträge in dem "Configuration ROM" betreffen das „root_directory", „unit_directory", „root & unit leaves" und die Information über „vendor_dependent_information". Alle vorgesehenen Bereiche
im "Configuration
ROM" sind im IEEE-1394-Standard definiert.
Die für
den Aufbau der „Node-Information"-Tabelle nötigen stationsspezifischen
Informationen variieren nach dem geforderten Inhalt dieser. Um beispielsweise
alle Informationen aus dem BusInfoBlock in der „Node-Information"-Tabelle zu erfassen,
werden die ersten 4 Quadlets im "Configuration
ROM" gelesen.
-
3 zeigt das Format des „bus_info_blocks". Im ersten Quadlet
ist lediglich der Ausdruck „1394" im ASCII-Format
abgelegt. Das zweite Quadlet des „Bus Info Blocks" enthält Einträge über die
Fähigkeiten
der Netzwerkteilnehmerstation. Der Eintrag irmc gibt an, ob die
Netzwerkteilnehmerstation die Fähigkeit
als „isochronous
resource manager" zu
fungieren besitzt. Der Eintrag cmc gibt an, ob die Netzwerkstation
die Fähigkeit
als „cycle
master" zu operieren
besitzt. Der Eintrag isc zeigt an, ob die Netzwerkteilnehmerstation
den isochronen Datentransfer unterstützt. Mit der Information bmc
wird angegeben, ob die Netzwerkteilnehmerstation die Fähigkeit
als „bus
manager" zu arbeiten
besitzt. Wichtig ist noch der Eintrag „chip_id_hi" im letzten Byte
des dritten Quadlets und „chip_id_lo" im vierten Quadlet.
Aus diesen beiden Angaben wird nämlich eine
eindeutige globale Identifikationsnummer für die Netzwerkteilnehmerstation
ermittelt. Diese Identifikationsnummer ist einmalig vergeben und
wird auch als GUID bezeichnet, wobei GUID für „Global Unique Identifier" steht. Da in einigen
Heimnetzwerken Netzwerktransaktionen teilweise GUID-adressiert ablaufen,
ist diese Information von großer
Wichtigkeit. Als Beispiel wird ein typisches HAVi-Netzwerk erwähnt, wobei
HAVi für „Home Audio
Video interoperability" steht.
-
4 zeigt das Format des ersten
Quadlets des „root_directories". Hierin ist noch
eine 24 Bit lange „module_vendor_id" Information vorgesehen.
Sie identifiziert den Hersteller des Gerätes.
-
Nachfolgend
wird die Protokoll-Architektur einer IEEE 1394-Schnittstelle anhand der 5 erläutert. Die unterste Kommunikationsschicht
Bitübertragungsschicht
(Physical Layer) 20 wird immer in Hardware realisiert.
Hierfür
sind separate ICs schon seit längerem
erhältlich.
Die nächst
höhere
Kommunikationsschicht Datensicherungsschicht (Data Link Layer) 21 ist üblicherweise
ebenfalls mittels Hardware realisiert. Separate Link-ICs sind auf
dem Markt ebenfalls erhältlich.
-
Die
weiteren gezeigten Schichten, nämlich „Transaction
Layer" 22, „Serial
Bus Management" 23 und „Application
Layer" 24 werden üblicherweise
mittels Software implementiert, die dann auf einem leistungsfähigen Mikrocontroller
in der Netzwerkstation ausgeführt
wird.
-
Innerhalb
der Schicht für
das „Serial
Bus Management" 23 sind
die Komponenten „Node
Controller" 27, „Isochronous Resource
Manager" 26 und „Bus Manager" 25 hervorgehoben.
In einem 1394-Netzwerk sind maximal ein „Bus Manager" 25 und
maximal ein „Isochronous
Resource Manager" 26 zu
einer Zeit aktiv, selbst wenn mehrere Netzwerkknoten die jeweilige
Funktionalität
erfüllen.
Welcher Netzwerkknoten die jeweilige Funktion ausführt, wird nach
jedem Busrücksetzvorgang
gemäß einem
im IEEE-1394-Standard vorgegebenen Verfahren bestimmt. Falls der „Root"-Knoten die jeweilige
Funktion ausführen
kann, ist es durch die besagten Verfahren recht wahrscheinlich,
dass die jeweilige Funktion des „Root" aktiviert wird. Es kann aber auch vorkommen,
dass überhaupt
kein „Bus
Manager" 25 vorhanden
ist, so dass dann der „Isochronous
Resource Manager" 26 (sofern
vorhanden) einige Aufgaben des „Bus Manager" 25 mit übernehmen
muss.
-
Für die hier
beschriebene Erfindung sind die Komponenten „Node Controller" 27 und „Transaction Layer" 22 wesentlich,
weshalb auf diese Komponenten im nachfolgenden genauer eingegangen
wird.
-
Die
Komponente „Transaction
Layer" 22 besteht
aus Teilen der Vermittlungsschicht (Network Layer) sowie der Transportschicht
(Transport Layer) gemäß dem OSI/ISO
Referenz-Modell der Datenkommunikation. Diese Komponente ist aber
detailliert im IEEE-1394-1995-Standard beschrieben. Die Komponente
Transaction Layer 22 bietet es als Service an, Daten an
eine bestimmte angegebene Adresse einer anderen Netzwerkstation
zu schreiben, Daten von einer angegebenen Netzwerkstation unter
einer angegebenen Adresse zu lesen, sowie Daten an eine andere Netzwerkstation
zu senden, um so eine Funktion ausführen zu lassen mit Rücksendung
des Ergebnisses. Für
die Erfindung wesentlich ist der Service, mit dem eine Lesetransaktion durchgeführt werden
kann. Bei der Lesetransaktion sendet die „Bus Management" Instanz oder die
Applikationsschicht eine Transaktionsanforderung des Typs READ.
In der Anforderung enthalten ist die Speicheradresse, unter der
die Information in den Knoten zu finden ist, sowie die Anzahl der
Daten, die ab dieser Startadresse gewünscht sind. Die Information,
an welche Netzwerkstation diese Transaktion gerichtet ist, wird
direkt von der Bus Management Instanz an die Datensicherungsschicht 21 weitergeleitet.
Die angeforderten Daten werden über
die Komponente Transaction Layer 22 an die anfragende „Bus Management"-Instanz weitergeleitet.
Sollte aufgrund der angeforderten Daten ein Fehlerkode als Antwort
eingegangen sein, so meldet die Komponente Transaction Layer 22 diesen
Fehlerkode ebenfalls an die „Bus
Management" Instanz.
-
In
dem IEEE-1394-Standard sind die folgenden Fehlerkodes bei Lesetransaktionen
vorgesehen:
„resp_conflict_error" bzw. ab IEEE1394a „ack_conflict_error": dieser Fehlerkode
soll zurückgeliefert
werden, wenn in der Netzwerkstation bereits eine Transaktion zu
der angegebenen Adresse gestartet ist und noch nicht abgeschlossen
ist.
„resp_data_error" bzw. „ack_data_error": Dieser Fehlerkode
wird geliefert, wenn z. B. beim Zugriff auf das „Configuration ROM" festgestellt wurde,
dass ein CRC Fehler vorliegt.
„resp_type_error" bzw. „ack_type_error": Dieser Fehlerkode
ist vorgesehen, wenn die Netzwerkstation nach Anforderung den Blocklesezugriff
nicht unterstützt.
„resp_address_error" bzw. ab IEEE1394a „ack_address_error": Dieser Fehlerkode
sollte generiert werden, wenn in der abgefragten Netzwerkstation
unter der angeforderten Adresse gar keine Daten befindlich sind,
d.h. wenn dieser Speicherbereich gar nicht allokiert worden ist.
-
Im
nachfolgenden wird anhand des Ablaufdiagramms gemäß 6 erläutert, wie der „Node Controller" 27 die
Abfrage der stationsspezifischen Informationen einer anderen Netzwerkstation
durchführt und
wie er auf die zurückgegebenen
Fehlerkodes reagiert.
-
In
dem Schritt 30 gibt der "Node Controller" 27 der abfragenden Netzwerkstation
die Anforderung an das „Transaction
Layer" 22 beispielsweise
die ersten 24 Bytes des "Configuration
ROM" einer spezifizierten
Netzwerkstation zu lesen. In Abfrage 31 prüft der "Node Controller" 27, ob
ein Fehlerkode vom Type „ack_type_error" oder resp_type_error
zurückgegeben
wurde. Wenn das der Fall ist, versucht der "Node Controller" die stationsspezifischen Informationen
mit Hilfe von Wortlesezugriffen anzufordern. Dazu wird innerhalb
des Ablaufplans für
die Abfrage der Informationen der Schritt 33 aufgerufen.
War in Schritt 31 kein dort genannter Fehlerkode eingegangen,
wird in der nachfolgenden Abfrage 32 überprüft, ob der Fehlerkode „resp_address_error" zurückgegeben
wurde. Wenn ja, wird in diesem Fall trotz der eigentlichen Bedeutung,
dass die angegebene Adresse nicht vorhanden ist, nochmals erneut
die stationsspezifische Information unter der angegebenen Adresse
angefordert, und zwar mit Wortlesezugriffen. Auch hier wird dann
im Ablaufplan mit Schritt 33 die Abfrageprozedur fortgesetzt.
War auch dieser Fehlerkode nicht aufgetreten, wird zum Ende der
Abfrageprozedur gesprungen. In Schritt 33 wird eine Zählvariable
i auf 1 gesetzt. Im nachfolgenden Schritt 34 erfolgt dann
die Leseaufforderung für
das erste Quadlet des „Configurations
ROM" mit Hilfe eines Quadlet-Lesezugriffs
an das „Transaction
Layer" 22. In
der nachfolgenden Abfrage 35 wird dann überprüft, ob eventuell erneut ein „resp_address_error" zurückgeliefert
wird. Ist das der Fall, wird gemäß der Erfindung
davon ausgegangen, dass tatsächlich
unter einer ungültigen
Adresse gelesen werden sollte und es wird die Abfrageprozedur damit
beendet. Wenn aber im anderen Fall gültige Daten zurückgeliefert
werden und dieser Fehlerkode nicht auftritt, wird in Schritt 36 die
Adresse für
das nächste
Quadlet des "Configuration
ROM" bestimmt und
es wird die Zählvariable
i inkrementiert. Ein nächster
Wortlesezugriff erfolgt dann nachdem in Abfrage 37 überprüft worden
ist, dass die Indexvariable i noch nicht den Wert 6 überschritten hat.
Dadurch werden die ersten sechs Quadlets des "Configuration ROM" jeweils richtig ausgelesen, obwohl
ein Zugriff auf diese Daten mit einem Blocklesezugriff nicht möglich war.
Anschließend
ist die Abfrageprozedur beendet.
-
Die
Erfindung ist nicht auf das hier beschriebene Ausführungsbeispiel
beschränkt.
Die Erfindung kann auch so ausgelegt sein, dass auch bei Rücklieferung
eines anderen Fehlerkodes zunächst
noch probiert wird, die gewünschten
Daten mit Hilfe von Wortlesezugriffen zu erhalten.