Diskussion:IEEE 1284

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Mehrfacheintrag / Aufräumen[Quelltext bearbeiten]

Ich bin auf den Artikel Line Printing Terminal gestoßen, als ich von der Engl. Wikipedia en:Parallel port auf die angebliche deutsche Überstzung klickte. Statt auf Parallele Schnittstelle oder Centronics-Schnittstelle bin ich bei diesem Artikel gelandet und ich finde, diese drei Artikel überschneiden sich ziemlich. Man sollte IMHO unterscheiden zwischen:

  • eine Parallelen Schnittstelle im Computerbereich allgemein (z.B. SCSI, Centronics, u.a.)
  • der Centronic-Schnittstelle
  • einem Terminaldrucker/Druckerterminal

Was meint ihr dazu? --RokerHRO 12:36, 12. Apr 2006 (CEST)

RokerHRO hat völlig recht. Hier überlappen sich mehrere Artikel stark und sollten aufgeräumt werden. Ich meine, Centronics-Schnittstelle, Parallel Port, Line Printer Terminal (Line Printing Terminal) sind unterschiedliche Begriffe für das gleiche Thema. Letztlich gehört auch "IEEE 1284 Port" mit dazu weil es die neue Definition diese Themas ist. Aber hier sollte man die Differenzierung vielleicht erhalten.

Parallel-Schnittstelle oder parallele Schnittstelle ist m.E. ein übergeordneter Begriff der die Schnittstellen mit paralleler Datenübertragung von solchen mit serieller Übertragung differenziert. Zu den parallelen Schnittstellen gehören die oben Genannten - aber auch SCSI etc.

In allen Artikeln sind übrigens noch ziemlich gravierende technische Fehler. --Poliol 08:41, 17. Apr 2006 (CEST)


>>Die Centronics-Schnittstelle ermöglicht eine Übertragungsgeschwindigkeit von höchstens 150 KB pro Sekunde (SPP-Modus) und eine Kabellänge von maximal ca. 3,50 m. (Bis zu 5 m bei hochwertigem Kabel, bestenfalls mit 8 Masse-Leitungen.) Man sollte noch hinzufügen, weshalb das Kabel nicht länger sein darf. Wieso genau darf es nicht länger sein? Reflektionen? Einstreuungen? wegen der unsymmetrischen Leitungsführung? Kenne mich da noch nicht so gut aus.--194.97.126.217 23:33, 15. Apr 2006 (CEST)

Die zitierte Aussage im Artikel über Länge des Kabels und Geschwindigkeit ist so pauchal schlichtweg falsch. Dies gilt sowohl für die "klassische Centronics" wie auch erst recht für die neudefinierte IEEE 1284.

Bei der alten "Centronics" gab es fast keine Definition von Treiber-Ausgangswiderstand, Protokoll, Timing, Kabel und Empfänger-Eingangswiderstand. Jeder Hersteller (Rechner und Drucker) handhabte das anders - manchmal sogar von Modell zu Modell unterschiedlich. So war es reine Glückssache, welche Länge und Geschwindigkeit man bei der Kombination von Rechnern und Druckern erreichte. IBM sprach von einer max. Länge von 1,8 Meter. Es ist den japanischen Druckerhestellern (allen voran EPSON) zu verdanken, dass sie Mitte der 80er(zumindest druckerseitig) eine gewisse Standardisierung schafften, die die Situation deutlich entschärfte und ihre Drucker relativ problemlos mit fast allen PC-Schnittstellen auch über mittlere bis größere Kabellängen arbeiten ließ. Eine generelle Aussage über die Kabellänge gab es nicht. Bei ungünstigen Geräte-Kombinationen mit schlechten Kabeln gab es schon bei 3 Metern Probleme. Bei günstigen Kombinationen und Einsatz von Spezialkabeln ging es bis über 30 Meter. Die Geschwindigkeiten lagen zwischen 40 und 120 Kbyte/s.

Die IEEE 1284 (1994) hat dann die elektrischen Eigenschaften der Rechner- und Peripherie-(Drucker-)Seite ziemlich klar definiert. Es gibt zwei Stufen der elektrischen IEEE 1284 Compliance:

