UsbPrn-Adapter

In der Schublade des Bastlers liegt des öfteren ein USB-Paralleldrucker-Konverter herum, der als Fehlinvestition als Ersatz für das fehlende Parallelport des neuen Notebooks oder Laptops schließlich auf die stoffliche Verwertung wartet.

Aber Stopp!

Mit ein paar Bauteilen kann man damit, moderne Software (etwa mein inpout32.dll) vorausgesetzt, trotzdem 8 Leuchtdioden mittels out-Befehl steuern!
Bis zu 4 Schrittmotoren gehen auch, aber das dürfte ruckeln, da der Ausgabedatenstrom nicht gleichmäßig fließt.

Das ganze geht ohne Kernel-Hacks! User-Mode genügt. Kein Treiber zu laden. Ab Windows 98. 64-Bit-Unterstützung inklusive. Linux auch.

in geht auch, allerdings auf 3 Bit begrenzt; siehe unten. Sogar ohne extra Hardware.

Man kann damit gut ein SPI- oder Hochvolt-Programmiergerät für AVR betreiben. Eine PonyProg2000-Erweiterung ist dafür in Arbeit. Immerhin arbeitet ein solches Ensemble aus USB-Paralleldrucker-Konverter und diesem Adapter ungefähr 10x so schnell wie ein USB-Seriell-Adapter im PingPong-Modus. Und man hat das Mehr an Ausgabeleitungen für die Hochvolt-Programmierung von zumindest 6-, 8- und 14-beinigen AVR-Typen.

Viele Programmiergeräte für USB benötigen einen programmierten Mikrocontroller. Ein Programmiergerät auf Basis eines USB-Paralleldrucker-Konverters löst das Henne-Ei-Problem auf elegante Weise. Das pure Einprogrammieren geht sehr schnell, nur das Rücklesen ist langsam.

Eine große Anzahl von Software verwendet inpout32.dll für den Zugriff auf ein (echtes) Parallelport. Da hierbei eine bekannte API als Zwischenschicht arbeitet, habe ich die DLL so umgestrickt, dass Software auf ein solches „unechtes“ Parallelport zugreifen kann. Wohlgemerkt, durch Lesen und Schreiben auf Portadresse 0x378 usw. — virtuell natürlich. Mit gewissen Einschränkungen bei der Anzahl von Portpins sowie Lesegeschwindigkeit. Daher lassen sich derartige Programme — trotz closed source und aussterbener Parallelports — mit diesem billigen Konverter weiter betreiben.

Technischer Hintergrund

Ein USB-Drucker-Konverter ist dazu gemacht, Paralleldrucker anzusteuern. Nichts weiter. Also muss sich das anzuschließende Gerät wie ein Paralleldrucker verhalten: Der Drucker erwartet Daten bei aktivem SROBE, und der Konverter fragt vom Drucker die Geräte-ID im Nibble-Modus ab. Außerdem kann dieser genau 3 Statusleitungen, nämlich Error, PaperEnd und Online, dem Computer melden. Das ist im USB-Standard so festgelegt. Deshalb funktioniert das gleichermaßen unter Windows und Linux.

Das Ausgeben von Bytes geht sehr schnell, einige 100 kByte/s sind kein Problem. Schneller als ein echtes Parallelport. Das hängt jeden USB-Seriell-Konverter locker ab.

Aber: Das Abfragen der 3 Statusbits dauert 1 ms! Das ist im Vergleich zu einem echten Parallelport sehr langsam. Etwa Faktor 100. Daher muss man beim Anfragen seriell arbeitender Geräte sehr viel Zeit mitbringen. Bei USB-Seriell-Adaptern ist es genauso.

Wichtig: Das Gros solcher Konverter hält das Datenport hochohmig im Tristate. Daher muss man das zuletzt ausgegebene Datenbyte auffangen.

Nicht bidirektional?

Druckerschnittstellen werden häufig mit „bidirektional“ beworben. Während PS/2-Bidirektionalität sowie EPP + ECP echte (8-bit)-Bidirektionalität meint, ist bei Druckern in der Regel nur die IEEE1284-Negotiation (BiTronics) gemeint, wofür Nibble Mode, also SPP, ausreicht.

Diese Funktion wird von USB-ParallelDrucker-Konvertern selbständig ausgeführt und an den PC geleitet. Für Bastelprojekte (also Nicht-Drucker) ist davon eher abzuraten:

Da USB-ParallelDrucker-Konverter nur für Drucker gedacht sind, ist eine 8-Bit-Bidirektionalität wahrscheinlich nicht eingebaut und daher nicht nutzbar.

Ob eventuell doch, und mit welchen Schaltungstricks, muss in einem gesonderten Versuch festgestellt werden! Auf jeden Fall gibt es eine API (Windows und Linux gleichermaßen), um den IEEE1284-String abzufragen. Er darf bis zu 64 Kilobyte lang sein und darf binäre Nullen enthalten. Also kann man derartige Datenpakete hardwareseits zusammenstellen.

