SPI zu RS485 (DMX) Transmitter IC mit Buffer

[Alex G. (Gast)]

Hallo,

Ich baue ein DMX Art-Net Node mit 4 DMX Outputs (Universen), auf Basis 
eines Ethernet PIC18F86J60 (41,6MHz mit PLL) der über SPI mit 4 
PIC18F25J11 (48MHz mit PLL) plaudert, welche jeweils für eines der 4 
Universen die maximal 512 Byte DMX Daten buffern (SPI DMA) und 
kontinuierlich mit 250kbit/s per UART rausschicken (inkl. Break, MAB, 
Startcode für DMX usw...).

Sobald ein UDP Art-Net ArtDmx Paket beim Ethernet PIC eintrifft welches 
also die Helligkeitswerte der einzelnen Kanäle enthält, werden sie ohne 
Zwischenspeicherung, aus dem Ethernetbuffer geholt und über SPI an die 
einzelnen DMX SendePICs weitergeschickt.

Die SPI Daten kommen in unterschiedlichen Zeitabständen bei den DMX PICs 
rein und werden immer während des DMX Breaks aus dem SPIDMA 
Empfangsbuffer in den DMX Sendebuffer gememcopyed (dauert bei 512 bytes 
ca 0.7ms). Doppelbufferung ist unbedingt erforderlich, da sich die 
Paketlängen bei jeder Übertragung ändern dürfen und auch keine DMX 
Pakete die sich aus 2 oder mehr SPI Übertragungen zusammensetzen 
verschickt werden dürfen. Sollte ein SPIDMA Empfang während der Breaks 
stattfinden, besteht die Breakzeit solange, bis der Empfang 
abgeschlossen ist und die frisch empfangenen Daten in den DMX 
Sendebuffer kopiert wurden.

Ein SPI Datenpaket setzt sich bei mir also so zusammen:

// DMX Packet Structure
typedef struct
{
    WORD PacketCount;
    BYTE DMXData[512];
} DMXPACKET;

Es werden somit immer 2+512 Byte per SPI verschickt, unabhängig davon 
wieviele DMX Bytes im ArtDmx Paket tatsächlich gekommen sind.

Meine Frage lautet nun: Gibt es einen fertigen DMX Transmitter IC, der 
variable DMX Datenlängen über SPI annimmt (von mir aus auch 8-Bit 
parallel), doppelbuffert und per UART rausschickt um die maximale DMX 
Performance (ca. 44fps) zu erreichen? Idealerweise sollte er auch 
HIGH-SPEED DMX können, ist aber kein Muss.
Mit meiner Lösung komme ich auf ca. 36fps pro Output wenn immer 512 DMX 
Pakete verschickt werden. Gibt es eventuell eine bessere Möglichkeit, 
das Ganze umzusetzen? Timing ist bei DMX ja bekanntlich alles. FPGA 
kommt für mich nicht in Frage, da habe ich noch keinerlei praktische 
Erfahrungen, selbst wenn solch ein DMX IC zu 90% aus D-FlipFlops 
bestehen würde.

Noch ein paar Randinfos: Aus den DMX PICs kommen die UART Daten über 
einen 4049, einen 6N137 und einen MAX485 bei einer der 4 XLR Buchsen 
raus. Für das lange Break LOW Signal wird ein weiterer Pin zum 
Runterziehen von TX Out verwendet (Lösungsansatz von Microchip). Das 
Projekt ist vollständig in Microchip C18. Der Teil nach dem Optokoppler 
bis Buchse läuft mit 5V und der Rest mit 3.3V. Das ArtNet Node vom 
Ulrich Radig habe ich schon komplett unter die Lupe genommen, da gibt es 
nur ein Universum, keine Doppelbufferung, somit eher ein Spielzeug und 
für professionelle Zwecke ungeeignet.

Vielen Dank!

Gruß Alex

[Alex G. (Gast)]

Alex G. schrieb:
> WORD PacketCount;

...ist leider ein verwirrender Name für diese Variable. Sollte eher 
DMXDataLength heissen.

[Falk B. (falk)]

@ Alex G. (Gast)

>Es werden somit immer 2+512 Byte per SPI verschickt, unabhängig davon
>wieviele DMX Bytes im ArtDmx Paket tatsächlich gekommen sind.

M>eine Frage lautet nun: Gibt es einen fertigen DMX Transmitter IC, der
>variable DMX Datenlängen über SPI annimmt (von mir aus auch 8-Bit
>Parallel), doppelbuffert und per UART rausschickt um die maximale DMX
>Performance (ca. 44fps) zu erreichen? Idealerweise sollte er auch
>HIGH-SPEED DMX können, ist aber kein Muss.

