Port-Steuerung auf USB2Parallel Converter ?

[kaimex]

Hallo,

ich habe mal einen "USB to Parallel Converter" gekauft.
Normale Verwendung ist der Anschluß eines älteren Druckers mit Parallel-Interface und DB25-Stecker an einen PC mit USB-Anschlüssen. Es gibt zum Converter keine weiteren Informationen, auch nicht über den angeblich bereits in Windows integrierten Treiber.

Ich würde damit gerne einen 12Bit DA-Wandler steuern, der über ein 4Bit-Interface mit 3-Registern verfügt, 2 Adress-Leitungen, Chip-Select und Strobe. Das hat man "anno-dunne-mals" auf dem Original-IBM-PC unter DOS durch direktes Ansprechen der 8Bit-Register auf dem Parallel-Interface gemacht.

Weiß jemand, ob das mit so einem Converter und dem Standard-Treiber oder einem speziellen Treiber auch möglich ist ?
Wenn ja, wo findet man eine Beschreibung ?

MfG Kai

[bitbrain2101]

Hallo Kai,

ich habe zwar keine Ahnung von Programmierung, aber ich weiss, dass moderne Betriebssysteme aus Sicherheitsgründen in Schichten (Layern) aufgebaut sind. Dadurch ist es nicht mehr möglich, Hardware direkt anzusprechen. Alte Spiele, bei denen direkt in den Speicher der Grafikkarte geschrieben wurde, funktionieren deshalb nicht auf modernen Betriebssystemen. Mit welchem Betriebssystem willst du den Converter betreiben ?

MfG, Tobias

[andreas42]

Hallo Kai,

gerade im Bezug auf USB-Parallel-Konverter habe ich schon viele wenig erfreuliche Dinge gelesen - z.B. dass sie oft nur zum Ansprechen von Druckern taugen, und auf USB-Seite irgendein high-level-Protokoll für Drucker beherrschen. Fürs klassische Basteln mit einzelnen IO-Pins sind sie wohl nur schwierig bis nicht geeignet.

Wenn Du einen USB-Seriell-Adapter hast, ist es wahrscheinlich leichter: RTS und DTR sind quasi frei setzbar, und mit einem entsprechenden Byte über TX kann man einen einzelnen Puls simulieren.

Der einfachste Weg: Du hast doch einen Raspberry Pi, oder? Der hat GPIO-Pins, die sich direkt als Devices ansprechen lassen, und dann sogar von der Shell aus setzbar sind:

Code:

echo "9" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio9/direction
echo "1" > /sys/class/gpio/gpio9/value

Du musst nur mit 3.3 V vs. 5 V bei der Logik aufpassen.

Viele Grüße
Andreas

[Selbstbauer]

Hallo Kai, habe leider selber nie mit so etwas herumgefummelt..

Erinnere mich nur, dass es auch mal Relais-Karten gab, die an den Parallelbus angeschlossen wurden. Nannte man das nicht mal Centronix-Kabel oder so ähnlich? Auch hatte ich mal eine PC-zu-PC-Verbindung über ein solches Kabel, es ging also auch bidirektional. ("Laplink" hieß das Teil, glaube ich, um die Schlepptops ins Filesystem einzubinden, und es gab auch ein serielles Kabel für COMx dazu)
Ich vermute, da gibt es im Parallelkabel eine Handshake-Leitung, und wenn die bedingungslos "OK" meldet, dann kann man da einfach und ungeniert seine Bytes hindurchschicken. Mehr weiß ich darüber jetzt auch nicht. Und wenn der Converter korrekt arbeitet, müsste das ja auch über USB so gehen.
Vermutlich weißt du das ja alles schon, aber falls eine verwertbare Info dabei ist ...

MfG, Binse

[andreas42]

Noch ein Nachtrag: Zumindest einen echten Parallelport kann ich in Python so benutzen:

Code:

import parallel
p = parallel.Parallel()
p.setData(0b101010)

Dazu muss das Paket "pyparallel" installiert sein, was pip (oder pip3) im Handumdrehen für Dich erledigt. Das gewünschte Bitmuster taucht dann unmittelbar am Ausgang auf.