Level 1 ist die elektrische Minimalanforderung, representiert den Status Quo Ante und bietet diesem gegenüber keine deutlichen Verbesserungen. Es wurde lediglich in einem Anhang (Annex C) auf die Sünden der Vergangenheit hingewiesen. Level 1 ist nur zum Drucken über das SPP (im sog. Compliant Mode) gedacht. EPP und besonders ECP sind hier nicht möglich.

Level 2 ist eine ganz neue und eng tolerierte elektrische Spezifikation die für die neuen Geschwindigkeiten der 1284 von über 1 Mbyte/s nötig war. Ein Level 2 Gerät ist mit Level 1 Geräten kompatibel und kann auch im SPP- (Compliant-)Mode arbeiten.

Auch die Protokolle und das jeweilige Timing für die unterschiedlichen Modi wurde in der IEEE 1284 ziemlich klar definiert. Sehr klar sind die Spezifikationen des Kabels. Es handelt sich um ein doppelt geschirmtes "Twisted Pair"-Kabelmaterial mit 18 Aderpaaren und definierten elektrischen Eigenschaften. Ebenso wurde die Belegung exakt festgelegt.

Ausgehend von den Spezifikationen der 1284 beträgt im Worst-Case die Kabellänge mit "1284 Compliant Cable" bei Level 2 mindestens 12 Meter. Weil die Hersteller von Rechnern und Perpheriegeräten insbesondere im SPP-Mode große Reserven im Timing lassen, ist die Übertragungslänge in der Praxis weitaus größer. Eben wegen dieser Reserven im Timing ist die Druckgeschwindigkeit im SPP-Mode niedriger als sie theoretisch sein könnte. In der Praxis liegt sie zwischen ca. 80 und 120 Kbyte/s bei einer Kabellänge von 3 Meter.

Anmerkung: Die Geschwindigkeit ist Längenabhängig und sinkt mit steigender Länge. Ganz extrem wirkt sich das bei ECP aus: Die theoretische Maximalgeschindigkeit von 4-5 Mbyte/s reduziert sich schon bei 2 Meter Kabel auf etwa die Hälfte.

Manches von dem Obigen ist schon etwas vereinfacht, geht aber m.E. für eine Enzyklopädie schon zu sehr ins Detail. --Poliol 09:27, 17. Apr 2006 (CEST)

Ich hatte die Frage von 194.97.126.217 nach den Ursachen der Längenbeschränkungen übersehen. Generell gibt es folgende Mechanismen, die zu einer Störung führen:

1) Signal-Verschleifung (Verlangsamung der Flanken) - Betrachtet man ein Kabel als RC-Glied, so ergibt sich aus dem Innenwiderstand des Treibers und der Signal/Masse-Kapazität ein Tiefpass. Kurze Signale könnten sogar "verschluckt" werden - aber das ist selten das Problem. Das Problem ist a) Die Signalflanke ist im Bereich des logischen Schwellwertes langsam und damit gefährdet, z.B. durch Störungen, nicht monoton (eindeutig) zu sein. b) Eventuelle Timing-Vorgaben werden übeschritten. Beispiel: Ein Rechner beachtet nur das BUSY des Druckers, ehe er ein Zeichen sendet (garnicht so selten). Wird dies zu stark verzögert, schickt der Rechner schon das nächste Zeichen obwohl das Erste noch garnicht gedruckt ist. Abhilfe zu 1): Innenwiderstand des Treibers verkleinern und/oder die Signal/Masse-Kapazität des Kabels verkleinern.

2) Übersprechen zwischen den zeitkritischen Signalen - Das wichtigste Beispiel ist das wechselseitige Übersprechen zwischen Daten und STROBE. Beispiel a): Die acht Daten-Signale werden erst angelegt und sollen dann durch den STROBE übernommen werden. Spricht der STROBE auf eine oder mehrere Datenleitungen über, so ist das übernommene Zeichen falsch. Beispiel b): Eine oder mehrere Datenleitungen sprechen auf den STROBE über (schlimmsten falls gehen alle Datenleitungen von "1" auf "0") und erzeugen damit ein falsches oder doppeltes Zeichen. Abhilfe auch hier wieder: Verkleinerung des Treiber-Innenwiderstandes und/oder Reduzierung der Ader/Ader-Kapazität der Signale.

