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
