DE69914425T2

DE69914425T2 - Modulare Übertragungssteuerung und -Verfahren

Info

Publication number: DE69914425T2
Application number: DE69914425T
Authority: DE
Inventors: Danny K. Newark Hui; Harry S. San Jose Hvostov; Anthony Pleasanton Fung; Peter San Jose Groz; Jim C. Santa Clara Hsu
Original assignee: STMicroelectronics lnc USA
Current assignee: STMicroelectronics lnc USA
Priority date: 1998-08-25
Filing date: 1999-08-24
Publication date: 2004-12-02
Anticipated expiration: 2019-08-25
Also published as: EP0982662A2; US6549951B1; EP0982662B1; DE69914425D1; EP0982662A3; JP2000124931A

Description

Diese Erfindung bezieht sich auf eine Kommunikation zwischen Einrichtungen, die an ein Datenkommunikationssystem angeschlossen sind. Insbesondere bezieht sich diese Erfindung auf eine Kommunikationssteuerung, die Datenpakete von einem seriellen Hochgeschwindigkeitsbus empfängt und Funktionen veranlasst, die an Knoten des Busses durchzuführen sind, basierend auf den Inhalten der Datenpakete.
In Allgemeinen gibt es zwei Arten von Datenbussen: serielle und parallele. Ein paralleler Bus wird typischerweise an seiner Kapazität und Geschwindigkeit gemessen. Eine Breitenkapazität eines parallelen Busses wird in Bytes gemessen und seine Geschwindigkeit wird üblicherweise in Megahertz oder Bytes/Sekunde gemessen. Zum Beispiel ist der bekannte Peripherkomponenten-Zwischenverbindungsbus (Peripheral Component Interconnect: PCI-Bus) ein paralleler Bus, der 32 Bit breit ist und bis zu 33 MHz betrieben werden kann. Bei dieser Frequenz kann er Daten bei einer Rate von über 1 Gigabit pro Sekunde (1 Gbps) tragen bzw. transportieren. Ein Definitionsmerkmal eines parallelen Busses ist, dass sämtliche der Bits in seiner Breite gleichzeitig gesendet werden, wobei z.B. in dem PCI-Bus sämtliche 32 Bits zur gleichen Zeit während eines Zyklus gesendet werden. Dies erfordert zumindest so viele Signalleitungen in dem Bus, wie seine Breite ist, und zusätzliche Leitungen für Adressierungssignale, eine Leistungszufuhr und andere Signale. Der PCI-Bus hat nahezu 50 Signalleitungen. Signalleitungen werden üblicherweise als Spuren bzw. Leiter auf einer gedruckten Schaltungsplatine oder als Drähte ausgebildet. Die große Anzahl an Signalleitungen in einem parallelen Bus macht die Realisierung teuer. Zusätzlich ist die Anzahl von Einrichtungen auf einen PCI-Bus begrenzt und jede Einrichtung fordert eine Karte und einen offenen entsprechenden Kartenschlitz bzw. -anschluss, um in den Bus eingesteckt zu werden.
Umgekehrt überträgt ein serieller Bus Daten mit einem Bit zu einer Zeit. Obwohl dies die Anzahl von Leitungen, die für den seriellen Bus nötig sind, verringert, dehnt dies die zur Übertragung von Daten erforderliche Zeit, verglichen mit einem parallelen Bus, aus. Zum Beispiel überträgt, wenn ein Betrieb oder dergleichen Frequenz vorliegt, ein serieller Bus nur ein Datenbit in der gleichen Zeit, in der ein PCI-Bus Bit überträgt. Ein Beispiel eines seriellen Busses ist der universelle serielle Bus (USB). Dieser Bus enthält vier Drähte bzw. Leitungen und hat eine maximale Datenrate von 12 Megabit pro Sekunde (Mbps). Die geringe Anzahl an Drähten machen einen seriellen Bus ideal zur Zwischenverbindung von Einrichtungen über ein Kabel, da das Kabel kostengünstig hergestellt werden kann. Weil jedoch datenintensive Anwendungen erfordern, dass ein hohes Datenvolumen schnell bewegt werden kann, haben sich Hersteller allgemein eher auf parallele als auf serielle Busse für die Zwischenverbindung von datenintensiven Einrichtungen verlassen. Anwendungen, die solche datenintensiven Einrichtungen verwenden, enthalten die Video- und Audiowiedergabe, Hochgeschwindigkeitsspeichereinrichtungen, wie etwa Festplattenlaufwerke, u. a.
Bis jetzt mussten Konstrukteure von Systemen, die Daten über einen Bus bewegen, zwischen dem schnellen und teuren parallelen Bus oder dem langsamen und kostengünstigen seriellen Bus wählen. Kürzlich sind Spezifikationen für einen seriellen Hochgeschwindigkeitsbus durch das Institute of Electrical and Electronics Engineers angepasst worden. Die Spezifikation IEEE 1394-1995 ist als "FireWire" oder einfach 1394 bekannt. Die 1394-Spezifikation enthält Standards für Datenübertragungsraten von bis zu 400 Mbps, wobei nur 2 Paare von Datenleitungen bzw. -dähten und ein Paar von Leitungen bzw. Drähten für die Leistung verwendet werden. Diese Datenrate ist schnell genug, um die datenintensiven Bedürfnisse von Video, Audio und Hochgeschwindigkeitsspeicherung unterzubringen. Weitere Bedürfnisse werden durch einen anderen vorgeschlagenen 1394-Standard befriedigt, der eine Datenrate von über 1 Gbps hat. Deshalb können durch Verwendung eines 1394-Standardbusses datenintensive Aufgaben kostengünstig auf einem seriellen Bus ohne die Nachteile der Verwendung eines parallelen Busses implementiert werden.
Der 1394-Bus verwendet eine Gleich-zu-Gleich-Architektur. Physikalische und logische Knoten sind an den 1394-Bus mittels eines Kabels mit sechs Leitern angeschlossen. Bis zu 63 Knoten können an jede unabhängige Busbrücke angeschlossen werden und 1023 Brücken sind in dem System erlaubt für eine Gesamtanzahl von über 65.000 Einrichtungen an einem 1394-System. Es ist wahrscheinlich, dass eine 1394-zu-PCI-Schnittstelle, die wahrscheinlich den Open-Host-Controller-Schnittstellenstandard (OHCI-Standard) verwendet werden wird, wenn ein 1394-Bus in einem Computer verwendet wird. Strikt ausgedrückt, kann jedoch der 1394-Bus unabhängig von einem Computer betrieben werden, indem Einrichtungen, die einen Bezug haben, über das Anschlusskabel zusammengekoppelt werden. Zusätzlich zu einer Kabelspezifikation wird eine Rückwandspezifikation für den 1394-Bus zur Verfügung gestellt. Eine Rückwandspezifikation wird am wahrscheinlichsten für einen Bus innerhalb eines Computers oder einige andere vollständig aufgenommene Systeme verwendet. Die Kommunikationssteuerung, die hierin beschrieben wird, arbeitet entweder in der Kabel- oder der Rückwandumgebung.
Der 1394-Standard spezifiziert drei "Schichten", die physikalische, die verbindungsmäßige und die übertragungsmäßige. Die physikalische Schicht überträgt elektrische Signale entlang des seriellen Busses, vermittelt den Bus, indem sichergestellt wird, dass nur ein Knoten zu einer Zeit sendet, und übersetzt elektrische Signale, die von dem Bus erfasst worden sind, in Datensignale für die Verbindungsschicht. Die Verbindungsschicht ordnet die Datensignale, die von dem Bus gewonnen worden sind, in Datenpaketen an und stellt Services bzw. Dienste zur Verfügung, wie etwa Adressierung, Datenprüfung und die Erzeugung eines "Zyklus"-Signals, das für die zeitliche Steuerung bzw. Taktung und Synchronisation verwendet wird. Die Übertragungsschicht akzeptiert die Datenpakete von der Verbindungsschicht und enthält Busübertragungen, die erforderlich sind, um eine Befehls- und Statusregisterarchitektur (CSR-Architektur) zu unterstützen, einschließlich Lesen, Schreiben und Datensperre. Verschiedene andere Busse verwenden den CSR-Standard und spezifizieren, dass 1394 auch zu dem CSR-Standard passen muss, was es einfach macht, einen 1394-Bus an diese anderen Busse anzupassen oder anzuschließen. Allgemein erscheinen die physikalische Schicht und die Verbindungsschicht wie auch eine begrenzte Anzahl von Abwicklungsfunktionen in der Hardware. Der Rest der Abwicklungsschichtfunktionen wird mit Software durchgeführt.
Um zweckmäßig zu sein, müssen zusätzliche Kommunikationsschichten mit den 1394-Schichten kommunizieren und oberhalb dieser arbeiten. Zum Beispiel ist direkt oberhalb der Abwicklungsschicht eine Übertragungsschicht, die z.B. ein serielles Busprotokoll-2 (SBP-2) oder funktionales Steuerprotokoll (FCP) verwendet. Diese Standards definieren ein Protokoll für den Transport von Befehlen und Daten über serielle Busse mit hoher Funktionsfähigkeit. Zusätzlich ist über der Transportschicht eine Anwendungsschicht, die solche Protokollstandards verwendet, wie etwa mit reduziertem Block (RBC), Druckerarbeitsgruppe (PWG) oder Internetprotokoll (IP). Die Zwischenwirkung dieser Schichten miteinander und mit den Schichten der 1394-Spezifikation werden hierin weiter beschrieben.
Es ist folglich wünschenswert, eine Kommunikationssteuerung zu haben, die sämtliche der Tätigkeiten durchführt, die in der 1394-Spezifikation in einer zweckentsprechenden Weise ausgeführt sind. Es ist auch für die Kommunikationssteuerung wünschenswert, leicht skalierbar zu sein, um neue Dienste und Aufgaben zu enthalten. Es ist auch ein Vorteil, eine Kommunikationssteuerungsarchitektur zu entwickeln, die leicht für eine Vielzahl von Rollen und Funktionen modifiziert werden kann.
Die "High Performance Transport"-Überarbeitung 0,3e durch Shigeru Ueda und Akihiro Shimura (Canon Inc.) definiert ein Protokoll mit einem kleinen Befehlssatz und ein Verhaltensmodell zum Transportieren bzw. Übermitteln von Daten zwischen einem Computersystem und einer peripheren Einrichtung über ein serielles Busprotokoll 2 (SBP-2). Der HPT stellt eine vollständige Duplex-Kommunikationsfähigkeit zwischen einer Initiatoreinrichtung und einer Zieleinrichtung zur Verfügung.
In einem Datenkommunikationssystem, z.B. einem 1394-Bussystem, arbeitet eine Abwicklungsschnittstelle an einem logischen Knoten auf dem Bus. Da Pakete entlang dem Bus gerichtet in Richtung des spezifischen Knotens, auf dem die Abwicklungsschnittstelle sitzt, gesendet werden, dekodiert die Abwicklungsschnittstelle den Paketinhalt in Steuerblöcke für einen weiteren Betrieb. Der weitere Betrieb kann die Ausführung durch eine Anwendung enthalten, die auch auf dem lokalen Knoten arbeitet. Zusätzlich kann die Anwendung erfordern, dass Daten zu einem anderen Knoten in dem Bus übertragen werden. In diesem Fall kommuniziert die Anwendung mit der Abwicklungsschnittstelle über Nachrichtensteuerblöcke, welche dann in Datensignale gewandelt werden und auf dem Bus angeordnet werden, um an dem Zielknoten empfangen zu werden.
Die Erfindung wird in den Ansprüchen 1, 11 und 15 hervorgehoben.
Einige Ausführungsformen der Erfindung werden nun im Wege eines Beispiels und unter Bezugnahme auf die begleitenden Darstellungen beschrieben, in welchen:
1 eine Darstellung ist, die eine mögliche 1394-Buskonfiguration zeigt.
2 ist eine Darstellung, die Schichten des 1394-Standards wie auch Schichten zeigt, die mit den Schichten des 1394-Standards wechselwirken.
3 ist eine Darstellung, die Dienste und Aufgaben gemäß einer Ausführungsform der vorliegenden Erfindung zeigt.
4 ist ein Diagramm, das eine Struktur eines Nachrichtensteuerblockes zeigt.
5 ist ein Diagramm, das Dienste und Aufgaben gemäß einer anderen Ausführungsform der vorliegenden Erfindung zeigt.
6 ist ein Diagramm, das Anwendungen und Protokolle zeigt, die mit einem 1394-Bus verwendet werden können.
Die 1 zeigt ein Verfahren zur Realisierung einer 1394-Busarchitektur. Ein Bus 100 wird in drei lokale Busse A, B und C unterteilt. Sowohl der lokale Bus A als auch der lokale Bus C verwendet eine Busbrücke 110, um an den lokalen Bus B angeschlossen zu sein. Die Einrichtungen sitzen als Knoten an den lokalen Bussen. Eine Schichtstruktur 2, die unten beschrieben wird, ist innerhalb sämtlicher der Knoten auf dem Bus enthalten. Die Einrichtungen können irgendeine Einrichtung sein, die verwendet wird, um Daten zu erzeugen, anzunehmen oder zu übertragen, wie etwa ein erstes Festplattenlaufwerk 120, ein zweites Festplattenlaufwerk 122 oder einen Druck 124. Jeder lokale Bus kann ein Maximum von 63 Knoten haben, wobei jedoch durch Verwendung von Busbrücken ein 1394-Bussystem über 65.000 Knoten haben kann. Typischerweise ist der Datenverkehr auf einen lokalen Bus begrenzt, so dass z.B. Einrichtungen an dem lokalen Bus C keine Daten erkennen können, die auf dem lokalen Bus A durchgelaufen sind. Dies erhöht die Bandbreite des Bussystems, indem nur Daten auf einem lokalen Bus durchlaufen, der auf den lokalen Bus gerichtet ist. Die Busbrücke 110 überwacht den Busverkehr auf dem lokalen Bus, an den sie angeschlossen ist, wobei sie nach Daten sucht, die für einen Knoten an einem anderen lokalen Bus gedacht sind. Wenn solche Daten erfasst werden, überträgt die Busbrücke 110 die Daten zu dem gewünschten Bus. Deshalb kann der Drucker 124 auf dem lokalen Bus A Daten entweder von dem Festplattenlaufwerk 120 (auf dem lokalen Bus A) oder von dem Festplattenlaufwerk 122 über die lokale Busbrücke 110 (an dem lokalen Bus B) empfangen. Zusätzlich könnte die Busbrücke 110 an den 1394-Bus zu einem Bus angekoppelt sein, der typischerweise in einem Computer verwendet wird, wie etwa ein PCI-Bus (nicht gezeigt).
Die 2 zeigt einen allgemeinen Überblick der Schichtstruktur 2 von 1394, einschließlich des Managements des seriellen Busses. Diese Schichtstruktur erscheint in jedem Knoten, der an einen lokalen 1394-Bus angesetzt ist. Die Schichtstruktur 2 enthält eine Abwicklungs- bzw. Transaktionsschicht 10, eine Verbindungsschicht 20, eine physikalische Schicht 30 und ein Management 40 eines seriellen Busses. In Verbindung mit den 1394-Schichten werden auch eine Transportschicht 80 und eine Anwendungsschicht 90, wie oben beschrieben, verwendet. Die Kommunikation zwischen den Schichten 10, 20, 30 und dem Management 40 des seriellen Busses wie auch mit den Schichten 80 und 90 geschieht über eine bidirektionale Zwischenschichtkommunikation 50, die mehr als einen Kommunikationspfad enthalten kann. Die Kommunikation 50 muss kein Datenbus sein, kann aber irgendeine einer Anzahl von Kommunikationsverfahren sein, wie etwa Signaldrähte, aufgeteilte Speicherressourcen oder andere Mittel. Wie in 2 gezeigt, kommuniziert die Transaktions- bzw. Abwicklungsschicht 10 unmittelbar mit der Verbindungsschicht 20, einem Busmanager 55 und gibt isochrone Signale zu einem isochronen Ressourcenmanager 65, der innerhalb der Managementeinrichtung 40 des seriellen Busses enthalten ist.
Schichten in einem Kommunikationssystem, wie etwa dem 1394-Bus, sind vorgesehen bzw. angeordnet, um unabhängig von Schichten um sie herum, aber in Verknüpfung bzw. Verbindung mit diesen zu arbeiten. Im Allgemeinen ist die Ordnung eine Schicht um so höher, je ferner eine Schicht von der Hardware, wie etwa den Datendrähten bzw. -leitungen eines 1394-Busses, ist. Schichten höherer Ordnung können Funktionen höherer Ordnung durchführen. Zum Beispiel führt die Transaktions- bzw. Abwicklungsschicht 10 der 1394-Spezifikation nur Lese-, Schreib- und Haltefunktionen durch. Eine Transportschicht 80 kommuniziert mit der Transaktionsschicht bzw. Abwicklungsschicht 10 und hat Befehle höherer Ordnung. Der bestimmte Standrad der verwendeten Transportschicht bestimmt seine Befehle. Zum Beispiel sind in der SBP-2-Transportsschicht Befehle verfügbar, wie etwa Einloggen, wieder Verbinden und Einstell- bzw. Ansteuerungspasswort. Über der Transportschicht 80 ist eine Anwendungsschicht 90, die Protokolle verwendet, wie etwa RBC, PWG oder IP. Die Anwendungsschicht 90 arbeitet in Verbindung mit Software, um die gewünschte Anwendung durchzuführen.
Die 1394-Spezifikation enthält zwei grundlegende Datenübertragungsdienste, die isochrone Datenübertragung und die asynchrone Datenübertragung. Die isochrone Datenübertragungsspezifikation ermöglicht es, Pakete entlang des seriellen Hochgeschwindigkeitsbusses mit regelmäßigen Intervallen zu senden. Typischerweise werden die isochronen Datenübertragungsdienste für große Volumen von Daten verwendet, die zwischen einem Datengenerator und einem Datenempfänger getragen werden, z.B. einer digitalen Videokamera und einer Multimediaelektronik, wie etwa einem Videodisplay oder einem Videoeditor. Eine isochrone Datenübertragung kommuniziert unmittelbar mit der Verbindungsschicht 20 und umgeht die Transaktionsschicht bzw. die Abwicklungsschicht 10. Die Transaktions- bzw. Abwicklungsschicht wird nur für eine asynchrone Datenübertragung verwendet. Der Hauptanteil der Bandbreite innerhalb der 1394-Spezifikation ist für die isochrone Datenübertragung reserviert, wobei 20% der Bandbreite für eine asynchrone Datenübertragung ist.
Eine Knotensteuerung 75 ist unmittelbar an die Verbindungsschicht und die physikalische Schicht angeschlossen. Der Busmanager 55, der isochrone Quellen- bzw. Ressourcenmanager 65 und die Knotensteuerung 75 werden jeweils gemäß dem CSR-Standard, IEEE 1212-1991, angesteuert bzw. betrieben. Andere Arten von Bussen verwenden auch diesen CSR-Standard, wobei die Anschließbarkeit eines 1394-Busses ausgedehnt wird. Die CSRs sind innerhalb des seriellen Busmanagers 40 angeordnet und werden als ein Management- bzw. Verwaltungs-CSR 57, ein isochroner CSR 67 und ein Standard-CSR 77 dargestellt.
Die Schichtstruktur 2, die ein serielles Busmanagement 40 enthält, ist in jedem Knoten entlang des Busses vorhanden. Jedoch ist nur ein Busmanager 55 und ein isochroner Quellen- bzw. Ressourcenmanager 65 an dem lokalen Bus aktiv. Diese Manager üben Managementverantwortlichkeiten über den gesamten lokalen Bus aus. Weil jeder lokale Bus nur einen Busmanager 55 (und nur einen haben kann) und nur einen isochronen Quellen- bzw. Ressourcenmanager 65 benötigt, sperren die anderen Knoten ihre jeweiligen Busmanager und isochronen Quellen- bzw. Ressourcenmanager. Die Knotensteuerung 75 ist für sämtliche operativen Knoten aktiv.
Wie oben bemerkt, werden die Verbindungsschicht 20 und die physikalische Schicht 30 im Allgemeinen durch Hardware verkörpert, z.B. einen von Silicon System Design, Inc. oder auch von Texas Instruments, Inc. verfügbaren Chip. Die Transaktions- bzw. Abwicklungsschicht 10, die Transportschicht 80, die Anwendungsschicht 90 und andere Funktionen der Transportschnittstelle werden allgemein in einer Softwareform verwirklicht, das heißt einem Softwareprogramm, das ausgeführt wird, sobald es in einen Speicher geladen ist. Bei einer bevorzugten Ausführungsform werden die Schichten und Funktionen in Firmware gespeichert, z.B. Kodes, die in einer programmierbare Speichereinrichtung gespeichert werden, wie etwa einem Festspeicher (ROM), einer programmierbaren logischen Anordnung (PLA) oder einem auf einer Festplatte gespeicherten Programmteil bzw. Programmpunkt. Ferner könnten die Schichten und Funktionen in eine anwendungsspezifische integrierte Schaltung (ASIC) mittels Verfahren, die im Stand der Technik wohl bekannt sind, programmiert werden. Allgemein arbeitet eine Auswahl von Operationen wie jene, die oben aufgelistet sind, schneller in Hardware als in Software, wobei jedoch ein Softwareprogramm leichter zu ändern, zu korrigieren und zu aktualisieren ist. Die bevorzugte Ausführungsform von Firmware kombiniert Vorteile sowohl der Hardware als auch der Software.
3 zeigt eine Ausführungsform der vorliegenden Erfindung. Eine Kommunikationssteuerung 200 erscheint in jedem Knoten auf dem Bus, wie etwa in den Festplattenlaufwerken 120, 122 oder in dem Drucker 124, die in 1 gezeigt sind. Die Transaktions- bzw. Abwechslungsschnittstelle 210 verkörpert einige der in 2 gezeigten Bestandteile. Unter Bezugnahme auf die in 3 gezeigten Bestandteile könnte ein Chip, der die Transaktions- bzw. Abwicklungshardware 205 verkörpert, die zuvor aufgezeigten Chips von Silicon System Design oder Texas Instruments sein. Die Abwicklungsschnittstelle 210 verwirklicht die 1394-Abwicklungsschicht. Das Managementunterprogramm 235 des seriellen Busses implementiert Funktionen des Busmanagements, wie etwa eine Rücksetzung oder eine Rücksetzung beim Einschalten. Der Rest der in 3 gezeigten Darstellungen implementiert Funktionen und Befehle, die durch die Transportschicht bestimmt werden, wie etwa SBP-2, in Verbindung mit der Anwendungsschicht, wie etwa RBC.
Mit der Ausnahme der Abwicklungshardware 205 können die Darstellungen in 3 in zwei Klassifikationen, Dienste und Unterprogramme bzw. Aufgaben aufgeteilt werden. Ein Task bzw. ein Unterprogramm kann andere Tasks oder Dienste aufrufen. Ein Service bzw. ein Dienst kann nur antworten, wenn er durch ein Unterprogramm bzw. einen Task aufgerufen worden ist, und wenn er fertigt ist, er zu dem aufrufenden Unterprogramm bzw. Task zurückkehrt. Die Abwicklungsschnittstelle 210 ist ein Dienst bzw. Service zusammen mit einem Kern (Anwendungssystem)/Scheduler (Steuerprogramm)/Dispatcher (Zuteiler) 220. Der Rest der Darstellungen, die in 3 gezeigt sind, sind Unterprogramme bzw. Tasks, wie unten beschrieben wird.
Die Abwicklungshardware 205 überwacht den 1394-Bus und wandelt elektrische Signale, die von dem Bus in Datenpaketen erfasst worden sind. Die Abwicklungsschnittstelle 210 dekodiert die Datenpakete, die von der Abwicklungshardware 205 empfangen worden sind. Diese Datenpakete werden analysiert, um zu bestimmen, falls ein Unterprogramm bzw. Task oder ein Dienst bzw. Service aufgerufen werden sollte oder falls keine Aktion bzw. Tätigkeit erforderlich ist. Falls ein Task oder ein Dienst aufgerufen werden muss, erzeugt das Abwicklungsinterface 210 einen Nachrichtensteuerblock (MCB) auf der Grundlage der Inhalte des Datenpakets und ruft den gewünschten Task oder Service auf. Nachrichtensteuerblöcke werden für sämtliche Kommunikationen zwischen Tasks bzw. Unterprogrammen oder Diensten verwendet und werden unten weiter beschrieben.
Die kleinste Dateneinheit, auf deren Grundlage die Abwicklungsschnittstelle 210 arbeiten kann, ist ein Datenpaket. Ein Datenpaket ist eine Gruppe von Daten. In ihrem kleinsten Element ist ein digitales Datum entweder eine 1 oder eine 0. Jedes individuelle Stück eines Datums wird Bit genannt. Eine Sammlung von 8 Bits wird als ein Byte bezeichnet und eine Sammlung von 4 Bytes (32 Bits) wird als ein Quadlet bzw. eine Vierergruppe bezeichnet. Ein asynchrones Paket muss zumindest vier Quadlets enthalten oder 128 Bits lang sein. Die ersten 128 Bits werden als ein Paketkopfteil bzw. eine Paketüberschrift bezeichnet. Ein asynchrones Paket kann auch einen Datenblock enthalten. Die Größe des Datenblocks variiert, ist aber auf ein absolutes Maximum basierend auf der Geschwindigkeit, bei welcher der 1394-Bus betrieben wird, beschränkt. Der 1394-Bus enthält Spezifikationen, um bei 98,304 Mbps, 196,608 Mbps oder 393,216 Mbps zu arbeiten. Diese Geschwindigkeiten werden häufig gerundet auf 100, 200 bzw. 400 Mbps und werden mit S100, S200 und S400 benannt. Wenn bei der Geschwindigkeit S100 gearbeitet wird, ist die maximale Blockgröße 512 Bytes (oder 128 Quadlets). Wenn bei S200 bzw. S400 gearbeitet wird, beträgt die maximale Blockgröße 1024 Bytes bzw. 2048 Bytes. Wenn höhere Busgeschwindigkeitsstandards bevorzugt werden, wird die maximale Blockgröße vermutlich ebenfalls anwachsen.
Das Abwicklungs- bzw. Durchführungsinterface 210 empfängt Daten von dem 1394-Bus und überträgt Daten zu diesem Punkt. In Bezug auf die Abwicklungsschicht 10 nach 2 gibt es drei Hauptfunktionen, die in Paketen zusammen mit dem Bus gesendet werden und durch die Abwicklungsschnittstelle 210 verarbeitet werden. Dieses sind Lese-, Schreib- und Sperr- bzw. Haltefunktionen. Für jede dieser Funktionen gibt es zwei Hauptoperationen, die Anfrage bzw. den Aufruf und die Antwort. Ein Aufruf fragt danach, dass ein Lesen, Schreiben oder Sperren bzw. Halten stattfindet, und eine Antwort zeigt an, dass das Lesen, Schreiben oder Sperren bzw. Halten versucht wurde und enthält ein Ergebnis.
Pakete, die für den Zielknoten bestimmt sind, auf dem die Abwicklungsschnittstelle 210 sitzt, werden durch einen Initiator auf dem 1394-Bus angeordnet. Pakete, die zu der bestimmten Knotenadresse geleitet werden, werden in einer Empfangsnische in der Abwicklungshardware 205 empfangen und eine Unterbrechung wird für die Abwicklungsschnittstelle 210 erzeugt. Sobald die Abwicklungsschnittstelle 210 ihren gegenwärtigen Task vervollständigt hat, wird eine Unterbrechungsserviceroutine bzw. wird ein Unterbrechungsserviceprogramm eingegeben. Bei einer Ausführungsform werden die sieben Arten von Paketen, die die Unterbrechung verursachen, durch einen Abwicklungskode mit 4 Bit identifiziert, der in der Kopfzeile des Pakets bzw. der Überschrift des Pakets enthalten ist. Die Abwicklungskodes für diese Ausführungsform der Erfindung werden wie folgt definiert:
Wie oben beschrieben, beträgt ein Quadlet 4 Bytes und ein Block ist entweder 512, 1024 oder 2048 Bytes, abhängig von der Geschwindigkeit, bei welcher der Bus betrieben wird. Ein Schreibaufruf bzw. eine Schreibanfrage für einen Datenblock fordert auf, dass ein Datenblock in eine spezifizierte Zielspeicheradresse bei einem bestimmten Knoten geschrieben wird. Ein Schreibaufruf für ein Daten-Quadlet ist identisch zu einem Schreibaufruf für einen Datenblock, wobei jedoch die Menge der Daten, die in die spezifizierte Zieladresse geschrieben werden, in einen Daten-Quadlet passen. Eine Leseanfrage bzw. ein Leseaufruf für einen Datenblock und ein Leseaufruf für ein Daten-Quadlet sind Aufrufe, um Daten von der spezifizierten Zielspeicheradresse an dem spezifizierten Knoten zurück zu gewinnen.
Schreib- und Leseaufrufe werden beantwortet, indem Antworten gesendet werden, die sowohl Lese- als auch Schreibantworten sowohl für Daten-Quadlets als auch für Datenblocks enthalten. Eine Leseantwort für ein Daten-Quadlet wird in Antwort zu einer Leseanfrage für ein Daten-Quadlet gesendet, wobei die angeforderten Daten innerhalb der Paketkopfzeile zurückgegeben werden. Eine Leseantwort für einen Datenblock ist gleich bzw. ähnlich zu einer Leseanfrage für ein Daten-Quadlet, wobei jedoch viel mehr Daten zurückgeleitet werden. Falls aus irgendeinem Grund die Leseanfrage nicht durchgeführt werden könnte, werden keine Daten zurückgesandt, sondern ein Fehlerstatus kann zu dem aufrufenden bzw. anfragenden Knoten gesandt werden. Schreibantworten werden in Antwort auf eine Schreibanfrage für entweder ein Daten-Quadlet oder einen Datenblock gesandt. Die Antworten senden einen Antwortkode zurück, der anzeigt, ob das Schreiben erfolgreich war und, falls nicht, wird der bestimmte Grund weitergegeben, warum es fehlschlug. In der Schreibantwort enthält die Paketkopfzeile diesen Antwortkode.
Sperr- bzw. Halteanfragen und Antworten arbeiten auf die gleiche Weise, ausgenommen, dass eher nur eine Adresse als tatsächliche Daten gesendet werden müssen.
Unter Bezugnahme auf 3 werden die Abwicklungsschnittstelle 210 und der Kern/Scheduler/Dispatcher in sämtlichen Ausführungsformen der Erfindung zugegen sein. Zusätzlich werden ein oder mehrere Tasks abhängig davon, welches Protokoll für die Transportsschicht 80 und die Anwendungsschicht 90, die in 2 gezeigt sind, verwendet wird, zugegen sein. Bei der in 3 gezeigten Ausführungsform sind sieben Tasks gezeigt. Diese Tasks sind aufgebaut, um Funktionen durchzuführen, die erforderlich sind, wenn das SBP-2-Protokoll für die Transportschicht 80 verwendet wird. Die Erfindung ist folglich skalierbar, um irgendein verwendetes Protokoll unterzubringen. Zum Beispiel zeigt die in 5 gezeigte Ausführungsform Tasks bzw. Unterprogramme, die für das FCP optimiert sind. Folglich können ein oder mehrere Tasks verwendet werden, um irgendein gewünschtes Protokoll zu verwirklichen.
Zurückgehend zu 3, ermöglichen es die sieben gezeigten Tasks der Erfindung, mit dem SBP-2-Protokoll zu arbeiten. Die Abwicklungsschnittstelle 210 ergreift verschiedene Maßnahmen, abhängig von dem empfangenen Abwicklungskode. Wenn z.B. eine Schreibanfrage für ein Daten-Quadlet oder einen Datenblock oder eine Leseanfrage für ein Daten-Quadlet oder einen Datenblock durch die Abwicklungs- bzw. Durchführungsschnittstelle 210 empfangen wird, führt die Abwicklungsschnittstelle einen geordneten Satz von Operationen durch, der das Aufrufen von einem oder mehreren Tasks bzw. Unterprogrammen einbezieht.
Die in 3 gezeigten Dienste und Tasks kommunizieren miteinander über Nachrichtensteuerblöcke (MCB), die in Warteschlangen angeordnet sind, die sich auf die aufgerufenen Dienste und Tasks beziehen. Jeder in 3 gezeigte Task hat zumindest eine jeweilige verbundene Warteschlange. Informationen, die zwischen den Tasks übertragen werden, sind nur über MCBs. Jeder spezifische Task hat seine eigene Art von Steuerblock, der Daten enthält, die speziell von dem Task benötigt werden, um zu arbeiten. In 3 sind sieben Tasks gezeigt, ein Befehls-ORB-Ausführungstask 245, der einen Befehlsnachrichtensteuerblock (CMC-Block) verwendet, einen Hol-Managementtask 215, der einen Hol-Managementnachrichtensteuerblock (FMC-Block) verwendet, einen ORB-Hol-Task 255, der einen ORB-Hol-Nachrichtensteuerblock (OMC-Block) verwendet, einen frei laufenden Statustask 265, der einen frei laufenden Statusnachrichtensteuerblock (UMC-Block) verwendet, einen Management-Mittel-Task 225, der Management-Mittel-Nachrichtensteuerblock (MMC-Block) verwendet, einen seriellen Busmanagementtask, der einen seriellen Busnachrichtensteuerblock (SMC-Block) verwendet, und einen Anwendungstask 275, der einen Anwendungsnachrichtensteuerblock (AMC-Block) verwendet. Die Dienste haben auch spezifisch für sie vorgesehene MCBs. Der Dispatcher 220 verwendet Zuteiler-Nachrichtensteuerblöcke (DMC-Blöcke) und die Abwicklungsschnittstelle 210 verwendet Abwicklungsnachrichtensteuerblöcke (TMC-Blöcke). Zusätzlich hat jeder Task und jeder Dienst zumindest eine Warteschlange, in welcher der jeweilige MCB angeordnet ist. Zum Beispiel hat der Management-Mittel-Task 225 eine Management-Mittel-Task-Warteschlange, die aufgebaut ist, um MMC-Blöcke zu empfangen. Nichts in der Architektur beschränkt die Verknüpfung bzw. Verbindung von Tasks und Warteschlangen. Zum Beispiel kann ein Task mehrere Warteschlangen haben oder eine Warteschlange kann mit mehreren Tasks verknüpft sein. Jeder Grad der Verknüpfung zwischen Tasks und Warteschlangen ist möglich.
Als ein Beispiel von einer Art von MCB zeigt 4 einen Management-Mittelnachrichtensteuerblock (MMC-Block). Da jeder MCB unterschiedlich ist, gibt es kein solches Ding wie einen Standardnachrichtensteuerblock, wobei jedoch der MMC-Block repräsentativ für die Arten von Daten ist, die in MCBs enthalten sind. Wenn ein Task den Management-Mittel-Task 225 einplanen will, baut der aufrufende Task einen MMC-Block auf und ordnet ihn in einer MMC-Warteschlange an. Ein MMC-Block 300, der in 4 gezeigt ist, enthält 44 Daten-Bytes. Jedes Byte ist entlang der linken Seite zur Bezugnahme nummeriert und ein Byte-Versatz, der 0–15 nummeriert ist, zeigt die individuellen Bits an, die die zwei Bytes von jeder Zeile ausmachen. Daten, die für den Task nützlich sind, werden in dem MCB, wie in 4 beschrieben, angeordnet. Zum Beispiel besetzt die Geschwindigkeit, mit der der Bus arbeitet, Bits 8, 9 und 10 (die einen Versatz von 7, 8 und 9 haben) der ersten zwei Bytes des MMC-Blocks. Eine Adresse für einen Managementbetriebsanfrageblock (ORB) ist 6 Bytes lang und enthält Bytes 4–9. Diese Daten sind nötig und werden durch den Management-Mittel-Task 225 während Operationen verwendet.
Um einen Task oder einen Dienst von einem anderen Task aufzurufen, müssen verschiedene Schritte eingehalten werden. Zunächst wird ein MCB für den bestimmten Task oder Service bzw. Dienst, der aufzurufen ist, erzeugt. Dann wird der MCB in der Warteschlange platziert, die mit dem bestimmten Task oder Dienst verknüpft ist, und ein Rückkehrkode wird zurück zu dem erzeugenden Task geschickt. Dann prüft der erzeugende Task den Rückkehrkode. Falls der Rückkehrkode anzeigt, dass der MCB nicht an der Spitze der Warteschlange ist, bedeutet dies, dass der Task momentan läuft und der erzeugende Task unternimmt nichts mehr. Keine Aktion wird unternommen, weil ein Task, der einmal gestartet ist, an sämtlichen der MCBs in seiner Warteschlange arbeitet, bis die Warteschlange leer ist. Folglich wird an dem MCB, der kürzlich in der Warteschlange des Tasks angeordnet worden ist, eventuell gearbeitet, wenn er an die Spitze der Warteschlange vorrückt. Falls jedoch der Rückkehrkode anzeigt, dass der MCB, der gerade in der Warteschlange des Tasks platziert worden ist, bereits an der Spitze der Warteschlange ist, das heißt, es gibt keine anderen MCBs in der Warteschlange des Tasks, erläutert dies dem erzeugenden Task, dass der aufgerufene Task nicht bereits läuft und gestartet werden muss.
Um einen Task zu starten, erzeugt der erzeugende Task einen Zuteiler-Nachrichtensteuerblock (DMC) für den Dispatcher 220. Der DMC-Block zeigt an, welcher Task zu starten ist und welche Priorität dem DMC-Block zu geben ist. Der Dispatcher 220 enthält eine darauf bezogene Warteschlange, die kontinuierlich nach Einträgen bzw. Eintritten geprüft wird. Wenn Einträge durch den Scheduler 220 empfangen werden, um die gewünschten Tasks zu starten, werden sie in der Dispatcher- bzw. Zuteiler-Warteschlange gemäß der Priorität angeordnet, wobei die höchste Priorität am höchsten in der Warteschlange angeordnet wird. Wie bei sämtlichen der Warteschlangen wird der Dispatcher oder Tasks nicht in seiner Bearbeitung an seinem gegenwärtigen MCB unterbrochen, selbst wenn ein MCB, der eine höhere Priorität hat, in seiner Warteschlange platziert wird. Statt dessen ordnet der Scheduler 220 DMC-Blöcke auf der Grundlage der Priorität des neuen Blocks und die gegenwärtig in der DMC-Warteschlange anhängigen Blöcke, jedoch nicht dem DMC-Block, an dem gegenwärtig gearbeitet wird. Wenn der DMC-Block die Spitze der DMC-Warteschlange erreicht, schaut der Dispatcher 220 in dem DMC-Block nach, um zu sehen, welcher Task oder Dienst aufzurufen ist, und informiert dann den aufgerufenen Task, dass dort ein MCB in seiner eigenen Warteschlange sitzt, der darauf wartet, betrieben zu werden. Dies veranlasst den aufgerufenen Task, mit dem Betrieb zu beginnen. So müssen, damit ein Task einen anderen Task oder Dienst zum Betrieb einplanen kann, entweder ein oder zwei MCBs erzeugt werden. Zuerst wird ein MCB spezifisch für den aufgerufenen Task erzeugt und in der mit ihm verknüpften Warteschlange angeordnet. Ein Rückkehrkode wird dann durch den erzeugenden Task geprüft. Falls der Rückkehrkode anzeigt, dass der MCB in der Warteschlange angeordnet wurde, jedoch nicht an dem Kopf der Warteschlange, tut der initiierende Task nichts mehr, weil der aufgerufene Task bereits läuft und an dem MCB arbeiten wird, wenn er in den Kopf der Warteschlange bewegt wird. Falls jedoch der Rückkehrkode anzeigt, dass der MCB an dem Kopf der Warteschlange für den aufgerufenen Task oder Dienst angeordnet wurde, wird ein DMC-Block durch den erzeugenden Task erzeugt, der anzeigt, welcher Task oder Dienst aufzurufen ist und welche Priorität dem DMC-Block gegeben wird. Der Scheduler 220 ordnet dann den DMC-Block an dem passenden Ort in der DMC-Warteschlange an, geordnet durch die Priorität. Wenn der DMC-Block den Kopf der DMC-Warteschlange erreicht, wird der aufgerufene Task oder Dienst alarmiert, dass ein MCB in seiner Warteschlange ist und der Betrieb zu beginnen ist. Der aufgerufene Task oder Dienst oder Service beginnt dann, gibt den DMC-Block zu einem freien Nachrichtenblockpool bzw. -reservoir und arbeitet dann an dem MCB an dem Kopf seiner eigenen Warteschlange.
Ein gemeinsamer Pool bzw. ein gemeinsames Reservoir für Ressourcen existiert für sämtliche MCBs. Der Nachrichtenblockpool bzw. das Nachrichtenblockreservoir wird durch den Kern 220 verwaltet. Der Pool besteht aus einem endlichen Speicherplatz, aus dem MCBs erzeugt werden können. Wenn mehr MCBs erzeugt werden, nimmt die Menge an Speicherplatz, die in dem Pool bzw. Reservoir zurückgeblieben ist, ab. Wenn kein Speicherplatz in dem Reservoir freier Blöcke verbleibt, können keine weiteren MCBs mehr erzeugt werden, bis mehr Ressourcen zugeführt werden. Ressourcen werden zugeführt, indem MCBs zurück zu dem Pool bzw. Reservoir geführt werden, nachdem an ihnen gearbeitet worden ist und sie nicht mehr benötigt werden, das heißt, wenn sie aus der Warteschlange entfernt sind. Wenn ein Task oder Dienst bzw. Service beendet wird, der ein MCB verwendet, das zuvor in seiner Warteschlange war, ruft er den Kern 220 auf und fordert an, dass der MCB zurück in dem Pool freier Blocks angeordnet wird. Er bewegt dann den nächsten freien MCB zu dem Kopf seiner Warteschlange. Falls zusätzlich ein DMC-Block nötig ist, um den Task oder Dienst bzw. Service zu starten, gibt der aufgerufene Task oder Dienst den DMC-Block sofort an den Pool bzw. das Reservoir freier Steuerblöcke zurück, bevor sein eigener MCB betrieben wird. Die Größe des Pools bzw. des Reservoirs der freien Speicherblocks wird durch die Menge an verfügbarem Speicher bestimmt und ist festgelegt, bevor irgendwelche MCBs zugeteilt werden.
Zusätzlich zu der Verwaltung der Zuteilungswarteschlange und der Verwaltung des Pools freier Nachrichtenblöcke führt der Kern/Scheduler/Dispatcher 220 auch andere Funktionen in 1394-Busabwicklungen durch. Der Kern 220 initialisiert die Datenstrukturen, die zeitlichen Steuerungen bzw. Taktgeber und Unterbrechungsvektoren. Sämtliche Tasks, die gesteuert bzw. getaktet werden, erfordern einen Taktgeber bzw. eine zeitliche Steuerung. Der Kern 220 stellt einen derartigen Zeitsteuerungs- bzw. Taktgeberverwaltungsdienst zur Verfügung, wie etwa Starten, Stoppen, neu Starten, Prüfen, Löschen und Zurverfügungstellung einer Unterbrechung auf der Grundlage der Taktgeber bzw. der Zeitsteuerungen. Die Taktgeber werden zugewiesen, wenn dies durch eine Task über einen Aufruf zu den Kerndiensten gefordert wird. Jeder Taktgeber bzw. jede Zeitsteuerung, die gegenwärtig aktiv ist, wird in jedem Taktzyklus eingestellt. Bei einer Ausführungsform wird ein Taktgeber bzw. eine Zeitsteuerung mit einer gegebenen Zahl initialisiert bzw. in einen Anfangszustand versetzt, der bei jedem Taktzyklus dekrementiert wird. Wenn der Zeitgeber bzw. Taktwert Null erreicht, wird eine Mitteilung zu dem Task gesandt, der mit dem Taktgeber bzw. dem Zeitgeber verknüpft ist.
Wie oben ausgeführt, hängen der bestimmte Task, der ausgewählt ist, um mit der Abwicklungsschnittstelle 210 und dem Kern/Scheduler/Dispatcher 220 zu arbeiten, von der Transportschicht 80 ab, die in dem bestimmten System verwendet wird. In der in 3 gezeigten Ausführungsform sind die Tasks ausgewählt, um mit dem SBP-2-Protokoll für die Transportschicht zu arbeiten. Wenn andere Transportschichtprotokolle verwendet werden, können andere Tasks zugegen sein oder einige der in 3 gezeigten Tasks können nicht zugegeben sein. Auf diese Weise ist die Kommunikationssteuerung 200 äußerst flexibel und skalierbar, wobei so viel individuelle Aufmachung wie gewünscht ermöglicht wird.
Wie in der Ausführungsform, die in 3 zu sehen ist, gezeigt ist, arbeitet der Befehls-ORB-Ausführungstask 245 auf der Grundlage von Daten und Statusabwicklungen zwischen dem Anwendungstask 275 und einem Initiator, der typischerweise an einem anderen Knoten platziert ist. Im Betrieb wird der Initiator Daten zu dem Anwendungstask 275 senden oder davon empfangen. Der Befehls-ORB-Ausführungstask 245 ist der prinzipielle Durchgang für die Daten und Statusnachrichten zwischen ihnen. Der Poolverwaltungstask 215 stellt sicher, dass ein Betrieb, der an einem bestimmten Knoten empfangen worden ist, für diesen Knoten bestimmt war. Falls der Betrieb an dem korrekten Knoten ist, aktualisiert der Hol-Verwaltungstask 215 eine Variable, die verwendet wird, um einen gegenwärtigen Zustand eines Mittels anzuzeigen. Der ORB-Hol-Task 255 empfängt mehrere ORBs, die Befehle von einem Initiator enthalten, und lässt sie zu dem Anwendungstask 275, um ausgeführt zu werden. Der Freilaufstatustask 265 sendet eine Statusnachricht an den Initiator, wenn dies von einem der anderen Tasks gefordert wird. Der Management- bzw. Verwaltungs-Mittel-Task 225 führt verwaltungsartige Funktionen durch, die durch den Initiator angefordert werden, einschließlich Zugriffsaufforderungen, Einloggen, Einstellen von Passworten usw. Der serielle Busmanagement- bzw. -verwaltungstask 235 funktioniert wie eine Schnittstelle zwischen dem seriellen Busmanagement bzw. -verwaltung 40 und dem Anwendungstask 275 für die gleichen Knoten. Schließlich arbeitet der Anwendungstask 275, um obere Protokollbefehle auszuführen, die in der Anwendungsschicht 90 nach 1 gefunden worden sind. Der Anwendungstask 275 ist der letzte Ursprung oder die letzte Bestimmung des Hauptteils von Daten, die entlang dem 1394-Bus übertragen werden.
Wendet man sich nun den spezifischen Umständen der Tasks, die in 3 gezeigt sind, zu, reagiert der Management-Mittel-Task bzw. Verwaltungs-Mittel-Task 225 auf Arten von Verwaltungsanfragen bzw. -aufrufen von einem Initiator. In Reaktion auf eine Management-Mittel-CSR-Einschreibung, die durch den Initiatorknoten gesendet ist, holt der Management-Mittel-Task 225 ein Management-OBR von dem Initiator und führt dann die ORB-Funktion aus. Beispiele von ORB-Funktionen enthalten das Login, das Einstellen bzw. Setzen eines Passworts, das wieder Anschließen und einen Beendigungstask. Falls der Management-Mittel-Task 225 zurück mit dem Initiator kommunizieren muss, benutzt er den Übertragungsabschnitt der Abwicklungsschnittstelle 210.
Die Abwicklungsschnittstelle 210 bereitet auch zusätzlich zum Empfangen von Paketen, die für den lokalen Knoten, wie oben beschrieben, bestimmt sind, Pakete vor, die für andere Knoten bestimmt sind. Sobald es vorbereitet ist, überträgt die Abwicklungsschnittstelle 210 die Pakete zu der Verbindungsschicht 20, wo sie synchronisiert werden, und zu der physikalischen Schicht 10 zur Umwandlung in elektrische Signale gesendet werden, um auf dem Bus platziert zu werden. Abhängig von der Art und der Menge von Daten, die von der Abwicklungsschnittstelle 210 zu senden sind, können eine Übertragungsnische, eine Nutzlastdatenübertragungsnische und/oder ein Direktspeicheradresskanal (DMA-Kanal) verwendet werden. Falls die Menge an Daten, die von der Abwicklungsschnittstelle 210 zu senden sind, groß ist, kann sie in mehrere Pakete aufgebrochen werden, die an dem Bus zu platzieren sind. Jedes Paket wird vorbereitet und dann den Bus entlang gesandt.
Tasks, die Daten zu einem anderen Knoten als dem senden wollen, an dem sie sind, senden die Daten über einen Übertragungsabschnitt der Abwicklungsschnittstelle 210. Die Abwicklungsschnittstelle 210 enthält zumindest zwei Warteschlangen, um TMC-Blöcke zu halten, einen für zeitkritische Abwicklungen und einen für zeitlich unkritische Abwicklungen. Daten, die entlang dem Bus zu senden sind, werden in TMC-Blöcke verpackt und in der zeitkritischen oder zeitlich nicht kritischen Warteschlange, wie gewünscht, angeordnet. Die nicht zeitkritische TMC-Warteschlange wird für Datenblockübertragungsanfragen verwendet, während die zeitkritische TMC-Warteschlange für Abwicklungen verwendet wird, die in Subtätigkeiten unterteilt werden müssen. Es kann mehrere Abwicklungen erfordern, um eine nicht zeitkritische TMC-Blockanfrage zu vervollständigen. Sobald die Abwicklungen fertig sind, sendet die Abwicklungsschnittstelle 210 eine Mitteilung zu dem Task, der die Daten sendet, dass der Task fertig ist.
Jede Abwicklung, die durch die Abwicklungsschnittstelle 210 eingeleitet worden ist, hat einen Softwaretaktgeber bzw. -zeitgeber, der damit verknüpft ist. Diese Softwarezeitgeberdienste werden durch den Kern 220, wie zuvor erörtert, zur Verfügung gestellt. Ein Wiederversuchszählfeld des TMC-Blocks wird inkrementiert, falls die Datenübertragung nicht erfolgreich ist. Solange die Wiederversuchszählung unterhalb der programmierbaren maximalen Zahl von Wiederversuchen ist, wird die Abwicklungsschnittstelle 210 versuchen, Daten wieder zu senden. Falls die maximale Wiederversuchszählung bzw. -zahl überschritten worden ist, wird eine Statusnachricht zurück zu dem aufrufenden Task gesandt, um ihn von dem Fehlschlag zu informieren. Bei der Vervollständigung einer Abwicklung, das heißt die Abwicklungsschnittstelle 210 empfing eine Bestätigung von dem Knoten, zu dem die Daten gesendet werden, plant die Abwicklungsschnittstelle 210 einen Abwicklungsvervollständigungsstatus oder ein anderes Antwortsignal ein, um es dem aufrufenden Task zurück zu senden. Die Daten werden in einem DMC-Block platziert und durch den Dispatcher 220 zu dem aufrufenden Task gesandt.
Zurückkehrend zu dem Management- bzw. Verwaltungs-Mittel-Task 225, wird der Task, nachdem der Task bzw. das Unterprogramm die Daten zu dem Initiator sendet, dann ausgesetzt, wobei eine Mitteilung von der Abwicklungsschnittstelle 210 anhängig ist. Wenn die Abwicklungsschnittstelle 210 die Datenabwicklung mit dem Initiator vervollständigt, weckt die Abwicklungsschnittstelle den Management-Mittel-Task 225 auf, indem ein Systemaufruf bzw. -anruf zu dem Scheduler 220 durchgeführt wird. Der Management-Mittel-Task 225 setzt dann seine Ausführung des Management- bzw. Verwaltungs-ORB für diesen Task fort. Sobald fertig, verwirft der Management-Mittel-Task 225 den MMC-Block von dem Kopf seiner Warteschlange, ruft den Kern auf, um den MMC-Block zu dem Pool freien Speicherblockes zurückzugeben, und beginnt den Betrieb an dem nächsten MMC-Block in seiner Warteschlange, falls vorhanden. Falls der Management-ORB einen Login-Befehl enthält, erzeugt der Management-Mittel-Task 225 einen OMC-Block und eine Login-Deskriptorliste. Der OMC-Block und die Login-Deskriptorliste werden entfernt, nachdem der Initiator ausgeloggt hat.
Der Anwendungstask 275 stellt die Anwendung dar, die an einem der Knoten an dem 1394-Bus arbeiten würde, z.B. Hochgeschwindigkeitsdrucker, Hochgeschwindigkeitsspeicher oder audiovisuelle Anwendungen. Die Anwendungen kommunizieren über ihre ursprünglichen Protokolle, wobei spezifische Anwendungsprotokolle verwendet werden, wie etwa reduzierte Blockbefehle (RBC) für Festplattenlaufwerke, Druckerarbeitsgruppen (PWG) für Drucker oder Internetprotokolle (IP) für Netzwerke. Verschiedene Anwendungen können zu einer Zeit an einem gegebenen Knoten arbeiten. Jede Anwendung dekodiert Befehle, validiert Befehle und führt Befehle aus, die ihr übergeben wurden. Jede getrennte Anwendung hat eine getrennte Warteschlange, die durch eine Zahl auf der Grundlage, wie viele Anwendungen am laufen sind, identifiziert wird.
Der ORB-Hol-Task 255 funktioniert, um mehrere Befehls-ORBs von einem Initiator zu einer Zeit zurück zu gewinnen, wobei die verkapselten Befehle zu dem Anwendungstask 275 zur Ausführung durchgegeben werden. Für jedes neue Holen wird ein Systemaufruf durchgeführt, um die AMC-Blockadresse zu bestimmen, die das Holen anfordert. Diese Blockadresse wird dann in dem OMC-Block entsprechend zu dem veranlassenden Task gespeichert. Die ORB-Adresse wird von dem OMC-Block zurückgewonnen. Dann wird das Abwicklungsinterface 210 vorgesehen, um die Befehls-ORBs zu lesen und zurückzugeben. Falls die Daten ohne Fehler zurück kommen, wird ein AMC-Block erzeugt und in der AMC-Warteschlange platziert, wobei die zurückgewonnenen Daten zu dem passenden Anwendungstask gesendet werden. Abhängig davon, wie viele Initiatoren zugegen sind, kann der ORB-Hol-Task 255 die Gesamtzahl von ORBs in jedem Holen beschränken, um eine faire Schlichtung zur Verfügung zu stellen.
Der Befehls-ORB-Ausführungstask 245 stellt Datenübertragungsanfragen und Statusüberlieferungen im Namen des Anwendungstasks 275 zur Verfügung. Der Befehls-ORB-Ausführungstask 245 gewinnt den Befehl, den er auszuführen hat, von dem Befehlsnachrichtensteuerblock (CMC) wieder, der in einer CMC-Warteschlange durch die Abwicklungsschnittstelle 210 platziert wurde. Der Befehls-ORB-Ausführungstask 245 sieht die Abwicklungsschnittstelle 210 vor, um die Daten oder den Status, wie gerichtet, zu senden oder wieder zu gewinnen. Sobald fertig, weckt die Abwicklungsschnittstelle 210 den Befehls-ORB-Ausführungstask 245, der dann den bestimmten Anwendungstask 275, für welchen er arbeitet, den Status der ORB-Ausführung mitteilt oder die angeforderten Daten zur Verfügung stellt.
Der Hol-Managementtask 215 verarbeitet zwei spezielle Schreibanfragen. In beiden Fällen aktualisiert der Hol-Managementtask 215 ein Feld in einem OMC-Block.
Schließlich arbeitet der frei laufende Statustask 265, um ein Statussignal zu den Initiatoren an anderen Knoten zu senden, selbst wenn dies nicht gefordert wird. Dieser Task würde arbeiten, um z.B. die Initiatoren mitzuteilen, die vor der Rücksetzung des Knotens eingeloggt waren.
Ein Beispiel der 1394-Busarchitektur im Betrieb stellt ein weiteres Verständnis der Zusammenwirkung der Dienste und der Tasks zur Verfügung. Ein Beispiel, das mehrere bzw. verschiedene der Tasks verwendet, ist eine Tätigkeit zum Einloggen in Host bzw. Datenanbieter über einen Management-Login-ORB. Dies würde z.B. auftreten, wenn ein Drucker an den 1394-Bus angeschlossen wird. Unter Bezugnahme auf 3 beginnt das Login mit einem Initiator an einem nicht lokalen Knoten. Der Initiator sendet oder eines oder mehrere Datenpakete zu der Abwicklungsschnittstelle 210 an dem lokalen Knoten, wo er durch die Hardware empfangende Nische empfangen und dekodiert wird. Die Abwicklungsschnittstelle 210 dekodiert einen Abwicklungskode von dem Paket und dekodiert es, um zu sehen, dass der initiierende Task Daten anfordert, die bei einer Zieladresse einzuschreiben sind, die auf dem lokalen Knoten gefunden worden ist (Einloggen in den Host bzw. Datenanbieter). Dieser bestimmte Betrieb ist eine Schreib-Management-Mittel-Operation und verwendet zunächst den Management-Mittel-Task 225.
Die Abwicklungsschnittstelle 210 fragt einen freien MMC-Block von dem Kern 220 an, initialisiert den MMC-Block mit Daten, die aus dem empfangenen Datenpaket gelesen worden sind, und befördert sie in die Arbeitswarteschlange des Management-Mittel-Tasks 225. Falls ein Rückkehrkode, der zu der Abwicklungsschnittstelle 210 zurückgesandt wird, zeigt, dass dieser MMC-Block gegenwärtig an dem Kopf der Warteschlange ist, ist der Management-Mittel-Task 225 gegenwärtig nicht in Betrieb und muss gestartet werden. Die Abwicklungsschnittstelle 210 baut einen DMC-Block auf und ruft den Dispatcher 220 auf, um den Management-Mittel-Task 225 zu starten. Der Dispatcher 220 teilt dem Management-Mittel-Task 225 dann mit, dass er einen Eingang in seiner Warteschlange hat. Der Management-Mittel-Task 225 dekodiert den MMC-Block in seiner Warteschlange und die darin enthaltene Operation. Die Operation bzw. der Betrieb, der dekodiert wurde, teilt dem Management-Mittel-Task 225 mit, dass er den Management-ORB von dem Host bzw. dem Datenanbieter lesen muss. Dies enthält die Übermittlung von der Abwicklungsschnittstelle 210. Ein TMC-Block wird erzeugt, mit der Management-ORB-Adresse oder anderen Parametern initialisiert und in einer TMC-Warteschlangen angestellt. Der Management-Mittel-Task 225 aktualisiert einen Taskzustand in dem MMC-Block, wobei vorgetragen wird, dass er auf ein Management-ORB-Holen wartet. Falls ein Rückkehrkode anzeigt, dass der TMC-Block an dem Kopf der Warteschlange ist, muss die Abwicklungsschnittstelle 210 über den Dispatcher 220 gestartet werden. Nachdem sie die Ausführung beginnt, dekodiert die Abwicklungsschnittstelle 210 den TMC-Block, um zu erkennen, dass sie eine Übertragung vorsehen muss. Sie wird vorgesehen und ausgeführt.
Die Abwicklungsschnittstelle 210 empfängt den Management-ORB von dem Initiator. Die Abwicklungsschnittstelle 210 ruft dann den Management-Mittel-Task 225 mit dem Login-Befehl auf. Der Management-Mittel-Task 225 versucht, für den Initiator einzuloggen. Falls sämtliche Login-Kriterien erfüllt sind, fordert der Management-Mittel-Task 225 einen neuen OMC-Block an. Der OMC-Block wird dann mit passenden Daten initialisiert und eine Login-Antwort wird aufgebaut. Die Login-Antwort wird mit der Abwicklungsschnittstelle 210 vorgesehen, indem ein TMC-Block in einer der TMC-Warteschlangen angestellt wird, wobei dem Initiator mitgeteilt wird, dass das Einloggen erfolgreich war. Später wird ein Statusblock zu dem Initiator zurückgesandt, indem ein TMC-Block in einer der TMC-Warteschlangen angestellt wird. Nachdem der Statusblock gesandt ist, wird der ursprüngliche MMC-Block abgewiesen, zu dem Pool freier Speicherblöcke zurückgebracht und der Management-Mittel-Task 225 arbeitet an dem nächsthöchsten MMC-Block in seiner Warteschlange. Wie ein Fachmann im Stand der Technik erkennen wird, können beliebige Funktionen für ein beliebiges Protokoll, das als die Transportschicht 80 verwendet wird, in Tasks ausgebildet werden, die die Abwicklungsschnittstelle 210 aufrufen kann.
Als ein weiteres Beispiel zeigt 5 eine Ausführungsform nach der Erfindung, die ein Funktionssteuerprotokoll als ihre Transportschicht 80 verwendet. Man bemerke, dass die Abwicklungshardware 205, die Abwicklungsschnittstelle 210 und der Kern 220 die gleiche Funktion wie die in 3 gezeigte Ausführungsform haben. Ferner sind der serielle Busmanagementtask 235 und der Anwendungstask 275 auch ähnlich bzw. gleich zu der in 3 gezeigten Ausführungsform. Jedoch werden einige Tasks, wie etwa der Anwendungs-/FCP-Befehlsausführungstask 295 spezifisch für das verwendete Protokoll, in diesem Fall FCP, erzeugt. Der CSR-Managementtask 285 ist ein alternatives Verfahren, um die CSR-Dienste zu enthalten, die erforderlich sind, um einen 1394-Bus zu verwirklichen. In der in 3 gezeigten Ausführungsform werden diese Dienste durch den seriellen Busmanagementtask 235 gehandhabt.
Einige der möglichen Anwendungen und Protokolle zur Verwendung mit einem 1394-Bus sind in 6 gezeigt. Der 1394-Bus, der die Kommunikationssteuerung 200, wie hierin beschrieben, verwendet, ermöglicht es, nahezu beliebige Arten von peripheren Einrichtungen aneinander anzuschließen. In der 6 wird der 1394-Bus an dem unteren Teil bzw. Boden der Figur dargestellt und zeigt, dass er sowohl asynchrone als auch isochrone Fähigkeiten enthält. Die nächste Schicht über dem 1394-Bus zeigt Beispiele der Transportschicht 80, die in 2 gezeigt ist. Gezeigt sind ein SBP-2, FCP und SBP-2 gemeinsames isochrones Paketformat. Die nächste Schicht oberhalb der Transportschicht zeigt Beispiele der Anwendungs schicht 90, wie in 2 gezeigt. Gezeigt sind Protokolle eines oberen Niveaus, wie etwa MMC-2, das für Festplattenlaufwerke und digitale Videoplattenlaufwerke verwendet wird, PWG, ein Protokoll zur Verwendung mit Druckern, RBC, ein anderes Protokoll, das häufig mit Festplattenlaufwerken verwendet wird, und ein AV-Abwicklungssatz, der für Unterhaltungselektronikeinrichtungen verwendet wird. Als Nächstes werden oberhalb der Anwendungsschicht 90 die Einrichtungen gezeigt, die die Protokolle verwenden, die unterhalb von diesen aufgelistet sind, einschließlich Druckern, Festplattenlaufwerken, DVD-Spielern usw. Natürlich können andere periphere Einrichtungen als die hier aufgeführten peripheren Einrichtungen zu ihrem Vorteil den 1394-Bus verwenden, mit verschiedenen Anwendungen oder Transportprotokollen. Wie oben bemerkt, dehnt dies die Kompatibilität des 1394-Busses mit anderen Bussen aus.
Aus dem Voranstehenden ist es zu erkennen, dass, obwohl spezifische Ausführungsformen der Erfindung hierin zu Zwecken der Darstellung beschrieben worden sind, verschiedene Modifikationen vorgenommen werden können, ohne den Bereich der Erfindung zu verlassen. Demgemäß ist die Erfindung, ausgenommen durch die beigefügten Ansprüche, nicht beschränkt.
In dem obigen Verfahren kann mehr als ein Dienst oder Task zur gleichen Zeit an dem gleichen Knoten betrieben werden und die Services bzw. Dienste und Tasks arbeiten unabhängig voneinander. Ein Satz von Tasks bzw. Unterprogrammen kann so ausgewählt werden, dass irgendwelche Anforderungen eines Transportschichtprotokolls erfüllt werden können. Die Warteschlange, die formatierte Daten akzeptiert, ist mit mehr als einem der mehreren Dienste oder Tasks verknüpft.