Warum machst du das nicht gleich mit dem zentralen PIC? Denn die Daten 
müssen so oder so verschickt werden. Wenn man es clever(tm) macht, und 
alle vier Kanäle gescheit synchronisiert, sollte das kein großer Aufwand 
sein und fast so leicht wie ein einkanaliger DMX-Generator. Man braucht 
nur 4 UARTs. Wenn die der PIC nicht hat, nimm einen schnellen, externen 
UART-IC, die gibt es. Oder vier einzel UART-ICs. Das mit vier extra PICs 
zu machen halte ich für nicht zweckmäßig.

>Mit meiner Lösung komme ich auf ca. 36fps pro Output wenn immer 512 DMX
>Pakete verschickt werden.

Hast du versucht herauszufinden, WO die Begrenzung deiner Datenrate 
liegt?
Ich behaupte, dasss mit deiner Konstellation (immerhin FÜNF 
Mikrocontroller!) die volle Bandbreite erreichbar ist. Alles "nur" eine 
Frage der Programmierung.

> Gibt es eventuell eine bessere Möglichkeit,
>das Ganze umzusetzen? Timing ist bei DMX ja bekanntlich alles. FPGA
>kommt für mich nicht in Frage, da habe ich noch keinerlei praktische
>Erfahrungen,

Naja, das wäre ein Lösung, die spielend Dutzende DMX-Kanäle treiben 
könnte ;-)

> selbst wenn solch ein DMX IC zu 90% aus D-FlipFlops
> bestehen würde.

Viel mehr ist in einem FPGA auch nicht drin. Viele FlipFlops und LUTs.

>Noch ein paar Randinfos: Aus den DMX PICs kommen die UART Daten über
>einen 4049, einen 6N137 und einen MAX485 bei einer der 4 XLR Buchsen
>raus. Für das lange Break LOW Signal wird ein weiterer Pin zum
>Runterziehen von TX Out verwendet (Lösungsansatz von Microchip).

Ein Schaltplan sagt mehr als 1000 Worte. Siehe Netiquette.

[chris (Gast)]

Wieso verwendest du SPI und nicht rs232 mit 4 galvanisch getrennten
rs485 tranceivern ?

[Alex G. (Gast)]

Danke erst mal für die Antworten,

Falk Brunner schrieb:
> Warum machst du das nicht gleich mit dem zentralen PIC? Denn die Daten
> müssen so oder so verschickt werden. Wenn man es clever(tm) macht, und
> alle vier Kanäle gescheit synchronisiert, sollte das kein großer Aufwand
> sein und fast so leicht wie ein einkanaliger DMX-Generator. Man braucht
> nur 4 UARTs.

Dagegen sprechen mehrere Faktoren: Es gibt laut Microchip Device 
Selector nur eine Hand voll PIC18* mit 4 UARTs. Diese sind extrem teuer 
(über 10€), können kein Ethernet und sind kaum wo zu bekommen. Ein 
solcher PIC den ich für ein Universum einsetze, kostet mich nur 2€ und 
es besteht leicht die Möglichkeit das Node auf mehr als 4 Universen zu 
erweitern. Ebenso hat ein solcher PIC auch nicht genug RAM um alles zu 
Buffern. Ein RAM angebunden über den Memory Bus wäre denkbar, jedoch 
muss dann ein noch teurer Ethernet PIC aus der selben Familie statt 
meinem her. Ich habe Anfangs versucht alles mit dem Ethernet PIC 
umzusetzen, nur für 2 Universen, da er nur 2 UARTS hat. Ich habe mehrere 
Konzepte ausprobiert. Mit dem besten kam ich nur auf ca 20fps. Fakt ist 
dass der Ethernet PIC mit dem Netzwerkzeug schon genug ausgelastet ist. 
Er muss ja nebenbei noch ARP und PING machen, uninteressante Pakete 
verwerfen, usw. Es ist auch noch ein LCD und Encoder dran und ich plane 
auch noch ein Webinterface, das den PIC dann wahrscheinlich komplett 
auslastet.

> Hast du versucht herauszufinden, WO die Begrenzung deiner Datenrate
> liegt?
> Ich behaupte, dasss mit deiner Konstellation (immerhin FÜNF
> Mikrocontroller!) die volle Bandbreite erreichbar ist. Alles "nur" eine
> Frage der Programmierung.

Die Begrenzung der Datenrate liegt in der längeren Breakzeit während des 
Empfangs eines SPI Pakets (2.6ms bei 514 Bytes) und den 0.7ms in denen 
die Daten vom SPI Buffer in den DMX Buffer kopiert werden. Darum wäre 
ein IC der diese Aufgaben komplett in Hardware erfüllt optimal.

Nach externen UARTs habe ich schon gesucht, jedoch nichts brauchbares 
gefunden (zuwenig Buffer/zu langsam/keine Möglichkeit ein DMX 
kompatibles Paket zu basteln)

