DE69232456T2

DE69232456T2 - Bidirektionales Parallelprotokoll

Info

Publication number: DE69232456T2
Application number: DE69232456T
Authority: DE
Inventors: Jeff D. Pipkins
Original assignee: Compaq Computer Corp
Current assignee: Compaq Computer Corp
Priority date: 1991-08-27
Filing date: 1992-08-13
Publication date: 2002-09-26
Anticipated expiration: 2012-08-14
Also published as: US5666558A; DE69232456D1; CA2075774C; MY153949A; EP0529887A3; CN1070497A; KR930004868A; EP0529887A2; EP0529887B1; BR9203330A; IE922610A1; AU2102392A; AU645920B2; MX9204892A; ATE214172T1; IL102823A0; US5507003A; TW203673B; JPH05341923A; CA2075774A1

Description

Die vorliegende Erfindung betrifft Protokolle, und insbesondere solche Protokolle, die eine Kommunikation in beiden Richtungen durch eine parallele Schnittstelle ermöglichen.
Ports sind Fachleuten auf dem Gebiet der Elektronik als Orte des Zugriffs auf ein Gerät oder Netzwerk bekannt, an denen Energie geliefert oder abgezogen werden kann, oder an denen Variablen des Geräts oder des Netzwerks beobachtet oder gemessen werden können. Ports lassen sich in zwei Kategorien aufteilen: seriell oder parallel. Erwartungsgemäß findet bei seriellen Ports eine Verarbeitung oder Handhabung zeitlich nacheinander statt, und bei parallelen Ports eine Verarbeitung oder Handhabung gleichzeitig.
Auf dem Gebiet von Mikroprozessoren umfaßt der Begriff "Ports" sogenannte "Tore" oder Öffnungen für Daten zum Durchgang von der Außenwelt zum Mikroprozessorsystem oder in Gegenrichtung. Mikroprozessoren weisen sowohl serielle als auch parallele Ports auf. In der Vergangenheit wurde der serielle Port in weitem Ausmaß so angesehen, dass er nützlich ist zur Kommunikation mit Modems, WANS oder dergleichen, und wurde vielfältige Software entwickelt, welche serielle Kommunikation unterstützt. Parallele Ports andererseits wurden herkömmlich nur für relativ einfache Aufgaben wie Drucken und Plotten verwendet, hauptsächlich deswegen, da sie so angesehen wurden, dass sie nur in einer Richtung arbeiten.
Vor kurzem wurde langsam von Fachleuten erkannt, dass ein Standard- Parallelport in zwei Richtungen arbeitet, nämlich dass man Eingaben oder Ausgaben auf bis zu zwölf Leitungen gleichzeitig durchführen kann. Eine serielle Karte andererseits kann Eingaben oder Ausgaben nur auf einer einzelnen Leitung vornehmen, mit einem Bit zur Zeit. Vergleicht man den Betrieb der beiden Ports, so wird die relative Überlegenheit des parallelen Ports deutlich: er kann ein Byte und ein halbes Byte in der Zeit ausgeben, die ein serieller Port zur Feststellung benötigt, ob die Zeit gekommen ist, eine einzelne Transaktion durchzuführen.
Weiterhin wurde erst vor sehr kurzer Zeit von Fachleuten erkannt, dass bestimmte Vorteile bei der Verwendung eines parallelen Ports für die Art von Kommunikation vorhanden sind, die normalerweise einem seriellen Port zugeordnet ist. Einige dieser Vorteile werden von Ross Greenburg in einem Artikel mit dem Titel "Adapting the Parallel Port for Bidirectional Communication" erläutert, der beginnend auf Seite 107 der Ausgabe vom September 1990 des Microsoft Systems Journal abgedruckt ist. In diesem Artikel erläutert Herr Greenburg, dass Kommunikation nicht immer in ASCII durchgeführt werden muß. Beispiele für derartige Gelegenheiten sind jene, wenn der Ein/Auszustand eines Sensors gelesen wird, oder wenn eine Leitung zu einem Relais ein- oder ausgeschaltet wird. Es ist vollständig unnötig, in derartigen Fällen einen seriellen Port zu verwenden, da nämlich die reale Welt sehr einfach an einen parallelen Port angeschlossen werden kann. Herr Greenburg bemerkt auch, dass infolge der Tatsache, dass ein paralleler Port mehrere Bits gleichzeitig annehmen oder wegschicken kann, er dazu fähig sein sollte, schnellere I/O als ein serieller Port zur Verfügung zu stellen. Selbstverständlich sind spezielle Codes und Protokolle, beispielsweise das hier vorgeschlagene Protokoll, dazu erforderlich, um die Fähigkeiten eines parallelen Ports vollständig zu nutzen.
Da sich die vorliegende Erfindung speziell mit Kommunikation befaßt, die einen Drucker betrifft, stellt Kommunikation mit derartigen Druckern einen Teil des zugehörigen Stands der Technik dar. Um die Möglichkeiten eines Druckers vollständig auszunutzen, beispielsweise eines Postscript-Druckers, muß ein Hostcomputer Abfragen senden und die entsprechenden Antworten empfangen können. Selbstverständlich kann, wie bereits erwähnt, Kommunikation in zwei Richtungen, hier zwischen einem Hostcomputer und einem Drucker, durch eine serielle Schnittstelle zur Verfügung gestellt werden. Allerdings kann, wie erst in jüngster Zeit erkannt wurde, Kommunikation in zwei Richtungen mit erheblich höheren Geschwindigkeiten auch durch eine parallele Schnittstelle zur Verfügung gestellt werden. Fachleute auf diesem Gebiet haben die letztgenannte Fähigkeit noch nicht dazu genutzt, Benutzern von Hostcomputer- und Druckersystemen die Funktionen der seriellen Schnittstelle zur Verfügung zu stellen, ohne die einfache Installierung und die höheren Übertragungsgeschwindigkeiten der parallelen Schnittstelle zu opfern. Daher stellt es einen Nachteil und eine Unzulänglichkeit beim Stand der Technik dar, dass niemand bislang ein entwicklungsfähiges Protokoll entwickelt hat, um Kommunikation in zwei Richtungen zwischen einem Hostcomputer und einem Drucker über eine parallele Schnittstelle zu gestatten.
Die US-A-4720813 beschreibt ein Kommunikationsprotokoll für zwei Richtungen. Auch Electronics World and Wireless World, Vol. 95, Nr. 1645, November 89, Seite 1089-1092 beschreibt ein Kommunikationsprotokoll in zwei Richtungen.
Die vorliegende Erfindung überwindet die Nachteile und Unzulänglichkeiten des Stands der Technik durch Bereitstellung eines Verfahrens zur Bereitstellung einer Rückkanalkommunikationsfähigkeit zwischen einem Computer und einem Drucker über eine parallele Schnittstelle, wobei das Verfahren folgende Schritte umfaßt:
a) Leiten eines Übertragungsmodussignals durch den Computer zu dem Drucker, wobei das Übertragungsmodussignal dazu dient, den Drucker in einen Übertragungsmodus zu versetzen;
b) Leiten eines ersten Signals durch den Computer zu dem Drucker, das anzeigt, dass das Übertragungsmodussignal zum Lesen bereit ist;
c) Leiten eines zweiten Signals durch den Drucker zu dem Computer, das anzeigt, dass der Drucker Computerdaten in dem Übertragungsmodus erzeugt, der in Schritt a) angezeigt wird;
d) Leiten eines Bereitschaftssignals durch den Drucker zu dem Computer, das anzeigt, dass das zweite Signal zum Lesen bereit ist;
e) Leiten eines dritten Signals durch den Computer zu dem Drucker, das anzeigt, dass der Computer bereit ist, eine erste Dateneinheit von dem Drucker zu empfangen;
f) Leiten der ersten Dateneinheit durch den Drucker zu dem Computer;
g) Leiten eines vierten Signals durch den Drucker zu dem Computer, das anzeigt, dass die erste Dateneinheit zum Lesen bereit ist
h) Leiten eines fünften Signals durch den Computer zu dem Drucker, das anzeigt, dass der Computer bereit ist, mehr Dateneinheiten zu empfangen;
i) Leiten einer zweiten Dateneinheit durch den Drucker zu dem Computer;
j) Leiten eines sechsten Signals durch den Drucker zu dem Computer, das anzeigt, dass die zweite Dateneinheit zum Lesen bereit ist.
Bei Ausführungsformen der vorliegenden Erfindung wird die Vorrichtung zum Umdrehen des Vorwärtskanals durch den Hostcomputer aktiviert. Bei diesen und auch bei anderen Ausführungsformen der vorliegenden Erfindung wird die Vorrichtung zum Umdrehen des Rückkanals zurück, um so den Vorwärtskanal erneut einzurichten, durch den Hostcomputer aktiviert.
Bei bestimmten Ausführungsformen der vorliegenden Erfindung umfaßt der Vorwärtskanal Statusleitungen, die zur Übertragung von Daten zwischen dem Drucker und dem Hostcomputer während des Rückkanalbetriebs verwendet werden.
Weiterhin kann gemäß der erfindungsgemäßen Lehre der Vorwärtskanal ein Eingabe/Ausgabe-Steuerkanal sein, der dazu verwendet werden kann, Steuer- und Statusinformation zwischen dem Drucker und dem Hostcomputer während des Rückkanalbetriebs zu übertragen.
Weiterhin kann gemäß der erfindungsgemäßen Lehre die Vorrichtung zum Steuern der Übertragung von Daten eine Vorrichtung für den Hostcomputer sein, um ein Paket aus Daten von Statusleitungen anzufordern. Bei derartigen Ausführungsformen der vorliegenden Erfindung kann das Datenpaket ein Halbbit aus Daten sein, kann die Vorrichtung für den Hostcomputer zum Anfordern eines Halbbits von Daten ein Signal *STROBE sein, und kann die Vorrichtung für den Drucker, um anzuzeigen, dass ein Halbbit von Daten sich auf den Statusleitungen befindet, ein SLCT-Signal sein. Bei derartigen Ausführungsformen kann ein Low-Halbbit von Daten über ein abgesenktes Signal *STROBE angefordert werden, und als Übertragung über ein angehobenes SLCT-Signal angezeigt werden; weiterhin kann ein High- Halbbit aus Daten über ein angehobenes Signal *STROBE angefordert werden, und als Übertragung über ein abgesenktes SLCT-Signal angezeigt werden.
Ausführungsformen der vorliegenden Erfindung können auch Vorrichtungen für den Drucker umfassen, die dazu dienen, dem Hostcomputer anzuzeigen, wieviele Datenbytes von dem Drucker an den Hostcomputer übertragen werden sollen.
Bei Ausführungsformen des Verfahrens gemäß der vorliegenden Erfindung können eine oder beide der Kanalumdrehschritte durch den Hostcomputer aktiviert werden.
Gemäß der erfindungsgemäßen Lehre kann der Vorwärtskanal Statusleitungen aufweisen, die zur Übertragung von Daten zwischen dem Drucker und dem Hostcomputer während des Rückkanalbetriebs verwendet werden können. Weiterhin kann gemäß der erfindungsgemäßen Lehre der Vorwärtskanal ein Eingabe/Ausgabesteuerkanal sein, der dazu verwendet werden kann, Steuer- und Statusinformation zwischen dem Drucker und dem Hostcomputer während des Rückkanalbetriebs zu übertragen.
Weiterhin kann gemäß der erfindungsgemäßen Lehre der Schritt der Steuerung der Übertragung von Daten den Schritt umfassen, dass der Hostcomputer ein Datenpaket anfordert, den Schritt, dass der Drucker anzeigt, dass sich ein Datenpaket auf Statusleitungen befindet, sowie den Schritt, dass der Hostcomputer das Datenpaket aus den Statusleitungen ausliest. Bei derartigen Ausführungsformen des Verfahrens gemäß der vorliegenden Erfindung kann das Datenpaket ein Daten- Halbbit sein. Weiterhin kann bei Ausführungsformen des Verfahrens gemäß der vorliegenden Erfindung der Schritt, dass der Drucker anzeigt, dass sich ein Daten- Halbbit auf Statusleitungen befindet, ein SLCT-Signal umfassen. Bei Ausführungsformen wie jenen, die voranstehend geschildert wurden, kann ein Halbbit von Daten mit dem Wert "Low" über ein abgesenktes Signal *STROBE angefordert werden, und als Übertragen durch ein angehobenes SLCT-Signal angezeigt werden, und kann weiterhin ein Daten-Halbbit mit dem Wert "High" über ein angehobenes Signal *STROBE angefordert werden, und als Übertragen über ein abgesenktes SLCT-Signal angezeigt werden.
Ein weiteres Ziel der vorliegenden Erfindung besteht in der Bereitstellung eines Protokolls, das für sich schlecht verhaltende Software transparent ist, welche direkt den parallelen Port treibt.
Ein weiteres Ziel der Erfindung besteht in der Bereitstellung eines Protokolls, bei welchem der Hostcomputer den Drucker schnell und wirksam abfragen kann, um festzustellen, ob irgendwelche zu lesenden Daten vorhanden sind.
Ein weiteres Ziel der vorliegenden Erfindung besteht in der Bereitstellung eines Protokolls, das keine Echtzeit-Randbedingungen dem Hostcomputer auferlegt.
Ein weiteres Ziel der vorliegenden Erfindung besteht in der Bereitstellung eines robusten, erweiterbaren Protokolls.
Andere Ziele, Vorteile und neue Merkmale der vorliegenden Erfindung werden aus der folgenden, detaillierten Beschreibung der Erfindung deutlich, unter Berücksichtigung der beigefügten Zeichnungen, wobei:
Fig. 1 ein Blockschaltbild eines parallelen Druckeradapters nach dem Stand der Technik ist;
Fig. 2 Einzelheiten einer Parallelport-Schnittstelle zeigt; und
Fig. 3 Signalübertragungen im Verlauf der Zeit in einem Protokoll gemäß der erfindungsgemäßen Lehre erläutert.
In den Figuren, in denen gleiche oder entsprechende Elemente mit gleichen Bezugszeichen bezeichnet sind, ist in Fig. 1 ein bereits entwickelter paralleler Druckeradapter dargestellt. Fig. 1 zeigt deutlich eine Anzahl an Einzelheiten, die wesentlich für den Aufbau und die Umsetzung der vorliegenden Erfindung in die Praxis sind.
Unter Bezugnahme auf Fig. 1 läßt sich zunächst anmerken, dass ein paralleler Port eines der einfachsten Bauteile eines Computers darstellt. Ein derartiger Port weist vier unterschiedliche Teile auf: einen Adressendekodierabschnitt, einen Schreiblogikabschnitt, einen physikalischen Eingabe/Ausgabeabschnitt; und einen Abschnitt zur Übertragung der Eingabe/Ausgabe an einen Bus. Im allgemeinen läuft der Betrieb des parallelen Ports folgendermaßen ab.
Zuerst wird der Adressendekodierabschnitt 2 aktiviert, wenn sich eine bestimmte Adresse auf einem Bus 4 befindet. Der Schreiblogikabschnitt 6 nimmt die Daten auf dem Bus 4 an und liefert sie an den physikalischen Eingabe/Ausgabeabschnitt 8. Der Abschnitt zur Übertragung von Eingabe/Ausgabe an den Bus macht die Daten von der Eingabe/Ausgabe dem Bus verfügbar, wenn dies angefordert wird.
Vier Adressen schalten den parallelen Port frei, zusammen mit den - oder -Busleitungen 10, 12. Die - und -Busleitungen IOR und IOW 12, 14 zeigen an, dass ein Eingabe- oder Ausgabevorgang eines Ports auf dem Bus stattfindet. Da normale Speicherlese- und Schreibvorgänge nicht die Anschlüsse einstellen, welche diesen Leitungen zugeordnet sind, ignoriert die gesamte Karte diese Arten von Operationen.
Die verschiedenen Kombinationen von Leitungen gestatten das Beschreiben und Lesen der Status- und Datenleitungen auf dem DB-25-Verbinder 14.
In Fig. 2 ist als Blockschaltbild die Hardware und das Kabel einer PC- Parallelport-Schnittstelle dargestellt. Diese Schnittstelle weist drei Register auf, die alle direkt durch Software manipuliert werden. Diese drei Register sind an Datenregister 24, ein Statusregister 26 und ein Steuerregister 28. Jedes dieser drei Register 24, 26 und 28 wird in einem gesonderten Absatz unmittelbar nachstehend erläutert.
Das Datenregister 24 ist ein Lese/Schreibzwischenspeicher mit 8 Bit nur für die Ausgabe. Der Zwischenspeicher kann gelesen werden, um die Daten festzustellen, die zuletzt in ihn eingeschrieben wurden. Obwohl bereits einige Vorgehensweise vorgeschlagen wurden, um diesen Zwischenspeicher so zu überlisten, dass er zur Eingabe verwendet wird, waren diese Vorgehensweisen bestenfalls nicht verläßlich, und beschädigten im schlimmsten Fall die Hardware.
Das Statusregister 26 ist nicht tatsächlich ein Register, sondern ein Port ohne Zwischenspeicherung für die Eingabe. Der Begriff "Statusregister" wird hier deswegen verwendet, um eine Verwechslung mit dem Begriff "Port" zu verhindern. Das "Lesen des Statusregisters" sollte hier so verstanden werden, dass eine Echtzeitabtastung der Statusleitungen gemeint ist.
Das Steuerregister 28 ähnelt dem Datenregister 24 in der Hinsicht, dass es ebenfalls ein Lese/Schreibzwischenspeicher nur für die Ausgabe ist. Die drei unbenutzten Bit in dem oberen Teil des Registers 28 werden traditionell als Einsen gelesen, sollten jedoch als Nullen zurückgeschrieben werden. Dies verhindert Fehlfunktionen bei bestimmten neueren Implementierungen, welche das Bit 5 verwenden. Das Bit 4 ist nicht tatsächlich eine Druckersteuerleitung; es wird zum Freischalten/Sperren des Interrupts verwendet.
Die Polarität der Status- und Steuerleitungen kann eine Hauptquelle von Verwirrungen darstellen. Dies wird noch dadurch verschlechtert, dass einige der Leitungen an der Schnittstelle invertiert werden. Eine gute Festlegung für die Benennung kann bei einer Implementierung viel Zeit und Mühen sparen helfen.
Ein Signal Aktiv-Low ist ein Zustand, der durch eine niedrige Spannung statt eine hohe Spannung angezeigt wird. Man bezeichnet das Signal *ACK als Aktiv-Low, da eine niedrige Spannung auf dieser Leitung eine Bestätigung von dem Drucker anzeigt. Das Sternchen (*) ist ein Teil des Namens, und dient als Erinnerung daran, dass das Signal Aktiv-Low ist.
Die PC-Parallelport-Schnittstelle invertiert das Signal BUSY und macht das Ergebnis als Bit 7 des Statusregisters 26 verfügbar. Wir bezeichnen dieses Bit als ~BUSY. Diese Tilde (-) gibt an, dass das Signal in Bezug auf das Kabel invertiert wird. Die Signale ~*STROBE, ~*AUTOLF und ~*SLCTin sind sowohl Aktiv-Low als auch in Bezug auf das Kabel invertiert.
Es wird darauf hingewiesen, dass einige Signale auf mehr als eine Art und Weise bezeichnet werden können. Beispielsweise ist die Aussage, dass *SLCTin abgesenkt wird, gleich der Aussage, dass ~*SLCTin angehoben wird. Bei Diskussion des Protokolls wird normalerweise das Signal so bezeichnet, wie es auf dem Kabel auftaucht, und nicht so, wie es auf der PC-Schnittstelle auftaucht.
Eine weitere mögliche Quelle für Verwirrungen stellt das Kabel selbst dar, einfach deswegen, da es bei dem in Fig. 2 gezeigten Beispiel einen Steckverbinder des Typs DB-25 an dem PC-Ende aufweist, und einen Centronix-Steckverbinder mit 36 Stiften am Druckerende. So ist beispielsweise die Bezugnahme auf einen "Stift k" mehrdeutig, da die Verbinder nicht in der Beziehung Eins zu Eins stehen. Fig. 2 stellt daher eine Nachschlagquelle für einen Programmierer für einen PC-Parallelport dar. Sie zeigt die Kabelanschlüsse mit Stiftnummern für beide Verbinder, die Signalbezeichnungen, die den Leitungen zugeordnet sind, die Register, auf welche durch den PC zugegriffen werden kann, und die der Schnittstelle zugeordneten Inverter.
Mit dem voranstehend geschilderten Hintergrund kann nunmehr im einzelnen ein Protokoll gemäß der erfindungsgemäßen Lehre diskutiert werden. Aus Gründen, die nachstehend deutlich werden, kann dieses Protokoll als "Halbbit-Modus- Rückkanalprotokoll" bezeichnet werden.
Herkömmlich erfolgt die Übertragung von Daten von dem Host an den Drucker über den Vorwärtskanal. Das Protokoll für zwei Richtungen gemäß den Lehren der vorliegenden Erfindung richtet einen Rückkanal für die Übertragung von Daten von dem Drucker an den Host ein.
Bei der Übertragung auf dem Vorwärtskanal taucht ein Byte pro Zeit auf; jedes Byte wird unabhängig übertragen. Der Rückkanal ist Dialog orientiert; jede Anzahl an Bytes (zwischen 0 und 16384) kann in einem einzigen Dialog übertragen werden.
Der Dialog weist eine Öffnungssequenz und eine Schließsequenz zum Zwecke der Änderung der Kanalrichtung auf, oder zum "Umdrehen des Kanals". Dies ist deswegen erforderlich, da die beiden Kanäle bestimmte Signale gemeinsam nutzen, deren Bedeutung davon abhängt, welcher Kanal aktiv ist. Es sind nicht ausreichend Signale in dem Kabel vorhanden, um beide Kanäle gleichzeitig aktiv sein zu lassen. Fig. 3 erläutert das Rückkanalprotokoll.
Wie aus Fig. 3 hervorgeht, leitet der Host den Dialog dadurch ein, dass ein Byte hex 01h auf die Datenleitungen eingeschrieben wird, und dann das Signal *SLCTin angehoben (deaktiviert) wird. Das Byte 01h repräsentiert eine Kommunikationsmodusnummer. Kommunikationsmodusnummern werden nachstehend genauer erläutert.
Der Drucker reagiert hierauf durch Anordnen eines Halbbits an Daten, nämlich des Schleifensteuerhinweises, auf den Statusleitungen, und nachfolgendes Absenken von SLCT. Stellt der Host fest, dass SLCT absinkt, liest er die Statusleitungen aus, um den Schleifensteuerhinweis zu erhalten. Auch dies wird nachstehend genauer erläutert. Nunmehr ist der Dialog eröffnet.
Die nächste Gruppe von Operationen in einem Protokoll gemäß den Lehren der vorliegenden Erfindung können als "Datenübertragungsschleifenoperationen" bezeichnet werden. In dieser Schleife senkt der Host *STROBE ab, um ein Low- Halbbit eines Bytes anzufordern. Geht SLCT hoch, kann der Host das Halbbit von den Statusleitungen lesen. Bei dem in Fig. 3 gezeigten Beispiel ist ~BUSY das Bit 3, *ACK das Bit 2, PE das Bit 1, und *ERR das Bit 0.
Daraufhin erhöht der Host *STROBE, um das High-Halbbit des Bytes anzufordern. Geht SLCT herunter, so kann der Host das Halbbit von den Statusleitungen lesen. Bei dem in Fig. 3 gezeigten Beispiel ist ~BUSY das Bit 7, *ACK das Bit 6, PE das Bit 5, und *ERR das Bit 4.
In Bezug auf den Schleifensteuerhinweis, der voranstehend kurz erwähnt wurde, liest während der Öffnungssequenz der Host den Schleifensteuerhinweis von den Statusleitungen ab (beim vorliegenden Beispiel ist -BUSY das Bit 3, *ACK das Bit 2, PE das Bit 1, und *ERR das Bit 0). Der Schleifensteuerhinweis ist eine ganze Zahl von vier Bit ohne Vorzeichen, die eine Obergrenze für die Anzahl an Bytes festlegt, die in dem neu eröffneten Dialog übertragen werden kann.
Ist der Schleifensteuerhinweis gleich 0h, dann hat der Drucker keine Daten zu senden, und muß der Host den Dialog schließen, ohne die Übertragung irgendwelcher Daten zu versuchen.
Ist der Schleifensteuerhinweis nicht gleich 0h, dann wird die Schleifensteuergrenze berechnet als 2 hoch (Schleifensteuerhinweis -1). Die folgende Tabelle gibt alle möglichen Kombinationen an:

Schleifensteuerhinweis Schleifensteuergrenze (Byte)

0h 0
1h 1
2h 2
3h 4
4h 8
5h 16
6h 32
7h 64
8h 128
9h 256
Ah 512
Bh 1024 (1KB)
Ch 2048 (2KB)
Dh 4096 (4KB)
Eh 8192 (8KB)
Fh 16384 (16KB)
Der Host muß nicht sämtliche verfügbaren Bytes lesen. Der Host kann jede Anzahl an Bytes von 0 bis zur Schleifensteuergrenze lesen. Liest der Host bis zur Grenze, so muß er den Dialog schließen. Falls der Host immer noch weitere Daten wünscht, kann er sofort einen anderen Dialog eröffnen. Es können weitere Daten verfügbar sein, oder auch nicht.
Als Beispiel wird angenommen, dass der Host 80 Bytes an Daten lesen möchte. Nach Öffnung eines Dialogs empfängt der Host einen Schleifensteuerhinweis von 7h, der angibt, dass er nicht mehr als 64 Bytes lesen darf. Der Host liest die 64 Byte, schließt den Dialog, und öffnet dann einen anderen Dialog. Es wird angenommen, dass dieses Mal der Schleifensteuerhinweis gleich 6h ist, wodurch angegeben wird, dass 32 Byte verfügbar sind. Der Host liest dann 16 Byte (um insgesamt 18 Byte zu erreichen), und schließt den Dialog.
Die nächste, am weitesten unten in Fig. 3 dargestellte Gruppe an Operationen betrifft das Schließen des Dialogs. Der Host ist dafür verantwortlich, den Dialog zu schließen, wenn er Bytes bis zur Schleifensteuergrenze gelesen hat, oder wenn er sämtliche Bytes erhalten hat, die er haben möchte, je nachdem, was zuerst erreicht wird.
Der Host schließt den Dialog durch Absenken von *SLCTin und nachfolgendes Warten darauf, dass SLCT hoch geht. Der Host muß auf SLCT warten, um anzuzeigen, dass die Statusleitungen nunmehr Statusinformation und keine Daten übertragen.
Nebenbei wird in Bezug auf das Beispiel für das Halbbild-Modus- Rückkanalprotokoll, das hier erläutert wird, darauf hingewiesen, dass zwar die meisten Drucker SLCT absenken, wenn sie aus irgendeinem Grund abgeschaltet werden, jedoch ein Drucker, wenn er das hier vorgeschlagene Beispiel für ein Protokoll unterstützen soll, dieses Verhalten nicht zeigen darf. Das SLCT-Signal muß vollständig für das Protokoll reserviert werden, und sollte nicht für irgendetwas anderes eingesetzt werden. Wenn sich der Drucker abschaltet, sollte er BUSY anheben, um zu verhindern, dass der Host Daten sendet.
Ein weiteres Thema in Bezug auf die vorliegende Erfindung, das hier ausreichend erläutert werden muß, sind Protokollzeitablauffehler. Es gibt zahlreiche Orte in dem Protokoll, an denen der Host unbegrenzt lange warten muß, bis ein Signalübergang auftritt. In diesen Schleifen kann ein Zeitgeber eingestellt werden, um einen Schwebezustand zu verhindern. Der empfohlene Zeitablauf-Zeitraum beträgt 2 Sekunden für jede Schleife, die auf einen Signalübergang von dem Drucker wartet. Hierdurch sollte dem Drucker ausreichend viel Zeit zur Verfügung stehen, um zu reagieren, aber dennoch dem Benutzer sofort mitgeteilt werden können, falls der Drucker das Protokoll überhaupt nicht unterstützt.
Wenn eine Warteschleife an der Seite des Hosts abläuft, während der Dialog geöffnet ist, sollte der Host versuchen, den Dialog zu schließen. Tritt ein Zeitablauf auf, während der Dialog geschlossen wird, dann könnte der Host den Drucker (unter Verwendung des Impulses *INIT) zurücksetzen, um den Dialog abzubrechen. Nach Empfang dieses Signals kann der Drucker drastischere Aktionen durchführen oder auch nicht, beispielsweise Abbruch des momentanen Auftrags. Der Host sollte immer sicherstellen, dass *SLCTin Low (Aktiv) ist, bevor er den Impuls *INIT sendet; ist *SLCTin High nach dem Impuls *INIT, so meint der Drucker, dass der Host versucht, einen neuen Dialog zu eröffnen. Der Host sollte niemals versuchen, Daten zu senden, während ein Rückkanaldialog noch geöffnet ist.
Nunmehr werden in Bezug auf Host-Software einige 80 · 86-Assembler- Codefragmente nachstehend zur Verfügung gestellt, um einen Programmentwickler der Treibersoftware auf der Seite des Hosts zu unterstützen. Diese Codefragmente sind nicht als Teil der Protokollspezifikation vorgesehen, sondern sollen nur wirksame, nicht-offensichtliche Lösungen an Orten zur Verfügung stellen, an denen offensichtliche Lösungen sehr ineffizient sein könnten.
Ein erstes, hier vorgeschlagenes Fragment betrifft das Lesen des Low- Halbbits. Wenn der PC das Statusregister liest, um das Low-Halbbit von Daten zu erhalten, befinden sich die Bits in der falschen Reihenfolge. Dieses Codefragment ordnet die Bits korrekt an.
Ein zweites, hier vorgeschlagenes Fragment betrifft das Lesen des High- Halbbits. Wenn der PC das High-Halbbit aus dem Statusregister ausliest, befinden sich die Bits wiederum in der falschen Reihenfolge. Dieses Codefragment ordnet sie in der richtigen Reihenfolge an, und kombiniert das High-Halbbit mit dem Low-Halbbit.
Dieses dritte Codefragment berechnet die Anzahl an Bytes, die gelesen werden soll, unter Verwendung des Schleifensteuerhinweises, sowie die Anzahl an Bytes, welche der Host benötigt.
Bis zu diesem Punkt wurde nur ein sogenanntes Halbbit-Modus- Rückkanalprotokoll diskutiert. Das Halbbit-Modus-Rückkanalprotokoll, das bislang vorgestellt wurde, stellt nur eines aus einer Gruppe von Protokollen dar, die für Parallelkommunikationsvorgänge in beiden Richtungen ausgelegt sind. Andere derartige Protokolle werden ebenfalls hier beschrieben.
In Bezug auf das voranstehend erläuterte Protokoll wurden die folgenden vier Kommunikationsmodus-Nummern zugeordnet:

Modus-Nummer Protokoll

0 Version ID protocol
1 Nibble-mode reverse channel protocol
2 IOCTL write mode
3 IOCTL rend using nibble-mode rev. ch. protocol
Die übrigen Modusnummern 4-255 kann man so ansehen, dass sie zur Verwendung in der Zukunft reserviert werden.
In Bezug auf das Öffnen und Schließen eines Kommunikationsmodus beginnt und endet jeder Kommunikationsmodus auf dieselbe Art und Weise. Zum Öffnen eines Kommunikationsmodus stellt der Host die Kommunikationsmodus-Nummer auf den Datenleitungen ein, und hebt dann das Signal *SLCTin an. Der Drucker bestätigt den Modus durch Absenken des Signals SLCT. Sämtliche Kommunikationsvorgänge von diesem Punkt aus müssen entsprechend dem festgelegten Protokoll erfolgen. Falls die Statusleitungen gegenüber ihren Standardbedeutungen geändert werden sollen, so tritt diese Änderung auf, bevor das Signal SLCT abgesenkt wird. Hierdurch können die Bedeutungen der Statusleitungen gemultiplext werden, auf der Grundlage des Kommunikationsmodus.
Um einen Kommunikationsmodus zu schließen senkt der Host *SLCTin ab, und wartet darauf, dass der Drucker SLCT anhebt, um anzuzeigen, dass er geschlossen ist. Die Bedeutungen der Statusleitungen werden wiederhergestellt, nachdem der Host *SLCTin abgesenkt hat, und bevor der Drucker SLCT anhebt. Der Host muß darauf warten, dass SLCT angehoben wird, bevor er weitermachen kann, um mögliche Überlaufbedingungen zu verhindern.
Nunmehr wird ein anderes Protokoll gemäß den Lehren der vorliegenden Erfindung beschrieben, das nachstehend als "Protokollversion ID" bezeichnet wird.
Da das in beiden Richtungen wirksame Parallelprotokoll erweitert werden kann, ist es hilfreich, wenn der Host bestimmen kann, welche Version des Protokolls von dem Drucker verwendet wird, oder ob der Drucker das Protokoll überhaupt nicht unterstützt. Das Protokoll der Version ID stellt diese Funktion zur Verfügung.
Das Protokoll der Version ID arbeitet exakt ebenso wie das Halbbit-Modus- Rückkanal-Parallelprotokoll, mit Ausnahme einiger weniger, sehr wichtiger Unterschiede. Zunächst einmal ist die Kommunikationsmodus-Nummer Null (0) anstatt Eins (1). Daher muß der Host, damit er beginnen kann, auf den Datenleitungen hex 00h einstellen.
Das Datenrücklesen ist konstant. Der Schleifensteuerhinweis ist immer gleich 2h, so dass die Schleifensteuergrenze immer gleich 2 ist. Es sind immer genau zwei Bytes zum Lesen vorhanden. Das erste Byte ist hex 5Ah. Das zweite Byte ist die Versionsnummer des Protokolls.
Vom Drucker wird gefordert, dass er das durch die Versionsnummer festgelegte Protokoll insgesamt implementiert. Eine partielle Implementierung ist nicht ausreichend.
Zur Klärung eines Punktes, der anderenfalls unklar sein könnte, wird auf folgendes hingewiesen: der Drucker kann 1 als Versionsnummer zurückschicken, und nur die Kommunikationsmodi 0 und 1 implementieren, wobei Modus 0 das Protokoll der Version ID ist, das in einer Version eines Dokuments angegeben ist, welches das Protokoll beschreibt, und Modus 1 das Rückkanalprotokoll ist, das in derselben Version des Dokuments festgelegt ist, so dass eine Aufwärtskompatibilität aufrechterhalten wird. Die Unterscheidung in Bezug auf Version 1 wird für zukünftige Drucker zugelassen, die keine IOCTL-Kanal aufweisen.
Es ist nunmehr angebracht, den IOCTL-Kanal mit einigen Einzelheiten zu diskutieren, beginnend mit einer Diskussion seines Zwecks.
Häufig ist es wünschenswert oder sogar erforderlich, dass Hostsystemsoftware den Drucker in Bezug auf detaillierte Statusinformation abfragt, oder Konfigurationsbefehle schickt. Der Datenstrom zu dem Drucker (häufig von einer völlig anderen Anwendung) kann jedoch nicht dadurch unterbrochen werden, dass in ihn asynchron neue Befehle eingegeben werden. Entsprechend ist es nicht wünschenswert, dass Hostsystemsoftware Daten von dem Drucker liest, der für eine Anwendung eingesetzt werden sollte, um zu versuchen, Statusinformation zu erlangen. Die Sache wird dadurch noch komplizierter, dass der Datenpuffer des Druckers wahrscheinlich voll ist, wenn die Systemsoftware eine Statusanforderung schicken muß.
Der Kanal IOCTL (I/O-Steuerung) stellt einen getrennten, logischen Kanal für die Kommunikation mit dem Drucker zur Verfügung. Dieser Kanal arbeitet in beiden Richtungen, ebenso wie der Datenkanal, so dass Information in beiden Richtung übertragen werden kann. Getrennte Puffer werden für diesen Kanal aufrechterhalten, so dass Steuer- und Statusinformation selbst dann übertragen werden können, wenn Datenpuffer voll sind.
Das Format der Information, die auf dem IOCTL-Kanal übertragen wird, wird durch den Drucker definiert. Im wesentlichen wird der IOCTL-Kanal zur Übertragung von Steuer- und Statusinformation verwendet. Er wird typischerweise nicht dazu eingesetzt, Seitenbeschreibungen oder andere Daten zu senden. Für diesen Zweck wird der eher geeignete Datenkanal eingesetzt.
Zum Lesen aus dem IOCTL-Kanal verwendet der Host exakt dasselbe Protokoll wie jenes, das für das Halbbit-Modus-Rückkanal-Protokoll verwendet wurde, mit Ausnahme der Tatsache, dass die Kommunikationsmodus-Nummer gleich 3 ist. Zum Öffnen des IOCTL-Kanals zum Lesen stellt daher der Host zuerst hex 03h auf den Datenleitungen ein, und hebt *SLCTin an, und geht der Dialog ebenso wie in dem Kommunikationsmodus 1 weiter.
Die auf diesem Kanal gelesene Information ist logisch von den Daten getrennt, die unter Verwendung des Kommunikationsmodus 1 gelesen werden. Sind keine Daten vorhanden, die von dem Rückkanal (Datenkanal) gelesen werden sollen, so läßt dies keine Rückschluß darauf zu, ob Information vorhanden ist, die von dem IOCTL-Kanal gelesen werden soll.
Zum Schreiben in den IOCTL-Kanal muß der Host den Kommunikationsmodus 2 benutzen. Zu Beginn der Übertragung schreibt der Host hex 02h auf die Datenleitungen ein, und hebt dann *SLCTin an. Der Drucker stellt dann den Status des IOCTL-Kanals auf den Statusleitungen ein, und senkt SLCT ab. Stellt der Host fest, dass SLCT nach Low geht, so weiß er, dass die Statusleitungen nun den Status des IOCTL-Kanals wiedergeben, und nicht des Datenkanals. Selbst wenn der Datenkanal belegt wäre, muß dies für den IOCTL-Kanal nicht der Fall sein.
Sobald der Kommunikationsmodus 2 eröffnet ist, wird Information von dem Host an den Drucker auf dieselbe Art und Weise übertragen, auf welche Daten auf dem Datenkanal übertragen werden, unter Verwendung der Datenleitungen, BUSY, *STROBE, *ACK, und der anderen Statusleitungen.
Nachdem die Steuerinformation an den Drucker übertragen wurde, muß der Host den Kommunikationsmodus schließen. Der Host senkt *SLCTin ab, und wartet darauf, dass SLCT auf High geht. Der Drucker stellt die Statusleitungen wieder her, um den Status des Datenkanals wiederzugeben, und hebt dann SLCT an. Das Schließen ist beendet, wenn der Host feststellt, dass SLCT auf High geht.
Beim Schreiben von Daten in den IOCTL-Kanal muß der Host häufig auf BUSY warten, da dies die Standardvereinbarung ist. Dieses Warten wird nicht durch denselben Zeitablauf von 2 Sekunden eingeschränkt, der voranstehend in Bezug auf das Halbbit-Modus-Rückkanal-Protokoll erläutert wurde. Der Zeitablaufwert im vorliegenden Fall steht im Belieben des Hosts. Wird der Host beim Warten auf das BUSY-Signal ungeduldig, und entscheidet einen Zeitablauf, sollte der Host zuerst versuchen, den Kommunikationsmodus auf normale Art und Weise zu schließen.
Nunmehr wird ein anderer Gesichtspunkt erläutert. Die Standardunterstützung BIOS INT 17h für Paralleldruckerkommunikationsvorgänge ist in ihrer Funktion sehr beschränkt. Die folgenden Erweiterungen werden vorgeschlagen, damit Software die neuen Protokolle verwenden kann, ohne sie neu zu implementieren. Diese Erweiterungen werden nur als Beispiele vorgeschlagen, um die Umsetzung der vorliegenden Erfindung in die Praxis zu erleichtern, jedoch nicht, um sie einzuschränken.
Die Funktion "Version identifizieren" stellt eine Vorgehensweise zur Verfügung, um anzugeben, dass die folgenden erweiterten Funktionen zum Einsatz verfügbar sind.