3) Reflexionen spielen bei der klassischen Centronics (Level 1) eine eher untergeordnete Rolle. Interessanterweise hat man sie aber bei Level 2 ganz gezielt ausgenutzt um durch Überschwingen die Probleme von 1a)zu umgehen.

4) Einstreuungen / Störungen - Kapazitives Einstreuen ist bei halbwegs vernünftig geschirmten Kabeln unter normalen Bedingungen unkritisch. Induktives Einstreuen kommt in der Praxis nur dann vor, wenn Datenkabel über Strecken in unmittelbarer Nähe von stark "verseuchten" Kabeltrassen verlegt werden. Dagegen hilft nur: Abstand. Die wichtigste Störungsquelle liegt eigentlich außerhalb der Centronics-Schnittstelle: Die Potentialunterschiede (Erdpotential) zwischen den Geräten - also die Elektroinstallation. Der geringe Störabstand von ca. 1-1,5 Volt kann hier sehr schnell überschritten werden. Das hat nichts mit der Länge der Übertragungsstrecke zu tun, sondern mit der steigenden Wahrscheinlichkeit einer höheren Potentialdifferenz zweier miteinander verbundene Geräte über die Entfernung.

5. Asymmetrie - Natürlich hätte eine symmetrische Signalübetragung ganz enorme Vorteile in jeder Hinsicht. Sie ist in der IEEE 1284 nicht realiert worden - aus Kostengründen aber auch weil damit keine Rückwärtskompatibilität mehr gegeben war. --Poliol 14:57, 17. Apr 2006 (CEST)

Wofür steht LPT?[Quelltext bearbeiten]

Hallo, ich bin von LPT hierher directed worden, finde aber keinen Hinweis, wofür LPT steht. --DB1BMN 14:36, 25. Jun 2006 (CEST)

LPT steht für Line Printer Terminal --Cjesch 14:43, 25. Jun 2006 (CEST)

Und, sollte das nicht irgendwie in den Text eingearbeitet werden? -- Fleasoft 11:16, 13. Sep 2006 (CEST)

Ja, es ist das gleiche Problem wie bei RS-232 – der Name, unter dem die Schnittstellen bei Millionen von Benutzern bekannt waren (COM und LPT), fehlt in den Artikeln. --Phst 18:19, 8. Sep. 2009 (CEST)[Beantworten]
Ich bin grade auch über dieses Problem gestolpert und frage mich ernshaft: und nun?! Ich werde das nicht einfügen, weil ich keinen Wikipedia-Account habe und daher sicher bin, dass es sofort wieder rausgenommen wird... -- Christopher Schwartz 13:17, 23. Jul. 2010 (CEST) (ohne Benutzername signierter Beitrag von 131.220.3.155 (Diskussion) )

War es nicht Line Printer? (= Zeilendrucker) (nicht signierter Beitrag von 134.109.9.176 (Diskussion) 16:16, 7. Mär. 2011 (CET)) [Beantworten]

Ergibt sich die Bedeutung von "erwartungsgemäß" nicht aus dem Kontext? OK: Korrekt müsste es heissen: "Er hat sich nicht in dem Maße durchgesetzt, wie die Väter des Standards das zwischen 1993 und 1994 erwartetet hatten". Aber so wird aus diesem Artikel ein 20-Seiter. "Er hat sich nicht durchgesetzt" ist so schlichtweg falsch. Dann lassen wir den Satz einfach weg - es wäre aber schade.

Ich bein dabei, den Artikel umzustrukturieren, nachdem er (nicht von mir) von "Centronics Schnittstelle" nach "IEEE 1284" verschoben wurde. Unter dieser Überschrift kann er unmöglich so bleiben. Dieses Umstrukturieren ist nicht so ganz einfach. Und man muss die Strukturen ja auch mit Inhalt füllen. Man gebe mir doch bitte ein paar Tage Zeit. Es ist nicht hilfreich, in der Zwischenzeit formale Korrekturen vorzunehmen. Wenn ich fertig bin, gerne. Ich bin auch nicht so fit in Wiki-Formatierung und freue mich dann über Kritik. Mfg Poliol