Viele Grüße
Andreas

[Kuni]

Diesen direkten Durchgriff auf die HW gab es unter DOS und den ersten DOS basierten Windows Versionen, bis Win98. Ab Win NT wurde die sog HAL (HW Abstraction Layer) eingeführt. Damit ist ein Zugriff auf die HW nur noch per API (Interface) eines HW Treibers möglich. In der Praxis sind mWn viele Treiber im Detail ihrer API gar nicht offen gelegt, was es schwierig macht heraus zu finden was per Interface geht. Windows konform müsste man ergo nun einen eigenen Treiber schreiben, der dann seinerseits ein Interface zum steuern der einzelnen Leitungen bereit stellt. 

Übrigens Kai, einen solchen rudimentären Logic Analyse hatte ich mal selbst geschrieben. War nicht schnell, hat aber ausgereicht um langsame Protokolle mit zu lesen. 
Anders herum ging auch, also Ausgabe von Digitalsignalen, als kleiner Logic Generator. War ne feine Sache 

[kaimex]

Hallo,
danke für die diversen Hinweise.

@Binse: Das kenne ich auch noch alles. Stammt aber aus vergangenen DOS-Zeiten.
Windows verwehrt normalerweise den Zugriff auf Port-Adressen für gemeine User, damit Microsoft an der Lizensierung von zertifizierten Treibern Geld verdienen kann.
Nichtsdestotrotz hat es von "Füchsen" Kernel-Erweiterungen gegeben, die doch direkte Port-Zugriffe (in eingeschränkten Adressbereichen) zuließen. Die habe ich auch. Zur Verwendung müßte man aber Port-Adressen kennen. Die wird es hier nicht geben, weil man ja erst mal Informationen zum USB-Bus schicken muß.
Man braucht also Funktionen, die per USB Daten an Ports auf dem Converter schicken.
Darüber verrät der Hersteller aber nichts.
Ich habe noch nicht versucht herauszubekommen, ob es darüber Informationen beim Hersteller des Interface-Chips (FTDI) gibt.
Das Ganze soll unter Windows laufen, weil da der "Rest" der benutzten Programme beheimatet ist. Deshalb möchte ich nicht den Umweg über den Raspi gehen.
Python wäre wahrscheinlich möglich.
@Andreas:
Gibt es denn auch Befehle, mit denen man den Status von Steuerleitungen auf der 25-poligen Parallel-Port-Buchse setzen kann (zur Realisierung von Write- und Datenübernahme- Strobes am DAC) ?

Wenn sich das Ganze als zu umständlich oder ungewiß herausstellt, wäre es vermutlich besser, einen Weg über USB->I2C Bus zu beschreiten. Die modernen und billigen I2C-Bus 12Bit DACs sind allerdings nicht (wie gewünscht) 12 V fähig (nur 3.3 bis max 5 V). Einen 25V fähigen alten CMOS 12Bit-DAC habe ich noch (doppelt) rumliegen. 
Irgendwo müßte sogar ein autarker 12Bit DAC mit RS232-Interface rumliegen, der vor Jahrzehnten mal an einem "Colani"-Laptop betrieben wurde.
Wunsch-Vorstellung ist aber ein 12Bit multiplying DAC, den ich an der 12 V Betriebsspannung des NE555 in der Speed Control der A77 betreiben kann zwecks Einstellung der Bandgeschwindigkeit.

MfG Kai

[andreas42]

Ja - ich kenne die Steuerleitungen nicht, aber das Python-Modul definiert zumindest folgende Funktionen:

Code:

p.setData(value)
p.setDataDir(level)
p.setDataStrobe(level)
p.setAutoFeed(level)
p.setInitOut(level)
p.setSelect(level)
p.getInError()
p.getInSelected()
p.getInPaperOut()
p.getInAcknowledge()
p.getInBusy()

Der Parameter "level" ist dabei jeweils 0/1 oder False/True.

