Hi!
An den der's dann eigeltlich braucht ;-)
Hab' sowas (von 1 x RS232 weg mit RXD, TXD und GND aber alles galvanisch getrennt) mal vor 10 Jahren gemacht um die damals sauteuren Terminalserver (Ethernet auf X RS232) zu ersetzen. Leider ist das Teil nicht mehr sinnvoll zu reproduzieren. Ich habe auch keine Rechte daran.
Busloesungen (RS485/RS422) halte ich nur fuer machbar wenn das Verhalten der vielen versch. Geraete vorhersehbar ist - sprich halb duplex bzw. Slave-Betrieb. Sonst wird's knirschen. GBIB halte ich schon wegen der Kabel fuer unbezahlbar. Ausserdem ist die RS232 Hardware ja auch auf den Geraeten gegeben. Bleib einfach dabei sag ich!
Wie hier ja auch schon in anderen Postings dazu erwahnt, kommen die vom Linux-Kernel bereits unterstuetzten PCI Multiport-Karten (ich arbeite meistens mit der Cyclom Y-Serie, mit je 8 Ports auf RJ12 von Cyclades /
formatting link
in Frage. Da kann man dann ganz normal auf die tty zugreifen. Damit wuerde das ganze dann schon mal nur mehr zu einem Software-Projekt werden.
Wem das aber nicht behagt (warum auch immer) dem bleibt IMHO nur der Loetkolben. Dazu wuerde ich persoenlich heutzutage also folgendes machen:
USB mit FT232BM
formatting link
ans interne schnelle (!) UART eines mit freien Tools (in C) programmierbaren FLASH-Kontrollers dazu Mehrfach-UARTS (ev. 2 x 8) mit der entsprechenden Handshake-Ausruestung (nur falls wirklich notwendig). Dann auf irgendwelche billigen Schnitstellen-Treiber auf RJ-Buchsen.
Die FT232-SW-Treiber stellen dem OS, wie ich gelesen habe, auch ein virtuelles Port zur Verfuegung und Du arbeitest per SW wie normal zur Seriellen.
Der Rest kann je nach Sicherheitsbeduerfnis (der DUe) eigentlich ganz einfach gehalten werden. Betrachte den Dispatcher (ich nenn das Ding jetzt einfach mal so) wie einen Drehwaehler. Wenn DU per SW Bytes an einen bestimmten Port senden willst schalte vor dem eigentlichen Telegramm mit "ESC-Byte Portnummer-Byte" auf das Port um (ein ESC als Ausnahme wird mit ESC ESC gesendet). Das gleiche macht der Dispatcher wenn er auf einem Port was hoert. Er bastelt einen Datenstrom der immer wieder den Daten die ESC-Sequenz mit dem Ursprungsport hinzufuegt. Die Applikation im PC sammelt das dann wieder ein. Unter Linux kann man sich dann bei der Realisierung wirklich austoben (ein grosses Programm das alles macht oder eines das die Daten nur auf Pipes verteilt und dann ein Programm pro externem Geraet usw.
- der Phantasie sind da keine Grenzen gesetzt). Je nachdem wie zeitkritisch das ganze ist muss man den "Drehwaehler" mit seinen Puffern optimieren bzw. apassen. Aber nachdem was ich so ueber die Endgeraete gelesen habe scheint mir das nicht sehr schnell zu sein? Etwas anspruchsvoller wird der Dispatcher natuerlich wenn tatsaechlich die Hardware-Hanshakes auch mit behandelt werden muessen.
Ach ja, falls der PC weit vom Dispatcher weg sein sollte dann verwende fuer diese einzelne interne Schnittstelle des Kontrollers eine RS422 Punkt zu Punkt Verbindung und nimm direkt am PC einen fertigen FTD-USB-RS232-Adapter und dann einen RS232/422-Adapter (mit TX auf Dauertastung). Dann sollte aber jede Eventualitaet (PC, Laptop, RS232, USB...) auch abgedeckt sein.
Falls Du aber wirklich pfuschen willst - das mit dem parallel-Port. Auch dazu gibt es USB-Umsezter. Unter der Annahme das das "Auslesen" der 16 Geraete nur dann stattfinden soll wenn der PC es will geschieht und die Geraete wirklich sonst passiv sind (keine Spontanmeldungen an den PC), kann man das obige Dispatcher-Prinzip auch per Hardware zusammenschustern. 2 x
4067 pro Richtung (nur als Beispiel = 16-channel Analog Multi./Demultiplexer) die legen je nach den 4 Bit (vom LPT) einen Pin auf einen von 16 Pins und damit die Schnittstelle auf 5V-Level zwischen den RS232-Treibern "verdrahten". Bei HS-Leitungen das gleiche.
D.h. dann Ausgabe der 4-Bitadresse zur Anwahl des Geraetes. Datenverkehr an bzw. von dem Geraet. Neues Geraet anwaehlen usw.
Falls das auch reicht soll's recht sein. Man muss halt beruecksichtigen was die Geraete brauchen. Und die kenne ich halt nicht.
Tschau, Charlie