"Hat sich erwartungsgemäß nicht durchgesetzt" heißt aber, dass irgendjemand erwartet hat, dass es sich nicht durchsetzt. Du meinst vielleicht: "Hat sich nicht erwartungsgemäß durchgesetzt" oder besser: "Hat sich, entgegen den Erwartungen des Normierungsgremiums, nicht durchgesetzt". Aber auch derartige Einfügungen sagen nicht viel aus. Denn wenn jemand einen Standard verabschiedet, kann man eigentlich immer davon ausgehen, dass derjenige erwartet oder davon ausgeht oder darauf hofft, dass sich dieser Standard durchsetzt. Da wir aber nicht wissen, ob die Leute im IEEE-1284-Normierungsgremium die Erwartung, oder die Hoffnung oder die (falsche) Gewissheit hatten, dass sich ihr Standard durchsetzt, können wir darüber auch keine Aussage treffen, ob nun ihre Erwartungen, ihre Hoffnungen oder ihre Gewissheit enttäuscht wurden. Somit klingt das zu sehr nach persönlicher Meinung (der Schreiber des Satzes scheint wohl enttäuscht zu sein), als nach neutralen und unbestreitbare Fakten ("Hat sich nicht durchgesetzt", unabhängig davon, warum das passiert ist und wer sich das vielleicht gewünscht oder erhofft hatte). Daher habe ich das Wort gelöscht. --RokerHRO 09:04, 13. Jul 2006 (CEST)

1) Ich meinte: "Hat sich nicht erwartungsgemäß durchgesetzt" - und genau das hatte ich geschrieben.

2) Der Schreiber war Mitglied im Gremium! "persönliche Meinung", "enttäuscht" ..... Was sollen solche Angriffe? -- Poliol 19:32, 13. Jul 2006 (CEST)

Welcher Schreiber? Den Text hast du eingefügt. Also bist/warst du Mitglied im IEEE-Normierungsgremium? Guck an, das wusste ich nicht. Hast du noch mehr Insider-Informationen? --RokerHRO 22:48, 13. Jul 2006 (CEST)

1) Siehe meine Quellenangabe 7.Juli. 2) Ja, die versuche ich ja gerade hier einzubringen. -- Poliol 01:10, 14. Jul 2006 (CEST)

Hat sich bisher ja nichts getan. Schade. --RokerHRO 13:48, 11. Sep. 2009 (CEST)[Beantworten]

Ich weiß nicht ob das in den Artikel gehört, aber wie erstellt man unter Linux mit mknode die lpt Gerätedatei erstellt? >>> evt. mit mkdev ("make device") , im /dev directory stehen die lpt Dateien lpt01 bis lpt04, wird bei Installation generiert. D.h "lpt ist keine Datei sondern ein "device", eine Adresse, an die die Daten übergeben werden. Guck mal im / nach , bei /bin /home /etc /proc /dev , dort musst Du hin !!

kommerzielle Werbung ?[Quelltext bearbeiten]

lpt-driver[dot]com ist doch eigentlich nur kommerzielle Werbung. Vielleicht rausnehmen ? --Krishl 19:09, 10. Apr. 2007 (CEST)[Beantworten]

Done. Cjesch 09:17, 12. Apr. 2007 (CEST)[Beantworten]

Geschichte ?[Quelltext bearbeiten]

Hallo Mod oder Bot, der Du den Teil wegen Mangel an Quellen löschen willst: Ich kann es nicht ändern, dass es keine offiziellen Quellen gibt. Ich war Mitglied im 1284 Comittee (1993-1996) und kann gewünschtenfalls Kontakt zum Chairman herstellen um dies und die Fakten zu bestätigen. Poliol 20:18, 22. Mai 2007 (CEST)[Beantworten]

Pinbelegung ?[Quelltext bearbeiten]

Laut http://www.doc.ic.ac.uk/~ih/doc/stepper/kari-salmi/stepper1.html und einem Dokument das mir vorliegt ist PIN 13 und PIN 17 vertauscht...Was stimmt nun? Trex2001 16:13, 25. Jan. 2010 (CEST)[Beantworten]

