DE69723726T2

DE69723726T2 - Anwendungsprogrammierungsschnittstelle für Datenübertragung und Busverwaltung einer Busstruktur

Info

Publication number: DE69723726T2
Application number: DE69723726T
Authority: DE
Inventors: Scott D. Los Gatos Smyers; Bruce Woodside Fairman
Original assignee: Sony Electronics Inc
Current assignee: Sony Electronics Inc
Priority date: 1996-02-02
Filing date: 1997-01-29
Publication date: 2004-04-22
Anticipated expiration: 2017-01-30
Also published as: US5991520A; ATE245837T1; KR100472908B1; CA2244713A1; EP1056016A2; KR19990082226A; JP3993893B2; EP2284713A3; DE69723726D1; DE69704344D1; CA2244713C; US6243783B1; EP0952526B1; WO1997028504A1; EP0952526A2; JP2000510659A; ATE199987T1; DE69704344T2; EP0952526A3; EP0877983A1

Description

Gebiet der Technik
Die vorliegende Erfindung betrifft das Gebiet des Vorsehens einer Schnittstelle für Anwendungen zur Kommunikation über eine Busstruktur. Im Besonderen betrifft die vorliegende Erfindung das Gebiet der Steuerung der Busverwaltung und der Datenübertragungsoperationen zwischen Anwendungen über eine Busstruktur in asynchronen und isochronen Formaten.
Die vorliegende Erfindung ist eine Ausscheidungsanmeldung der europäischen Patentanmeldung mit der Nummer 97904203.3.
Stand der Technik
Der IEEE 1394 Standard, "P1394 Standard für einen seriellen Hochleistungsbus", Entwurf 8.01v1, 16. Juni 1995, ist ein internationaler Standard zur Implementierung einer kostengünstigen seriellen Hochgeschwindigkeits-Busarchitektur, die Datenübertragungen sowohl im asynchronen als auch im isochronen Format unterstützt. Isochrone Datenübertragungen sind Übertragungen in Echtzeit, die derart erfolgen, dass die Zeitintervalle zwischen signifikanten Momenten an den sendenden und empfangenden Anwendungen die gleiche Dauer aufweisen. Jedes isochron übertragene Datenpaket wird innerhalb seines eigenen Zeitraums übertragen. Ein Beispiel für eine ideale Anwendung für die isochrone Datenübertragung ist von einem Videorekorder zu einem Fernseher. Der Videorekorder zeichnet Bilder und Ton auf und speichert die Daten in diskreten Blöcken oder Paketen. Der Videorekorder überträgt später jedes Paket, welches das das über einen begrenzten Zeitraum aufgezeichnete Bild und den Ton während dieses Zeitraums zur Anzeige auf einem Fernseher darstellt. Die Busarchitektur des IEEE 1394 Standards sieht mehrere Kanäle für die isochrone Datenübertragung zwischen Anwendungen vor. Eine Kanalnummer mit sechs Bit wird mit den Daten übertragen, um den Empfang durch die entsprechende Anwendung zu gewährleisten. Dies ermöglicht es, dass mehrere Anwendungen gleichzeitig isochrone Daten über die Busstruktur übertragen. Asynchrone Übertragungen sind traditionelle Datenübertragungsoperationen, die sobald wie möglich ausgeführt werden, und wobei eine Datenmenge von einer Quelle an ein Ziel übertragen wird.
Der IEEE 1394 Standard sieht einen seriellen Hochgeschwindigkeitsbus zur Verbindung digitaler Vorrichtungen miteinander vor, wodurch eine universelle E/A-Verbindung geschaffen wird. Der IEEE 1394 Standard definiert eine digitale Schnittstelle für die Anwendungen, wodurch es nicht mehr erforderlich ist, dass eine Anwendung digitale Daten in analoge Daten umwandelt, bevor diese über den Bus übertragen werden. Dementsprechend empfängt die empfangende Anwendung digitale Daten von dem Bus und keine analogen Daten, und somit muss sie keine analogen Daten in digitale Daten umwandeln. Das gemäß dem IEEE 1394 Standard benötigte Kabel ist im Vergleich zu den für derartige Vorrichtungen ansonsten verwendeten größeren Kabeln verhältnismäßig klein bzw. dünn. Vorrichtungen bzw. Geräte können bei aktivem Bus einem IEEE 1394 Bus hinzugefügt oder von diesem entfernt werden. Wenn eine Vorrichtung auf diese Weise hinzugefügt oder entfernt wird, konfiguriert sich der Bus automatisch neu für die Datenübermittlung zwischen den dann existierenden Knoten. Ein Knoten ist eine logische Einheit mit einer eindeutigen Adresse an der Busstruktur. Jeder Knoten sieht ein Identifikations-ROM, einen standardisierten Satz von Steuerregistern und einen eigenen Adressraum auf.
Der IEEE 1394 Standard definiert ein Protokoll gemäß der Veranschaulichung in der Abbildung aus 1. Dieses Protokoll weist einen seriellen Busmanagementblock 10 auf, der mit einer Transaktionsschicht 12, einer Verknüpfungsschicht 14 und einer physikalischen Schicht 16 gekoppelt ist. Die physikalische Schicht 16 sieht die elektrische und mechanische Verbindung zwischen einer Vorrichtung oder Anwendung und dem IEEE 1394 Kabel vor. Die physikalische Schicht 16 sieht ferner eine Arbitrierung vor, um zu gewährleisten, dass alle mit dem IEEE 1394 Bus gekoppelten Vorrichtungen Zugriff auf den Bus sowie die tatsächliche Datenübertragung und den Datenempfang. Die Verknüpfungsschicht 14 sieht einen Datenpaketzustelldienst sowohl für den asynchronen als auch den isochronen Datenpakettransport vor. Dies unterstützt sowohl den asynchronen Datentransport unter Verwendung eines Quittungsprotokolls als auch den isochronen Datentransport, wobei ein garantiertes Bandbreitenprotokoll in Echtzeit für eine Just-in-Time-Datenzustellung vorgesehen wird. Die Transaktionsschicht 12 unterstützt die erforderlichen Befehle für die Durchführung asynchroner Datenübertragungen, einschließlich Lesen, Schreiben und Sperren. Der serielle Busmanagementblock 10 weist einen isochronen Ressourcenmanager zur Verwaltung isochroner Datenübertragungen auf. Der serielle Busmanagementblock 10 sorgt auch für die Konfigurationssteuerung des seriellen Busses insgesamt vor, und zwar in Form der Optimierung der Zuteilungszeitsteuerung, der Gewährleistung der entsprechenden elektrischen Leistung für alle Vorrichtungen an dem Bus, der Zuweisung des Zyklusmasters, der Zuweisung isochroner Kanal- und Bandbreitenressourcen sowie der grundlegenden Fehlerbenachrichtigung.
Eine Anwendungsprogrammierschnittstelle (API) für Anwendungen unter Verwendung des seriellen Busses gemäß dem IEEE 1394 Standards wurde von Skipstone entwickelt, um es einer Anwendung zu ermöglichen, den IEEE 1394 Bus für Datenübertragungen zu nutzen. Skipstone liefert in Verbindung mit deren API ein Handbuch mit dem Titel "The SerialSoft IEEE 1394 Developer Toolkit", das von Skipstone, Inc., 3925 West Braker Lane, #425, Austin, Texas 78759, USA, erhältlich ist. Skipstone definiert die eigene API als eine Sammlung von Programmaufrufen, welche die Anwendung verwendet, um die Daten zu verwalten, die über einen IEEE 1394 Bus an eine Vorrichtung geschrieben oder von einer Vorrichtung erhalten werden. Zur Initialisierung einer isochronen Übertragung können mehrere asynchrone Datenübertragungen erforderlich sein, um die Anwendungen zu konfigurieren und um den speziellen Kanal zu bestimmen, der für die Datenübertragung verwendet wird. Nachdem der Kanal bestimmt worden ist, werden Puffer an der übermittelnden bzw. sendenden Anwendung zum Speichern der Daten vor der Übertragung und an der empfangenden Anwendung zum Speichern der Daten vor deren Verarbeitung verwendet. Bei einer sendenden Anwendung verwaltet die API von Skipstone aktiv die Datenübertragung von dem entsprechenden Abschnitt des entsprechenden Puffers zu der Busstruktur über den entsprechenden Zeitraum. In einer empfangenden Anwendung verwaltet die API von Skipstone aktiv den Datenempfang von der Busstruktur, wobei die Daten in dem entsprechenden Abschnitt des entsprechenden Puffers gespeichert und danach über den entsprechenden Zeitraum verarbeitet werden.
Während asynchronen Datenübertragungen verwaltet die Skipstone API aktiv die erforderlichen Transaktionen für die vollständige Ausführung der Datenübertragung. Während einer asynchronen eingehenden Schreibtransaktion sieht die Anwendungen einen Puffer an die API vor, abgebildet auf einen bestimmten Bereich des 1394 Busadressraums. Wenn Schreibtransaktionen an der API ankommen, werden ihre Daten in den Puffer geschrieben. Während einer asynchronen eingehenden Lesetransaktion ist die Anwendung dafür zuständig, sicherzustellen, dass der Puffer nützliche Informationen enthält. Der 1394 Bus liest danach die Daten an der angeforderten Adresse aus dem Puffer, wenn die Lesetransaktion ankommt. Die API von Skipstone verwaltet und erzeugt jede erforderliche Transaktion für Schreib- und Lesetransaktionen. Wenn ein Datenblock mit einer Größe, die mehrere Transaktionen voraussetzt, zum Beispiel zu der Anwendung übertragen wird, erfordert es die API von Skipstone, dass die Anwendung jede erforderliche 1394 Transaktion beschreibt, die erforderlich ist, um die Übertragung des Datenblocks auszuführen. Dies verbraucht signifikante Verwaltungsdaten durch den Prozessor der Anwendung und erfordert die volle Aufmerksamkeit der API während einer asynchronen Datenübertragungsoperation.
Die API von Skipstone unterstützt isochrone Datenübertragungsoperationen auf die gleiche Art und Weise. Im Besonderen muss die Anwendung jedes isochrone Paket für die Skipstone API beschreiben. Die API von Skipstone überträgt danach jedes Paket zum entsprechenden Zeitpunkt. Dies erfordert signifikante Verwaltungsdaten und verhindert dadurch die effiziente Verarbeitung der isochronen Daten durch die Anwendung.
Benötigt wird eine API, die isochrone Übertragungsfunktionen der Busstruktur gemäß dem IEEE 1394 Standard sehr effizient implementiert, wodurch ein hohes Maß der Hardware-Automatisierung ermöglicht wird, wenn dies von der Anwendung benötigt wird.
Zusammenfassung der Erfindung
Vorgesehen ist gemäß einem ersten Aspekt der vorliegenden Erfindung ein Verfahren gemäß dem gegenständlichen Anspruch 1, und gemäß einem zweiten Aspekt der vorliegenden Erfindung ist eine Schnittstelle gemäß dem gegenständlichen Anspruch 7 vorgesehen.
Eine Anwendungsprogrammierschnittstelle implementiert und verwaltet isochrone Übertragungsvorgänge zwischen einer Anwendung und einer Busstruktur. Während einer isochronen Datenübertragung wird ein Pufferverwaltungsschema zur Verwaltung einer verknüpften Liste von Datenpufferdeskriptoren verwendet, die durch die Anwendung vorgesehen wird. Die verknüpfte Liste der Pufferdeskriptoren wird von der API verwaltet, um den ununterbrochenen Fluss des ununterbrochenen Stroms isochroner Daten zu gewährleisten. Die verknüpfte Deskriptorenliste kann eine Zirkularliste von Puffern bilden und einen Vorwärtszeiger auf den nächsten Puffer in der Liste und einen Rückwärtszeiger auf den vorherigen Puffer in der Liste für jeden Puffer aufweisen. Die verknüpfte Deskriptorenliste kann auch eine lineare Liste bilden, an welche oder von welcher die Anwendung zusätzliche Puffer anhängen oder entfernen kann. Während isochronen Datenübertragungen sieht die API eine Implementierung eines Resynchronisierungsereignisses in dem Datenstrom vor, wobei eine Resynchronisierung durch die Anwendung auf einen bestimmten Punkt in den Daten ermöglicht wird. Es wird auch eine Implementierung für eine Rückrufroutine für jeden Puffer in der Liste vorgesehen, wobei die Anwendung an einem vorbestimmten Punkt während der Datenübertragung aufgerufen wird.
Kurze Beschreibung der Zeichnungen
Es zeigen:
1 ein durch den IEEE 1394 Standard definiertes Protokoll;
2 ein schematisches Blockdiagramm einer Anwendungsprogrammierschnittstelle in einem System, das eine Busstruktur aufweist;
3 ein System, das eine Videokamera 50, einen Videokassettenrekorder 52 und einen Computer 54 aufweist, die über Ein-Ausgabe-Busse (E/A-Busse) 56 und 58 verbunden sind;
4 ein Blockdiagramm eines Hardwaresystems, das sich in jedem System zur Implementierung der erfindungsgemäßen Anwendungsprogrammierschnittstelle befindet;
5 eine Liste von Pufferdeskriptoren, die den Puffern entspricht, die einer API 20 durch eine Anwendung zugewiesen werden; und
6 ein Flussdiagramm einer API-Pufferverarbeitung für isochrone Sende- und Empfangsoperationen.
Genaue Beschreibung des bevorzugten Ausführungsbeispiels
Die Abbildung aus 3 veranschaulicht ein System, das eine Videokamera 50, einen Videokassettenrekorder 52 und einen Computer 54 aufweist, die über Ein-Ausgabe-Busse (E/A-Busse) 56 und 58 verbunden sind. Der E/A-Bus 56 koppelt die Videokamera 50 mit dem Videokassettenrekorder 52, so dass die Videokamera 50 Daten zur Aufzeichnung an den Videokassettenrekorder 52 senden kann. Der E/A-Bus 58 koppelt den Videokassettenrekorder 52 mit dem Computer 54, so dass der Videokassettenrekorder 52 Daten zur Anzeige an den Computer 54 senden kann.
Eine erfindungsgemäße Anwendungsprogrammierschnittstelle (API) kann in jedem oder in allen angeschlossenen Teilsystemen implementiert werden, einschließlich der Videokamera 50, des Videokassettenrekorders 52 oder des Computers 54, um die Datenübertragungsoperationen zu steuern, die über die Busstrukturen 56 und 58 übermittelt werden. In dem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung handelt es sich bei den Busstrukturen 56 und 58 um Kabel gemäß dem IEEE 1394 Standard.
Die Abbildung aus 4 veranschaulicht ein Blockdiagramm eines in jedem System vorhandenen Hardwaresystems zur Implementierung der erfindungsgemäßen Anwendungsprogrammierschnittstelle. In dem in der Abbildung aus 4 veranschaulichten Hardwaresystem ist eine gedruckte Schaltung bzw. eine Leiterplatte 60 mit einer Benutzer-Schnittstelle 70 gekoppelt. Die Leiterplatte 60 weist eine Zentraleinheit (CPU) 62 auf, die durch den Systembus 68 mit einem Systemspeicher 64 und einer E/A-Busschnittstelle 66 gekoppelt ist. Die Benutzerschnittstelle 70 ist ebenfalls mit dem Systembus 68 gekoppelt. Die Benutzerschnittstelle 70 ist von dem Teilsystem abhängig, wobei sie eine Tastatur, eine Anzeige oder andere E/A-Vorrichtungen zur Kommunikation mit einem Benutzer bzw. Anwender des Teilsystems aufweisen kann.
Zur Implementierung der erfindungsgemäßen Anwendungsprogrammierschnittstelle weist jedes der Teilsysteme einschließlich der Videokamera 50, des Videokassettenrekorders 52 und des Computers 54 ein Hardwaresystem auf, wie etwa das in der Abbildung aus 4 veranschaulichte System. Die CPU 62 in jeder dieser Vorrichtungen wird zur Ausführung der Anwendungsprogrammierungsanweisungen verwendet. Die erfindungsgemäße API verwaltet dabei sowohl isochrone als auch asynchrone Datenübertragungsoperationen zwischen dem residenten Teilsystem und einem der anderen Teilsysteme über einen entsprechenden Bus der Busse 56 und 58.
Eine erfindungsgemäße Anwendungsprogrammierschnittstelle implementiert isochrone und asynchrone Datenübertragungen zu und von einer Anwendung über eine Busstruktur. Der hierin verwendete Begriff Anwendung betrifft entweder eine Anwendung oder einen Gerätetreiber. Bei der Busstruktur, über welche die Datenübertragungsoperationen ausgeführt werden, handelt es sich vorzugsweise um eine Busstruktur gemäß dem IEEE 1394 Standard. Für den Fachmann ist es jedoch erkennbar, dass die erfindungsgemäße Anwendungsprogrammierschnittstelle auch für einen Einsatz bei der Verwaltung von Datenübertragungen über andersartige Busstrukturen angewandt werden kann. Die Anwendungsprogrammierschnittstelle bietet die Möglichkeit zur Übertragung jeder Datenmenge zwischen einem durch die Anwendung vorgesehenen lokalen Datenpuffer und einem Adressraum über die Busstruktur unter Verwendung einer oder mehrerer asynchroner Transaktionen. Wenn eine asynchrone Übertragung eines Datenblocks eingeleitet wird, sendet die Anwendungsprogrammierschnittstelle einen Befehl an einen automatischen Transaktionsgenerator. Der automatische Transaktionsgenerator erzeugt daraufhin automatisch die erforderlichen Lese- oder Schreibtransaktionen für die asynchrone Übertragung des ganzen Datenblocks ohne direkte Prozessorsteuerung oder ohne eine erforderliche Überwachung durch die Anwendungsprogrammierschnittstelle.
Die Anwendungsprogrammierschnittstelle kann ferner Daten zwischen der Anwendung und einem anderen Knoten an dem Bus isochron über einen dedizierten Kanal übertragen. Während einer isochronen Datenübertragung wird ein Pufferverwaltungsschema zur Verwaltung der Datenpuffer in der Anwendung verwendet. Die Anwendung kann abhängig von der Art und der Menge der zu übertragenden Daten einen, mehr als einen oder eine verknüpfte Liste von Puffern verwenden. Eine verknüpfte Liste von Pufferdeskriptoren, die auf die Puffer zeigen, wird von der API verwaltet, um den ununterbrochenen Fluss des ununterbrochenen Stroms isochroner Daten zu gewährleisten. Diese verknüpfte Deskriptorenliste kann eine lineare oder zirkulare Pufferliste implementieren und weist einen Vorwärtszeiger auf den Deskriptor für den nächsten Puffer in der Liste und einen Rückwärtszeiger auf den Deskriptor für den vorherigen Puffer in der Liste für jeden Puffer auf. Wenn eine lineare Liste implementiert wird, kann die Anwendung dynamisch Puffer an die Liste anhängen oder bestehende Puffer von der Liste entfernen, sofern dies für dei Datenverarbeitung erforderlich ist.
Während einer isochronen Datenübertragung sieht die erfindungsgemäße Anwendungsprogrammierschnittstelle eine Implementierung eines Resynchronisierungsereignisses in dem Datenstrom vor, wobei die Resynchronisierung mit einem bestimmten Punkt in den Daten ermöglicht wird. Die Implementierung für eine Rückrufroutine für jeden Puffer ist ebenfalls vorgesehen, wobei die Anwendung an einem bestimmten vorbestimmten Punkt während der Datenübertragungsoperation aufgerufen wird. Sowohl das Resynchronisierungsereignis als auch die Rückrufroutine werden von dem IEEE 1394 Standard unterstützt.
Die erfindungsgemäße Anwendungsprogrammierschnittstelle kann ferner bei Bedarf Busverwaltungsoperationen über die Busstruktur ausführen. Zu derartigen Busverwaltungsoperationen zählen die bedarfsweise Zuweisung und Aufhebung von Zuweisungen isochroner Kanalnummern sowie die Zuweisung und die Aufhebung von Zuweisungen isochroner Bandbreite. Wenn es sich bei der Busstruktur um eine Busstruktur gemäß dem IEEE 1394 Standard handelt, führt die Anwendungsprogrammierschnittstelle auch weitere Busverwaltungsoperationen aus, die gemäß dem IEEE 1394 Standard erforderlich sind.
Die Abbildung aus 2 veranschaulicht ein schematisches Blockdiagramm einer erfindungsgemäßen Anwendungsprogrammierschnittstelle in einem System, das eine Busstruktur aufweist. Die API 20 dient als Schnittstelle zwischen den Anwendungen 22 und 24 und der Busstruktur 28, wobei sie die Datenübertragung zwischen der Busstruktur 28 und den Anwendungen 22 und 24 verwaltet. Wie dies in der Abbildung aus 2 veranschaulicht ist, kann eine einzelne API 20 als Schnittstelle zwischen mehreren Anwendungen und der Busstruktur 28 dienen. In dem in der Abbildung aus 3 veranschaulichten Computersystem 54 kann eine einzelne API 20 zum Beispiel als eine Schnittstelle zwischen einer oder mehreren Anwendungen fungieren, die durch das Computersystem 54 ausgeführt werden.
Eine Hardware- und physikalische Schnittstelle 26 ist zwischen der API 20 und der Busstruktur 28 vorgesehen. Die Hardware- und physikalische Schnittstelle 26 weist einen automatischen Transaktionsgenerator 38 zur automatischen Erzeugung der erforderlichen Transaktionen zur Ausführung einer asynchronen Datenübertragung zwischen einer der Anwendungen 22 oder 24 und einem anderen Knoten an der Busstruktur 28 auf. Die Hardware- und physikalische Schnittstelle 26 weist ferner eine Busschnittstelle 40 zur Überwachung und Verwaltung des Datenflusses zu und von der Busstruktur 28 auf. Die Hardware- und physikalische Schnittstelle 26 ist mit einer Gruppe von Speicherpuffern 30 dargestellt, die durch die API 20 gesteuert werden. Die Gruppe der Speicherpuffer 30 weist die Speicherpuffer 32, 34 und 36 auf. Wie dies nachstehend im Text beschrieben ist, werden die Speicherpuffer 32, 34 und 36 durch die Anwendung 22 für die API 20 zur Verwendung der Aufrechterhaltung isochroner Datenübertragungen zu und von der Anwendung 22 reserviert.
Isochrone Datenübertragungen
Zur Initialisierung einer isochronen Datenübertragungsoperation fordert eine Anwendung zuerst einen isochronen Kanal von der API 20 an. Die Anwendung kann entweder eine bestimmte Kanalnummer oder jede aktuell verfügbare Kanalnummer anfordern. Die API 20 ermittelt danach einen Kanal für die Isochrone Übertragung gemäß den Anforderungen des IEEE 1394 Standards. Der IEEE 1394 Standard unterstützt eine Kanalnummer von sechs Bit, die mit einem Datenstrom über die Busstruktur 28 gesendet wird. Nachdem ein Kanal für die Isochrone Datenübertragung zwischen einer Anwendung und einem anderen Knoten an der Busstruktur 28 zugewiesen worden ist, können keine anderen Knoten diese bestimmte Kanalnummer verwenden. Nachdem ein Kanal zugewiesen worden ist, müssen die Datenpuffer durch die Anwendung der API 20 zur Verwendung für die Datenübertragung zugewiesen werden.
Die API 20 ermöglicht es der Anwendung, einen, mehr als einen oder eine Liste von Datenpuffern zur Verwendung für den Empfang oder das Senden des isochronen Datenstroms zuzuweisen. Jeder der API 20 zugewiesene Puffer kann zusammenhängend oder unterteilt sowie logisch oder physisch sein. Die Liste der Datenpuffer kann zirkular oder linear sein. Wenn der API 20 eine lineare Liste von Datenpuffern zugeordnet ist, kann die Anwendung 22 gemäß den jeweiligen Anforderungen für die Datenverarbeitung der Liste zusätzliche Puffer hinzufügen oder Puffer von der Liste entfernen.
In dem in der Abbildung aus 2 veranschaulichten System weist die Anwendung 22 drei zugewiesene Puffer 30 auf, darunter die Puffer 32, 34 und 36 für die API für isochrone Datenübertragungen. Der Anwendung ist ferner eine verknüpfte Liste von drei Pufferdeskriptoren für die API zugewiesen, mit je einem Deskriptor für jeden der Puffer 32, 34 und 36. Die API 20 unterhält einen Pufferdeskriptor für jeden Puffer in der verknüpften Liste und verwaltet den Strom isochroner Daten zwischen der Anwendung, den zugewiesenen Puffern und der Busstruktur 28. In der von der API 20 verwalteten Liste von Deskriptoren wird jeder Puffer durch einen Pufferdeskriptor dargestellt, einschließlich eines Vorwärtszeigers auf den Deskriptor für den nächsten Puffer in der Liste und eines Rückwärtszeigers auf den Deskriptor für den vorherigen Puffer in der Liste. Die Abbildung aus 5 veranschaulicht eine Liste von Pufferdeskriptoren, die den Puffern entsprechen, die einer API 20 durch eine Anwendung zugewiesen sind. Jeder der Pufferdeskriptoren 1-n entspricht einem Speicherpuffer 1-n. Im Besonderen entspricht der Pufferdeskriptor 80 dem Speicherpuffer 84, und der Pufferdeskriptor 82 entspricht dem Speicherpuffer 86.
Die Pufferdeskriptoren weisen jeweils eine Adresse und Länge des entsprechenden Puffers auf. Der Pufferdeskriptor weist ferner eine Rückrufausführungsroutine zum Aufruf nach dem Füllen oder Leeren des Puffers auf, abhängig jeweils von der Richtung der aktuellen Datenübertragungsoperation. Die Pufferdeskriptoren weisen ferner ein optionales Synchronisierungsereignisfeld auf, das durch die Anwendung programmiert wird und der Synchronisierung des Puffers mit einem bestimmten Ereignis oder Zeitpunkt entspricht. Im besonderen umfasst der Pufferdeskriptor 80, der dem Speicherpuffer 84 entspricht, eine Adresse 80a und eine Länge 80b für den Speicherpuffer 84. Eine Ausführungsroutine 80c und ein Synchronisierungsereignis 80d sind bei Bedarf ebenfalls vorhanden.
Dieser Einsatz der Pufferdeskriptoren und Speicherpuffer ermöglicht einer Anwendung unter Verwendung der erfindungsgemäßen API eine hohe Flexibilität, da die Deskriptoren, Puffer, Ausführungsroutinen und Synchronisierungsereignisse alle durch die Anwendung gemäß den jeweiligen speziellen Anforderungen bestimmt werden. Bei einer Anwendung, die in einer digitalen Videokamera ausgeführt wird, die Daten isochron an einen digitalen Videomonitor überträgt, werden zum Beispiel Daten in Speicherpuffer geladen, für welche die API Pufferdeskriptoren verwaltet. Die API verwaltet danach die Übertragung jedes Datenpakets von den Puffern zu dem Videomonitor. Die Videokamera kann eine zweifache Komprimierungsfunktion in der vertikalen Richtung dadurch implementieren, dass Deskriptorenpaare auf den gleichen Speicherpuffer zeigen. Das heißt, die Deskriptoren 1 und 2 zeigen auf den Speicherpuffer 1, die Deskriptoren 3 und 4 zeigen auf den Speicherpuffer 2 und so weiter. Eine Ausführungsroutine in dem zweiten Deskriptor jedes Paares teilt dem Videomonitor mit, dass die Daten in dem Speicherpuffer zum Auslesen bereit sind. Dies bedeutet, dass während der Ausgabe der ersten und zweiten Abtastzeilendaten durch die Videokamera die zweite Abtastzeilendaten die ersten Abtastzeilendaten in dem Speicherpuffer mit den zweiten Abtastzeilendaten überschreiben. Der Videomonitor liest den Speicherpuffer erst nachdem die zweite Abtastzeile geschrieben worden ist, so dass der Monitor die ersten Abtastzeilendaten nie zu Gesicht bekommt. Auf diese Weise wird jede zweite Abtastzeile übersprungen.
Die Deskriptoren ermöglichen eine zirkulare Liste, wodurch der ununterbrochene Datenfluss zu oder von den Puffern 32, 34 und 36 aufrechterhalten werden kann. Während einer isochronen Datenübertragung von der Anwendung 22 zu einem anderen Knoten entlang der Busstruktur 28 füllt die Anwendung 22 wiederum die Puffer 32, 34 und 36 mit den Daten. Die API 20 verwaltet daraufhin die Datenübertragung von dem entsprechenden Puffer zu der Busstruktur 28 während einem entsprechend geeigneten Zeitraum. Die Busschnittstelle 40 in der Hardware- und physischen Schnittstelle 26 steuert die Datenübertragung von den Puffern 32, 34 und 36 zu der Busstruktur 28. Während einer isochronen Datenübertragung von einem anderen Knoten entlang der Busstruktur 28 zu der Anwendung 22 verwaltet die API 20 die Datenübertragung von der Busstruktur 28 über die Busschnittstelle 40 zu dem entsprechenden Puffer 32, 34 und 36. Wenn ein zugewiesener Puffer gefüllt ist, werden die Daten in dem nächsten Puffer in der verknüpften Liste gespeichert. Die Anwendung 22 liest danach während dem entsprechenden Zeitraum die Daten aus dem entsprechenden Puffer 32, 34 oder 36. Sobald die Anwendung 22 die Daten ganz aus dem Puffer gelesen hat, wird der Puffer wieder der API 20 zur Verfügung gestellt und die Anwendung 22 verarbeitet die Daten von dem nächsten Puffer.
Die Pufferdeskriptoren implementieren auch eine lineare Liste von Puffern, so dass die Anwendung je nach Bedarf für die Vollendung der Datenübertragungsoperation Puffer der API 20 zuweisen oder von dieser entfernen kann. Wenn die Anwendung zum Beispiel während einer isochronen Empfangsoperation mit der Verarbeitung jedes Puffers fertig ist, kann sie diesen wieder der API für den Empfang von mehr Daten zuweisen. Wenn dementsprechend zusätzliche Puffer erforderlich sind, um eine Datenübertragungsoperation auszuführen, kann die Anwendung der API mehr Puffer zuweisen.
Die API 20 führt ein Resynchronisierungsereignis und/oder eine Rückrufroutine während der Übertragung isochroner Daten aus, wenn dies von der Anwendung 22 verlangt wird. Ein Resynchronisierungsereignis ermöglicht die Resynchronisierung durch die Anwendung au einen vorbestimmten speziellen Zeitpunkt innerhalb der Daten während der Übertragung. Da die Daten isochron übertragen werden, synchronisiert das Resynchronisierungsereignis auch die Anwendung auf einen entsprechenden Zeitpunkt im Verhältnis zu dem Datenfluss. Die Übertragung von Videodaten ist ein ideales Beispiel für die Implementierung eines Resynchronisierungsereignisses. Während der Übertragung von Videodaten von einer Anwendung wie etwa einem Videorekorder werden die Daten in Blöcken übertragen, welche die erforderlichen Daten zum Anzeigen einer horizontalen Zeile auf einem Monitor oder Fernseher darstellen. Nach dem Anzeigen jeder horizontalen Zeile muss sich der Monitor selbst zurücksetzen, so dass er zum Anzeigen der nächsten horizontalen Zeile bereit ist. Ein Resynchronisierungsereignis kann von dem Monitor am ende der Daten jeder horizontalen Zeile eingesetzt werden, so dass sich der Monitor selbst auf den Anfang der nächsten horizontalen Zeile resynchronisieren kann.
In dem bevorzugten Ausführungsbeispiel der erfindungsgemäßen API kann eine isochrone Operation synchronisiert oder zur unverzüglichen Ausführung terminiert werden, und zwar zu einer bestimmten Buszeit, wenn ein spezieller Wert in dem Header des isochronen Datenblockpaket erscheint oder wenn isochrone Daten an einem speziellen Kanal des Busses für Startoperationen erscheint oder an einem bestimmten Kanal des Busses für Stoppoperationen enden.
Jeder der API 20 zugewiesene Puffer kann ein Resynchronisierungsereignis und eine Rückrufroutine aufweisen. Eine Rückrufroutine kann während der Übertragung von Videodaten am ende der Übertragung eines Datenblocks eingesetzt werden, der ein Bild darstellt. Ein Monitor oder ein Fernsehgerät gruppiert horizontale Zeilen in einem Bild und setzt sich selbst am Ende jedes Bilds auf das obere Ende des Bildschirms zurück, bereit für den Beginn des nächsten Bilds. Danach kann eine Rückrufroutine am Ende des jedes Bild darstellenden Datenstroms verwendet werden. Ein derartiges Schema ermöglicht es, dass ein Puffer mit den Daten gefüllt werden kann, die ein Videobild von einer Quelle darstellen, die mit der Busstruktur 28 gekoppelt ist. Nachdem die das Videobild darstellenden Daten übertragen worden sind kann die Rückrufroutine verwendet werden, um der Anwendung mitzuteilen, dass die das nächste bild darstellenden Daten übertragen worden sind und zur Verarbeitung zur Verfügung stehen. Die Anwendung kann die Daten für dieses Datenbild daraufhin verarbeiten, während die Daten für das nächste Bild in den nächsten Puffer geladen werden.
Die Abbildung aus 6 zeigt ein Flussdiagramm, das die API-Pufferverarbeitung für isochrone Sende- und Empfangsoperationen veranschaulicht. Dabei wird beim Start 102 einer isochronen Empfangsoperation angenommen, dass die Anwendung die Puffer/Deskriptoren, Aufrufe der Ausführungsroutine und Synchronisierungsereignisse festgelegt hat. Das Flussdiagramm 100 beginnt mit dem Schritt 102 für jeden isochronen Strom, der in dem Bussystem verarbeitet werden muss. Die API 20 verfolgt einen aktuellen Deskriptor zur Verarbeitung der eingehenden Daten. Mit anderen Worten unterhält die API einen Zeiger auf den nächsten Puffer und eine Position in dem nächsten Puffer, an der die Daten gespeichert werden können.
In dem Schritt 104 wird der nächste Pufferdeskriptor aus der verknüpften Liste abgerufen. In dem Schritt 106 wird geprüft, ob sich weitere Deskriptoren in der verknüpften Liste befinden. Wenn sich in der verknüpften Liste keine weiteren Deskriptoren befinden, endet die Verarbeitung in dem Schritt 108. Wenn weitere Deskriptoren vorhanden sind, springt die Routine zu dem Schritt 112, in dem sie wartet, bis das Synchronisierungsereignis für den aktuellen Puffer erreicht worden ist. Sobald das Synchronisierungsereignis erreicht worden ist, wird der aktuelle Puffer in dem Schritt 114 entweder mit eingehenden Daten für eine Empfangsoperation gefüllt oder die Daten aus dem Puffer werden für eine Sendeoperation übermittelt. Nachdem der Puffer verarbeitet worden ist, wird in dem Schritt 116 bestimmt, ob für diesen Puffer eine Rückrufroutine vorhanden gewesen ist. Wenn eine Rückrufroutine vorhanden gewesen ist, wird die Rückrufroutine in dem Schritt 118 aufgerufen. Ansonsten springt die Routine zurück zu dem Schritt 104 und ruft den nächsten Deskriptor ab. Unabhängig davon, ob eine Rückrufroutine vorgesehen ist oder nicht, stellen die API und das Hardware-Teilsystem 26 sicher, dass der nächste Pufferdeskriptor abgerufen wird, so dass keine isochronen Daten verloren gehen.
Die Schritte aus dem Flussdiagramm 100 können von einer CPU und zugeordneten Teilsystemen ausgeführt werden, wie sie in einem üblichen Personalcomputer (PC) oder integrierten Verarbeitungssystem etc. zu finden sind, wie dies bereits vorstehend in Bezug auf die Abbildungen der 3 und 4 beschrieben worden ist. Im Allgemeinen können die Schritt der in der vorliegenden Beschreibung vorgesehenen Flussdiagramme in jeder geeigneten Programmiersprache wie etwa "C", PASCAL, FORTRAN, BASIC, in Assemblersprache etc. sowie in einer Kombination dieser Sprachen implementiert werden. Jede geeignete Computerprogrammierungstechnik kann für ein Softwaredesign zur Implementierung der Schritte verwendet werden, wie etwa eine verfahrensorientierte oder objektorientierte Programmierung, parallele oder verteilte Verarbeitung, unterbrechungsgesteuerte oder Abrufereignisverarbeitung, etc. In Bezug auf die in den Flussdiagrammen veranschaulichten Schritte können Schritte modifiziert, hinzugefügt oder entfernt werden, wobei weiterhin die in der vorliegenden Beschreibung beschriebenen und in den Ansprüchen aufgeführten Verfahrensschritte und Vorrichtungsbestandteile realisiert werden. Die Verarbeitung in einem Schritt kann in zwei oder mehr Schritte aufgeteilt werden. Bei bestimmten Ausführungsbeispielen können ferner zwei oder mehr Schritte gleichzeitig ausgeführt oder deren Aufgaben verschachtelt werden. Die Ablauffolge oder Reihenfolge der Schritte ist ebenfalls veränderlich. Jedes Flussdiagramm steht lediglich für ein einfaches Beispiel für die Logik, die verwendet wird, um eine Funktion in einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung zu realisieren.
Im Sinne der Beschreibung werden die kumulativen Schritte eines Flussdiagramms als eine "Routine" oder ein Programm bezeichnet, wobei sie jedoch auch in zwei oder mehr Routinen, Programmen, Verfahren, etc. implementiert werden können. Die Schritte der Flussdiagramme können auch auf Prozessoren verteilt werden, die sich in der gleichen oder in verschiedenen Vorrichtungen befinden.
Bei einem Beispiel für einen isochronen Datenübertragungsvorgang, wenn es sich bei der Anwendung 22 um einen Videomonitor handelt, der Daten isochron von einem Videorekorder an einem mit der Busstruktur 28 verbundenen Knoten empfängt, verwaltet die API 20 den Datenstrom von der Busstruktur zu den Puffern 32, 34 und 36, die jeweils durch einen Pufferdeskriptor in der verknüpften Liste dargestellt sind. Ein erster Puffer 32 wird mit den von dem Videorekorder empfangenen Daten gefüllt. Wenn der erste Puffer 32 gefüllt ist, wird dieser verarbeitet und durch den Videomonitor 22 angezeigt, während der nächste Puffer 34 in der verknüpften Liste gefüllt wird. Wenn der erste Puffer 32 am Ende der Daten für ein Bild eine Rückrufroutine aufweist, so kann die Rückrufroutine verwendet werden, um den Videomonitor 22 zu benachrichtigen, dass dieser die Daten in dem ersten Puffer 32 verarbeiten kann, welche das erste Bild darstellen. Wenn der Videomonitor 22 die Verarbeitung der Daten in dem ersten Puffer 32 abgeschlossen hat, kann er den Puffer 32 wieder an die API 20 zum Speichern weiterer von der Busstruktur 28 empfangener Daten vorsehen.
Wenn es sich bei der Anwendung 22 um einen Videorekorder handelt, der isochrone Daten an einen anderen mit der Busstruktur gekoppelten Knoten übermittelt, lädt die Anwendung die Puffer 32, 34 und 36 wiederum mit Daten. Die API 20 verwaltet dabei die Übertragung der Daten von den Puffern 32, 34 und 36 auf die Busstruktur 28 mit der entsprechenden Kanalnummer zum entsprechenden Zeitpunkt. auf diese Weise verwaltet die erfindungsgemäße API 20 isochrone Datenübertragungen von und zu einer Anwendung 22.
Asynchrone Datenübertragungen
Für die Ausführung eines asynchronen Datenübertragungsvorgangs zwischen einer Anwendung 24 und einem anderen mit der Busstruktur 28 gekoppelten Knoten definiert die API 20 im Wesentlichen ein Modell mit direktem Speicherzugriff (DMA), wobei ein Niveau der Hardware-Automatisierung zur automatischen Erzeugung der erforderlichen Anforderungen für die Ausführung der Übertragung verwendet wird, und wobei die Anwendung und die API 20 weitere Funktionen ausführen können, während die Datenübertragungsoperation ausgeführt wird. Die API 20 sieht eine auf den Speicher abgebildete Schnittstelle mit der Anwendung für asynchrone Datenübertragungen vor. Zum Einleiten eine asynchronen Datenübertragung sendet eine Anwendung 24 einen Deskriptor an die API 20, einschließlich einer Adresse eines Puffers in dem Adressraum der Anwendung, einer Startadresse in dem Adressraum der Busstruktur, an der die Übertragung erfolgen soll, einer Länge des zu übertragenden Datenblocks und eines Codes, der anzeigt, ob es sich bei der Übertragung um einen Lese- oder Schreibvorgang handelt. Die API 20 sieht die erforderlichen Daten an den automatischen Hardware-Übertragungsgenerator 38 vor, der daraufhin die erforderliche eine oder mehrere Transaktionen erzeugt, die zur Ausführung der Übertragung des ganzen Datenblocks über die Busstruktur 28 erforderlich sind. Der automatische Übertragungsgenerator 38 erzeugt daraufhin die erforderlichen Lese- oder Schreibtransaktionen zur Ausführung der Datenübertragung zwischen dem durch die Anwendung 24 zugewiesenen Puffer und den entsprechenden Adressen über die Busstruktur 28. Diese Automatisierung erfordert nicht die Aufmerksamkeit der API 20 oder der Anwendung 24 zur Ausführung eines asynchronen Datenübertragungsvorgangs. In dem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung ist der automatische Transaktionsgenerator 38 zwar als Hardware implementiert, wobei der Fachmann jedoch erkennen wird, dass der automatische Übertragungsgenerator auch in Software in der API 20 implementiert werden kann. Wenn die Anwendung dieses Niveau der Hardware-Automatisierung nicht erfordert, kann die API 20 auch die erforderlichen Transaktionen erzeugen, um einen Datenübertragungsvorgang auszuführen, ohne dass der automatische Transaktionsgenerator 38 zum Einsatz kommt.
Wie dies für den Fachmann auf dem Gebiet bekannt ist, kann jede Lese- oder Schreibtransaktion nur eine bestimmte Datenmenge übertragen, wobei dies von dem System und den Kapazitäten der Busstruktur 28 abhängig ist. Für die Übertragung eines Datenblocks kann es somit erforderlich sein, mehrere Lese- oder Schreibtransaktionen zu erzeugen. Im Gegensatz zu den dem Stand der Technik entsprechenden Systemen sendet die erfindungsgemäße API 20 einen einzigen Befehl an den automatischen Transaktionsgeneratorblock 38. Der automatische Transaktionsgeneratorblock 38 erzeugt daraufhin die erforderlichen Lese- oder Schreibtransaktionen für die Übertragung des ganzen Datenblocks über die Busstruktur 28, ohne dass ein weiterer Eingriff der API 20 erforderlich ist. Auf diese Weise ist das System effizienter, da die API 20 und die Anwendung 24 andere Aufgaben ausführen können, während die Übertragung ausgeführt wird. Da es sich um eine asynchrone Übertragung handelt, benachrichtigt die API 20 die Anwendung 24 sobald die Übertragung des ganzen Datenblocks abgeschlossen ist.
Wie dies bereits vorstehend im Text erörtert worden ist, handelt es sich bei der Busstruktur 28 in dem bevorzugten Ausführungsbeispiel der Erfindung um eine Busstruktur gemäß dem IEEE 1394 Standard. Für asynchrone Datenübertragungen sieht die Busstruktur 28 somit einen Adressraum von 64 Bit vor. In dem Deskriptor, der dem automatischen Transaktionsgenerator 38 bereitgestellt wird, wird die entfernte Adresse, an der die Datenübertragung erfolgen soll, durch eine 64-Bit-Rdresse spezifiziert.
Zum Einleiten eines asynchronen Lesevorgangs übermittelt die Anwendung 24 einen Deskriptor an die API 20, einschließlich der Adresse des Puffers in dem Adressraum der Anwendung, zu dem die Daten übertragen werden sollen, einer 64-Bit-Startadresse in dem Adressraum der Busstruktur 28, von der die Daten gelesen werden sollen, der Länge des übertragenen Datenblocks sowie eines Codes, der anzeigt, dass es sich bei der Übertragung um einen Lesevorgang handelt. Die API 20 übermittelt daraufhin die erforderlichen Informationen an den automatischen Transaktionsgenerator 38. Der automatische Transaktionsgenerator 38 erzeugt daraufhin die erforderlichen Lesebefehle für die Übertragung der Daten an den Puffer der Anwendung von dem entsprechenden Knoten der Busstruktur 28. Die Anwendung ist dafür verantwortlich, sicherzustellen, dass der spezifizierte Puffer verfügbar ist, bevor die Lesetransaktionen erzeugt werden. Die Daten werden danach als Reaktion auf die durch den automatischen Transaktionsgenerator 38 erzeugten Transaktionen auf bekannte Art und Weise gelesen.
Zum Einleiten eines asynchronen Schreibvorgangs übermittelt die Anwendung 24 einen Deskriptor an die API 20, einschließlich der Adresse des Puffers in dem Adressraum der Anwendung, von der die Daten übertragen werden sollen, einer 64-Bit-Startadresse in dem Adressraum der Busstruktur 28, an welche die Daten geschrieben werden sollen, der Länge des zu übertragenden Datenblocks und eines Codes, der anzeigt, dass es sich bei der Übertragung um einen Schreibvorgang handelt. Die API 20 übermittelt die erforderlichen Informationen daraufhin an den automatischen Transaktionsgenerator 38. Der automatische Transaktionsgenerator 38 erzeugt daraufhin die erforderlichen Schreibbefehle für die Übertragung an den entsprechenden Knoten der Busstruktur 28 aus dem Puffer der Anwendung. Die Daten werden daraufhin von dem Puffer der Anwendung als Reaktion auf die durch den automatischen Transaktionsgenerator 38 erzeugten Transaktionen auf bekannte At und Weise übertragen. Die Anwendung 24 wird benachrichtigt, wenn der Puffer übertragen wird.
API-Konventionen und Busverwaltungsoperationen
Eine Anwendung ruft eine Routine in der API 20 entweder synchron oder asynchron auf. Wenn eine Anwendung eine Routine synchron aufruft, so hat die API die angeforderte Operation bis zu dem Zeitpunkt ausgeführt, wenn die Routine zu der Anwendung zurückkehrt, oder die API gibt einen Ausführungsstatus zurück, der anzeigt, dass die ausgewählte Anforderung nicht vollständig ausgeführt werden konnte. Wenn eine Anwendung eine Routine alternativ asynchron aufruft, so ist die angeforderte Aufgabe höchstwahrscheinlich bis zu dem Zeitpunkt, wenn die Routine die Steuerung wieder an den Client abgibt, noch nicht vollständig ausgeführt. Für einen asynchronen Aufruf einer Routine sieht die Anwendung eine Ausführungs-Rückrufroutine vor. Die API kann diese Ausführungsroutine aufrufen, bevor sie von dem ursprünglichen Aufruf zurückgekehrt ist. In den meisten Fällen führt die API die angeforderte Operation jedoch aus, nachdem sie von dem ursprünglichen Aufruf zurückgekehrt ist, der die Operation eingeleitet hat, wobei daraufhin die Ausführungsroutine der Anwendung aufgerufen wird, um anzuzeigen, dass der Vorgang abgeschlossen ist.
Vor dem Einsatz eines durch die API vorgesehen Dienstes muss eine Anwendung die API zuerst initialisieren. Jede Anwendung muss die API einzeln initialisieren. Eine Anwendung initialisiert die API durch Aufruf einer ActivateSony/API Unterroutine. Diese Unterroutine erzeugt eine Verbindung zwischen der API und der Anwendung. Beim Aufruf von ActivateSonyAPI kann die Anwendung Melderoutinen spezifizieren, welche die API aufruft, wenn ein Zurücksetzen des Busses oder ein anderes Busereignis auftritt. Die Unterroutine ActivateSonyAPI gibt einen Wert an die Anwendung zurück, den die Anwendung daraufhin bei folgenden Aufrufen der Routinen der API verwendet.
Anwendungen, die eine große Anzahl von Meldungen bzw. Anzeigen im Verlaufe ihres Betriebs erwarten, können die Routine AddIndBuffers aufrufen, um zusätzliche Meldepuffer zur ausschließlichen Verwendung der API zuzuführen. Der Client kann zuerst die Routine CountIndBuffers aufrufen, um die Anzahl der Puffer zu überprüfen, welche die API gegenwärtig besitzt. Vor der Deaktivierung der API kann die Anwendung die vorher an die API vorgesehenen Puffer durch Aufrufen der Routine ReIIndBuffers freigeben.
Wenn eine Anwendung die Nutzung der API abgeschlossen hat, ruft sie eine Routine DeactivateSonyAPI auf. Diese Routine unterbricht die Verbindung zwischen der Anwendung und der API und gibt etwaige von der API verwendete Meldepuffer oder andere Ressourcen für die Anwendung frei. Hiermit wird festgestellt, dass die API unter Umständen nicht in der Lage ist, sich sofort von einer bestimmten Anwendung zu trennen, wenn einige der Puffer der Anwendung gerade durch die API genutzt werden. Während dem Zeitraum, über den die API für eine bestimmte Anwendung aktiv ist, weist diese Anwendung Zugriff auf alle von dieser API vorgesehenen Dienste auf.
Nach der Initialisierung der API kann eine Anwendung verschiedene IEEE 1394 Busverwaltungsfunktionen ausführen, die in Abschnitt 8 des IEEE 1394 Standards definiert sind und nachstehend beschrieben werden. Über die entsprechenden Routinen MGMTAllocateChannel bzw. MGMTDeAllocateChannel kann eine Anwendung isochrone Kanalnummern dem gegenwärtig aktiven isochronen Ressourcenmanager zuweisen oder derartige Zuweisungen aufheben. Unter Verwendung dieser Anwendungen kann die Anwendung die Zuweisung jeder gegenwärtig verfügbaren Kanalnummer anfordern. Diese API-Routinen entsprechen den Anforderungen des IEEE, 1394 Standards in Bezug auf die Zuweisung sowie das Aufheben von Zuweisungen isochroner Kanalnummern. Beim Einsatz isochroner Kanalnummern ist die Anwendung dafür verantwortlich, alle weiteren Anforderungen zu erfüllen, die gemäß dem IEEE 1394 Standard oder jedem anderen geltenden Protokolldokument gelten.
Eine Anwendung kann isochrone Bandbreite dem gegenwärtig aktiven isochronen Ressourcenmanager über die entsprechenden Routinen MGMTAllocateBandwidth bzw. MGMTDeAllocateBandwidth zuweisen oder entsprechende Zuweisungen aufheben. Die API-Routinen entsprechen den Anforderungen des IEEE 1394 Standards in Bezug auf die Zuweisung und das Aufheben von Zuweisungen isochroner Bandbreite. Beim Einsatz dieser Routinen ist die Anwendung dafür zuständig, das korrekte Ausmaß isochraner Bandbreite zu berechnen und genau diese zuzuweisen. Die Anwendung ist ferner dafür verantwortlich alle anderen geltenden Richtlinien gemäß der Dokumentation in dem IEEE 1394 Standard und etwaiger anderer geltender Protokolldokumente in Bezug auf die Zuweisung, die Aufhebung von Zuweisungen oder die Belegung einer isochronen Bandbreite zu erfüllen.
Wenn eine Anwendung die API deaktiviert, versucht die API nicht, die Zuweisungen für etwaige Busressourcen aufzuheben, welche die Anwendung vorher zugewiesen hat: Dies ermöglicht es der Anwendung, die Beherrschung dieser Ressourcen leicht aufzugeben, wie dies gemäß dem IEC AV Protokollstandard erforderlich sein kann. Dabei wird die vollständige Verantwortung für die Erfüllung geltender Protokolle bei der Zuweisung oder der Aufhebung von Zuweisungen für isochrone Busressourcen jedoch auf die Anwendung übertragen.
Unter Verwendung der Routine MGMTBusInfo kann eine Anwendung die aktuelle Topologieabbildung und Geschwindigkeitsabbildungsinformationen von dem aktiven Busmanager, sofern vorhanden, sowie alle anderen verfügbaren Businformationen abrufen. Diese Routine ruft die aktuellsten Informationen von dem Busmanager ab, unabhängig davon, ob der Knoten, an dem die Anwendung ausgeführt wird, der aktive Busmanager ist oder nicht. Hiermit wird festgestellt, dass diese Routine fehlschlägt, wenn aktuell kein Busmanager aktiv ist. Abschnitt 8 des IEEE 1394 Standards definiert das Format der Topologieabbildung und Geschwindigkeitsabbildung sowie die Bedingungen, unter welchen ein Busmanager existiert oder nicht existiert.
Nach der Initialisierung der API kann die Anwendung die Routine ASYNDataRequest aufrufen, um Anforderungen für asynchrone Datenübertragungen über den seriellen IEEE 1394 Bus einzuleiten. Die Anwendung kann diese Routine zur Einleitung jeder asynchronen Transaktion verwenden, die in dem IEEE 1394 Standard definiert ist, einschließlich Datenblock-Lese- oder Datenblock-Schreibanforderungen, Quadlet-Lese- oder Quadlet-Schreib-Anforderungen oder etwaige Sperranforderungen. Wenn die Anwendung die Routine ASYNDataRequest aufruft, überträgt die Routine einen Deskriptor für einen Puffer in dem Adressraum der Anwendung, eine Startadresse in dem IEEE 1394 64-Bit-Adressraum, eine Datenübertragungslänge und einen Transaktionscode. Die ASYNDataRequest Routine erzeugt daraufhin eine oder mehrere IEEE 1394 Transaktionen zur Erfüllung der Anforderung. Wenn die API die angeforderte Datenübertragungsoperation abschließt oder wenn ein Fehler auftritt, kehrt die API zu der Anwendung zurück oder ruft die Rückrufroutine der Anwendung auf, abhängig davon, ob die Anwendung diese Routine synchron oder asynchron aufgerufen hat.
Zur Ausführung einer Sperrtransaktion über den seriellen IEEE 1394 Bus ruft die Anwendung die Routine ASYNDataRequest auf und leitet einen Argumentwert, einen Datenwert und einen Sperroperationscode weiter. Die API erzeugt die angeforderte Sperroperation und kehrt zu der Anwendung zurück oder ruft die Rückrufroutine der Anwendung auf, wie dies durch die Aufrufart bestimmt worden ist, d. h. synchron oder asynchron.
Nach der Initialisierung der API kann die Anwendung einen Kanal isochroner Daten an dem seriellen IEEE 1394 Bus sourcen oder einlassen. Vor der Übertragung isochroner Daten muss die Anwendung zuerst einen isochronen Port über die Routine ISOCHOpen öffnen. Beim Aufruf dieser Routine spezifiziert die Anwendung die Richtung und weitere Informationen zu dem Strom isochroner Daten, welche die Anwendung übertragen möchte. Die Routine ISOCHOpen bestimmt, ob die erforderlichen Systemressourcen zur Verfügung stehen und kehrt danach zu der Anwendung zurück. Wenn die Routine erfolgreich vollständig ausgeführt wird, sind alle erforderlichen Systemressourcen für die ausschließliche Nutzung der Anwendung reserviert, um einen Strom isochroner Daten zu übertragen. Wenn eine Anwendung auf einem isochronen Kanal spricht oder zuhört, handelt es sich bei der Quelle oder dem Ziel der isochronen Daten in dem Host-System um einen oder mehrere Datenpuffer, die von der Anwendung beherrscht werden und in einer Datenstruktur beschrieben sind. Die Anwendung leitet diese Puffer durch den Aufruf der Routine ISOCHAttach an die API weiter. Diese Routine "hängt" die Anwendungspuffer an den isochronen Strom in Vorbereitung auf die Übertragung von Anwendungsdaten in die Puffer oder aus diesen Puffern an. Wenn die Anwendung ihre Puffer wieder beanspruchen möchte, bevor die API mit diesen fertig ist, kann die Anwendung die Routine ISOCHDetach aufrufen, wobei die Puffer spezifiziert werden, welche die Anwendung wieder zurückgewinnen möchte.
Der durch die API definierte Pufferdeskriptor, den die Anwendung zur Beschreibung ihrer isochronen Datenpuffer verwendet, ermöglicht es der Anwendung, einen, mehr als einen oder eine Liste von Datenpuffern für den Einsatz zum Empfangen oder Übermitteln isochroner Daten zu spezifizieren. Jeder Puffer kann zusammenhängend oder unterteilt, logisch oder physisch sein, und die Anwendung kann Rückrufroutinen Puffer für Puffer spezifizieren. Dies ermöglicht eine außerordentlich flexible Pufferhandhabung in der API für die Anwendung, wodurch eine Vielzahl von Anwendungsanforderungen unterstützt werden.
Wenn die Anwendung einen isochronen Port geöffnet und Puffer an diesen Port angehängt hat, kann die Anwendung den entsprechenden Strom isochroner Daten steuern. Dies erfolgt durch Aufruf der Routine ISOCHControl. Diese Routine ermöglicht es der Anwendung, einen isochronen Strom in die Anwendungspuffer oder aus den Anwendungspuffern zu starten oder anzuhalten. Beim Aufruf dieser Routine kann die Anwendung ein Ereignis spezifizieren, bei dem der Strom gestartet oder angehalten wird, wie zum Beispiel sofort, bei einem bestimmten isochronen Zyklus oder einem anderen Ereignis. Wenn die Anwendung die Übertragung eines Stroms isochroner Daten abgeschlossen hat, gibt sie die dem offenen Port zugeordneten Systemressourcen durch den Aufruf der Routine ISOCHClose frei.
Die Routinen ActivateSonyAPI und DeactivateSonyAPI sehen einen Initialisierungsmechanismus vor, der spezifische Dienste für IEEE 1394, die durch die API vorgesehen werden, für die aufrufende Anwendung verfügbar macht. Die Routine ActivateSonyAPI erzeugt eine Verbindung mit den durch die API vorgesehenen Diensten. Die Routine DeactivateSonyAPI entfernt die spezifizierte Verbindung mit den durch die API vorgesehenen Diensten. Das Ergebnis einer Aktivierung ist eine gültige Struktur activateReq. Die aufrufende Anwendung leitet einen Zeiger als Bestandteil aller folgenden Aufrufe der API an diese Struktur weiter. Im Rahmen der Aktivierung der API für eine Anwendung kann die Anwendung Melderoutinen vorsehen, welche die API verwendet, um den Aufrufer bzw. Anrufer darüber zu informieren, dass an dem zugeordneten IEEE 1394 Bus etwas erfolgt ist, wie etwa ein Zurücksetzen des Busses oder eine Meldeanforderung von einem entfernten Knoten. Das Ergebnis der Deaktivierung ist es, dass für Melderoutinen, sofern vorhanden, die zum Aktivierungszeitpunkt registriert worden sind, die Registrierung aufgehoben wird. Nach der Deaktivierung kann der Aufrufer keine der API-Dienste verwenden, sofern die API nicht zuerst wieder aktiviert worden ist.
Die folgende Funktion aktiviert die API für weitere Operationen:
STATUS ActivateSonyAPI (ActivateRegPtr activateReq);
Diese Routine nimmt einen Parameter und gibt einen Statuswert zurück. Der Aufrufer füllt die activateReq Datenstruktur, wie dies nachstehend definiert ist, und leitet einen Zeige auf die Routine ActivateSonyAPI weiter. Nachdem diese Routine einen Status GOOD wiedergibt, speichert der Aufrufer die resultierende Datenstruktur activateReq. Die Datenstruktur stellt die Verbindung zwischen der Anwendung und der API dar. Zur Identifizierung dieser Verbindung leitet der Aufrufer einen Zeiger auf die Datenstruktur activateReq bei folgenden Aufrufen der API weiter. Die möglichen Statusrückgabewerte sind GOOD, wodurch angezeigt wird, dass die API jetzt aktiviert ist und die activateReq Datenstruktur für den Einsatz weiterer Operationen gültig ist, PENDING, wodurch angezeigt wird, dass die API eine Anforderung angenommen hat, zu diesem Zeitpunkt jedoch nicht aktiv ist, und UNDDEFINEDERROR, wodurch angezeigt wird, dass ein unerwarteter Fehler während dem Versuch zur Aktivierung der API aufgetreten ist und dass die API nicht aktiviert worden ist. Nach der Rückgabe eines Wertes PENDING ruft die API die Routine AsyncCompletion auf, wenn die Aktivierungsanforderung vollständig ausgeführt worden ist. Zu diesem Zeitpunkt weist das Anforderungsstatusfeld den Ausführungsstatus für die Aktivierungsanforderung auf.
Der einzelne Parameter weist die Adresse einer activateReq Datenstruktur auf. Diese Datenstruktur liefert die erforderlichen Informationen für die Aktivierung der API, wie dies in der nachstehenden Tabelle I definiert ist:
TABELLE I
Wenn das BusResetHandler-Feld ungleich Null ist, weist es die Adresse der Routine auf, die nach dem Empfang eines Busrücksetzereignisses aufgerufen werden soll. Wenn eine Busrücksetzung an dem IEEE 1394 Bus erfolgt, ruft die API die Routine BusResetHandler auf, wobei die Adresse der Datenstruktur weitergeleitet wird, welche die Busrücksetzinformationen aufweist. Wenn das Feld IndicationHandler ungleich Null ist, weist es die Adresse der Routine auf, die nach dem Auftreten einer Meldung aufgerufen werden soll, die nicht von der API behandelt wird. Wenn die API eine Anforderungsteilaktion von einem entfernten Knoten empfängt, ruft sie die Routine IndicationHandler auf, leitet die Adresse einer Datenstruktur weiter, welche die Anforderung beschreibt. Die API verwendet den Wert in diesem Feld bei folgenden Aufrufen. Die aufrufende Anwendung darf den Wert in diesem Feld nicht modifizieren. Wenn das Feld AsyncCompletion ungleich Null ist, weist es die Adresse der Routine auf, die aufgerufen werden soll, wenn die API aktiv ist und zur Verwendung durch die anfragende Anwendung verfügbar ist. Hiermit wird festgestellt, dass die aufrufende Anwendung für eine Ausführungsroutine spezifizieren kann, ob es sich um eine asynchrone oder synchrone Anforderung handelt. Das Feld UserPtr steht zur Nutzung durch die Ausführungsroutine der aufrufenden Anwendung zur Verfügung. Die API modifiziert dieses Feld nicht. Das Statusfeld weist den Status der Aktivierungsanforderung auf.
Die folgende Funktion beendet die Instantiierung der API, die durch die Anforderung dargestellt ist:
status DeactivateSonyAPI (ActivateRegPtr request);
Die möglichen Statusrückgabewerte für diese Funktion sind GOOD, wodurch angezeigt wird, dass die API jetzt deaktiviert ist und die activateReq Datenstruktur für den Einsatz weiterer Operationen gültig ist, INVALIDCONNECTION, PENDING, wodurch angezeigt wird, dass die API eine Deaktivierungsanforderung angenommen hat, zu diesem Zeitpunkt jedoch noch aktiv ist, und UNDDEFINEDERROR, wodurch angezeigt wird, dass ein unerwarteter Fehler während dem Versuch zur Deaktivierung der API aufgetreten ist und wobei die API aktiviert sein kann. Nach der Rückgabe eines Wertes PENDING ruft die API die Routine AsyncCompletion auf, wenn die Deaktivierungsanforderung vollständig ausgeführt worden ist. Zu diesem Zeitpunkt weist das Anforderungsstatusfeld den Ausführungsstatus für die Aktivierungsanforderung auf.
Der eine Parameter weist die Adresse der activateReq Datenstruktur auf, die vorher zur Aktivierung der API verwendet worden ist. Der vorstehende Abschnitt definiert diese Datenstruktur und beschreibt deren Felder. Hiermit wird festgestellt, dass der Aufrufer bei einer Deaktivierung die gleiche Datenstruktur verwenden muss, die auch vorher ur Aktivierung der API verwendet worden ist. Der Aufrufer kann die Werte in dem Feld AsyncCompletion und dem Feld UserPtr modifizieren. Der Aufrufer sollte kein anderes Feld in der Datenstruktur activateReq nach dem ersten Aufruf der Routine ActivateSonyAPI und vor dem Aufruf der Routine DeactivateSonyAPI modifizieren. Zusätzlich zur Deaktivierung der API für eine spezielle Anwendung gibt diese Routine auch alle Meldepuffer frei, die von der Anwendung belegt werden, und die Anwendung versucht diese Routine synchron aufzurufen, wobei die Routine einen Fehler zurückgibt. Wenn dies eintritt kann die Anwendung diese Routine erneut aufrufen und eine Ausführungsroutine spezifizieren. Die API führt die Deaktivierungsanforderung vollständig aus und ruft die Melderoutine der Anwendung auf, wenn alle Meldepuffer der Anwendung freigegeben worden sind.
Die API ruft die Meldebehandlungsroutinen BusResetHandler und IndicationHandler asynchron auf und ihnen können eingeschränkte Systemdienste zur Verfügung stehen. Abhängig von der Umgebung und möglicherweise einigen anderen Umständen kann die API diese Routinen auf Unterbrechungsebene aufrufen. In der BusResetHandler Routine wird der Handhabungsroutine ein Zeiger auf die Busrücksetzinformationen zugeführt. In der Routine IndicationHandler wird der Handhabungsroutine ein Zeiger auf die Meldeinformationen zugeführt. Die Anwendung leitet die Adresse einer oder beider der Melderoutinen zu dem Zeitpunkt an die API weiter, wenn sie die API aktiviert. Die Anwendung kann eine dieser Behandlungsroutinen, beide Behandlungsroutinen oder gar keine Behandlungsroutine vorsehen.
Die Busrücksetz-Behandlungsroutine weist den folgenden Aufruf auf:
void BusResetHandler (BusResetBlockPtr busResetBlock);
Die Datenstruktur busResetBlock weist die Adresse einer Datenstruktur auf, die ein Busrücksetzereignis gemäß der Definition in der nachstehenden Tabelle II beschreibt.
TABELLE II
Die API ruft die Behandlungsroutine zur Busrücksetzung bei jeder an dem IEEE 1394 Bus auftretenden Busrücksetzung auf, während die API für die Anwendung aktiv ist, welche die Behandlungsroutine zur Busrücksetzung vorgesehen hat. Wenn ein Cluster von Rücksetzungen aufgrund der physikalischen Eigenart der Busverbindung und Bustrennung erfolgt, wird die Behandlungsroutine einmal aufgerufen. Es erfolgt kein neuerlicher Eintritt in die Behandlungsroutine, sie kann aber mehrere Male hintereinander aufgerufen werden. Als Folge der Zurücksetzung des Busses werden alle zum Zeitpunkt der Zurücksetzung des Busses ausstehenden asynchronen Transaktionen mit einem Fehlerstatus ausgeführt. Der isochrone Verkehr wird gemäß der IEEE 1394 Spezifikation wieder aufgenommen und kann während der Ausführung der Behandlungsroutine zur Busrücksetzung Meldungen erzeugen.
Die asynchrone Melderoutine der Transaktionsanforderung weist den folgenden Aufruf auf:
void IndicationHandler (IndicationBlockPtr IndicationBlockPtr)
Die Datenstruktur IndicationBlockPtr weist die Adresse eines Meldeblocks an, wie dies in der folgenden Tabelle III definiert ist.
TABELLE III
Die API ruft die Melderoutine auf, wenn sie eine asynchrone Anforderungsteilaktion empfängt, die nicht entweder durch die API selbst oder durch die IEEE 1394 Schnittstellen-Hardware bearbeitet wird. Bei jedem derartigen Ereignis ruft die API die Melderoutine jeder Anwendung auf, beginnend mit der ersten Anwendung, um die API zu aktivieren und eine Meldebehandlungsroutine vorzusehen. Jede Behandlungsroutine gibt einen Wert an die API zurück, um anzuzeigen, ob sie die Meldung bearbeitet hat oder nicht. Wenn die API einen Status von einer Melderoutine empfängt, der anzeigt, dass die Meldung bearbeitet worden ist, ruft die API keine anderen Melderoutinen für diese Meldung auf.
Die API bearbeitet einige Anforderungsteilaktionen selbst. Bei diesen Transaktionen ruft die ABI keine Meldebehandlungsroutine auf. Die API leitet alle IEEE 1394 Transaktionsinformationen weiter, die die Meldung verursacht haben sowie die zusätzlichen erforderlichen Informationen für die Meldebehandlungsroutine zur Erzeugung einer Antwortteilaktion über die API.
Die Anwendung kann Puffer zu der Meldebehandlungsroutine beitragen. Dies ermöglicht es der Anwendung, die Standardanordnung der Meldepuffer zu erweitern, um anwendungsspezifischen Anforderungen Rechnung zu tragen. Eine größere Anordnung von Meldepuffern ermöglicht klarere Meldungen, ohne dass an der IEEΈ 1394 Schnittstelle ein Bestätigungssignal für einen belegten Zustand bewirkt wird. Die Anwendung empfängt nicht garantiert einen zugehörigen Puffer, wenn sie eine Meldung von der API empfängt. Ferner kann die API bei Bedarf einen Anwendungsmeldepuffer an eine andere Anwendung weiterleiten, wenn eine Meldung verzeichnet wird.
Die Funktion Current Indication Puffer Count gibt den Gesamtwert der Meldepuffer in dem Meldepufferpool wider. Bei dem zurückgegebenen Wert handelt es sich um den aktuellen Wert der Meldepuffer.
Die Funktion Add Indication Buffers trägt Puffer zu der Meldepuffergruppe bei. Die Pufferelemente werden als LocalBuffer (lokaler Puffer) bezeichnet. Der Aufrufer dieser Funktion überträgt die Verfügungsgewalt über den durch diese Anforderung dargestellten Speicher an die API und muss sich vor der Entsorgung des Speichers die Verfügungsgewalt wieder verschaffen.
STATUS AddIndBuffers (ActivateRegPtr context, BufMgmtBlockPtr bufBlock);
Die möglichen Statusrückgabewerte für eine AddIndBuffers Funktion sind GOOD, wodurch angezeigt wird, dass die API die Anforderung angenommen hat und diese zu einem späteren Zeitpunkt ausführt, INVALIDCONNECTION, PENDING, wodurch angezeigt wird, dass die API die Anforderung angenommen hat, UNSUPPORTEDOP, wodurch angezeigt wird, dass die Puffer nicht auf dieser Plattform hinzugefügt werden können, und UNDEFINEDERROR, wodurch angezeigt wird, dass ein unerwarteter während der Würdigung der Anforderung Fehler aufgetreten ist, wobei einige Daten jedoch übertragen worden sein können. Wenn ein ausstehender Wert zurückgegeben wird, ruft die API die Ausführungsroutine AsyncCompletion auf, wenn die Anforderung ausgeführt ist. Zu diesem Zeitpunkt weist das Statusfeld von BufMgmtBlock den Ausführungsstatus für diese Anforderung auf.
Der erste Parameter einer Funktion AddInBuffers enthält die Adresse einer gültigen ActivateReq Datenstruktur. Der zweite Parameter weist die Adresse einer Datenstruktur BufMgmtBlock auf. Diese Datenstruktur beschreibt die Puffer gemäß der Definition in der nachstehenden Tabelle IV.
TABELLE IV
Das Feld APIprivate weist private Daten zur Verwaltung der Anforderung auf. Das Feld LocalBufferPtr weist Deskriptoren für den bzw. die beizutragenden Puffer auf. Diese Puffer können jede Größe aufweisen. Die API kann nach Belieben keinen, einige oder alle der beigetragenen Puffer verwenden. Wenn das Feld AsyncCompletion ungleich Null ist, weist es die Adresse der Routine auf, die bei vollständiger Ausführung der Operation aufgerufen werden soll. Das Feld UserPtr steht zur Verwendung durch die aufrufende Ausführungsroutine zur Verfügung. Die API modifiziert dieses Feld nicht. Das Statusfeld weist den Status der angeforderten Datenübertragungsoperation auf. Das Statusfeld weist den Status "ausstehend" aus, bis die asynchrone Operation abgeschlossen ist. Wenn die Ausführungsroutine aufgerufen wird, weist das Statusfeld den Ausführungsstatus auf.
Die Funktion Release Indication Buffers gibt vorher hinzugefügte Puffer an den Aufrufer zurück. Die Pufferelemente werden als ein LocalBuffer beschrieben. Der Aufrufer dieser Funktion kann eine Untergruppe der durch eine Anforderung der Funktion AddIndBuffers hinzugefügten Puffer spezifizieren. Wenn alle angeforderten Puffer freigegeben werden, wird die Ausführungsroutine aufgerufen.
STATUS RelIndBuffers (ActivateRegPtr context, BufMgmtBlockPtr bufBlock);
Die möglichen Statusrückgabewerte für eine Funktion RelIndBuffers sind PENDING, wodurch angezeigt wird, dass die API die Anforderung angenommen hat und diese zu einem späteren Zeitpunkt ausführt, INVALIDCONNECTION, UNSUPPORTEDOP, wodurch angezeigt wird, dass Puffer auf dieser Plattform nicht hinzugefügt werden können und UNDEFINEDERROR, wodurch angezeigt wird, dass während dem Versuch der Behandlung der Anforderung ein unerwarteter Fehler aufgetreten ist, wobei einige Daten jedoch übertragen worden sein können.
Der erste Parameter von Release Indication Buffer weist die Adresse einer gültigen Datenstruktur activateReq auf. Der zweite Parameter weist die Adresse einer Datenstruktur BufMgmtPtr auf. Diese Datenstruktur beschriebt die Puffer gemäß der vorstehenden Definition. Wenn die Anwendung von der API die Freigabe eines Puffers verlangt, muss sie diesen Puffer unter Verwendung der gleichen Beschreibung beschreiben als wäre der Puffer zuerst der APT zugewiesen.
Die Puffermanagementroutinen führen IEEE 1394 Busmanagementfunktionen aus. Zu diesen Funktionen zählen das Zuweisen und das Aufheben von Zuweisungen isochroner Busressourcen sowie das Abrufen von Informationen über die Topologie oder Konfiguration des IEEE 1394 Busses.
Die Routine MGMTAllocateChannel verwendet die in Abschnitt 8 des IEEE 1394 Standards definierten Protokolle für die Zuweisung einer einzelnen isochronen Kanalnummer. Die Konvention für den Aufruf der Routine MGMTAllocateChannel ist wie folgt:
status MGMTAllocateChannel (ActivateRegPtr context, MGMTAllocateChBlockPTr allocateChBlock);
Die möglichen Statusrückgabewerte für die Routine MGMTAllocateChannel sind GOOD, wodurch angezeigt wird, dass der Kanal erfolgreich zugewiesen worden ist, INVALIDCONNECTION, wodurch angezeigt wird, dass der Kontextparameter nicht die Adresse einer derzeit aktiven Verbindung mit der API aufweist, PENDING, wodurch angezeigt wird, dass die API die Anforderung angenommen hat, CHUNAVAILABLE, wodurch angezeigt wird, dass die angeforderte Kanalnummer zur Zeit nicht verfügbar ist, und UNDDEFINEDERROR, wodurch angezeigt wird, dass ein unerwarteter Fehler aufgetreten ist. Wenn ein ausstehender Wert (Pending) zurückgegeben worden ist, ruft die API die Routine MGMTCompletion auf, wenn die Zuweisungsanforderung vollständig ausgeführt worden ist, und zu diesem Zeitpunkt weist das Statusfeld den Ausführungsstatus für diese Anforderung auf.
Der erste Aufrufparameter einer Routine MGMTAllocateChannel ist die Adresse einer aktiven ActivateReq Datenstruktur. Der zweite Parameter weist die Adresse einer Datenstruktur gemäß der Definition in Tabelle V unten auf.
TABELLE V
Das Kanalfeld weist die zuzuweisende Kanalnummer auf. Wenn die Kanalnummer im Bereich von 0 bis einschließlich 63 liegt, versucht die Routine die spezifizierte Kanalnummer zuzuweisen. Wenn die Kanalnummer nur aus Einsen besteht, so wählt die Routine eine zuzuweisende Kanalnummer aus. Wenn die Kanalnummer einen anderen Wert aufweist, füllt die Routine das Feld chAvailable und gibt den Status chUnavailable zurück. Hiermit wird festgestellt, dass dies zur Bestimmung des aktuellen Werts der verfügbaren Bitmaske des Kanals aus der aktuell aktiven Funktion Isochronous Resource Manager verwendet werden kann. Das Feld allocatedCh wird mit der tatsächlich zugewiesenen Kanalnummer gefüllt oder ausschließlich mit Einsen, wenn ein Kanal nicht als Folge des Aufrufs dieser Routine zugewiesen worden ist. Das Feld chAvailable wird mit dem aktuellen Wert von channels available CSR an dem Isochronous Resource Manager gefüllt. Hiermit wird festgestellt, dass der Wert in CSR ich jederzeit ändern kann, so dass der Wert in diesem Feld lediglich eine Momentaufnahme darstellt und sich bei folgenden Aufrufen unterscheiden kann. Wenn der Wert in dem Feld MGMTCompletion ungleich NULL ist, so weist dieses Feld die Adresse der Routine auf, die bei vollständiger Ausführung aufgerufen werden soll. Das Feld UserPtr steht zur Verwendung durch die Ausführungsroutine der Anwendung zur Verfügung. Die API modifiziert dieses Feld nicht. Das Statusfeld weist den Ausführungsstatus für diesen Aufruf auf. Wenn die Anwendung diese Routine asynchron aufruft, weist dieses Feld den Status PENDING auf, bis die Ausführungsroutine aufgerufen wird.
Die Routine MGMTAllocateBandwidth verwendet die in dem Abschnitt 8 des IEEE 1394 Standards für die Zuweisung isochroner Bandbreite definierten Protokolle. Die Konvention für den Aufruf der Routine MGMTAllocateBandwidth ist wie folgt gegeben:
status MGMTAllocateBandwidth (ActivateRegPtr context, MGMTAllocateChBlockPtr allocateChBlock);
Die möglichen Statusrückgabewerte für die Routine MGMTAllocateBandwidth sind GOOD, wodurch angezeigt wird, dass die Bandbreite erfolgreich zugewiesen worden ist, INVALIDCONNECTION, wodurch angezeigt wird, dass der Kontextparameter nicht die Adresse einer derzeit aktiven Verbindung mit der API aufweist, PENDING, wodurch angezeigt wird, dass die API die Anforderung angenommen hat, BWUNAVAILABLE, wodurch angezeigt wird, dass die Bandbreite zur Zeit nicht verfügbar ist, und UNDEFINEDERROR, wodurch angezeigt wird, dass ein unerwarteter Fehler aufgetreten ist. Wenn ein ausstehender Wert zurückgegeben worden ist, ruft die API die Routine MGMTCompletion auf, wenn die Zuweisungsanforderung vollständig ausgeführt worden ist, und zu diesem Zeitpunkt weist das Statusfeld den Ausführungsstatus für diese Anforderung auf.
Der erste Aufrufparameter einer Routine MGMTBandwidth ist die Adresse einer aktiven ActivateReq Datenstruktur. Der zweite Parameter weist die Adresse einer Datenstruktur gemäß der Definition in der folgenden Tabelle VI auf.
TABELLE VI
Das Bandbreitenfeld (Bandwidth) weist das Ausmaß der zuzuweisenden Bandbreite auf. Wenn diese Zahl nur aus Einsen besteht, füllt die Routine das Feld bwAvailable und gibt den Status BWUNRVAILABLE zurück. Hiermit wird festgestellt, dass dies zur Bestimmung des aktuellen Wertes des Felds bwavailable über den gerade aktiven Isochronous Resource Manager verwendet werden kann. Das Feld bwAvailable wird mit dem aktuellen Wert des bandwidth available CSR an dem Isochronous Resource Manager gefüllt. Hiermit wird festgestellt, dass der Wert in CSR jederzeit veränderlich ist, so dass der Wert in diesem Feld lediglich eine Momentaufnahme darstellt und sich bei folgenden Aufrufen unterscheiden kann. Wenn der Wert in dem Feld MGMTCompletion ungleich NULL ist, so weist es die Adresse der nach vollständiger Ausführung aufzurufenden Routine auf. Die API modifiziert dieses Feld nicht. Das Statusfeld weist den Ausführungsstatus für diesen Aufruf auf. Die API modifiziert dieses Feld nicht. Das Statusfeld weist den Ausführungsstatus für diesen Aufruf auf. Wenn die Anwendung diese Routine asynchron aufruft, weist dieses Feld den Status PENDING auf, bis die Ausführungsroutine aufgerufen wird.
Die Routine MGMTDeAllocateChannel verwendet die in dem Abschnitt des IEEE 1394 Standards definierten Protokolle für die Aufhebung der Zuweisung einer einzigen isochronen Kanalnummer. Die Konvention für den Aufruf der Routine MGMTDeAllocateChannel lautet wie folgt:
status MGMTDeAllocateChannel (ActivateRegPtr context, MGMTAllocateChBlocPtr allocateChBlock);
Die Routine verwendet zwei Parameter und gibt einen Statuswert zurück. Die möglichen Statusrückgabewerte für MGMTDeAllocateChannel sind GOOD, wodurch angezeigt wird, dass die Zuweisung für den Kanal erfolgreich aufgehoben worden ist, INVALIDCONNECTION, wodurch angezeigt wird, dass der Kontextparameter nicht die Adresse einer gegenwärtig aktiven Verbindung mit der API aufweist, PENDING, wodurch angezeigt wird, dass die API die Anforderung angenommen hat, CHUNAVAILABLE, wodurch angezeigt, dass die angeforderte Kanalnummer nicht zugewiesen worden ist, und UNDEFINEDERROR, wodurch angezeigt wird, dass ein unerwarteter Fehler aufgetreten ist. Wenn ein ausstehender Wert zurückgegeben worden ist, ruft die API die Routine MGMTCompletion auf, wenn die Zuweisungsanforderung vollständig ausgeführt worden ist, und wobei das Statusfeld zu diesem Zeitpunkt den Ausführungsstatus für diese Anforderung aufweist.
Der erste aufrufende Parameter einer Routine MGMTDeAllocateChannel ist die Adresse einer aktiven ActivateReq Datenstruktur. Der zweite Parameter weist die Adresse einer Datenstruktur MGMTAllocateChBlock auf. Diese Routine hebt die Zuweisung des in dem Kanalfeld dieser Datenstruktur definierten Kanals auf und füllt das Feld chAvailable mit dem aktuellen Wert der Bitmaske channels available des aktuelle aktiven isochronen Ressourcenmanagers.
Die Routine MGMTDeAllocateBandwidth verwendet die in dem Abschnitt 8 des IEEE 1394 Standards definierten Protokolle für die Aufhebung der Zuweisung isochroner Bandbreite. Die Konvention für den Aufruf der Routine MGMTDeAllocateBandwidth lautet wie folgt:
status MGMTDeAllocateBandwidth (ActivateRegPtr context, MGMTAllocateChBlockPtr allocateChBlock);
Die Routine verwendet zwei Parameter und gibt einen Statuswert zurück. Die möglichen Statusrückgabewerte für eine Routine MGMTDeAllocateBandwidth sind GOOD, wodurch angezeigt wird, dass die Zuweisung von Bandbreite erfolgreich aufgehoben worden ist, INVALIDCONNECTION, wodurch angezeigt wird, dass der Kontextparameter nicht die Adresse einer aktuell aktiven Verbindung mit der API aufweist, PENDING, wodurch angezeigt wird, dass die API die Anforderung angenommen hat, BWUNAVAILABLE, wodurch angezeigt wird, dass die Ausführung dieser Anforderung bewirken würde, dass das Register bandwidth available in dem isochronen Ressourcenmanager ungültig und keine Maßnahme ergriffen wird, und UNDEFINEDERROR, wodurch angezeigt wird, dass ein unerwarteter Fehler aufgetreten ist. Wenn ein ausstehender Wert zurückgeführt worden ist, ruft die API die Routine MGMTCompletion auf, wenn die Zuweisungsanforderung vollständig ausgeführt worden ist, und zu diesem Zeitpunkt weist das Statusfeld den Ausführungsstatus für diese Anforderung auf.
Bei dem ersten Aufrufparameter der Routine MGMTDeAllocateBandwidth handelt es sich um die Adresse einer aktiven ActiveReq Datenstruktur. Der zweite Parameter weist die Adresse einer MGMTAllocateBWBlock Datenstruktur auf. Diese Routine hebt die Zuordnung der Bandbreite in dem Bandbreitenfeld auf und füllt das Feld bwAvailable mit dem aktuellen Wert des Registers bandwidth available in dem aktuell aktiven isochronen Ressourcenmanager.
Die Routine MGMTBusInfo gibt Informationen über den Knoten zurück, an dem die Anwendung ausgeführt wird sowie den verbundenen IEEE 1394 Bus. Zu diesen Informationen zählen die aktuelle Einstellung des PHY Lückenwertes, die Anzahl der mit dem IEEE 1394 verbundenen Busses, ein Zeiger auf die Bustopologieabbildung und ein Zeiger auf die Busgeschwindigkeitsabbildung gemäß der Definition in dem IEEE 1394 Standard.
Die Routine ASYNDataRequest erzeugt eine oder mehrere IEEE 1394 asynchrone Lese- oder Schreibtransaktionen zur Übertragung von Daten zwischen dem Datenpuffer der Anwendung und einem linearen Bereich von Adressen in dem IEEE 1394 64-Bit-Adressraum. Die Konvention für den Aufruf der Routine ASYNDataRequest lautet wie folgt:
STATUS ASYNDataRequest (ActivateRegPtr request, asyncTransportPtr xfrBlock);
Die möglichen Statusrückgabewerte für eine Routine ASYNDataRequest sind GOOD, wodurch angezeigt wird, dass die API die Datenübertragungsanforderung erfolgreich ausgeführt hat, PENDING, wodurch angezeigt wird, dass die API die Anforderung angenommen hat und diese zu einem späteren Zeitpunkt ausführt, INVALIDOPCODE, wodurch angezeigt wird, dass in dem Feld flags.opCode ein unbekannter Code vorhanden ist, INVALIDCONNECTION, wodurch angezeigt wird, dass das Feld activateRegPtr keine aktive Verbindung darstellt, und UNDEFINEDERROR, wodurch angezeigt wird, dass bei dem Versuch der Würdigung der Anforderung ein unerwarteter Fehler aufgetreten ist, wobei jedoch einige Daten übertragen worden sein können.
Der erste Parameter einer Routine ASYNDataRequest weist die Adresse einer gültigen activateReq auf. Der zweite Parameter weist die Adresse einer asyncTransport auf. Diese Datenstruktur beschreibt die angeforderte Datenübertragungsoperation gemäß Definition in der nachstehenden Tabelle VII.
TABELLE VII
Das Feld ASYdata weist private Daten zur Verwaltung der Anforderung auf. Das Feld OpCode weist einen Code auf, der die angeforderte Operation beschreibt und einen der in asyncOpCodes definierten Werte darstellt. Wenn das Feld NonIncr auf Eins gesetzt ist, weist es die Routine an, alle Daten an die gleiche IEEE 1394 Adresse zu übertragen, die in dem Feld remoteBufPtr vorhanden ist, und wenn es auf Null gesetzt ist, wird die Routine angewiesen, Daten an einen inkrementierenden Bereich von IEEE 1394 Adressen zu übertragen, beginnend mit der Adresse in dem Feld remoteBufPtr. Das Feld BlockSize weist die maximale Größe in Bytes zur Verwendung für alle Blocklese- oder Schreibteilaktionen auf. Ein Wert von Null bedeutet die Verwendung der maximalen Anforderungsgröße für die ausgesuchte Busgeschwindigkeit. Das Feld APPLBufPtr weist den Deskriptor für den Anwendungsdatenpuffer auf. Das Feld RemoteBufPtr weist die 64-Bit-Adresse des Datenpuffers in einem entfernten IEEE 1394 Knoten auf. Das Feld Length (Länge) enthält die Anzahl der zu übertragenden Bytes, die kleiner oder gleich der Länge des Anwendungsdatenpuffers sein kann. Wenn das Feld AsyncCompletion ungleich Null ist, weist es die Adresse auf, welche die Routine nach der vollständigen Ausführung der Datenübertragung aufrufen soll. Das Feld UserPtr steht zur Verwendung durch die Ausführungsroutine der aufrufenden Anwendung zur Verfügung und wird nicht durch die API modifiziert. Das Statusfeld weist den Status der angeforderten Datenübertragungsoperation auf. Dieses Feld weist den Status "ausstehend" auf, bis die asynchrone Operation vollständig ausgeführt ist. Wenn die Ausführungsroutine aufgerufen wird, weist dieses Feld den Ausführungsstatus auf.
Die Routine ASYNLockRequest erzeugt eine Sperrtransaktion an dem IEEE 1394 Bus. Die Routine ASYNLockRequest weist die folgende Konvention für den Aufruf auf:
STATUS ASYNLockRequest (ActivateRegPtr request, AsyncLockBlockPtr lockBlock);
Die möglichen Statusrückgabewerte für eine Routine ASYNLockRequest sind GOOD, wodurch angezeigt wird, dass die API die Sperrtransaktion erfolgreich ausgeführt hat und sich die Ergebnisse in AsyncLockBlock befinden, PENDING, wodurch angezeigt wird, dass die API die Anforderung angenommen hat und diese zu einem spätere Zeitpunkt ausführt, INVALIDOPCODE, wodurch angezeigt wird, dass sich in dem Feld OpCode der Datenstruktur AsyncLockBlock ein unbekannter Code befindet, INVALIDCONNECTION, wodurch angezeigt wird, dass das Feld activateRegPtr keine aktive Verbindung darstellt, und UNDEFINEDERROR, wodurch angezeigt wird, dass bei dem Versuch der Würdigung der Anforderung ein unerwarteter Fehler aufgetreten ist, wobei jedoch einige Daten übertragen worden sein können.
Der erste Parameter in der Routine ASYNLockRequest weist die Adresse einer gültigen activateReq Datenstruktur auf. Der zweite Parameter weist die Adresse einer AsyncLockBlock Datenstruktur auf. Diese Datenstruktur beschreibt die angeforderte Datenübertragungsoperation gemäß der Definition in der nachstehenden Tabelle VIII.
TABELLE VIII
Das Feld APIPrivate weist private Daten für die Verwaltung der Anforderung auf. Das Feld OpCode weist einen Code auf, der die angeforderte Operation beschreibt und muss einen der in dem Enum asyncOpCodes efinierten Werte aufweisen. Das Feld ArgData struct weist das Argument und die Daten für diese Sperrtransaktion auf. Das Feld remoteBufPtr weist die 64-Bit-Zieladresse an dem IEEE 1394 Bus auf. Wenn das Feld AsyncCompletion ungleich Null ist, weist es die Adresse der Routine auf, die nach vollständiger Ausführung der Sperrtransaktion aufgerufen werden soll. Das Feld UserPtr steht zur Verwendung durch die Ausführungsroutine der aufrufenden Anwendung zur Verfügung und wird durch die API nicht modifiziert. Das Statusfeld weist den Status der angeforderten Datenübertragungsoperation auf. Das Feld weist den Status "ausstehend" auf, bis die asynchrone Operation vollständig ausgeführt worden ist. Wenn die Ausführungsroutine aufgerufen wird, weist dieses Feld den Ausführungsstatus auf.
Die Routinen Isochronous Resource Management weisen erforderliche Systemressourcen für die Übertragung isochroner Daten über die IEEE 1394 Schnittstelle in oder aus Anwendungsdatenpuffern zu oder heben derartige Zuweisungen bzw. Zuordnungen auf. Die Zuweisung oder die Aufhebung der Zuweisung ist erforderlich, um Konflikte zwischen mehreren potenziellen Anwendungen isochroner Daten in dem System zu verhindern. Bei jedem isochronen Datenstrom über den IEEE 1394 Bus gibt es eine Einheit an dem IEEE 1394 Bus, welche die Herrschaft über die erforderlichen Busressourcen aufweist, dies sind Kanalnummern und Bandbreite. Jede Anwendung, die isochrone Daten verwendet, weist ihren eigenen Satz geltender Regeln auf, wer diese Ressourcen zuweisen und derartige Zuweisungen aufheben muss und wann. Die Busmanagementroutinen in der API ermöglichen es, dass eine Anwendung diese Ressourcen gemäß den Anforderungen des IEEE 1394 Standards zuweist. Hiermit wird festgestellt, dass die Routinen in diesem Abschnitt keine IEEE 1394 Busressourcen zuweisen; diese Routinen weisen nur Systemebenenressourcen zu, die erforderlich sind, um isochrone Daten in oder aus Anwendungsdatenpuffern zu übertragen. Diese Ressourcen umfassen einen DMA-Kanal und die Systemressourcen zu dessen Aufrechterhaltung, wie etwa die Unterbrechungsbehandlungsroutine auf unterer Ebene und der Verteiler.
Die Routine TSOCHOpen öffnet und initialisiert einen isochronen Port. Ein isochroner Port ist eine Sammlung von Hardware- und Softwareressourcen in dem lokalen Knoten, an dem die Anwendung der API und die API ausgeführt werden. Diese Sammlung von Ressourcen sieht alles Erforderliche in dem lokalen Knoten für die Übertragung eines einzelnen Stroms isochroner Daten in und aus dem Knoten vor. Diese Sammlung von Ressourcen umfasst nicht die IEEE 1394 Busressourcen, welche die Anwendung separat zuweisen muss, und zwar gemäß den Verwaltungsregeln, die in Abschnitt 8 des IEEE 1394 Standards definiert sind sowie geltender Regeln und Anforderungen für die Anwendung. Die Routinen, die einer Anwendung der API die Zuweisung und die Aufhebung von Zuweisungen der IEEE 1394 Busressourcen ermöglichen, wurden vorstehend im Text beschrieben.
Die Routine zur Öffnung des Ports wird durch die folgende Konvention aufgerufen:
status ISOCHOpen (ActivateRegPtr connectionPtr, ISOCHOpenBlockPtr openBlock);
Der erste Parameter der Routine zum Öffnen eines Ports weist die Adresse einer gültigen activateReq Datenstruktur auf. Der zweite Parameter weist die Adresse einer ISOCHOpenBlock Datenstruktur auf. Nach erfolgreicher Ausführung dieser Routine verwendet die Anwendung diese ISOCHOpenBlock Datenstruktur als Verweis dieses offenen isochronen Ports in der Zukunft auf die API, die diesen Port beeinflusst.
Die möglichen Statusrückgabewerte für eine Routine zum Öffnen eines Ports sind Good, wodurch angezeigt wird, dass eine Öffnungsanforderung erfolgreich ausgeführt worden ist, PENDING, wodurch angezeigt wird, dass die API die Anforderung angenommen hat und diese zu einem späteren Zeitpunkt ausführt, NORESOURCES, wodurch angezeigt wird, dass ein isochroner Port oder eine andere erforderliche Ressource gegenwärtig nicht verfügbar ist und die Anforderung abgelehnt wird, INVALIDREQUEST, wodurch angezeigt wird, dass die angeforderte Busgeschwindigkeit nicht unterstützt wird, INVALIDCONNECTION, wodurch angezeigt wird, dass das Feld ActivateRegPtr keine aktive API-Verbindung darstellt, und UNDEFINEDERROR, wodurch angezeigt wird, dass die Anforderung nicht behandelt werden konnte, wobei der Fehler jedoch nicht identifiziert werden konnte.
Der Aufrufparameter einer Routine zum Öffnen eines Ports weist die Adresse einer ISOCHOpenBlock Datenstruktur auf. Diese Datenstruktur beschreibt die Anforderung gemäß der Definition in der folgenden Tabelle IX.
TABELLE IX
Das Richtungsfeld zeigt die Richtung der isochronen Datenübertragung an. Wenn das Feld AsyncCompletion ungleich Null ist, weist es die Adresse auf, welche die Routine nach der vollständigen Ausführung aufrufen soll. Das Feld UserPtr steht zur Verwendung durch die Ausführungsroutine der aufrufenden Anwendung zur Verfügung und wird durch die API nicht modifiziert. Das Statusfeld weist den Status der angeforderten Datenübertragungsoperation auf. Das Feld weist den Status "ausstehend" auf, bis die asynchrone Datenübertragungsoperation vollständig ausgeführt worden ist. Wenn die Ausführungsroutine aufgerufen wird, weist dieses Feld den Ausführungsstatus auf. Wenn die Anwendung mit dem isochronen Port fertig ist, leitet es isochPortPtr an die Routine ISOCHClose weiter.
Die Routine ISOCHClose schließt einen vorher mit Hilfe der Routine ISOCHOpen geöffneten isochronen Port. Diese Routine weist die folgende Konvention für den Aufruf auf:
STATUS ISOCHClose (ActivateRegPtr connectionPtr, ISOCHOpenBlockPtr openBlock);
Diese Routine nimmt eine einzigen Parameter und gibt einen Statuswert zurück. Diese Routine wird asynchron ausgeführt und ruft die in ISOCHOpenBlock definierte Ausführungsroutine nach der Ausführung auf. Die möglichen Statusrückgabewerte einer Routine ISOCHClose sind GOOD, wodurch angezeigt wird, dass die Operation erfolgreich ausgeführt worden ist, PENDING, wodurch angezeigt wird, dass die API die Anforderung angenommen hat und diese zu einem späteren Zeitpunkt ausführen wird, INVALIDCONNECTION, wodurch angezeigt wird, dass connectionPtr keine aktive API-Verbindung darstellt oder dass openBlock keinen zur Zeit offenen isochronen Port darstellt, und UNDEFINEDERROR, wodurch angezeigt wird, dass die Anforderung nicht bearbeitet werden kann, wobei der Fehler nicht identifiziert werden konnte.
Bei dem ersten Aufrufparameter der Routine ISOCHClose handelt es sich um die Adresse einer gültigen Datenstruktur activateReq. Der zweite Aufrufparameter ist die Adresse der Routine ISOCHOpenBlock, die zum Öffnen des Ports mit der Routine ISOCHOpen verwendet wird.
Die Steuerroutine für isochrone Daten steuert einen Strom isochroner Daten in oder aus den Anwendungsdatenpuffern. Bei Anwendungen, die auf isochrone Daten hören, beeinflussen diese Steuerroutinen lediglich den Fluss isochroner Daten in das System, wobei sie die isochronen Daten an dem IEEE 1394 Bus selbst nicht beeinflussen. Bei Anwendungen, die isochrone Daten von Anwendungspuffern übermitteln, beeinflussen diese Steuerroutinen auch den Fluss isochroner Daten an dem IEEE 1394 Bus.
Die Routine ISOCHControl weist die folgende Konvention für den Aufruf auf:
STATUS ISOCHControl (ISOCHOpenBlockPtr opensBlockPtr, ISOCHCtlBlockPtr ctlRegPtr);
Die möglichen Statusrückgabewerte für eine Routine ISOCHControl sind GOOD, wodurch angezeigt wird, dass die Operation erfolgreich ausgeführt worden ist, INVALIDCONNECTION, wodurch angezeigt wird, dass das Feld openBlock keine aktiven isochronen Port darstellt, PENDING, wodurch angezeigt wird, dass die Operation derzeit anstehend ist, INVALIDOPCODE, wodurch angezeigt wird, dass das Feld opCode von ISOCHControlBlock einen ungültigen Wert aufweist, UNSUPPORTEDOP, wodurch angezeigt wird, dass die Operation aufgrund einer Restriktion an der Hardware der IEEE 1394 Schnittstelle oder einer Restriktion der Software oder der Betriebsumgebung nicht unterstützt wird, und UNDEFINEDERROR, wodurch angezeigt wird, dass die Operation nicht ausgeführt werden konnte, wobei der Fehler nicht identifiziert werden konnte. Wenn ein anstehender Wert zurückgegeben wird, weist das Statusfeld in ISOCHControlBlock zum Zeitpunkt des Aufrufs der Rückrufroutine einen Ausführungsstatus der Steueranforderung auf.
Der erste Parameter einer Routine ISOCHControl weist die Adresse einer gültigen ISOCHOpenBlock Datenstruktur auf. Der zweite Parameter weist die Adresse einer ISOCHCtlBlock Datenstruktur auf. Diese Datenstruktur beschreibt die angeforderte Steueroperation gemäß der Definition in der folgenden Tabelle X.
TABELLE X
Das Feld APIPrivate weist den privaten Speicher auf, den die API zur Verwaltung dieser Anforderung verwendet. Das Feld IsoOpCode weist einen Wert aus dem IsoOpCode Enum auf, das die angeforderte Steueroperation beschreibt. Das Feld IsoEvent spezifiziert das auslösende Ereignis, bei dem die angeforderte Operation ausgeführt wird. Wenn das Feld IsoEvent den Wert "SYFIELD" aufweist, so weist das Feld Sy den Wert in dem Fe3ld Sy auf, der bewirkt, dass der isochrone Kanal startet oder stoppt. Wenn das Feld IsoOpCode den Wert "START" aufweist, wird der Wert aus dem Feld Tag als Tag-Wert in dem Header des isochronen Datenblockpakets verwendet. Wenn das Feld IsoOpCoe den Wert "START" aufweist, wird der Wert aus dem Kanalfeld für den Kanalwert in dem Header des isochronen Datenblockpakets verwendet. Wenn das Feld IsoEvent den Wert "TIME" aufweist, weist das Zeitfeld die Buszeit auf, zu der die angeforderte Aktion erfolgen soll. Wenn das Feld AsyncCompletion ungleich Null ist, weist es die Adresse der Routine auf, die nach der Ausführung der Datenübertragung aufgerufen werden soll. Das Feld UserPtr steht zur Nutzung durch die Ausführungsroutine der aufrufenden Anwendung zur Verfügung. Die API modifiziert dieses Feld nicht. Das Statusfeld weist den Status der angeforderten Datenübertragungsoperation auf. Dieses Feld weist den Status "anstehend" auf, bis die asynchrone Datenübertragungsoperation vollständig ausgeführt ist. Wenn die Ausführungsroutine aufgerufen wird, weist dieses Feld den Ausführungsstatus auf.
Die isochrone Anhängungsroutine leitet die Deskriptoren der Anwendungsdatenpuffer an die API-Software weiter. Die Anwendung kann diese Routine zu jedem Zeitpunkt aufrufen, um die Puffer für die Hardware der IEEE 1394 Schnittstelle und die zugeordneten unteren Softwareebenen zur Verfügung zu stellen. Die Konvention für den Aufruf dieser Routine ist wie folgt gegeben:
status ISOCHAttach(ISOCHOpenBlockPtr openBlock, ISOCHAppendBlockPtr append);
Die möglichen Statusrückgabewerte für eine isochrone Anhängungsroutine sind GOOD, wodurch angezeigt wird, dass die Operation ausgeführt worden ist und die Anwendungsdatenpuffer angenommen werden, INVALIDCONNECTION, wodurch angezeigt wird, dass das Feld openBlock keinen aktiven isochronen Port darstellt, UNSUPPORTEDOP, wodurch angezeigt wird, dass das in einem Pufferdeskriptor spezifizierte Resynchronisierungsereignis nicht unterstützt wird, wobei dies auf die Hardware-Implementierung, die Software-Implementierung oder andere Restriktionen der Systemumgebung zurückzuführen sein kann, INVALIDREQUEST, wodurch angezeigt wird, dass ein Versuch zum Anhängen einer zirkularen Liste von Anwendungsdatenpuffern während dem Fluss isochroner Daten oder zum Anhängen neuer Puffer an eine bestehende zirkulare Liste während dem Fluss isochroner Daten ungültig gewesen ist, und UNDEFINEDEROR, wodurch angezeigt wird, dass die Operation nicht ausgeführt werden konnte, wobei kein tatsächlicher Fehler identifiziert werden konnte.
Der erste Parameter einer Routine ISOCHAttach weist die Adresse einer gültigen ISOCHOpenBlock Datenblock auf. Der zweite Parameter weist die Adresse einer ISOCHAppendBlock Datenstruktur auf. Diese Datenstruktur beschreibt die Anwendungsdatenpufferliste gemäß der Definition in der nachstehenden Tabelle XI.
TABELLE XI
Das Feld APIPrivate weist den privaten Speicher auf, den die API zur Verwaltung der Anforderung verwendet. Das Feld IsochBuffList weist die Adresse des ersten isochronen Puffers einer Liste zum Anhängen an den spezifizierten Port auf. Wenn die aktuelle Pufferliste oder die anzuhängende Pufferliste zirkular ist, kann die Operation nur ausgeführt werden, wenn der Port angehalten wird, und die Anhängeoperation ersetzt alle etwaigen vorher angehängten Puffer. Eine nicht zirkulare Liste von Puffern kann jederzeit an eine vorhandene nicht zirkulare Liste von Puffern angehängt werden. Wenn das Feld AsyncCompletion ungleich Null ist, weist es die Adresse der nach vollständiger Ausführung aufzurufenden Routine auf. Das Feld UserPtr steht zur Verwendung durch die Ausführungsroutine der aufrufenden Anwendung zur Verfügung und wird durch die API nicht modifiziert. Das Statusfeld weist den Status der angeforderten Operation auf. Dieses Feld weist den Status "PENDING" auf, bis die asynchrone Datenoperation vollständig ausgeführt ist. Wenn die Ausführungsroutine aufgerufen wird, weist das Feld den Ausführungsstatus auf.
Das Feld IsochBuffList weist die Adresse eines isochBuffer auf. Die isochBuffer Datenstruktur beschreibt einen einzigen Anwendungsdatenpuffer. Kennzeichnenderweise existieren die Datenstrukturen isochBuffer in einer doppelt verknüpften Liste. Diese Datenstruktur ist in der nachstehenden Tabelle XII definiert.
TABELLE XII
Das Feld Next weist die Adresse des nächsten Puffers in der Liste auf. Das Feld Previous weist die Adresse des vorherigen Puffers in der Liste auf. Das Feld Circular zeigt an, dass die vollständige Anordnung der Puffer zirkular ist. Das Feld ResynchEvent weist ein optionales Resynchronisierungsereignis auf. Ein Wert IMMEDIATE in diesem Feld zeigt keine Resynchronisierung an. Wenn das Feld ResynchEvent einen Wert "SYFIELD" aufweist, weist das Feld Sy den Sy Wert für eine Pause vor der Übertragung von Daten in oder aus diesem Anwendungsdatenpuffer auf. Wenn das Feld ResynchEvent einen Wert "TIME" aufweist, weist das Zeitfeld die Buszeit auf, die gewartet werden soll, bevor Daten in oder aus diesem Anwendungsdatenpuffer übertragen werden. Das Feld ApplBufPtr weist die Adresse des Anwendungsdatenpuffers auf. Die Adresse kann abhängig von den Fähigkeiten der Betriebsumgebung logisch, physikalisch, verstreut oder zusammenhängend sein. Das Feld IsochCompletion weist die Adresse der Ausführungsadresse auf. Wenn der Wert in diesem Feld ungleich Null ist, wird diese Routine aufgerufen, wenn die Datenübertragung für diesen Puffer vollständig ausgeführt ist. Das Feld UserPtr steht zur Verwendung durch die Ausführungsroutine der aufrufenden Anwendung zur Verfügung und wird durch die API nicht modifiziert.
Die Routine ISOCHDetach ruft die Anwendungsdatenpuffer von der API ab und gibt die Kontrolle an die Anwendung zurück. Die Anwendung kann diese Routine jederzeit aufrufen, um Puffer van der Hardware der IEEE 1394 Schnittstelle und zugeordneten unteren Ebenen der Software zu trennen. Die angeforderten Puffer werden getrennt, wenn die Ausführungsroutine aufgerufen wird. Die Konvention für den Aufruf dieser Routine lautet wie folgt:
status ISOCHDetach(ISOCHOpenBlockPtr openBlock, ISOCHAppendBlockPtr unhook);
Die möglichen Statusrückgabewerte einer Routine ISOCHDetach sind GOOD, wodurch angezeigt wird, dass die Operation vollständig ausgeführt worden ist und die Anwendungsdatenpuffer jetzt gelöst bzw. getrennt sind, PENDING, wodurch angezeigt wird, das die Operation gegenwärtig anstehend ist, INVALIDCONNECTION, wodurch angezeigt wird, dass das Feld openBlock keinen aktiven isochronen Port darstellt, INVALIDREQUEST, wodurch angezeigt wird, dass die in ISOCHAppendBlock beschriebenen Puffer nicht gefunden werden konnten oder dass sie nicht der Steuerung durch den in der Struktur ISOCHOpenBlock beschriebenen isochronen Port unterliegen, und UNDEFINEDERROF, wodurch angezeigt wird, dass die Operation nicht ausgeführt werden konnte, wobei kein tatsächlicher Fehler identifiziert werden konnte. Wenn ein anstehender Wert zum Zeitpunkt des Aufrufs der Rückrufroutine zurückgegeben wird, weist das Statusfeld in ISOCHAppendBlock den Ausführungsstatus für die Trennungsoperation auf.
Der erste Parameter einer Routine ISOCHDetach weist die Adresse einer gültigen ISOCHOpenBlock Datenstruktur auf. Der zweite Parameter weist die Adresse einer ISOCHAppendBlock Datenstruktur auf. Diese Datenstruktur beschreibt die Anwendungsdatenpufferliste gemäß der vorstehenden Definition.
Die vorliegende Erfindung wurde in Bezug auf spezifische Ausführungsbeispiele beschrieben, die Details zur Erleichterung des Verständnisses der Grundsätze der Konstruktion und des Einsatzes der vorliegenden Erfindung aufweisen. Verweise in der vorliegenden Beschreibung auf spezifische Ausführungsbeispiele und Einzelheiten dieser schränken den Umfang der anhängigen Ansprüche nicht ein. Für den Fachmann ist es erkennbar, dass Modifikationen bezüglich des zur Veranschaulichung ausgewählten Ausführungsbeispiels möglich sind, ohne dabei vom Umfang der Erfindung abzuweichen.

