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)
>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.
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.
@ 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 dranGä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 ;-)
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).