INIT oder /INIT[Quelltext bearbeiten]

Hatte die Ur-Schnittstelle wirklich ein High-aktives Reset-Signal? Sieht mir nach einem Fehler aus. (nicht signierter Beitrag von 134.109.9.176 (Diskussion) 16:16, 7. Mär. 2011 (CET)) [Beantworten]

Sieht mir auch wie ein Fehler aus. Da wurde wahrscheinlich IEEE1284 und ISA-Implementation durcheinandergehauen, siehe Folgebeitrag. --Henrik Haftmann (Diskussion) 11:04, 4. Jun. 2012 (CEST)[Beantworten]

BUSY und ACKNOWLEDGE[Quelltext bearbeiten]

Laut anderen Internetseiten ist BUSY invertierend und ACKNOWLEDGE nicht ! siehe:

http://logix4u.net/Legacy_Ports/Parallel_Port/A_tutorial_on_Parallel_port_Interfacing.html http://en.wikipedia.org/wiki/Parallel_port

Bitte ändern falls wieder jemand auf die Idee kommt, und Eigenbau - Hardware nach Wikipedia Diagrammen herstellen will ;-)

--84.115.156.89 13:40, 17. Mär. 2011 (CET)[Beantworten]

Ist alles in Ordnung.

Beachte: Der Drucker ist BUSY, wenn die Leitung 5 V (HIGH) führt, daher NICHTINVERTIERT. Der Drucker ACKnowlätscht (=bestätigt, 'tschuldige die Wortschöpfung), wenn die Leitung 0 V (LOW) führt, daher INVERTIERT.

Hingegen, die „ISA-Implementation der Schnittstelle“ (die Bezeichnung verrät, dass es sich um eine PC-typische Ausprägung handelt, andere Computerhersteller dürfen da ihr eigenes Süppchen kochen) INVERTIERT die Busy-Leitung (zum Bit 7 des Statusregisters im E/A-Adressraum), die ACK-Leitung hingegen nicht.

Also: IEEE1284 nicht mit dessen ISA-Implementation verwursteln.

--Henrik Haftmann (Diskussion) 11:01, 4. Jun. 2012 (CEST)[Beantworten]

Wofür genau ist eigentlich diese Steuerleitung da?

Kann es sein, dass diese Leitung steuert, ob beim Erreichen des rechten Druckrandes (typ. 80 Zeichen) die Buchstaben übereinandergeklopft werden (wie bei einer Schreibmaschine) oder automatisch (deshalb das AUTO) ein Zeilenvorschub gemacht wird, was dann aber den Zeilenaufbau und die Paginierung (bspw. beim Leporello-Seitensprung) durcheinanderbringen kann?

Das mit dem ZeilenVorschub (LF) nach WagenRücklauf (CR) ist womöglich eine modernere Interpretation.

Wofür steht das XT? Für Extended? Für Extension? Für den PC-XT (also den 8086-Computer mit 16-bit-Bussystem und Festplatte)? Oder noch etwas anderes? --Henrik Haftmann (Diskussion) 10:50, 4. Jun. 2012 (CEST)[Beantworten]

Teilabschnitt C64 Am Ende des Artikels.[Quelltext bearbeiten]

12:09, 9. Mai 2015 (CEST)In diesem Abschnitt steht nahezu nur Unsinn.

  1. Der proprietäre Anschluss der Commodore Heimcomputer ist kein komplettes EIngegebräu von Commodore gewesen, sondern vielmehr eine serielle Version des IEEE-488 Bus-Systems
  2. Im "Kernel" des C64 waren Routinen für eine RS232-Schnittstelle vorhanden. Diese war am Userport ausgeführt, es wurde jedoch nur mit TTL-Pegeln gearbeitet, sprich für eine RS232-Verbindung benötigte man einen Pegelumsetzer. (Ein MAX232, vier kleine Elkos)
  3. Um eine Parallelschnittstelle am Userport realisieren zu können, brauchte man keinen "geänderten Kernel". Eine kleine Assembler-Rouitine im RAM, ein "verbogener Vektor" in der Zeropage und der Apfel war geschält.

80.137.231.61 12:09, 9. Mai 2015 (CEST)[Beantworten]