mehrere UARTS realisieren?

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

z.B. TL16C754

http://www.datasheetarchive.com/search.php?q=TL16C754

Gruss,
rweber

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"

>
> 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.

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.

@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,

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