zwei Geräte mit unterschiedlichen seriellen Geschwindigkeiten koppel

  • Hallo,

    habe 2 serielle Geräte, die verschiedene Geschwindigkeiten haben und sich nicht durch Konfiguration anpassen lassen.


    Jetzt hätte ich gerne die Möglichkeit die Geräte doch zu koppeln. Kennt jemand dazu eine Software die das Puffern übernimmt?

    Stelle mir das so vor, an einem seriellen Port hängt das erste Gerät mit zB.: 2400 Baud.

    An einer zweiten Schnittstelle hängt das zweiter Gerät mit 110 Baud.

    Eine Software greift auf beide Schnittstellen zu, verbindet die Geräte und "switched" die Geschwindigkeitsunterschiede.


    Oder ginge das mit 2 Modems?

    Suche QBUS Diskettencontroller (DILOG DQ 419, MTI MXV22). Ersatzteile und Omnibus Karten für PDP8/E, Unibus Ersatzteile für PDP 11/40

    Edited once, last by gnupublic ().

  • Oder ginge das mit 2 Modems?

    Nein.


    Kennt jemand dazu eine Software die das Puffern übernimmt?

    Ich wüsste nicht.

    Stelle mir das so vor, an einem seriellen Port hängt das erste Gerät mit zB.: 2400 Baud.

    An einer zweiten Schnittstelle hängt das zweiter Gerät mit 110 Baud.

    Gehts es hier um Daten von einer Kiste auf die andere zu schaufeln, oder ist hier eine direkte Verbindung gefragt ?

    Bei letzeren sehe ich schwarz...


    Gruß, Gerd

  • Vielleicht kann man sich was mit einem "Zwischenrechner" (raspberry pi?) bauen mit 2 Schnittstellen. C-Kermit hat eine Makro-Sprache, damit könnte man sicher ein wenig automatisieren. Um welche Anwendung geht es?


    Wenn es um Dateien ausdrucken, zum Locher schicken, Daten transferieren geht, sollte das machbar sein.


    Eine direkte Teletype-Verbindung hingegen (Bediendrucker) stelle ich mir schwer realisierbar vor.

  • Oder ginge das mit 2 Modems?

    Nein.

    Und warum nicht?

    Telefonanlage ist natuerlich Voraussetzung.


    Die Geschwindigkeiten auf der seriellen Schnittstelle und auf der Telefonleitung waren nicht die gleichen.

    ;------------------------------------
    ;----- ENABLE NMI INTERRUPTS
    (aus: IBM BIOS Source Listing)

  • Unidirektionale oder bidirektionale Kommunikation?


    Unidirektional sollte jedes Betriebssystem mit Ein- und Ausgabe-Umleitung das können. Sowas wie unter MS-DOS:


    copy com1: com2:


    Natürlich vorher mit mode die Kommunikationsparameter beider Schnittstellen festlegen.

  • Es geht mir um die direkte Verbindung. CP/M Rechner mit min 2400Baud mit Konsole an ASR-33 als Ein/Ausgabegerät mit 110Baud.


    Habe eben mal meinen Kaypro 2 genommen, den kann ich auf 110 Baud einstellen und die Eingabe umlenken (stat con:=tty:), dann habe ich die ASR-33 als Terminal.


    Eigentlich würde ich das gerne mit meiner Pertec machen, aber da kann ich nur sehr begrenzt Einfluss auf das serielle Interface nehmen.


    Im Prinzip wäre das sowas wie MQ-Series für Arme....

    Suche QBUS Diskettencontroller (DILOG DQ 419, MTI MXV22). Ersatzteile und Omnibus Karten für PDP8/E, Unibus Ersatzteile für PDP 11/40

  • Ein Arduino Uno kann mehrere serielle Schnittstellen, eine bringt er hardwaremäßig mit, eine zweite ließe sich über die Bibliothek SoftwareSerial realisieren. Laut https://www.arduino.cc/en/Reference/SoftwareSerialBegin aber mindestens 300 Baud. Ob der UART des ATMega328 (der Microcontroller) 110 Baud hinkriegt?

    Ja, das wäre ein schönes Arduino-Projekt. Die 2400 Baud über die Hardware-Schnitstelle und 110 Baud per SoftwareSerial. Die SoftwareSerial-Library müsste man evtl. modifizieren für 110 Baud.

  • Geht sowas nicht auch mit einem Unix und 2 Schnittstellen, indem man einfach die eine auf die andere umleitet ? Automatische Anpassung inklusive ? , so ala "cat /dev/tty0 | /dev/tty1" (oder ttyS0/ttyS1) (keine Ahnung, ob das wirklich sinnvoll ist).

  • Das wäre wohl nicht bidirektional.

    Aber ich schaue mal ob ich da etwas simples mit Python hin bekomme.

    Suche QBUS Diskettencontroller (DILOG DQ 419, MTI MXV22). Ersatzteile und Omnibus Karten für PDP8/E, Unibus Ersatzteile für PDP 11/40

  • Habe mal einen Versuch gemacht. Mit einem Raspi und zwei seriellen USB Interfaces. Diese hängen an einem Laptop jeweils an einem Terminal. So kann ich die beiden Terminals mit verschiedenen Geschwindigkeiten einrichten.

    Dazu ein kleines Progrämmchen, was jeweils von den Schnittstellen liesst und auf die andere Schnittstelle das gelesene schreibt.

    Tippe ich nun in dem einen Terminal etwas ein, erscheint es am Anderen und umgekehrt.

    Das geht zum Beispiel prima wenn ich ein Terminal mit 9600 8N1 und das andere mit 2400 8N1 betreibe.


    Nicht mehr klappen tut es wenn ich statt 8N1 auf 7N2 wechsele. Dann kommt nicht mehr an was gesendet wurde, sondern etwas anderes!


    Hier der Beispielcode in Python:


    import serial

    ser1=serial.Serial('/dev/ttyUSB0',9600,bytesize=7,parity='N',stopbits=2,timeout=0.004)

    ser2=serial.Serial('/dev/ttyUSB1',110,bytesize=7,parity='N',stopbits=2,timeout=0.03)


    ser1.reset_input_buffer

    ser1.reset_output_buffer

    ser2.reset_input_buffer

    ser2.reset_output_buffer


    x=0;

    while (x < 1000):

    eins=ser1.read(40)

    zwei=ser2.read(10)

    ser1.write(zwei)

    ser2.write(eins)

    x=x+1;


    ser1.close()

    ser2.close()

    Suche QBUS Diskettencontroller (DILOG DQ 419, MTI MXV22). Ersatzteile und Omnibus Karten für PDP8/E, Unibus Ersatzteile für PDP 11/40

  • Du darfst nicht vergessen, auch die Terminalprogramme auf 7 Bit umzustellen.

  • Klar, das war angepasst. Die jeweiligen Terminal - Seriell Verbindungen sind in sich stimmig.


    Werde heute abend mal mit minicom testen ob es damit klappt.

    Suche QBUS Diskettencontroller (DILOG DQ 419, MTI MXV22). Ersatzteile und Omnibus Karten für PDP8/E, Unibus Ersatzteile für PDP 11/40

  • Die Frage ist halt auch, was passiert, wenn du auf der einen Seite mit 8 Bit sendest, und auf der anderen Seite mit 7 Bit empfängst, wie wird das konvertiert, oder wird einfach nur abgeschnitten?

  • Für das Python wird pyserial benötigt. Aus dessen Dokumentation:

    https://pythonhosted.org/pyserial/pyserial_api.html

    geht hervor es kann auch 50 und 75 Baud.


    Ob es funktioniert hängt eventuell sehr mit den verwendeten Seriellen Interfaces ab. Nimmt man den Raspberry, kommt man bei mehreren Schnittstellen um USB Interfaces nicht herum.

    Mit denen habe ich, auch hier beim Testen, mit verschiedenen Schnittstellen sehr unterschiedliche Ergebnisse bekommen! Die billigen Chinakracher für 4€ machen manchmal sehr seltsame Sachen und haben das Letzte Byte tausendfach im Eingangspuffer. Mit Anderen Schnittstellen taucht das Problem gar nicht auf.

    Am besten wäre für solche Experimente wohl ein "richtiger" PC mit echter serieller Schnittstelle.

    Suche QBUS Diskettencontroller (DILOG DQ 419, MTI MXV22). Ersatzteile und Omnibus Karten für PDP8/E, Unibus Ersatzteile für PDP 11/40

  • bytesize – Number of data bits. Possible values:
    FIVEBITS, SIXBITS, SEVENBITS, EIGHTBITS

    parity – Enable parity checking. Possible values:
    PARITY_NONE, PARITY_EVEN, PARITY_ODD, PARITY_MARK, PARITY_SPACE

    stopbits – Number of stop bits. Possible values:
    STOPBITS_ONE, STOPBITS_ONE_POINT_FIVE, STOPBITS_TWO


    Vielleicht mal die Werte aus der verlinkten Anleitung einsetzen. Es sagt ja niemand, daß die wirklich auf Zahlen oder Einzelbuchstaben "mappen" und Du schreibst ja "7" bzw. "N" statt der Sachen da.


  • Leider nein. Mit den API Benennungen gibts böse Fehlermeldungen. Blätter mal zurück nach "short Introduction". Da ist dann folgendes Beispiel:


    Code
    1. >>> ser
    2. Serial<id=0xa81c10, open=False>(port='COM1', baudrate=19200, bytesize=8, parity='N', stopbits=1, timeout=None, xonxoff=0, rtscts=0)

    Suche QBUS Diskettencontroller (DILOG DQ 419, MTI MXV22). Ersatzteile und Omnibus Karten für PDP8/E, Unibus Ersatzteile für PDP 11/40

  • So sollte das nach Beschreibung doch gehen...

  • So, geschafft! Es klappt:


    Die Pertec ist mit 2400 7N2 remote gestartet und hat brav auf die ASR-33 (110 7N2) ausgegeben!


    Das Programm war schon in Ordnung so wie es oben steht, natürlich habe ich die Schleife etwas verlängert.

    Die Schwierigkeit bestand mal wieder in den USB-Interfaces. Tests bis 300 Baud runter gingen prima, aber 110 Baud haben die einfach nicht gemacht. Dann kam gar nichts oder Murks heraus.

    stty zeigte aber die korrekten Einstellungen an.

    Daher habe ich die native serielle Schnittstelle am Raspberry in Betrieb genommen. Die brauchte noch einen TTL nach RS232 Konverter. Damit (/dev/ttyAMA0) konnte ich zuerst erfolgreich mit dem Laptop testen. Dann habe ich die Oldies angeschlossen und sofort ging es wie gewünscht.

    Einzig die Zeichen "XE@@" am Anfang stammt vom Einschalten der Pertec und gehört nicht zur Ausgabe.


    Soweit zum seriellen Switch! Hier noch mal kurz das Konzept:


    ASR-33 (110 Baud 7N2) ----> /dev/ttyAMA0 ---- Raspberry ---- /dev/ttyUSB0 <------ Pertec-PCC2000 (2400Baud 7N2)


    Nochmal kurz das finale mini code mit Endlosschleife in Python:


    import serial

    ser1=serial.Serial('/dev/ttyUSB0',2400,bytesize=7,parity='N',stopbits=2,timeout=0.004)

    ser2=serial.Serial('/dev/ttyAMA0',110,bytesize=7,parity='N',stopbits=2,timeout=0.01)

    ser1.reset_input_buffer

    ser1.reset_output_buffer

    ser2.reset_input_buffer

    ser2.reset_output_buffer

    x=0;

    while (x < 1000):

    eins=ser1.read(40)

    zwei=ser2.read(10)

    ser1.write(zwei)

    ser2.write(eins)

    # x=x+1;



    Was ich beobachtet habe, ist ein gewisses Stottern bei der Rückmeldung der Eingabe. Das kann man bestimmt noch erheblich verbessern durch passendere timeout Werte. Zeichen sind aber wohl nicht verloren gegangen. Python und die Bibliotheken sind im Raspbian Image schon dabei, wer will kann also gleich loslegen.

    Wegen des Geräuschpegels der ASR werde ich weitere Versuche verschieben...

    So einen seriellen "man in the middle" kann ich mir auch für bestimmte Analyse oder Reparaturzwecke vorstellen.

    Suche QBUS Diskettencontroller (DILOG DQ 419, MTI MXV22). Ersatzteile und Omnibus Karten für PDP8/E, Unibus Ersatzteile für PDP 11/40

  • Übrigens, wenn man die Datenblätter der USB-Serial Konverter liest, kann man leicht sehen, dass z.B. der beliebte FT232R keine 110 baud kann.

    Da kann man den chinesischen USB-Kabel-Herstellern keinen Vorwurf machen. Mit dem CH340 sollte es dagegen gehen... :prof:

    Auch wegen der Windows-Treiberproblematik verwende ich gerne die 340-er.


    Ich habe das mal gegenübergestellt - nur damit keine alternativen Fakten verbreitet werden:

  • Welche Windows-Treiberproblematik? Mit FT232?


    Ich hatte von den CH340 nichts gutes gehoert. Bis jetzt.

    ;------------------------------------
    ;----- ENABLE NMI INTERRUPTS
    (aus: IBM BIOS Source Listing)

  • ich meinte die bekannte Problematik mit den chinesische Clones/Raubkopien der älteren FT232 chips, die dann von Windows 7+ nicht mehr akzeptiert wurden. Das hat nichts mit der Technik zu tun, sondern mit Urheberrechtsschutz. Rechtlich in Ordnung, aber für den "normalen" Endverbraucher ärgerlich, da man ja nie genau weiß was man da so kauft, auch im guten deutschen Einzelhandel.


    Ich habe den Eindruck, dass da zu den USB-RS232 Konvertern viele Gerüchte und Mythen im Umlauf sind. Und natürlich ist eine direkte RS-232C oder TTL Verbindung immer noch vorzuziehen (USB-Latenzzeiten etc.).


    Ich will jetzt aber keinen Krieg nach dem Motto "was ist besser" beginnen , sondern wollte auf die Datenblätter hinweisen, in denen meist nützliche Informationen stehen.

  • ich meinte die bekannte Problematik mit den chinesische Clones/Raubkopien der älteren FT232 chips, die dann von Windows 7+ nicht mehr akzeptiert wurden.

    Noch schlimmer. FTDI at die FT232-Clone per Software-Treiber geziehlt unbrauchbar gemacht. Später hat sich dann ein Weg gefunden, die wieder zu reaktivieren. Das war ein ziemliches Eigentor, denn da man als Käufer nicht unterscheiden konnte, ob man ein Board mit Original oder Clone hat, wurden die FT232-Chips gemieden. Das hängt denen heute noch nach.

    https://www.golem.de/news/ftdi…haedigen-1410-110039.html


    Die Chinesen sind dann auf CH340 umgestiegen. Fast alle meine Arduinos haben den CH340 drauf. Funktioniert mindestens so unproblematisch wie FT232.

  • <spoiler>Wie sieht es denn inzwischen (unter Win 10) aus, kann man da gefahrlos wieder gefakte FT232 anstöpseln? Hab zwei solche im F(l)achhandel mal gekauft, einer HAMA verpackt, der andere von DELOCK, also nicht gerade Chinesenbillischmarkeausderbucht, und beide sind mir seinerzeit unter Win 8 deaktiviert worden. Ich glaube einen Chinesenbillischmarkeausderbucht mit TTL fürs Gotekflasshen hab ich auch noch. Irgendwas mit älteren Treibern hab ich damals was gebastelt dass die wieder gingen, aber diese private Win 8 Installation und das Firmennotebook aus der Zeit gibts schon nicht mehr. Aktuell hängen sie irgendwo in meiner Bastelbude "am Nagel"...</spoiler>