Hallo, Ich Stehe vor dem Problem das ich 2 Controller mit einem Endgerät Kommunizieren lassen muss via RS232 38400 Baud . Ein Änderung der Geräte ist leider ausgeschlossen die Kommunikation erfolgt zudem noch Bidirektional. Reine Passive Lösung (Y-Kabel mit Dioden) quick and dirty funktioniert aber nicht so ganz 100% zufriedenstellend. Zwischen den Datenpaketen sind Große Zeitlücken somit sollte es doch möglich sein die Daten zwischen zu Buffern. Das ganze ist nicht sehr Zeitkritisch (0,5 Sec) und nun meine Frage kennt jemand ein kommerzielles Produkt hierfür oder einen Lösungsansatz? Vielen Dank Sven
Sven F. schrieb: > Stehe vor dem Problem das ich 2 Controller mit einem Endgerät > Kommunizieren lassen muss Kannst du sicherstellen, dass jeweils nur einer der Controller auf das Endgerät zugreift?
leider nein! Aber der Zugriff könnte durchaus verzögert werden wäre nicht krittisch. Sven
:
Bearbeitet durch User
Kann mir nicht vorstellen das es da was fertiges gibt. Ob man das hinbekommt hängt auch von der Art des Protokolls bzw wie die Geräte miteinander kommunizieren ab. Wenn die Kommunikation immer vom Master initiert wird und nach einem Anfrage<->Antwort Prinzip funktioniert könnte man einen Controller mit 3 Schnittstellen verwenden der die Anfragen koordiniert und zwischenspeichert wenn gerade der andere Master kommunizert. Sobald aber das Gerät selstständig sendet und möglicherweise Betriebszustände hat die umgeschaltet werden können ist das nicht mehr so Einfach.
Das Protokoll ist fast 90% dem eines GSM Modems identisch also AT Kommandos. Der Empfang wäre auch nicht kritisch die Empfänger (Master) erkennen ihre Daten. Nur Sendeseitig gibt es von der Seite Master --> Slave die Probleme. deshalb mein Gedanke mit dem "zwischen Buffern" so das der 2. Master einfach mit Verzögerung seine Anfrage Los wird. Das Endgerät sendet auch Selbstständig aber diese Daten können ohne Probleme von beiden Geräten ausgewertet werden. Danke Sven
:
Bearbeitet durch User
Sven F. schrieb: > so das der 2. Master > einfach mit Verzögerung seine Anfrage Los wird. Das Verzögern ist ja nicht wirklich das Problem, sondern das Synchronisieren. Die Master müssen also voneinander wissen, sonst senden sie zu einem völlig zufälligen Zeitpunkt, und daran ändert eine Verzögerung garnichts (Verzögerung gegenüber was??). A. Das System entsprechend ändern, z.B. nur 1 echter Master. B. Einen Controller zwischenschalten, der parallel empfangen kann und die Daten dann kontrolliert getrennt weitergibt. C. In das Protokoll (gibt es sowas?) eine Kollisionserkennung und Fehlerbehandlung einbauen. Georg
Das Problem ist deine Befehle müssen irgend etwas zum selektieren drin haben. Transaktions ID, Adresse etc. Sonst kann man die Antwort nicht mehr zum Master zuordnen. Außerdem wissen wir nicht ob der slave in einer gewissen Zeit antworten muss oder welche Abfolge der Telegrammverkehr erfordert.
Sven F. schrieb: > leider nein! > Aber der Zugriff könnte durchaus verzögert werden wäre nicht krittisch. > > Sven So wie ich es verstehe, ist ein u[CP] basierter Knoten dazwischen zwingend. So wie ich es auch noch verstehe, können alle Telegramme vom Slave an beide Masters "dupliziert" werden (...die Masters erkenne die an sie gerichtete Telegramme). Also: irgendein (embedded-)Linux dazwischen haupsache mit 3 Serial Ports. Kernel + BusyBox drauf duerfte als RapidPrototype genügen...
Funktioniert trotzdem nicht da sich die Telegramme ähneln. Da kann der Master vergleichen wie er will er bekommt das nicht auseinander für wem das war. Das funktioniert so in dem man das Paketweise macht Frage->Antwort Man merkt sich von welchen Port die Frage kam und sendet dann die Antwort an den entsprechenden Master. Wartet man auf eine Antwort Buffert man das zwischen oder teilt dem Master mit er möge es später nochmal versuchen. Besser wäre wenn man anhand des Telegramms die Anfragen auseinander halten kann. Wie oben erwähnt durch Adressen, IDs etc. Aber wir wissen nicht ob der slave durch z.Bsp Frage->Frage den Befehl abbricht. Dann funktioniert das nur so das man auf eine Antwort warten muss bevor man eine neue Frage sendet. Größe des Buffer und Timeout Zeiten muss man dann zu der Anwendung kalkulieren.
:
Bearbeitet durch User
Also Linux ist jetzt Overkill. Selbst der kleinste uC mit 2 Sios reicht mehr als aus. 2xRx, jedes Byte was reinkommt wird rausgepustet, wenn auf beiden Rx gleichzeitig, dann halt zwischen gepuffert. Das sind in C 20 Zeilen + uart aufsetzen... Den Rückweg braucht der uC ja weder kennen noch managen.... Selbst mit 1 UART und 2 Gatter -Ics wäre das machbar... wer als erstes sendet bekommt die direkt Leitung der andere solange auf Rx...
Marco H. schrieb: > Funktioniert trotzdem nicht da sich die Telegramme ähneln. Da kann der > Master vergleichen wie er will er bekommt das nicht auseinander für wem > das war. > > Das funktioniert so in dem man das Paketweise macht Frage->Antwort > > Man merkt sich von welchen Port die Frage kam und sendet dann die > Antwort an den entsprechenden Master. > > Wartet man auf eine Antwort Buffert man das zwischen oder teilt dem > Master mit er möge es später nochmal versuchen. > > Besser wäre wenn man anhand des Telegramms die Anfragen auseinander > halten kann. Wie oben erwähnt durch Adressen, IDs etc. > > Aber wir wissen nicht ob der slave durch z.Bsp Frage->Frage den Befehl > abbricht. Dann funktioniert das nur so das man auf eine Antwort warten > muss bevor man eine neue Frage sendet. Größe des Buffer und Timeout > Zeiten muss man dann zu der Anwendung kalkulieren. Wenn ich den TO (und den Thread Titel) richtig verstanden habe, will er Multiple Master Single Slave bei unverändertem Slave Verhalten, d.h. der Slave geht nach wie vor von einem Master aus und wird die Daten beider Master genau gleich behandeln. Da RS232 keine Halb Duplex Busarchitektur unterstützt, würden die beiden Master (physikalisch entkoppelt) ihre Tx Leitungen zusammen auf die Rx des Slave führen und die Rx des Slaves auf die Tx beider Master aufsplitten. Der TO hat ja schon geschrieben, dass es den Mastern scheinbar egal ist, ob sie "erwartete" oder "unerwartete" Daten kriegen (womit die gesplittets Rückrichtung kein Problem ist), also bleibt der einzig kritische Punkt die unmögliche Synchronisation der Master untereinander, wie Georg schon geschrieben hat. Das lässt sich nur Protokollmässig abfangen (also retransmission policies bei durch Kollision verursachtem Datensalat auf der entkoppelten Tx Leitung), was dann natürlich nicht geht, wenn der Slave das nicht schon unterstützt und nicht verändert werden kann. Ich würde in diesem Fall auch für einen dazwischenliegenden Arbitrator uC mit 3 UARTs plädieren.
Ruediger A. schrieb: > uC mit 3 UARTs plädieren. warum wieder 3? Du hast doch selbst geschrieben: Ruediger A. schrieb: > (womit die gesplittets Rückrichtung kein Problem ist), und dann braucht es doch nur 2 Rx und 1 Tx, oder habe ich was übersehen?
Richtig sicher wirst Du das Problem nicht lösen können! Wenn ich unterstelle, dass die Master nichts voneinander wissen, so senden sie üblicherweise irgendwann. Nach Murphy immer dann, wenn auch der andere was zu sagen hat. Das kommt dann auch so an. Die einzige Lösung wäre hierfür ein Cleverle dazwischen schalten. Mit drei unabhängigen, seriellen Schnittstellen. An zwei schließt Du die Master an, an die Dritte den Slave. Jetzt ist es aber nicht mit der Verteilung der Signale getan. Das Cleverle muss das vollständige Protokoll beherrschen. Hat nämlich die Nummer eins eine Verbindung begonnen, so darf ihm die Nummer zwei nicht eher dazwischen quatschen, ehe nicht die Verbindung offiziell beendet wurde. Das aber geht nur, wenn das dazwischengeschaltete Teil zu jeder Zeit weiß, was Sache ist. Meiner Meinung nach: Vergiss es!
Achim S. schrieb: > Ruediger A. schrieb: >> uC mit 3 UARTs plädieren. > > warum wieder 3? Du hast doch selbst geschrieben: > > Ruediger A. schrieb: >> (womit die gesplittets Rückrichtung kein Problem ist), > > und dann braucht es doch nur 2 Rx und 1 Tx, oder habe ich was übersehen? Sorry, hast Recht, war ein Denkfehler (ich hatte Probleme mit dem Visualisieren der Hinrichtung - unbeabsichtigtes Wortspiel...). 2 sollten reichen, danke für den Einwand! Allerdings scheint Amateur denselben Denkfehler zu haben ;-) Wenn der Slave allerdings tatsächlich ein Zustandsbehaftetes Gerät wie ein Modem ist, dann hat Amateur aber natürlich auch recht mit seinem Zusatzeinwand bzgl. der Protokollarbitrierung.
:
Bearbeitet durch User
Ich denke um die 3 seriellen Schnittstellen kommst Du nicht herum. Puffer hin oder her. Du hast zwei Sender Tx. Die dürfen aber - voraussichtlich - nicht beide gleichzeitig senden. Du hast zwei Empfänger Rx, die sollten den Quatsch (antworten der anderen Verbindung) auch nicht beide empfangen. Im Falle eines Falles sollte das Zwischenteil, den anderen vollständig vertrösten können, wenn der Eine gerade am Quatschen ist. Eine Umleitung ins Nirwana ist in den wenigsten Fällen hilfreich. Übrigens: Große Lücken im Protokoll bedeuten ja nicht kleines Datenvolumen. Ein weiterer Punkt wird sein: Wenn ich eine Peer-to-Peer Verbindung programmiere, so achte ich zwar auf vieles, aber nicht darauf, dass plötzlich ein anderer dazwischen quatscht. Leide ich aber unter schrecklicher Langeweile, so implementiere ich ein: "Jetzt geht es los" und ein: "Ich melde mich wieder - irgendwann". Nur dann könnte es gehen. Es gibt nur eine Ausweichmöglichkeit: Alle übertragenen Daten dürfen in den gleichen Topf - unwahrscheinlich.
Amateur schrieb: > Ich denke um die 3 seriellen Schnittstellen kommst Du nicht herum. > Puffer hin oder her. > > Du hast zwei Sender Tx. Die dürfen aber - voraussichtlich - nicht beide > gleichzeitig senden. Genau. Dafür braucht's den Arbitrierer. > Du hast zwei Empfänger Rx, die sollten den Quatsch (antworten der > anderen Verbindung) auch nicht beide empfangen. > Lt. vorheriger Aussage des TO ist das kein Problem: > "Der Empfang wäre auch nicht kritisch die Empfänger (Master) erkennen > ihre Daten." ... > "Das Endgerät sendet auch Selbstständig aber diese Daten können ohne > Probleme von beiden Geräten ausgewertet werden." Ich teile aber deine Skepsis.
Hallo, Also das Endgerät und einen Master kann ich nicht beeinflussen außer über die Steuerleitungen evtl. müßte ich probieren, wäre ein Ansatz. Sind zwar nicht unbedingt nötig wären aber evtl. verwendbar. Ein Master wäre evtl auch Software mäßig anpassbar. Protokoll Abarbeitung wird bedingt benötigt macht aber im Moment selbst mit einem virtuellen y Kabel via Software keine Probleme. Die Daten die vom Gerät Sklave kommen sind immer mit eindeutigen kennungen somit weiß der Master was für ihn ist. Das ganze ist auch kein Geheimnis es handelt sich um ein Motorola mtm800 an dem 2 Geräte via PEI Schnittstelle abgeschlossen werden sollen nicht schön aber... Auf alle Fälle schon mal danke für die hilfe Eigentlich sollte es kein Problem sein da es angeblich einen PEI multiplexer an Port hat nur der scheibt lediglich in der etsi zu existieren oder wir haben einen bösen Denkfehler. Jedenfals bekommen wir in nicht dazu mit uns zusammen zu arbeiten. Evtl. Kennt eine aus der GSM Ecke einen Tipp zu AT +CMUX. Danke Sven
Beitrag #5006194 wurde vom Autor gelöscht.
Sven F. schrieb: > Also das Endgerät und einen Master kann ich nicht beeinflussen außer > über die Steuerleitungen Meinst du damit, dass diese Geräte Hardware-Handshake unterstützen, zumindest optional so konfigurierbar sind? Dann ist es absolut trivial. So trivial, dass der ganze Thread hier bereits weh tut, weil völlig überflüssig...
Hallo, Ganz sicher kann ich es nicht sagen. Du meinst mit den Hardware handshake gegenseitig sperren solange der andere senden will? Wenn das geht hätte ich den Wald vor lauter Bäume übersehen... Sven
Sven F. schrieb: > Du meinst mit den Hardware handshake gegenseitig sperren solange der > andere senden will? Nein, ein ganz klein wenig Steuerelektronik wäre auch dann immer noch nötig, der Mechanismus ist ja eigentlich für einen anderen Zweck gedacht. Aber der Aufwand läge weit unter dem Level eines µC mit zwei UARTs oder gar irgendwelchen CPLDs oder FPGAs. Nur zwei spottbillige Standard-CMOS-Logik-ICs. Das wäre jedenfalls die Lösung, die mir in vielen Varianten sofort einfällt. Ein FF und ein paar Gatter. Ich würde nichtmal ausschließen, dass sich bei genauerer Analyse des ganzen Zoos an verfügbaren Standard-CMOS-Käfern sogar eine Lösung ergeben könnte, die mit nur einem davon auskommt.
Du meist also so ähnlich wie im Anhang für das rs232 interface nur das damit dann das Hardware handshake des 2. Masters gesperrt wird. Ist eine gute Idee zudem einmal könnte ich ja auf alle Fälle drauf zurückgreifen. Sven
Dann lass doch nur einen Cntroller mit dem Endgerät reden in diesen Controller dann mit dem 2. Controller?!
Ich halte es für ausgeschlossen, dass Du mit diesem Gerät einen stabilen Betrieb zusammen mit 2 Mastern bekommen kannst. Die Software auf Master A wirkt mit hoher Wahrscheinlichkeit nicht damit zurecht kommen, dass zwischenzeitlich Master B eine andere Konfiguration oder andere Befehle an das Gerät geschickt hat. Die hardwareseitige Implementation des Sharing ist das kleinste Problem, das sicher auch gut in den Griff zu bekommen ist. Wenn aber Master-Software und Geräte-Firmware nicht auf ein Sharing ausgelegt sind (und davon auch garnichts wissen), dann wird das Funktionieren der Kommunikation immer ein timingabhängiger Zufall bleiben. Gruß, Stefan
Hallo, also Flusssteuerung via RTS CTS fällt flach da das zur sofortigen Störungsmeldung des einem Masters führt. eine Möglichkeit hätte ich zum Einflussname die Geschwindigkeit könnte ich an allen Geräten beeinflussen. nun mein Gedanke! wenn ich die beiden Master mit 9600 Baud anbinde und das Endgerät mit 34800 Baud dann müsste ich doch ohne Probleme die Daten Zwischen puffern können? ok dann müsste ich zwar auch die RX Schiene mit "umwandeln" aber so müste ich doch genügend Zeit erhalten um "schön" getrennt die Daten zuzustellen? oder habe ich da einen Denkfehler? Der Gedanke mit dem Konfigurationen ist gut aber kompl. unproblematisch da die Konfiguration nur im Start Moment geschieht und bei beiden Mastern gleich ist. Das konnte ich schon mitloggen. selbst das Y-Kabel mit Dioden geht solange nicht gleichzeitig beide Master senden. Sven Sven
:
Bearbeitet durch User
Sven F. schrieb: > oder habe ich da einen Denkfehler? Viel mehr als einen, abgesehen davon dass das nur mit einem zwischengeschalteten Prozessor überhaupt möglich ist. Und dann löst das vielleicht ein Problem, das garnicht existiert, und andere nicht - z.B. wenn ein Master dem Gerät einen Auftrag erteilen kann, etwas zu messen, kannst du gleich alles vergessen, weil die Antwort darauf dem Master nicht wieder zugeordnet werden kann. Funktionieren könnte das nur, wenn das zwischengeschaltete System praktisch einen Master und seine Software vollkommen ersetzt, und seinerseits den Mastern gegenüber sich komplett wie 2 Geräte verhält. Vom Aufwand mal abgesehen, beim vorhandenen Kenntnisstand (Y-Kabel) ist das völlig illusorisch. Georg
Danke Georg (Gast) aber den Wissensstand anhand eines Y-Kabels
einzuschätzen ist "GUT"!
das das Ganze ohne Prozessor nicht aus kommt ist klar schon allein wegen
den Umwandlungen der Baud Rate.
Die Empfangsseite ist keinerlei Problem wie ich schon schrieb da die
Werte einer Festen Variable zugeordnet sind.
Anfrage Master 1 : AT+CSQ?
Anfrage Master 2 : AT+CTOM?
Antwort Slave : +CSQ: 25,99
OK
+CTOM: 0
OK
Zudem der Master 1 in ca. 5 Sec Intervallen ca 500 ms nur Aktiv ist,
und Master 2 max 200 ms somit sollte eigentlich selbst ohne
Geschwindigkeitswandel das ganze Abgearbeitet werden.
Das Ganze ist ein ganz normales V.250 AT-Protokoll.
somit kann der master immer die Daten rausfiltern die er braucht egal ob
zusätzliche Daten kommen das stört überhaupt nicht.
lediglich das "Kollidieren" des Senden muss verhindert werden.
und wegen mir könnte sogar ein Master den ich nicht ändern kann Vorrang
haben.
Mein Gedanke wäre jetzt dahin:
1. mögl.
Master 1 sendet MC bekommt Daten und reicht Sie an Ausgang weiter.
2. mögl.
Master 2 sendet MC bekommt Daten und reicht Sie an Ausgang weiter.
3. mögl.
Master 1 sendet MC bekommt Daten und reicht Sie an Ausgang weiter.
Master 2 sendet MC Speichert zwischen und sendet wenn Master 1 fertig
ist am anschluß.
das Ganze müste doch unter den Voraussetzungen ziemlich Betriebssicher
hinzubekommen sein bei diesen Rahmenbedingungen?
Da selbst bei dem "Y-Kabel" es eher selten zu Datenkonflikten gibt und
diese sollten dann ja Geschichte sein.
Danke
Sven
:
Bearbeitet durch User
Geht trotzdem nicht, da dies zu unterschiedlichen Setup Daten im Master führt. Einer stellt den Kanal um der zweite weiß davon nichts und zeigt die alte Frequenz. Ich weiß nicht ob die Firmware so ist wenn der Master eine Antwort bekommt das er diesen Parameter dann auch setzt oder nur wenn diese selbst initiiert. Noch schöner -> der eine sagt Hop der andere Hüh. Das gibt das feinst Chaos an Fehlfunktionen. Das Protokoll ist genau dafür ausgelegt Master-> Slave und nicht für Buslösungen.
:
Bearbeitet durch User
Ich wiederhole mich ungern aber solange wie der thread schon gewoben wird, wär's schon lange ausprobiert: einfach etwas script-fu beigeben: > Also: irgendein (embedded-)Linux dazwischen haupsache mit 3 Serial > Ports. Kernel + BusyBox drauf duerfte als RapidPrototype genügen...
Hallo Ausprobiert ist es inzwischen zwar nicht mit Linux aber mit Windows und hier geht es ohne Probleme mit dem Programm Vspe. Steuern tut nur ein Gerät das 2. Zeigt nur die Daten mit an. Somit gibt's da keine Probleme. Der 2. Master lässt sich auch mit cts stoppen. Werde das jetzt als externe Lösung testen. Aber trotzdem den Software mux den das mtm800 eigentlich haben soll noch mit im Auge behalten. Auf alle Fälle erst mal danke für die tips und Ansatzpunkte! Sollte sich noch ein wissender dafür finden würde ich mich über Tipps freuen da Motorola hier leider absolut uninfomativ ist. Es würde hier um die Anwendung des at+cmux Befehls handeln der ja schön beworben wird.... Danke Sven
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.