Das Modul scheint auch unter Windows zu laufen, es hat intern Implementierungen für die Linux- und die Windows-Api. Ein ausführliches Beispiel, wie man es für die Ansteuerung eines LCD verwenden kann, ist hier: https://github.com/pyserial/pyparallel/b...les/lcd.py. Dort kann man auch in den Code der Interfaces zum Betriebssystem schauen.

Viele Grüße
Andreas

[kaimex]

Danke Andreas,
das, was hinter p.set steht, klingt vertraut und vielversprechend.

Der Weg über Python sollte in diesem Fall nur ein "Work-around" sein. Da ich mit einem Windows-Programm den nächten Wert des DAC berechne, müßte ich aus dem Programm die Python-Befehle abschicken können.
Gibt es dafür Beispiele ?

Es gäbe noch eine andere Alternative zur Steuerung des vorhandenen CMOS-DAC:
ein µController mit USB-Interface (als Empfänger), der über seinen Daten- und Adressbus das 4-Bit Interface des DAC bedient.
Dazu wäre von Interesse, welches der "schlankste" µC von zB Atmel/AVR wäre, für den es USB fertig gibt.
Das AVR-Studio o.ä. hatte ich vor Jahren schon mal auf einem Laptop (bis dessen Harddisk crashte).

MfG Kai
Nachtrag: "Zur Not könnte man natürlich auch einen Controller nehmen, der bereits eine 12Bit-Dac enthält. Dessen Output müßte dann allerdings uU noch in Richtung 4...12V transponiert werden.

[andreas42]

Hallo Kai,

Der Weg über Python sollte in diesem Fall nur ein "Work-around" sein. Da ich mit einem Windows-Programm den nächten Wert des DAC berechne, müßte ich aus dem Programm die Python-Befehle abschicken können.
Gibt es dafür Beispiele ?

vielleicht gibt es ja nativ für die Sprache / Umgebung, in der Du den Wert ausrechnest, auch so ein Modul, was den Parallelport für Dich abstrahiert und ansprechbar macht. Das wäre sicherlich am einfachsten.

(Python kann man zwar auch als Skriptsprache in eine Anwendung mit dem ganzen Interpreter einbetten - aber das geht für Deinen Anwendungsfall nun mehr als nur zu weit.) Und auch den Ratschlag "mach doch einfach alles in Python" wirst Du mir eher um die Ohren hauen

Ich würde das über Sockets machen: Ein kleines Python-Programm lauscht nur auf einem Netzwerk-Port, und bedient entsprechend den Parallelport. Das andere Programm muss dann nur eben in diesen Netzwerk-Port was reinschreiben. Ob das einfach oder schwierig ist, hängt wieder sehr von Deiner Sprache und Umgebung ab.

Vorteil der Netzwerk-Variante: Es wäre dann völlig egal, ob steuerndes Programm und DAC-Befüller auf dem gleichen oder auf unterschiedlichen Rechnern laufen - womit auch der RasPi mit seinen GPIO-Pins wieder in Betracht kommt, wenn der USB-Parallel-Wandler seine unschöne Seite zeigt.

Wie das mit den Sockets in Python geht, steht ausführlich hier: https://docs.python.org/3/howto/sockets.html. Die Kurzfassung sieht so aus:

Code:

import parallel
import socket

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind(('', 1234))
s.listen(5)

while True:
    cs, addr = s.accept()
    data = cs.recv(10)
    p.setData(int(data, 16))

Hab ich heute nicht wieder ausprobiert, damit konnte ich mal auf den Parallelport eines anderen Rechners schreiben, z.B. mit netcat, oder mit telnet.

Es gäbe noch eine andere Alternative zur Steuerung des vorhandenen CMOS-DAC:
ein µController mit USB-Interface (als Empfänger), der über seinen Daten- und Adressbus das 4-Bit Interface des DAC bedient.
Dazu wäre von Interesse, welches der "schlankste" µC von zB Atmel/AVR wäre, für den es USB fertig gibt.
Das AVR-Studio o.ä. hatte ich vor Jahren schon mal auf einem Laptop (bis dessen Harddisk crashte).

