Vier serielle Schnittstellen multiplexen/demultiplexen

Vollduplex auf einem Draht, oder getrennte Sende- und Empfangsleitung?

Stichwort: Zeitmultiplex

Ein Multiplexer 8:1 und ein Demultiplexer 1:8 auf beiden Seiten und mit mehr als der 20-fachen maximalen Datenrate durchtakten. Problem ist dabei nur die Taktrückgewinnung und die Synchronisation.

Ich würde 4 Kaben ziehen :-)

Gruß

Stefan DF9BI

Ich meinte getrennte Sende- und Empfangsleitung und Zeitmultiplex.

Das wäre die technisch einfachere Lösung. Sie ist aber leider nicht immer praktikabel, womit wieder die angedachte Multiplexgeschichte als interessante Alternative anzusehen ist.

MfG Martin

Martin Konopka schrieb:

Falls die Daten sowieso in den Rechner gehen sollten und du keine Allergie gegen USB hast, kannst du dir n RS232 nach USB Konverter besorgen und einen USB-Hub dazu. In früheren Jahren gab es auch RS232 (und V24) Konzentratoren für die Mainframe-Terminals. Keine Ahnung, ob es so was noch gibt, im Zeitalter der WLANs und sonstigen Gedöns. Vor 10 Jahren hätte ich mehrere 32 Port Konzentratoren für umsonst haben können, aber mein Keller war nicht groß genug :-)

Waldemar

Grundsätzlich würde das gehen, aber leider kommen unsere seriellen Signale nicht immer aus einem PC mit USB-Anschluß heraus. Auch sollten die Signale quasi "gleichzeitig" übertragen werden, womit einige Fragen bezüglich des Timings verbunden sind. Unsere Übertragungsstrecke kann zudem gestört sein und sollte auch dann definiert reagieren. Funkstrecken sind nicht möglich. Gefühlsmäßig glaube ich nicht, dass fertige Systeme immer problemlos in diesem Umfeld funktionieren. Bei einem Eigenbau sind zumindest die Grenzen bekannt und man kann bei geänderten Anforderungen einfacher reagieren.

MfG Martin

Martin Konopka schrieb:

Ich habe für wenige Euro 1 x USB 1.1 nach 4 x RS232 gekauft. Jeder dieser 4 RS232 taucht als eigene COMx auf und kann offensichtlich auch als solche ganz normal angesprochen werden. 115 kBaud habe ich getestet und funktioniert auch. Wie das Handling mit mehreren Schnittstellen GLEICHZEITIG läuft, weiß ich nicht; habe ich noch nicht probiert. Wozu die vier Taster über den RS232 gut sind, habe ich noch nicht raus bekommen. Auf eine Anleitung verzichtete der Hersteller.

Servus Christoph Müller

Hallo Martin,

Wenn das richtig sicher gehen soll, wuerde ich ein Traegerfrequenzverfahren mit FSK in Erwaegung ziehen. Ist aetzend in der Entwicklung, aber nur einmal. Danach kann man es immer wieder einsetzen.

Ansonsten gibt es vielleicht hier Ideen:

--
Gruesse, Joerg

http://www.analogconsultants.com

Waldemar Krzok schrieb:

gibbet immer noch ....

Wenn RS485 in Frage kommt, dann ist der Drops doch bereits gelutscht. Du betreibst das Teil mit z.B. 1MBit/s und läßt Modbus als Containerprotokoll drauf laufen.

Das hat den Charme, daß du überhaupt nix neu entwickeln mußt, denn alle nötigen Komponenten, um über dieses Backbone dann deine vier RS232-Verbindungen quasi-gleichzeitig abzuwickeln, gibt's fix und fertig in Industriequalität für relativ kleines Geld zu kaufen. Insgesamt würde der Spaß ungefähr 700 ¤ kosten.

Keine Eigenentwicklung mit Anspruch auf eine Industrielösung hat auch nur näherungsweise die Chance, in diese Preisregion vorzustoßen.