Eingabe:

AX = 80A5h

Antwort:

AX is 5A5Ah
BX will have the version number
Die zurückgeschickte Versionsnummer entspricht der Versionsnummer eines geeigneten Dokuments, welches das Protokoll beschreibt. Die Versionsnummer hat das Format "H.L.", wobei der Abschnitt "H" in BH zurückgeschickt wird, und der Abschnitt "L" in BL. Die Geschichte der Überarbeitungen zu Beginn des geeigneten Dokuments sollte zusätzliche Information in Bezug auf Versionsnummern bereitstellen.
Im Idealfall sind alle zukünftigen Änderungen bei BIOS-Erweiterungen aufwärts kompatibel.
Die Funktion "Schreib Daten" schickt einen Datenpuffer an den Drucker. Eingabe: Antwort:
Die Funktion "IOCTL schreiben" schickt einen Puffer aus I/O-Steuerinformation an den Drucker. Die Daten werden statt in den Datenkanal in den IOCTL-Kanal geschrieben. Eingabe: Antwort:
Die Funktion "Lies Daten" liest einen Datenpuffer von dem Drucker. Eingabe: Antwort:
Die Funktion "IOCTL lesen" liest einen Puffer aus I/O-Steuerinformation von dem Drucker. Die Daten werden aus dem I/O-Steuerkanal gelesen, anstatt aus dem Datenkanal. Eingabe: Antwort:
Als letzte Erweiterung wird in Bezug auf Lese/Einstell-Zeitablaufwerte für Schreibvorgänge vorgeschlagen: Eingabe:
Fachleuten auf diesem Gebiet sollte nun deutlich geworden sein, dass die vorliegende Erfindung ein in beiden Richtungen arbeitendes paralleles Protokoll zur Verfügung stellt, das robust ist, erweiterbar, und sehr gut daran angepaßt, zwischen einem Hostcomputer und einem zugehörigen Drucker zu arbeiten. Das Protokoll gemäß den Lehren der vorliegenden Erfindung kann vorhandene PC-Parallelport- Hardware und Kabel verwenden, ist jedoch für sich ungünstig verhaltende Anwendungssoftware und dergleichen transparent. Darüber hinaus läßt das Protokoll gemäß den Lehren der vorliegenden Erfindung eine schnelle Abfrage zu, wobei es keine problematischen Echtzeit-Randbedingungen auferlegt.
Fachleute auf diesem Gebiet werden erkennen, dass zahlreiche Modifikationen und Variationen über jene hinaus, die speziell erwähnt wurden, bei den Vorgehensweisen vorgenommen werden können, die hier geschildert wurden, ohne wesentlich vom Konzept der vorliegenden Erfindung abzuweichen. Daher kann innerhalb des Umfangs der beigefügten Patentansprüche die vorliegende Erfindung anders in die Praxis umgesetzt werden, als dies hier speziell beschrieben wurde.

