Guten Abend welche Möglichkeiten habe ich, wenn due UARTs nicht ausreichen: der von mir verwendete µC besitzt 4 Stück, die ich für die beiden USB und 2 DMX-Outputs verwenden würde. Zusätzlich hab ich noch 4x DMX-Inputs und Midi: a) Software-UARTS - Problem wie ich gehört habe sind die Timing-Probleme - wieviele habt ihr von denen in einem Projekt realisiert, so dass es auch gespielt hat? Stellt ein Software-UART überhaupt eine "gute" Möglichkeit dar? b) UARTS mit mehrern Teilnehmern - ist es möglich über einen MAster mehere Slaves (die 4 DMX-Inputs) anzusprechen? Bzw. wie groß wäre ca. die Verzögerung der Daten, wenn alle gleichzeitig Daten empfangen? ist damit die "echtzeitfähigkeit" für das menschliche Auge gefährdet? c) mehrere µC verwenden - z.b. drei µC um die ganzen UARTS zusammenzubekommen und anschließend zu einem µC die Daten senden und dort verarbeiten etc. ? Wie schnell wäre so ein system? und über welche Schnittstellen würde man sowas am besten realisieren? d) FPGA verwenden? e) gibt es noch andere Möglichkeiten bzw. Optionen die man betrachten sollte? Hans
Hans wrote: > Guten Abend > > welche Möglichkeiten habe ich, wenn due UARTs nicht ausreichen: der von > mir verwendete µC besitzt 4 Stück, die ich für die beiden USB und 2 > DMX-Outputs verwenden würde. Zusätzlich hab ich noch 4x DMX-Inputs und > Midi: > Es gibt ICs (z.B. TI TL16C7xx mit 4 UARTs für den externen Bus. > > a) Software-UARTS > - Problem wie ich gehört habe sind die Timing-Probleme > - wieviele habt ihr von denen in einem Projekt realisiert, so dass es > auch gespielt hat? Stellt ein Software-UART überhaupt eine "gute" > Möglichkeit dar? > Das größte Problem liegt bei Software UARTs nicht beim senden sondern beim empfangen. Hier Sollte mit mindestens 4-8 fach Oversampling abgescannt werden. Wenn Du nur auf die UARTs rausschreibst ohne etwas zu empfangen, ist das weniger schwierig. > > b) UARTS mit mehrern Teilnehmern > - ist es möglich über einen MAster mehere Slaves (die 4 DMX-Inputs) > anzusprechen? Bzw. wie groß wäre ca. die Verzögerung der Daten, wenn > alle gleichzeitig Daten empfangen? ist damit die "echtzeitfähigkeit" für > das menschliche Auge gefährdet? > Bei DMX kannst Du bis ui 32 Slaves auf eine Leitung hängen (RS485) bei 250Kbit > c) mehrere µC verwenden > - z.b. drei µC um die ganzen UARTS zusammenzubekommen und anschließend > zu einem µC die Daten senden und dort verarbeiten etc. ? Wie schnell > wäre so ein system? und über welche Schnittstellen würde man sowas am > besten realisieren? > Ist unsinnig. Die Verwaltung schluckt mehr als die Geschwindigkeit, die Du Dir erhoffst. > d) FPGA verwenden? > Noch größerer Unsinn. Sie oben, externe Chips > e) gibt es noch andere Möglichkeiten bzw. Optionen die man betrachten > sollte? > Das sollte doch ausreichen. > Hans
Hallo Dirk, vielen Dank für deine Antwort... Haben die ICs TI TL16C7xx noch eine genauere Bezeichnung?? Wollt mir nämlich grad mal das Datasheet von so einem anschauen bzw. mal bei Reichelt oder so schauen was die kosten und konnte unter dieser bezeichnung nichts finden? Hans
Robert Weber wrote: > z.B. TL16C754 > > http://www.datasheetarchive.com/search.php?q=TL16C754 > > Gruss, > rweber Siehe es jetzt nicht als Werbung. Ich hatte vor ner Weile einen Thread unter "Markt" da ich ein paar davon übrig habe. Hier der Link zu meinem Beitrag. Da sind auch die Links zu den Datasheets Beitrag "Quad UARTS von TI abzugeben"
> b) UARTS mit mehrern Teilnehmern > - ist es möglich über einen MAster mehere Slaves (die 4 DMX-Inputs) > anzusprechen? Bzw. wie groß wäre ca. die Verzögerung der Daten, wenn > alle gleichzeitig Daten empfangen? ist damit die "echtzeitfähigkeit" für > das menschliche Auge gefährdet? > >Bei DMX kannst Du bis ui 32 Slaves auf eine Leitung hängen (RS485) bei >250Kbit das funktioniert aber nur bei Inputs... würde es sich um Outputs handeln wäre das ja nicht möglich... oder hab ich da einen denkfehler...? Wenn an einem Output tatsächlich 32 Geräte dranhängen, muss doch im µC alles schnell schnell gehen.. wenn ich da schon eine große verzögerung im µC habe, sieht man doch diese auch? Oder liege ich hier falsch? Hans
> > das funktioniert aber nur bei Inputs... würde es sich um Outputs handeln > wäre das ja nicht möglich... oder hab ich da einen denkfehler...? > > Wenn an einem Output tatsächlich 32 Geräte dranhängen, muss doch im µC > alles schnell schnell gehen.. wenn ich da schon eine große verzögerung > im µC habe, sieht man doch diese auch? Oder liege ich hier falsch? > > Hans @Hans Seit wann empfängt der Master bei DMX Daten von den Slaves ??? Die RS485 geht nur in eine Richtung. Vom Master zu den Salves. Es sei den, Du hast einen eigenen Standard geschaffen ;-) Bei DMX512 kannst Du max. 512Byte für 32 Slaves (es sei den Du benutzt Leitungsverstärker also Repeater) übertragen. Das ganze mit einer fixen Übertragungsrate von 250 Kbit. Welchen µC verwendest Du denn? Was heisst, es muß schnell schnell gehen ? Schau Dir mal das Timimg Diagramm im Link hier an. Dann kannst Du Dir ausrechnen wieviel Zeit Du hast oder benötigst. http://www.soundlight.de/techtips/dmx512/dmx512.htm Dirk
Bei DMX512(A) ist sehr wohl ein bidirektionale Kommunikation möglich, siehe RDM ANSI E1.20-2006. Allerdings muss diese nicht jedes Endgerät oder Inline-Device auch zwingend können. Ein "kleiner" µc mit 4 UART der schon 2 DMX in/out und 2 USB bedienen soll, dürfte damit in "Realtime" schon seine liebe Mühe und Not haben, da bleiben ja gerade mal ca. 5,5 µs für die Verarbeitung jedes DMX Datenbyte. Und die Generierung/Detektion von BREAK/MAB und DMX Timeout will ja auch noch gemacht werden. Also in Realtime mit minimalem Delay und RDM fähig wird das eher nix. Anders sieht es evtl. bei µc mit DMA und blockorientierter Arbeitsweise. Aber dann gibt`s ja wieder Delays.
darf ich mal fragen welchen uC du da benutzt? 4 uarts sind schon echte seltenheit
@Mikki Mertens wie realisieren dass den die Hersteller von prof. Geräten (mit 4 DMX-Outputs, zwei DMX-Inputs, Artnet-Schnittstelle etc.)? Die haben ja die gleiche bzw. ähnliche Problematik? Leider besitze ich nicht so ein Gerät, so dass ich es einfach mal aufschrauben und nachschauen könnte. Hab auch mal versucht das Delay welches bei einem Software-UART entstehen würde auszurechnen... c = fQ / Baudrate = 16MHz / 250kbit/s bei DMX --> ergibt das 64 Zyklen von nöten sind, um ein Bit zu übertragen. Allerdings kommen dazu noch 9 Zyklen für das putchar und getchar und 7 Zyklen die Routine rcall und ret... macht also 80 Zyklen (wenn 8Bit oder mehr übertragen werden, fallen die 7 Zyklen auch nur einmal an)... Während dieser Zeit kann ich ja auch nichts machen wie z.B. Daten vielleicht auswerten oder so... @tom bei den Atmega von Atmel sind ein paar dabei, die vier UARTs besitzen - z.B. ATmega1281 oder ATmega2560 oder halt noch größer....
Mikki Merten wrote: > Bei DMX512(A) ist sehr wohl ein bidirektionale Kommunikation möglich, > siehe RDM ANSI E1.20-2006. Allerdings muss diese nicht jedes Endgerät > oder Inline-Device auch zwingend können. Ein "kleiner" µc mit 4 UART der > schon 2 DMX in/out und 2 USB bedienen soll, dürfte damit in "Realtime" > schon seine liebe Mühe und Not haben, da bleiben ja gerade mal ca. 5,5 > µs für die Verarbeitung jedes DMX Datenbyte. Und die > Generierung/Detektion von BREAK/MAB und DMX Timeout will ja auch noch > gemacht werden. Also in Realtime mit minimalem Delay und RDM fähig wird > das eher nix. Anders sieht es evtl. bei µc mit DMA und blockorientierter > Arbeitsweise. Aber dann gibt`s ja wieder Delays. @Mikki Hast Du mal geschaut, von wann diese Norm ist und weisst Du wann sich sowas voll etabliert. @Hans Schreib doch mal, was Deine Anforderungen auf all diesen Kanälen sind. Wieviele Slaves möchtest Du bedienen. Nur schreiben oder auch empfangen ??? Also abzüglich des Sendeaufwandes, bleiben zur Verarbeitung und Datenbereistellung ( die ja auch von irgendwo kommen muß) selbst bei einem AVR mit 16 oder 20 MHz (max. 16-20 Mips) kaum Resourcen frei.
Hallo Dirk, also bezüglich µC hab ich zwar schon welche angeschaut - eben mit 4 UARTs - aber noch keinen gekauft... Anschlüsse - 4x DMX Inputs (also rein Daten empfangen) Datenrate 250kBaud - 2x DMX Outputs (rein Daten rausschieben) - MIDI In und Out zur Synchronisation - USB 2.0 (Datenrate 480kBaud) zur Verbindung an einen Computer, um z.B. die DMX-Signale angezeigt zu bekommen in einer Simulationssoftware für Licht, Merging-Optionen, DMX-Signal überprüfen zu können etc. - USB 2.0 / oder 1.1 Schnittstelle um über einen USB-Stick z.B. Presets für die Merging-Parameter oder ähnlichem abspeichern bzw. uploaden zu können. - Grafik-display über eine serielle Schnittstelle um auch die wichtigsten Funktionen ohne Computer einstellen zu können. - was noch nicht sicher ist, aber wenn es denn die Hardware zulassen würde sehr interessant wäre, ist eine Ethernet-Schnittstelle um die DMX-Daten über Artnet weiterverschicken zu können oder empfangen zu können... da muss ich aber ersteinmal einen überblick bekommen, mit welcher Hardware das überhaupt realisiert werden kann oder wird... Wie wird sowas in prof. Geräten bewerkstelligt - würde mich auch interessieren! Hans
@Hans Also meiner Einschätzung nach, muß hier neben den Schnittstellenverwaltung auch noch einiges an Daten verarbeitet werden. Wieviele Teilnehmer hängen denn an einem DMX Port? Hier wirst Du wohl von der Leistung auf einen mind. 16Bit Controller gehen müssen, der auch DMA fähig ist. Welchen Controller hast Du Dir denn bis jetzt ausgesucht ? Dirk
>Also meiner Einschätzung nach, muß hier neben den >Schnittstellenverwaltung >auch noch einiges an Daten verarbeitet werden. das stimmt... ist nur die frage ob das möglich ist; oder darunter die "Echtzeitfähigkeit" stark bzw. augenscheinlich leidet. >Wieviele Teilnehmer hängen denn an einem DMX Port? an den DMX-Outputs können auch 32 Geräte dranhängen... und an den Inputs max. 5. >Hier wirst Du wohl von der Leistung auf einen mind. 16Bit Controller >gehen müssen, der auch DMA fähig ist. >Welchen Controller hast Du Dir denn bis jetzt ausgesucht ? Wie gesagt bis jetzt noch keinen so richtig, da ich mir noch nicht so sicher bin, dass das mit einem µC möglich überhaupt zu realisieren ist (vor allem vielleicht auch noch mit Ethernet)... bzw. leider nicht genau weiß welche Raffinessen es bei den µC wie z.B. DMA noch gibt.. DMA macht auf jeden Fall Sinn, um neben dem Datentransfer bzw. Schnittstellenverwaltung auch noch ein paar Verarbeitungen der Daten anstellen zu können... Muss mich mal umschauen welche µC von Atmel z.B. mit DMA ausgestattet sind.. oder gibt es welche, die von den Leistungsmerkmalen besonders hervorstechen?? z.B. höhere Bitzahl oder so? Hans
Also, das diese Aufgabe von einem µC nicht bewältigt werden kann, glaube ich nicht. Es gibt genügend leistungsfähige. Du solltest bei so einem Projekt auf jeden Fall sehr zielorientiert vorangehen. Ein Pflichtenheft (auch in Deinem eigenen Interesse) wäre absolut sinnvoll. Daher, notiere Dir alle Eckpunkte, auf die es hier ankommen soll, um den entgültigen Aufwand abschätzen zu können. Den sogennanten WorstCase berechnen, also kurz gesagt, was kommt da im Maximalfall auf den µC zu. Hast Du schon Erfahrungen im Umgang Hard- und Software mit µCs? Gerade wir hier im Forum sehr beliebt, könntest Du gerade mit den ARM Controllern eine gute Lösung erzielen. Es gibt Sie in mannigfaltigen Ausführungen von vielen Herstellern von kleinen bis großen Ausführungen. Dem entsprechend sieht es hier auch mit dem Hard und Software Support aus. Dirk
Hallo Dirk, bis jetzt hab ich nur kleine Projekte mit den Atmegas gemacht - meistens Atmega16... Arbeitsaufwand meinst du in erster Linie von wo, wie schnell und wann kommen die Daten an und müssen wieder verarbeitet werden + die Zeit, die ich brauche für die Verarbeitung der Befehle... >Gerade wir hier im Forum sehr beliebt, könntest Du gerade mit den ARM >Controllern eine gute Lösung erzielen. Werd mir die Controller mal anschauen - vielen Dank für den Tipp.
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.