"Martin Konopka" :

Problem ist ja, dass die 4 RS232 Signale zueinander nicht synchron sind. Teilweise (oder meistens?) kann da auch gar kein Transfer stattfinden. Du brauchst 1 CPU mit 5 SIO's. Auf dem Sammelkanal Nr. 5 wird zeitversetzt immer gesendet (entweder die Daten von den 4 Kanälen oder einfach nur 0) und nur dann wenn wirklich Daten da sind, wird das

9.bit gesetzt. Die Gegenseite braucht dann nur mitzuzählen - und wenn das 9.bit gesetzt ist - die Daten dem entsprechenden Kanal weiterzureichen.

M.

--
Bitte auf mwnews2@pentax.boerde.de antworten.

Martin Konopka schrieb:

Als uC Fetischist :) schlage ich einen ARM7 von z.B. ST vor.

Da gibt es Derivate mit 4 UARTS. Mit einem parallel - seriell - Tranceiver dann über das Kabel oder eventuell mit CAN-Schnittstelle.

Alternativ, aber auch mit uC :), mit billig ARM7 von NXP einen einfachen Zeitmultiplexer aufbauen. Sollte bei 4x115k und 60MHz-Takt noch gut machbar sein. Kommt allerdings auch auf die Kabellänge/Qualität und Störungen an. Wenn aufwendige Signalformung/Filterung notwendig wird, muss man genau prüfen ob's geht.

Ansonsten gib's ja noch FPGA oder diskreter Aufbau (bei großen Stückzahlen) oder PC-Board/Linux mit Flash-Disk bei Einzelstücken.

mfg Rolf

Stefan Brröring schrieb:

Wie kommst du auf die 20? Erfahrung? Oder das Abtasttheorem ein bischen aufgerundet?

Fragt sich, Johannes

--
PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
meisten hier bereits mit Namen kennen.
  Markus Gronotte aka "Makus" aka "Kosst Amojan" in de.sci.electronics

In diese Richtung laufen auch meine Überlegungen. Dazu suche ich einen gut Handhabbaren µC mit 5 SIOs oder einen Baustein mit mindestens 4 UARTs, der von einem µC (mit einer SIO) angesprochen wird. Der 4-UART-Baustein sollte hierbei gut mit einem 9. Datenbit umgehen können, einen kleinen Datenpuffer besitzen und mindestens 1 MBaud beherrschen.

MfG Martin

Mit 5 SIOs würde ich das nach Möglichkeit auch machen, aber die Vorgaben des OP passen vermutlich nicht dazu: Beliebige Protokolle!!

Das Problem mit der Synchonität bekommt man dann nur durch eine ausreichend hohe Abtastfrequenz hin, d.h. ich muss jeden Kanal mit etwa der 10 fachen Bitrate abtasten, die maximal vorkommen kann. Eventuell reicht 5x, müsste man ausprobieren. Bei 115 KBit/s kommt man dann schnell auf ca. 5 MHz, entsprechend 200ns Abtastrate. Das ganze verpackt man dann in einen Protokolrahmen mit Start- und Stopbit.

Also:

Startbit = 1 Abtastwert Kanal 0 x Abtastwert Kanal 1 x Abtastwert Kanal 2 x Abtastwert Kanal 3 x Stopbit = 0

Start- und Stopbit braucht man, um den Takt zurückzugwinnen, mit dem der Taktgeber für den De-Multiplexer auf der Empfangsseite auf 0 gesetzt wird.

Alternativ könnte man zunächst die seriellen Datenströme synchronisieren. Dann kommt man mit einer Abtastung je Bit hin.

Stefan DF9BI

Um einen seriellen Datenstrom ohne weitere Maßnahmen über ein Kabel zu übertragen, brauche ich ein Bandbreite, die deutlich höher ist, als die Bitrate. Wenn ich davon ausgehe, dass ich eine Bandbreite von ca. 10x Bitrate brauche, um noch ein einigermaßen sauberes serielles Signal zu haben, muss ich dieses dann mit mehr als der 20 fachen Bitrate abtasten, damit am Ausgang noch etwas vernünftiges rauskommt.