Claims

1. Verfahren zum Herstellen eine Rückkanal-Übertragungsfähigkeit zwischen einem Computer und einem Drucker über eine parallele Schnittstelle, wobei das Verfahren die folgenden Schritte umfasst:

a) Leiten eines Übertragungsmodussignals durch den Computer zu dem Drucker, wobei das Übertragungsmodussignal dazu dient, den Drucker in einen Übertragungsmodus zu versetzen;

b) Leiten eines ersten Signals durch den Computer zu dem Drucker, das anzeigt, dass das Übertragungsmodussignal zum Lesen bereit ist;

c) Leiten eines zweiten Signals durch den Drucker zu dem Computer, das anzeigt, dass der Drucker Computerdaten in dem Übertragungsmodus erzeugt, der in Schritt a) angezeigt wird;

d) Leiten eines Bereitschaftssignals durch den Drucker zu dem Computer, das anzeigt, dass das zweite Signal zum Lesen bereit ist;

e) Leiten eines dritten Signals durch den Computer zu dem Drucker, das anzeigt, dass der Computer bereit ist, eine erste Dateneinheit von dem Drucker zu empfangen;

f) Leiten der ersten Dateneinheit durch den Drucker zu dem Computer;

g) Leiten eines vierten Signals durch den Drucker zu dem Computer, das anzeigt, dass die erste Dateneinheit zum Lesen bereit ist;

h) Leiten eines fünften Signals durch den Computer zu dem Drucker, das anzeigt, dass der Computer bereit ist, mehr Dateneinheiten zu empfangen;

i) Leiten einer zweiten Dateneinheit durch den Drucker zu dem Computer;

j) Leiten eines sechsten Signals durch den Drucker zu dem Computer, das anzeigt, dass die zweiten Dateneinheit zum Lesen bereit ist.

2. Verfahren nach Anspruch 1, wobei die erste Dateneinheit ein Low-Halbbit ist.

3. Verfahren nach Anspruch 2, wobei die zweite Dateneinheit ein High-Halbbit ist.

4. Verfahren nach Anspruch 1, wobei der Übertragungsmodus ein Rückkanal- Übertragungsmodus ist.

5. Verfahren nach Anspruch 1, wobei der Übertragungsmodus ein Eingangs-/Ausgangs-Steuermodus ist.

6. Verfahren nach Anspruch 1, wobei der Übertragungsmodus ein Rückkanal- Halbbit-Modus ist.