Hallo, ich habe den Beitrag über den "Webserver 1k" von Jens verfolgt. Da man per Ethernet/UDP sehr gut DMX-Pakete transportieren könnte (z. B. kabellos per Wireless LAN) und Ethernet auch galvanisch getrennt arbeitet (da freut sich jeder Musiker), kam mir die Idee, daß vielleicht Internet/UDP/Ethernet die Lösung aller Lichtprobleme darstellen könnte. Die PC-Steuerung des DMX beötigt dann lediglich neue Treiber, auf die teueren Direkt-Adapter könnte man dann verzichten. Meine Idee: Man nimmt z.B. einen ATMEL RD2 (der hat ja glaube ich 1k RAM) oder ähnlich, 'n RS485-Treiber, CS8900A und fertig ist der "lokale" DMX-Knoten, der dann seine Pakete per UDP erhält. Konfiguration natürlich per Webserver. Hardwarekosten: Schätze mal ca. 15 EUR, Software z.B. von www.wickenhaeuser.de (für umme, wenn ich das richtig sehe?). 1.) Hätte jemand Lust da mitzumachen? 2.) Sowas könnte man sicher auch verkaufen, hätte da jemand Interesse? DJ B.
Hi, ist ne sehr interessante idee und würde auch gern meien senf dazu beitragen .... Moritz
Also der AT89 RD2 dürfte auf Empfängerseite um einiges "zu klein" sein um 250 kBit kontiuierlichen Datenstrom via LAN to DMX zu verarbeiten. Ebenso kommen natürlich die Timingprobleme (Delay) einer LAN to DMX Anbindung hinzu. Ist also nicht unbedingt der ideale Lösungsansatz bzw. doch mit erheblich Hardwareaufwand verbunden.
Mmerten, also ich denke, das bekommt man zum Laufen! 250 kBit sind 25kB/sec. Wo liegt da das Problem? Und Hardwareaufwand: siehe oben. ich bin sicher das geht. Delay? Na ja, wenn's per Internet um die Welt geht vielleicht 200 msec, aber sonst: in-Hoses < 5 msec, so schnell kann Dein Dimmer nichmal durchbrennen .. DJ B. PS.: Außerdem kann man sowas bereits kaufen, ist nur Schweine-Teuer!
Wenn du nur ein paar Dimmerdaten übermitteln willst, mag dein Lösungsansatz wohl funktionieren, aber wenn deine Scanner und MovingLights nicht wie erwartet arbeiten, wirst du feststellen, daß DMX512 via LAN nicht ganz unproblematisch ist. Daher gibt es nur recht wenige Lösungen die wirklich funktionieren und teilweise auch recht hohe Anforderungen stellen (z.B. didizierte LAN Verkabelung) und die sind in der Tat "schweineteuer".
token ring wär besser...da weist du nämlich wann welche daten wo sind...bei ethernet müsstest du min 100mbit machen können damit du delays unter 1ms hinbeskommst...sonnst vergiss es... also nix avr sonder arm oder H8 auf µC-Linux...oder sonnst einen RT-Kernel... dann gehts sicher... Wlan kannst auch vergessn da viel zu langsam und unsicher...sprich wenn deine strobos oä abgehen geht kein wlan mehr...wär doch auch ned so toll... 73 de oe6jwf / hans
Als ich hätte da schon einen Anfang auf meiner seite ulrichradig.de aber halt mit 2 KB speicher because ein ethernet frame hat halt nun 1500 Byte Mfg Ulrich Radig
Also ich habe mir mal Gedanken über das Timing gemacht. Da es Converter für USB1.1 gibt, die ganz gut funktionieren, sollte das eigentlich auch mit 10 MBit funktionieren: 1.) Verwendet würde - na klar - ein switching Hub, d. h. kein unnötiger Traffic. 2.) Wenn ich mich nicht verrechnet habe, schaft ein RD2 im regulären Transfer-Modus ca. 2 Bytes pro 6 uSec bei 30 MHz Taktung, d.h. er kann die Daten mit ca. 333 kB/Sec aus'm Netzwerk-Chip saugen, die 25kB/Sec würden ihn also max. 10% CPU-Zeit kosten... DMX-Out ginge per IRQ, wären ca. 2-3% zusätzlich. Was also um alle Welt soll das Teil sonst noch machen in seinen 85% Freizeit? 3.) Artisticlicense ist übrigens ein Anbieter, die verkaufen außer ihren Knoten ganz reguläres Equipmnet: http://www.artisticlicence.com/cat3_1.htm DJ B.
So einfach ist das leider nicht, denn nur mit "Daten aus dem Netzwerk-Chip saugen" ist es leider nicht getan.
Na ja, wo liegt das problem? 1.) PC sendet DMX-Blöcke per UDP (Multi-, Single- oder Broadcast). 2.) uC wartet auf UDP-Blöcke (die 16 Bytes Header kosten ja nix). 3.) Gelesen werden NUR UDP-Blöcke, Rest wird implizit aus CS8900 gedropped, wenn neue RX-Status abgefragt wird. 4.) Zwei alterantive OUT-Buffer für DMX werden abwechselnd mit den eingegangenen UDP-Daten geladen (kostet max. 1.5 msec/512 Bytes) 5.) IRQ haut mit 250 kBd die Blöcke abwechselnd raus. Habe ich was vergessen? Ach ja: Konfiguration: 6.) Wenn natürlich mal ein TCP (HTTP) Request kommt, hat der Priorität (Einstellungen per WebBrowser etc..). Ansonsten liegt TCP einfach "so" rum und kostet keinerlei CPU-Zeit.
@DJ B: Schon mal was vom IP-Stack gehört? Ein Ethernet-Chip stellt dir die unterste Ebene der verschiedenen Ethernet-Layer zur Verfügung. Da UDP schon etwas höher angesiedelt ist, muss erst aus dem ankommenden Datenrahmen die für dich interessante Information herausgefiltert werden. Es gibt nette kleine Ad-Ons, die auch schon UDP etc ausspucken. Siehe www.siteplayer.com. Es gibt auch nette Sachen, die eine Reihe von Ports und Schnittstellen zur Verfügung stellen wie die www.Ethernut.de Soweit ich den CS8900 kenne, liefert der dir auch nur sämtliche Daten, die an seine IP-Adresse geschickt werden. Natürlich kann man da relativ einfach herausfinden, was UDP und was TCP ist. Aber das in der von dir geforderten Geschwindigkeit herauszufinden stelle ich mir schon recht kompliziert vor. Solltest Du zu einem Ergebnis kommen, wären hier bestimmt eine Menge Leute stolz auf dich und am Ergebnis sehr interessiert.
Na klar weiss ich was'n IP-Stack ist (hab schliesslich ein komplettes Informatik-Studium hinter mir ;-), über den ISO/OSI-Quatsch etc. könnte ich Dir 'n 12-stündigen Vortrag halten... Das is was für Billies, die mit ihrem PC die Hütte heizen. Ich habe früher mal Least-Level-Treiber für Computerspiele programmiert (C64, Amiga, Atari XL, ST, ...), denke ich kann 'n Timing schon einschätzen.
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.