Claims

Kommunikationssteuerung (200) an einem Knoten, angekoppelt an einen seriellen Bus (100), wobei die Steuerung aufweist: eine Abwicklungs- bzw. Durchführungsschnittstelle (210), die aufgebaut ist, um Datenpakete von dem Bus anzunehmen und Tätigkeiten nur in Reaktion auf Aufrufe von einem Task und in Reaktion auf Daten durchzuführen, die innerhalb der Datenpakete für einen isochronen bzw. zeitgleichen und asynchronen Datentransfer bzw. Datenübertragung enthalten sind; gekennzeichnet durch: einen Dispatcher bzw. eine Zuteilereinrichtung (220), der bzw. die aufgebaut ist, um Informationen zu empfangen, die ihm bzw. ihr zur Verfügung gestellt werden und Startbefehle nur in Reaktion auf Aufrufe von einem Task und auf die empfangenen Informationen ausgibt; mehrere getrennte unabhängige Tasks (215, 225, 235, 245, 255, 265, 275), die jeweils eine spezialisierte Funktion in Reaktion auf Daten, die zur Verfügung gestellt werden, durchführen; jeder planmäßige Task ist ausgeführt zu werden, wenn ihm Daten von der Abwicklungs- bzw. Durchführungsschnittstelle oder irgendeinem der anderen Tasks zur Verfügung gestellt werden; jeder Task ist aufgebaut, um auszuführen, bis sämtliche der ihm zur Verfügung gestellten Daten von ihm verbraucht bzw. verarbeitet sind; jeder Task wird ausgeführt, nachdem der Dispatcher bzw. die Zuteilereinrichtung einen Startbefehl für den bestimmten Task ausgibt, wobei der Startbefehl durch den Dispatcher bzw. Zuteiler nur ausgegeben wird, wenn der Dispatcher bzw. die Zuteilereinrichtung eine Anzeige von der Abwicklungs- bzw. Durchführungsschnittstelle oder einem anderen Task empfängt, die für den bestimmten Task Daten zur Verfügung stellt, die der bestimmte Task gegenwärtig nicht ausführt; und jeder Task ist aufgebaut, um in Konkurrenz zu und unabhängig von sämtlichen der anderen Tasks betrieben zu werden.
Steuerung nach Anspruch 1, die ferner zumindest eine Datenhalteschlange bzw. -warteschlange enthält, die mit jedem Task, der Abwicklungs- bzw. Durchführungsschnittstelle und dem Dispatcher bzw. der Zuteilereinrichtung verknüpft ist, wobei die Schlangen bzw. Warteschlangen aufgebaut sind, um Daten von der Abwicklungs- bzw. Durchführungsschnittstelle oder irgendeinem der anderen Tasks anzunehmen, wenn von dem Task, der Abwicklungs- bzw. Durchführungsschnittstelle oder dem Dispatcher bzw. der Zuteilereinrichtung gewünscht wird, durch die Abwicklungs- bzw. Durchführungsschnittstelle oder irgendeinen der Tasks angerufen bzw. aufgerufen zu werden.
Steuerung nach Anspruch 2, wobei die Daten, die in die Schlange bzw. Warteschlange aufgenommen sind, ein Nachrichtensteuerblock sind, der aufgebaut ist, um mit Daten, die für den jeweiligen Task der Schlange bzw. Warteschlange, den Dispatcher bzw. Zuteiler oder die Abwicklungs- bzw. Durchführungsschnittstelle bestimmt sind bzw. besonders sind, formatiert zu werden.
Steuerung nach Anspruch 1, wobei die Tasks aufgebaut sind, um Operationen durchzuführen, die durch das SBP-2-Protokoll benötigt werden.
Steuerung nach Anspruch 1, wobei: die Abwicklungs- bzw. Durchführungsschnittstelle eine Abwicklungs- bzw. Durchführungsschnittstellenschlange bzw. -warteschlangen hat; der Dispatcher bzw. die Zuteilereinrichtung eine Dispatcher- bzw. Zuteilereinrichtungsschlange bzw. -warteschlange hat, wobei der Dispatcher bzw. die Zuteilereinrichtung aufgebaut ist, um Informationen, die zu der Dispatcher- bzw. Zuteilereinrichtungsschlange bzw. -warteschlange gesandt worden sind, lediglich in Reaktion auf Anrufe bzw. Aufrufe von einem Task anzunehmen; einer oder mehrere der mehreren getrennten, unabhängigen Tasks haben jeweils ihre eigene Schlange bzw. Warteschlange, wobei jeder Task aufgebaut ist, um eine spezialisierte Funktion in Reaktion auf Daten durchzuführen, die von der jeweiligen Schlange bzw. Warteschlange erhalten bzw. gewonnen worden sind; jeder Task wird planmäßig ausgeführt, wenn Daten in seiner Schlange bzw. Warteschlange durch die Abwicklungs- bzw. Durchführungsschnittstelle oder irgendeinen der anderen Tasks platziert werden; jeder Task ist aufgebaut, Daten von dem Kopf seiner Schlange bzw. Warteschlange zu entfernen, wenn an den Daten nicht mehr gearbeitet bzw. aufgrund dieser operiert wird; und ein bestimmter Task wird ausgeführt, nachdem der Dispatcher bzw. die Zuteilereinrichtung einen Startbefehl für den bestimmten Task ausgibt, wobei der Startbefehl durch den Dispatcher bzw. die Zuteilereinrichtung nur ausgegeben wird, wenn der Dispatcher bzw. die Zuteilereinrichtung Daten in seiner Schlange bzw. Warteschlange platziert hat, die anzeigen, dass der bestimmte Task gegenwärtig nicht ausgeführt wird.
Steuerung nach Anspruch 5, wobei die Daten, die in den Schlangen bzw. Warteschlangen platziert sind, ein Nachrichtensteuerblock sind, der insbesondere für den Service oder den Task strukturiert ist, der auf ihm betrieben wird.
Steuerung nach Anspruch 2 oder Anspruch 6, wobei der Dispatcher bzw. die Zuteilereinrichtung aufgerufen wird, um einen Startbefehl auszugeben, falls einer der Nachrichtensteuerblöcke in einer der Schlangen bzw. Warteschlangen des Tasks platziert ist und der Nachrichtensteuerblock am Kopf der Schlange bzw. Warteschlange ist.
Steuerung nach Anspruch 1 oder Anspruch 5, die ferner einen Kern enthält und wobei mehrere Tasks zu der gleichen Zeit betrieben werden können, wobei ei nige der Operationen erfordern können, dass einer oder mehrere Tasks ausgesetzt werden, und wobei der Kern oder die anderen Tasks die Zeit verwenden können, die durch den ausgesetzten Task oder die ausgesetzten Tasks verwendet hätten werden können.
Steuerung nach Anspruch 5, wobei die Tasks aufgebaut sind, um Operationen durchzuführen, die durch das FCP/CMP-Protokoll gemäß dem Standard IEC 61883 erforderlich sind.
Steuerung nach Anspruch 5, wobei Tasks hinzugefügt, ersetzt bzw. ausgetauscht oder gelöscht werden können, um die Steuerung strukturiert sein zu lassen, um Funktionen durchzuführen, die durch irgendein Abwicklungs- bzw. Durchführungsschichtprotokoll gefordert werden.
Verfahren zur Kommunikation über einen seriellen Bus, das an einem Knoten an dem seriellen Bus aufweist: Informationspakete werden von dem seriellen Bus an einer Abwicklungs- bzw. Durchführungsschnittstelle empfangen; gekennzeichnet durch: die Pakete werden dekodiert und die Informationen werden analysiert, die empfangen worden sind, um zu bestimmen, ob eine Dienstleistung bzw. ein Service oder ein Task aufzurufen sind; falls eine Dienstleistung bzw. ein Service oder ein Task aufzurufen sind, werden die Daten formatiert, um in einer Schlange bzw. Warteschlange platziert zu werden, die mit einem oder mehreren von Dienstleistungen bzw. Services oder Tasks verbunden sind; die Daten werden in der jeweiligen Schlange oder Warteschlange des aufgerufenen Service bzw. Dienstleistung oder Task platziert; die Dienstleistung bzw. der Service oder der Task werden gestartet, falls keine Daten in der jeweiligen Schlange bzw. Warteschlange des aufgerufenen Service bzw. Dienstleistung oder Task bereits zugegen werden.
Verfahren nach Anspruch 11, wobei Daten, die in den Schlangen bzw. Warteschlangen zu platzieren sind, in der Form von Nachrichtensteuerblocks sind, wobei jeder Nachrichtensteuerblock spezifisch aufgebaut ist, um nur durch einen bestimmten der Tasks oder Services bzw. Dienstleistungen betrieben zu werden.
Verfahren nach Anspruch 12, wobei Formatieren eines Nachrichtensteuerblockes, der in einer der Schlangen bzw. Warteschlangen zu platzieren ist, aufweist: anfordern eines freien Nachrichtensteuerblockes von einem Kern; nachdem der Kern einen freien Nachrichtensteuerblock zur Verfügung gestellt hat, werden Daten, die für den Task oder Service bzw. Dienstleistung, dessen Aufruf gewünscht wird, in den Nachrichtensteuerblock übertragen; und der Nachrichtensteuerblock wird in die jeweilige Schlange bzw. Warteschlange des Tasks oder Service bzw. Dienstleistung versetzt.
Verfahren nach Anspruch 13, wobei das Starten des Service bzw. der Dienstleistung oder des Tasks aufweist: nach dem Versetzten des Nachrichtensteuerblockes in die jeweilige Schlange bzw. Warteschlange des Tasks oder der Dienstleistung bzw. des Service wird ein Rückkehrcode zu dem Task zurückgesandt, der den Nachrichtensteuerblock in die Schlange bzw. Warteschlange versetzt hat; der Rückkehrcode wird überprüft; und falls der Rückkehrcode anzeigt, dass der Nachrichtensteuerblock an dem Kopf einer Schlange bzw. Warteschlange platziert wurde, wird ein Dispatcher bzw. eine Zuteilereinrichtung aufgerufen, um den Task oder Service bzw. die Dienstleistung zu starten, dessen bzw. deren Aufruf gewünscht wird.
Elektronisch lesbares Medium an einem Knoten eines seriellen Busses (100) zum Speichern von programmierten Codes, die ein Verfahren für eine elektronische Einrichtung definieren, um über den seriellen Bus zu kommunizieren; wobei das Verfahren die Schritte aufweist: Pakete von Informationen werden von dem Bus an einem Empfangsraum bzw. -zwischenraum einer Abwicklungs- bzw. Durchführungsschnittstelle empfangen, die konfiguriert bzw. aufgebaut ist, um eine isochrone bzw. zeitgleiche und eine asynchrone Datenübertragung durchzuführen; gekennzeichnet durch: die Pakete werden dekodiert und die empfangenen Informationen werden nur in Reaktion auf Aufrufe von einem Task analysiert, um zu bestimmen, ob ein Task aufgerufen werden sollte; falls ein Task aufzurufen ist, werden Daten formatiert, die in einer Schlange bzw. Warteschlange zu platzieren sind, die mit zumindest einem von mehreren Tasks verknüpft ist, und mit den Daten wird eine Warteschlange in der jeweiligen Schlange bzw. Warteschlange des Tasks, der aufgerufen wird, gebildet; der Task wird gestartet, falls die Daten an dem Kopf der jeweiligen Warteschlange des Tasks, der aufgerufen wird, platziert wurden; und der Betrieb des aufgerufenen Tasks wird fortgesetzt, bis sämtliche Daten aus der Warteschlange entfernt sind.
Elektronisch lesbares Medium nach Anspruch 15, wobei mehr als ein Service bzw. als eine Dienstsleistung oder ein Task gleichzeitig und unabhängig voneinander betrieben werden können.
Elektronisch lesbares Medium nach Anspruch 15, wobei ein Satz von Tasks ausgewählt wird, so dass sämtliche Funktionen, die erforderlich sind, wenn das FCP/CMP-Protokoll gemäß dem Standard IEC 61883 als eine Transportschicht verwendet wird, durch die Tasks durchgeführt werden können.
Elektronisch lesbares Medium nach Anspruch 15, das ferner aufweist, dass, nachdem mit Daten eine Warteschlange in der jeweiligen Warteschlange gebildet worden ist, planmäßig gestartet wird, den Task auszuführen.
Elektronisch lesbares Medium nach Anspruch 15, wobei das Dekodieren der Pakete und das Analysieren der Informationen auch die Bestimmung enthält, ob ein Service bzw. eine Dienstleistung aufgerufen werden soll, und falls dem so ist, wird die Dienstleistung bzw. der Service aufgerufen.
Elektronisch lesbares Medium nach Anspruch 15, wobei der serielle Bus zu einem beliebigem der Standards IEEE 1394 passt.
Elektronisch lesbares Medium nach Anspruch 15, wobei Daten, die in den Warteschlangen zu platzieren sind, in der Form eines Nachrichtensteuerblockes sind, wobei jeder Nachrichtensteuerblock Daten enthält, die spezifisch durch einen der Tasks oder Services bzw. Dienstleistungen verwendet werden.
Verfahren nach Anspruch 12, wobei das Formatieren eines Nachrichtensteuerblockes, der in einer der Warteschlangen zu platzieren ist, aufweist: ein Befehl, um einen freien Nachrichtensteuerblock von einem Kern anzufordern, wird gesendet; wenn ein freier Nachrichtensteuerblock zur Verfügung gestellt wird, wird der Nachrichtensteuerblock mit Daten gefüllt, die für den Task oder Service bzw. Dienstleistung, deren Aufruf gewünscht ist, spezifisch sind; und mit dem Nachrichtensteuerblock wird eine Warteschlange in der jeweiligen Warteschlange des Tasks oder des Service bzw. der Dienstleistung gebildet.
Verfahren nach Anspruch 22, wobei das Starten des Service bzw. der Dienstleistung oder des Tasks aufweist: nachdem mit dem Nachrichtensteuerblock eine Warteschlange in der jeweiligen Warteschlange des Tasks oder des Services bzw. der Dienstleistung gebildet worden ist, wird ein Rückkehrcode zu dem die Warteschlange bildenden Task zurückgesandt; der Rückkehrcode wird geprüft; und falls der Rückkehrcode anzeigt, dass der aufgerufene Task oder Service bzw. Dienstleistung nicht bereits gestartet war, wird ein Dispatcher bzw. eine Zuteilereinrichtung aufgerufen, um den Task oder Service bzw. die Dienstleistung, dessen bzw. deren Aufruf gewünscht wird, zu starten.