Vermutlich reicht aber auch eine geringere Bandbreite, um halbwegs brauchbare Rechteckimpulse zurückgewinnen zu können. Insofern ist das nur eine grobe Schätzung.

Wenn die Eingangssignale miteinander synchronisiert sind, sieht das allerdings anders aus, dann kann ich den Abtastzeitpunkt auf die Mitte der Bits setzen und muss nur mit der Bitrate abtasten.

Wenn du zumindest gleichbleibende Übertragungsparameter verwendest, also gleiche Baudrate, Bitanzahl, Anzahl der Stopbits, würde ich wie von einem anderen Poster oben schon geschrieben eine Lösung mit entsprechend vielen Uarts bzw. SIOs vorsehen. Die Signale über 4 Ports einlesen und über einen gemeinsamen Port mit entsprechend höherer Baudrate und einem Protokollrahmen wieder raussenden. Der Rest ist dann Software.

Wenn du keine gleichbleibdenden Übertragungsparameter garantieren kannst, könntest du diese vieleicht automatisch erkennen. Beim alten

8052AH Basic (siehe Basic EMUF) z.B. wurde die Baudrate des angeschlossenen Terminals automatisch erkannt. Dazu musste man allerdings als erstes Zeichen ein Space zum EMUF senden.

Interessant wäre noch, wie genau du den zeitlichen Zusammenhang zwischen den Signalen benötigst. Geht es dabei um Mikrosekunden?

Gruß

Stefan DF9BI

Ich hab da noch eine Idee zur praktischen Realisierung:

4 Prozessoren mit 2 Uarts, damit der Sender schneller als der Empfänger sein kann, z.B. ATmega162 (?)

Die 4 seriellen Signale jeweils auf den ersten Uart der Prozessoren 0-3 schalten

Die 4 Uart Ausgänge über eine oder-Verknüpfung auf einen gemeinsamen Ausgang schalten

Jeder Prozesser bekommt dann noch eine Enable-Leitung als Eingang und eine Disable-Leitung als Ausgang.

Der Prozessor Nr. 0 stößt das ganze an. Er sendet eine Startsequenz und gibt dann den Prozessor Nr. 1 frei. Der sendet seine Daten mit Kanalkennung und gibt dann den Prozessor Nr. 2 frei usw. Wenn Nr. 3 keine Freigabe an Nr. 0 sendet, gibt es ein Timeout und Nr. 0 startet von vorne.

Die Prozessoren sollten z.B. 4 Bytes zwischenspeichern. Bei der Übertragung wird dann jeweils die Kanalkennung + Blocklänge + 4 Datenbytes übertragen. Man benötigt dann benötige dann die 6-fache Baudrate, wie an den Eingängen der Prozessoren.

Jedes Signal, das in das System eintritt, sollte es am anderen Ende nach max. 1 ms wieder verlassen haben. Fehlerhaft übertragene Signale müssen z.B. als Nullbyte weitergesendet werden.

MfG Martin

Das Protokoll der zu übertragenen Signale besitzt immer 8 Datenbits, wobei aber jedes Byte einen beliebigen Inhalt haben darf. Die Durchlaufzeiten jedes Bytes durch das System dürfen maximal 1 ms betragen.

Diesen Ansatz finde ich sehr interessant. Nur muss dann ein (so etwa) 5 MHz-Rechtecksignal übertragen werden, was der 40- bis 50-fachen Übertragungsbandbreite gegenüber dem jetzigen System entspricht. Das wird Probleme bereiten.

Leider geht das nicht.

MfG Martin

inen gut=20

RTs, der=20

Warum nicht die vier "=C3=A4u=C3=9Feren" SIOs/UARTs in Software machen? D= er Controller hat ja sonst fast nichts zu tun.

Gru=C3=9F, Enrik