Hallo, ich habe das Problem das ich mehrere RS232-Geräte (mindestens 6) an eine vorhandene UART anschließen muß. Meine Suche nach einem brauchbaren Multiplexer o.ä. ergab nichts wirklich brauchbares. Nun der Gedanke: Ein Xmega128 kostet nicht viel (5€) und hat 8-Hardware-UARTs. Nun könnte dieser eine UART für die Verbindung zur Steuerung nutzen, die restlichen 7 für die Geräte. Die Ansteuerung würde über ein kleines Protokoll erfolgen, zb. wird beim Senden von der Steuerung aus der Zielport mitgeschickt. Ebenso wird bei Antworten vom Xmega zur Steuerung der Absender mitgeschickt. Sogesehen hat man hier dann sogar mehr als einen Multiplexer, dadurch daß der RAM des Xmega groß genug zum ausreichenden Puffern ist kann man quasi alle Geräte gleichzeitig bedienen, bzw. man verpasst zumindest nichts was ein Gerät einem ohne Aufforderung sendet. Das ganze wäre dann natürlich im Prinzip auch kaskadierbar, zumindest wenn man das im Protokoll so vorsieht. Meine Frage: Übersehe ich hier irgendeinen Haken oder ist es tatsächlich so simpel ? Oder gibt es noch eine wesentlich einfachere Lösung die ich nicht sehe ?
Max schrieb: > Meine Frage: Übersehe ich hier irgendeinen Haken oder ist es tatsächlich > so simpel ? Oder gibt es noch eine wesentlich einfachere Lösung die ich > nicht sehe ? Das kommt auf den Einsatz an. Ich betreibe bis zu 64 Geräte an einem PC, aber der PC spricht diese Geräte nacheinander an und wartet auf Antwort, die Geräte melden sich nicht selbst - also reiner Master-Slave-Betrieb. Unter den Umständen ist ein so komplexer Multiplexer wie deiner nicht nötig, TxD geht einfach an alle und RxD von allen wird über ein NAND-Gate verknüpft, es antwortet ja immer bloss ein Gerät. Uarts sind daher überflüssig und man muss sich am Multiplexer auch nicht um die Baudrate kümmern. Solange die Software so bleibt, bietet dein Multiplexer keinerlei Vorteile. Gruss Reinhard
Ja, das wäre soweit die ganz simple Lösung. In meinem Fall habe ich damit aber schon das Problem das es Geräte des gleichen Typs gibt, dh. die werden dann beide antworten wenn Tx an alle geht, da sie das gleiche Protokoll sprechen. Das ganze soll möglichst flexibel gestaltet werden, dh. selbst wenn es im Moment nicht zwingend notwendig ist daß ein Gerät auch als Master senden kann so hätte ich das gern für die Zukunft drin. Wenn das einzige Hindernis sein sollte einen kleinen Protokollaufsatz für die Baudrateneinstellungen zu erstellen ist alles ok. Mich würde eher interessieren ob es zB. Probleme bezüglich dem Betreiben von 8 HW-UARTs gleichzeitig geben könnte ?
>Mich würde eher interessieren ob es zB. Probleme bezüglich dem Betreiben >von 8
HW-UARTs gleichzeitig geben könnte ?
Der Controletti steckt das locker weg. Bis 115kB sehe ich kein Problem,
bei 500kB aufwärts könnte es bei viel Traffic spannend werden.
Max schrieb: > Wenn das einzige Hindernis sein sollte einen kleinen Protokollaufsatz > für die Baudrateneinstellungen zu erstellen ist alles ok. Mich würde Du könntest auch gleich eine Autobauderkennung einbauen... wen schon denn schon ;) Aber wenn du eh flexibel bist ("Protokoll erstellen") könntest du auch ein Protokoll ähnlich dem MultiMaster bei AVRs für UART nutzen.
Max schrieb: > Ja, das wäre soweit die ganz simple Lösung. In meinem Fall habe ich > damit aber schon das Problem das es Geräte des gleichen Typs gibt, dh. > die werden dann beide antworten wenn Tx an alle geht, da sie das gleiche > Protokoll sprechen. Hallo, natürlich sprechen alle das gleiche Protokoll, und natürlich enthält ein Tx-Record ebenso wie ein Rx-Record die Slave-Adresse 1..64. Das ist ja so oder so notwendig. Gruss Reinhard
Max schrieb: > ... Mich würde > eher interessieren ob es zB. Probleme bezüglich dem Betreiben von 8 > HW-UARTs gleichzeitig geben könnte ? Hallo, du musst dir natürlich drüber klar sein, dass der Datenstrom für alle Geräte letzlich über das zentrale UART geht - der Mux kann also zwar zwischenspeichern, damit nichts verloren geht, aber der Durchsatz wird damit nicht erhöht. Ausserdem musst du die Software sehr komplex verschachteln oder für n Geräte n Threads einrichten, sonst spricht dein Programm ja doch immer nur mit einem Gerät. Das ist auch der Normalfall, was anderes lohnt sich in der Praxis nicht, nur wenn du damit unbedingt technologische Fähigkeiten beweisen willst. Es gibt natürlich immer eine Baudrate, ab der der Mux überfahren werden kann. Aber für grosse Datenmengen nimmt man normalerweise keine serielle Schnittstelle. Gruss Reinhard
Hallo Max Villt. Geht es mit dem DMA des Xmega... >>• Allows High-speed data transfer >– From memory to peripheral >– From memory to memory >– From peripheral to memory >– From peripheral to peripheral >>• 4 Channels >>• From 1 byte and up to 16 M bytes transfers in a single transaction >>• Multiple addressing modes for source and destination address >– Increment >– Decrement >– Static >>• 1, 2, 4, or 8 bytes Burst Transfers >>• Programmable priority between channels Mit dem erkennen/einstellen welches Gerät angesprochen werden soll, kann ein kleines Programm geschrieben werden das dem Xmega mitteilt wer der Teilnehmer sein soll zb. manuell (vor jedem senden einstellen und dann senden) oder wenn es machbar ist automatisch (Programm erkennt welche SW senden will und stellt den Xmega ein auf senden zu Gerät X). Multiplexen stelle ich mir etwas schwieriger vor aber "maybe" geht es jeder SW eine gewisse Zeit senden zu lasssen wie es im PC Betriebssystem gehandhabt wird!? Gruß
Das durch 2 UARTs zu schleifen, bringt aber auch ne Verzögerung von 20 Bitzeiten. Wie soll denn die Umschaltung erfolgen? Die Variante mit Multiplexer/Demultiplexer-ICs (74HC138/74HC251) stelle ich mir deutlich einfacher vor: Der PC sendet erstmal 2 Bytes (Gerät, Anzahl) an nen MC und der schaltet dann für die Anzahl Bytes den MUX durch. Der Sende-MUX wird danach wieder abgeschaltet, d.h. die ersten 2 Bytes sieht keiner der Slaves. Der Empfangs-MUX bleibt bis zum nächsten Paket akiv. Als MC reicht ein ATTiny2313. Peter
Die Verzögerung bzw. der Gesamtdatendurchsatz wird nicht das Problem sein, da ist sehr viel Raum nach oben. Im Prinzip muß der Master auch nur immer mit einem Gerät gleichzeitig reden. Dennoch würde ich mir aus Erweiterungsgründen gerne die Option drinnehalten daß zb. 2 Geräte gleichzeitg auch als Master senden können. Zudem scheint die xMega-Lösung noch einen weiteren Vorteil zu haben: So wie ich das sehe kann man die Pinfunktionen frei zuordnen, dh. theoretisch könnte man mit einem Xmega auch 40 Geräte bedienen (nat. nur 7 "gleichzeitig"). Die Umschaltung würde wohl so erfolgen: Master sendet an Xmega @[Portnummer][Datenbytes] Genau das gleiche umgekehrt, der Xmega filtert die Portnummer nat. wieder aus dem Datenstrom raus. Also mir will sich die angebliche Komplexität der Xmega-Lösung nicht wirklich einleuchten, der schwierigste Teil dürfte das FPGA-Löten für den Prototyp sein..
Der Vorteil des XMEGA ist dessen DMA plus Eventsystem. Damit kannst Du ziemlich viel Traffic ohne CPU-Zutun wegstecken. Diese wird dann lediglich zum Konfigurieren und zum Management gebraucht. Abgesehen von RS232 Treibern brauchst Du dann kaum noch Bauteile, ein USER-Interface (Display/Tasten/Fernbedienung) ist da auch noch drin und wenn der XMEGA dann noch etwas Zeit hat, kann er nebenbei noch etwas Musik machen ;-).
Max schrieb: > Also mir will sich die angebliche Komplexität der Xmega-Lösung nicht > wirklich einleuchten, Wenn er nur das gleiche machen soll, wie die Multiplexerversion, dann nicht. Schwierig wirds erst, wenn er auch durcheinander empfangen können soll. Dann mußt Du Dir irgendein Protokoll ausdenken. Die Multiplexerversion hätte auch den Vorteil, daß Du sie bequem löten kannst und keine 3,3V Pegelwandler brauchst. Peter
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.