Ich hab dafür einen Teensy 2.0 in der Schublade: https://www.pjrc.com/teensy/, den gibts z.B. auch bei Reichelt. Programmiert sich wie ein Arduino, man findet also 1000 Anleitungen für alles im Netz, und er kann am Ende ganz einfach über den USB einen virtuellen seriellen Port anbieten. Ist aber eine Nummer komplizierter, als das einfach über den RasPi zu machen

Viele Grüße
Andreas

[kaimex]

Bei der TU-Chemnitz habe ich dies gefunden:
https://www-user.tu-chemnitz.de/~heha/ba...C/USB2LPT/
aber noch nicht "das Kleingedruckte" gelesen.
Ziemlich weit oben steht "unfertig weil JTAG fehlt". Da frage ich mich: gibt es das nun oder nicht ?

Sockets oder sowas ähnliches habe ich schon benutzt, um zwischen zwei Windows-Programmen Daten über den Speicher auszutauschen. Das hilft hier aber nicht. Ich müßte also zwischen Python-Prog und Windows-Prog austauschen und die Python-Programmierung das Windows-API unterstützen.

Da der Raspi über WLAN am Internet-Router hängt, kommt er nicht über LAN an Windows-Rechner. Das ist mir zu riskant.

Ich dachte nicht an Teensy & Consorten, sondern an ATiny2313 o.ä. mit minimalen USB-Empfangsmöglichkeiten.

Angeblich gibt es noch Parallel-Port Interfaces für PCI-Bus. Ob man da die Leitungen setzen kann ?

MfG Kai

[andreas42]

Hallo Kai,

Sockets oder sowas ähnliches habe ich schon benutzt, um zwischen zwei Windows-Programmen Daten über den Speicher auszutauschen. Das hilft hier aber nicht. Ich müßte also zwischen Python-Prog und Windows-Prog austauschen und die Python-Programmierung das Windows-API unterstützen.

naja, Netzwerk ist Netzwerk, und solange beide Parteien die ausgetauschten Bytes gleich interpretieren, sind doch Programmiersprache und Betriebssystem völlig egal.

Ich dachte nicht an Teensy & Consorten, sondern an ATiny2313 o.ä. mit minimalen USB-Empfangsmöglichkeiten.

Hm, wieviele 100 Stück willst Du denn davon produzieren, dass der Preisunterschied eine Rolle spielt? Der Teensy 2.0 ist wahrscheinlich der einfachste Weg, und mit 19,50 € bei Reichelt (oder 6,50 € bei ebay) auch nicht unerschwinglich.

Angeblich gibt es noch Parallel-Port Interfaces für PCI-Bus. Ob man da die Leitungen setzen kann ?

Ja, sowas habe ich mal irgendwo verbaut - das ist dann ein echter Parallelport. Setzt allerdings einen PCI- oder PCIe-Bus voraus, der in den allgegenwärtigen Notebooks leider nicht vorhanden ist. Wenn es allerdings um einen stationären Rechner geht, wäre das meine erste Wahl.

Viele Grüße
Andreas

[kaimex]

Das, was ich damals benutzt habe, hatte nichts mit Netzwerk zu tun. Die beiden Programme hatten einen gemeinsamen Speicherbereich und dazugehörige Flags, über die sie Daten vorher vereinbarter Größe und Menge austauschten.
Die genaue Windows-typische Bezeichnung habe ich vergessen. Müßte ich im Source-Code nachsehen (wenn der noch vorhanden ist).

Ich bezahle ungern Dinge, die ich nicht benutze, auch wenn sie mich nicht arm machen. (Mein Vater pflegte zu sagen: "Junge, nu aas ma nich so mit meinem Geld !". Davon ist was hängen geblieben.)

Dieser Rechner steht unterm Tisch, hat ein Midi-Gehäuse und einen riesigen Kühlkörper mit langsam laufendem Lüfter auf der CPU, damit man von ihm nix hört.  Ich hab ihn zwar noch nie auf gehabt, er sollte aber einen PCIe Bus o.ä. haben, jedenfalls das, was 2012 aktuell war)...
Auf der Rechnung steht u.a. VGA ATI ..... PCI16
Das Mainboard ist ein GigaByte Z77-DS3H.