Einfache Lösung

Nur Eingabe

Für die Abfrage der drei Statusleitungen wird überhaupt keine extra Hardware benötigt. Einfach anschließen genügt.

Die angegebenen Pin-Nummern beziehen sich auf D-Sub 25, nicht auf den 36-poligen Druckerstecker!

Dazu Ausgabe

Zum Ausgeben der 8 Datenbits wird zwingend ein Latch- oder Flipflop-Schaltkreis benötigt! Ansonsten erscheinen die Daten nur für ein paar Mikrosekunden mit STROBE. (Flankengetriggerte) Flipflops haben den Vorteil, dass man sich um die Polarität des Takteingangs keine Gedanken machen muss, da die Daten sowohl bei fallender als auch bei steigender Flanke von STROBE stabil anliegen. (Transparent-)Latches haben diesen Vorteil nicht, sie müssen bei STROBE=L transparent sein und bei STROBE=H verriegeln. Beim '373 oder '533 ist's dummerweise gerade verkehrt herum. Notfalls muss man STROBE invertieren, was ein weiteres Gatter kostet.
So kann das D-Latch vom Druckerport gespeist werden. Die LEDs sind hier nur zur Demonstration
Wer weniger Bits braucht kann auch einen Flipflop-Schaltkreis mit weniger Bits verwenden, für 4 Bit beispielsweise 74HC(T)175, '192, '193, '195 … oder CMOS 4029, 4035, 4042 … was die Bastelkiste gerade hergibt. Wer nur Bipolarschaltkreise (74LS) vorfindet, kann auch diese verbauen und muss diese mit 5 V fremdspeisen. Fremdspeisung macht die Fangschaltung funktionssicherer.

Anwendung

Sterngucker: Keinesfalls sollte man die Bilddaten einer altertümlichen CCD-Kamera über ein solches Interface schicken! Es wäre unerträglich langsm, wenn's denn überhaupt funktioniert: Hier muss ein gesonderter Mikrocontroller her. Etwa ein USB2LPT mit problemangepasster Firmware sowie eine problemangepasste (nicht meine) InpOut32.dll.

„Nichtlineares“ Routing oder mehr E/A-Leitungen

Wenn man schon einen Zwischenstecker basteln muss und inpout32.dll eh' virtualisiert, kann man auch Datenausgänge auf Steuerausgänge legen oder per se nicht unterstützte Statuseingänge (BUSY und ACK) benutzen, um bestimmte Hardware glücklich zu machen.

Kann man der DLL irgendwie mitteilen, dass bestimmte Portbits für bestimmte Software entsprechend zu vertauschen ist? Etwa, um STROBE (Pin 1 = 0x37A Bit 0) zu generieren und BUSY (Pin 10 = 0x379 Bit 7) abzufragen? Entsprechendes wenn man ein invertierendes Latch/Flipflop eingebaut hat?

Vielleicht sogar, wenn man 2 6-Bit-Latches eingebaut hat um auf 12 Ausgabeleitungen zu kommen?

Ein voll ausgestattetes Parallelport würde vier Standardlogikschaltkreise erfordern
Die aktuelle (2015) Version von meiner inpout32.dll hat noch nichts dazu eingebaut. Bitte bei Bedarf anfragen!


Endergebnis — was möglich ist.

Die Parallelisierung von S3 auf S3..S5 macht Geschwindig­keits­faktor 3. Die Widerstände entkoppeln die Flip­flops bei parallelem Anschluss von S3..S5.

Der Ausgang INI kann nur einen Low-Impuls fester Breite liefern, und das erst ab Windows XP.

Komfortable Lösung

Die Schaltung bietet die Parallelisierung der BUSY-Leitung in 3 Bits. Das macht das Lesen von bitseriellen Geräten um den Faktor 3 schneller. Lohnt sich also bei derartigen Geräten sehr. Auf Autodetect mithilfe bestimmter Brücken (wie beim Pony-STK200) wird man zugunsten der Geschwindigkeit besser verzichten.

Die Mehrheit der gesichteten Programmiergeräte verwendet BUSY für serielle Eingabedaten. Deshalb ist dieser Anschluss dafür auserwählt worden. Beispiele:

Gegenbeispiele gibt's natürlich auch:

Schaltplan

Der Schaltplan, auch verfügbar als Eagle-Quelle
Die Schaltung hat durch ihre „möglichst geniale“ Verdrahtung folgende Eigenschaften: Der Einbau erfolgt einfach fliegend in ein entsprechendes Donglegehäuse, fertig.
So sieht's aus, wenn's fertig zusammengebaut ist. Hier ohne Deserialisierung; der aufgebrachte Schaltplan macht's klar.
Die Verbindungsleitungen zwischen USB-Paralleldrucker-Konverter, diesem Adapter und der Endschaltung (Programmiergerät) sollte möglichst kurz gehalten werden! Die USB-Leitung zu verlängern ist ohnehin viel bequemer.