An die Netiquette habe ich gedacht, ein Schaltplan auf Papier existiert 
jedoch erst ab dem Ausgang der UARTs, welches für meine Fragestellung 
nicht von belang ist. Habe dennoch eine vereinfachte Darstellung vom 
Ganzen (ohne PSUs) gezeichnet.

[Falk B. (falk)]

@ Alex G. (Gast)

>meinem her. Ich habe Anfangs versucht alles mit dem Ethernet PIC
>umzusetzen, nur für 2 Universen, da er nur 2 UARTS hat. Ich habe mehrere
>Konzepte ausprobiert. Mit dem besten kam ich nur auf ca 20fps.

Dann hast du wahrscheinlich das falsche Konzept. Fakt ist, die Daten 
müssen so oder so vom Ethernet-PIC zu den anden PICs/ICs geschickt 
werden. Die Datenrate ist IDENTISCH. OK, mit SPI kann man sie Faktor 10 
schneller senden, das ist aber nicht sooo entscheidend.

> Fakt ist
>dass der Ethernet PIC mit dem Netzwerkzeug schon genug ausgelastet ist.

Diesen "Fakt", wüde ich erstmal du genauer Analyse und Messung 
untermauert sehen wollen.

>Er muss ja nebenbei noch ARP und PING machen,

Das passiert alle Jubeljahre einmal.

>verwerfen, usw. Es ist auch noch ein LCD und Encoder dran

Gähn Das langweilt den kleinsten uC.

>Die Begrenzung der Datenrate liegt in der längeren Breakzeit während des
>Empfangs eines SPI Pakets (2.6ms bei 514 Bytes) und den 0.7ms in denen
>die Daten vom SPI Buffer in den DMX Buffer kopiert werden.

Klingt nach blockierender Programmierung. Damit geht es natürlich nicht. 
Man muss sich im Kopf locker machen und die Konzepte von Interrupt 
und Multitasking verstehen und anwenden.

> Darum wäre
> ein IC der diese Aufgaben komplett in Hardware erfüllt optimal.

Es wäre leichter.

>Nach externen UARTs habe ich schon gesucht, jedoch nichts brauchbares
>gefunden (zuwenig Buffer/zu langsam/keine Möglichkeit ein DMX
>kompatibles Paket zu basteln)

Was gibt es denn da zu basteln? DMX IST stinknormaler UART. Das Break 
kann man leicht mit ein wenig Zusatzlogik erzeugen. Fertig.

>nicht von belang ist. Habe dennoch eine vereinfachte Darstellung vom
>Ganzen (ohne PSUs) gezeichnet.

Immerhin. Hmmm. Das mit dem BREAK ist etwas brutal, ein OR bzw. AND 
hätte man da spendieren können, wenigsten mit Diodenlogik. Die 
Widerstände hinter dem MAX485 sind unsinnig. Eine Terminierung kommt 
beim unidirektionalen RS485 ans ENDE des Strangs, siehe 
Wellenwiderstand.

Mal als Beispiel. Ich hab vor einigen Monaten einen DMX-Recoder gebaut, 
dort arbeitet ein kleiner AVR@16 MHz und schreibt/liest DMX512 mit 
voller Bandbreite auf SD-Karte. Und das bei ca. 40% mittlerer CPU-Last 
beim Schreiben! Darum glaube ich, dass dein Projekt noch VIEL Luft zur 
Leistungsverbesserung hat. Poste Quelltext (wenn du dich traust ;-)

[Alex G. (Gast)]

Klar trau ich mich ;)

Voll ausgelastet ist der EthernetPIC natürlich nur im Extremfall. 
Uninteressante Pakete sind nicht zu vernachlässigen da Art-Net auch 
Broadcast Übertragung erlaubt und wenn mehrere Nodes im Netzwerk hängen 
und der nur gebroadcastet wird, kann es durchaus passieren dass der PIC 
mit Netzwerkdaten viel zutun hat. Der Ethernet PIC läuft mit dem 
Microchip TCPIP Stack, wo ich unnötigen Müll entfernt habe und die UDP 
Kommunikation nur für den Empfang von Art-Net optimiert wurde (nur ein 
Socket).

In der ZIP die Firmware von einem DMX PIC (für alle 4 identisch), im 
Docs Ordner ein Screenshot des Logicanalysers wo man die verlängerte 
Breakzeit aufgrund eines laufenden SPIDMA Empfangs sieht und auch die 
gespeicherte Auswertung des Logianalysers für das Programm Logic von 
Saleae (Downloadlink auch im Docs Ordner). Es werden in der Simulation 
nur Daten für 2 der 4 DMX Universen gesendet. Die angezeigten Bytewerte 
der SPI Daten bitte ignorieren (zu schnell für den Analyzer).