Claims

Verfahren zum Vorsehen einer Schnittstelle zu einer Anwendung (22) und Verwaltung von isochronen Datenübertragungsoperationen zwischen der Anwendung (22) und einer Busstruktur (28), wobei die genannte Schnittstelle eine Anwendungsprogrammierschnittstelle umfasst, welche die folgenden Schritte ausführt: a) Empfangen einer Anforderung für eine Datenübertragungsoperation von der Anwendung (22); und b) Verwalten einer verknüpften Liste von Pufferdeskriptoren, wobei jeder Deskriptor einem durch die Anwendung (22) vorgesehenen Puffer zur Ausführung der Datenübertragungsoperation entspricht, wobei die Daten zwischen einem Puffer und der Busstruktur (28) übertragen werden, während die Anwendung (22) einen weiteren Puffer verarbeitet; wobei die verknüpfte Liste einen Vorwärtszeiger und einen Rückwärtszeiger für jeden Puffer in der verknüpften Liste aufweist, und wobei die Anwendungsprogrammierschnittstelle ferner die Fähigkeit für ein Resynchronisierungsereignis unter Verwendung von Resynchronisierungsdaten von jedem der Puffer in der Liste aufweist, wobei das Resynchronisierungsereignis aktiviert wird, um die Anwendung (22) während einer Datenübertragungsoperation auf einen vorbestimmten Punkt zu resynchronisieren.
Verfahren nach Anspruch 1, wobei die Anwendung (22) während einer isonchronen Sendeoperation einen Puffer verarbeitet, indem Daten in den Puffer geladen werden.
Verfahren nach Anspruch 1, wobei die Anwendung (22) während einer isonchronen Empfangsoperation einen Puffer verarbeitet, indem Daten aus dem Puffer erhalten werden.
Verfahren nach Anspruch 1, wobei jeder Puffer aus der verknüpften Liste die Fähigkeit für eine Rückrufroutine aufweist, die aktiviert wird, um die Anwendung (22) an einem vorbestimmten Punkt während einer Datenübertragungsoperation aufzurufen.
Verfahren nach einem der vorstehenden Ansprüche, wobei das Verfahren ferner eine Einrichtung zum Hinzufügen von Pufferdeskriptoren zu der verknüpften Liste umfasst.
Verfahren nach Anspruch 5, wobei das Verfahren ferner eine Einrichtung zum Entfernen von Pufferdeskriptoren aus der verknüpften Liste umfasst.
Schnittstelle zwischen einer Anwendung (22) und einer Busstruktur (28) zur Verwaltung von Datenübertragungsoperationen zwischen der Anwendung (22) und der Busstruktur (28), wobei die Schnittstelle folgendes umfasst: a) eine Anwendungsprogrammierschnittstelle (20) zur Kommunikation mit der Anwendung (22) und zum Empfangen van Anforderungen von der Anwendung (229 und zum Senden von Befehlen an die Anwendung (22); b) ein Pufferverwaltungssystem zur Steuerung isochroner Datenübertragungsoperationen zwischen der Anwendung (22) und der Busstruktur (28), einschließlich der Verwaltung einer verknüpften Liste von Pufferdeskriptoren, die jeweils einem Puffer entsprechen und einen Puffer darstellen; und c) eine Busschnittstellenschaltung zum Vorsehen einer physikalischen Schnittstelle mit der Busstruktur (28) zum Senden und Empfangen von Datenpaketen von der Busstruktur (28) wobei die Puffer durch die Anwendung (22) vorgesehen werden, und wobei die verknüpfte Liste ferner einen Vorwärtszeiger und einen Rückwärtszeiger für jeden Puffer in der Liste aufweist, wobei die Anwendungsprogrammierschnittstelle die Fähigkeit für ein Resynchronisierungsereignis unter Verwendung von Resynchronisierungsdaten von jedem der Puffer in der Liste aufweist, wobei das Resynchronisierungsereignis aktiviert wird, um die Anwendung (22) während einer Datenübertragungsoperation auf einen vorbestimmten Punkt resynchronisiert wird.
Schnittstelle nach Anspruch 7, wobei jeder der Puffer in der Liste die Fähigkeit für eine Rückrufroutine aufweist, die aktiviert wird, um die Anwendung (22) an einem vorbestimmten Punkt während einer Datenübertragungsoperation aufzurufen.
Schnittstelle nach einem der vorstehenden Ansprüche, wobei es sich bei der Busstruktur (28) um eine IEEE 1394 Standard-Busstruktur handelt.
Schnittstelle nach einem der vorstehenden Ansprüche, wobei die Schnittstelle ferner eine Einrichtung zum Hinzufügen von Puffern zu der verknüpften Liste umfasst.
Schnittstelle nach Anspruch 10, wobei die Schnittstelle ferner eine Einrichtung zum Entfernen von Puffern aus der verknüpften Liste umfasst.