Im Prinzip wäre es möglich, die Aufgabe der Wert-Berechnung und DAC-Steuerung auf den Raspi zu verlagern. Dazu müßte ich in der Lage sein, dort Audio-Daten einzulesen und per FFT zu analysieren. Ersteres habe ich auf dem Raspi noch nicht gemacht. Unter Windows ist mir bekannt, wie es geht.
Mir wäre auch nicht wohl dabei, zwei Audio-Interfaces parallel an die A77 anzuschließen. Bei einfachen hat man an den Eingängen "Spuren" des Abtast-Prozesses. Das könnte das jeweils andere Interface stören.

MfG Kai

[timo]

Die genaue Windows-typische Bezeichnung habe ich vergessen.

DDE? OLE?

[kaimex]

Nee, glaub ich nicht.
Ich guck demnächst mal nach,
im Moment fordert die Überspielung eines zweiten ARISTONA Bandes (730m, 4-Spur) meine volle Aufmerksamkeit.
Die Software befindet sich auf einem anderen Rechner, der gerade Pause hat.

MfG Kai

[JUM]

Schau mal nach STM32G0 und da nach NUCLEO-G071RB.
Entwicklungssystem gibt es für 0 € bei KEIL/ARM.
VG Jürgen

[kaimex]

Danke für den sicher gut gemeinten Hinweis,
erscheint mir aber ein paar Nummern zu groß für die Aufgabe.
Es soll doch eigentlich nur eine 12-Bit Zahl von Windows aus gesendet und vor Ort in drei 4-Bit Häppchen an einen DAC übergeben werden. Dafür braucht man keine 32-Bit ARM Cortex CPU.

MfG Kai
PS.: Hier wird gerade geballert, als hätte niemand darum gebeten, es in diesem Jahr mal sein zu lassen.

[kaimex]

So,
ich hab mal nachgeguckt, was ich vor "geraumer Zeit" (anscheinend 2007) benutzt habe zum Datenaustausch zwischen zwei Windows-Programmen.
Das nennt sich "WM_COPYDATA"-Message, wird zB beschrieben hier
https://docs.microsoft.com/en-us/windows...m-copydata
hier gibt es ein Anwendungsbeispiel
https://www.codeproject.com/articles/115...m-copydata

MfG Kai

[kaimex]

Inzwischen habe ich mal meinen USB-Parallel-Port Adapter näher inspiziert.
Der taugt tatsächlich nur (wie von Andreas vermutet) als Druckeranschluß.
Zugriff auf die emulierten Ports wird nicht unterstützt.
Damit ist er eigentlich überflüssig, es sei denn es ergäbe sich mal ein Grund, einen meiner noch im Keller und auf dem Boden rumstehenden 9- und 24-Nadeldrucker zu benutzen.
Der aktuelle Laserdrucker läuft über USB.

An Andreas hätte ich noch die Frage zum Port-Zugriff unter Python, ob das auch für 64-Bit Linux zutrifft.

Bei Windows ist es so, daß es für 32 Bit Versionen ein halbes Dutzend  "Workarounds" gibt, die doch Zugriff auf die Ports ermöglichen.
Bei 64-Bit Windows hat Microsoft die Hürde so weit erhöht, daß es nur mit "zertifizierten" Treibern geht, die sich normale Sterbliche nicht leisten können/wollen.
Mit WinIO ist es "im Prinzip" machbar, aber nur in einem speziellen Entwicklungsmodus oder eben mit teurem Zertifikat.

Ist unter den Lesern jemand, der auf seinem Rechner "Virtuelle Maschinen" betreibt ?
Mich würde mal interessieren,
1. ob man bei Installation vom letzten DOS oder FreeDOS in einer VM unter 64 Bit-Windows mit alten 16 Bit Programmen aus der Zeit Zugriff auf die IO-Ports bekommt.
2. ob es geht, wenn man Windows NT oder XP in einer VM unter 64-Bit Windows (7) installiert.

MfG Kai