Guten Abend. Ich bin für ein Projekt am tüfteln wie ein i2c auf DMX umsetzer auszuesehen hat. Ziel des ganzen, ich will über ein Raspberry ein paar RGB LED Bars per DMX steuern. Hab mir das so gedacht die DMX Adressen nach i2c Adressen umzusetzen. Würde das funktionnieren oder hat einer andere ideen DMX per Rasberry auszugeben ? Bin was DMX/i2c angeht nicht so bewandert. Danke für Tipps und Anregungen
LOL schrieb: > Hab mir das so gedacht die DMX Adressen nach i2c Adressen umzusetzen. Kann man schon machen, jedoch hat I2C nur 127 Adressen. DMX hätte max. 512. Die verlierst also ein grossen teil des Adressraumes. LOL schrieb: > hat einer andere ideen DMX per Rasberry auszugeben ? Einfach ein USB zu DMX Interface oder die UART direkt nutzen? LOL schrieb: > Bin was DMX/i2c angeht nicht so bewandert. Alle Spezifikationen sind im Internet verfügbar.
Das I2C des RPi verträgt kein Clock Stretching. Andererseits ist ein Mikrocontroller als I2C Slave nahezu unweigerlich darauf angewiesen - oder das I2C wird mit z.B. 10 kHz sehr langsam getaktet.
Der RPi hat allerdings eine UART und DMX basiert ebenfalls auf diesem Protokoll. Das sollte also mit einem Transceiver-Modul auch direkt möglich sein. Alternativ sollten DMX Module für USB basierend auf FTDI Chips auch an den RPi passen.
:
Bearbeitet durch User
Mit dem BREAK Signal des DMX gibts dann aber Probleme. Daher habe ich bei meinen Projekten die DMX Bytes per SPI rausgeschoben und ein AVR hat das dann auf DMX umgesetzt. Das Ganze ließe sich natürlich auch per I2C machen aber nicht die I2C Adressen nutzen sondern nur einen Slave Adressieren und dem dann 512Bytes zuschicken.
Danke für alle Antworten. Ich würde es gerne mit so wenig externe Hardware wie möglich realisieren. Was müsste ich beachten wenn ich es über die UART vom Pi machen will ? [Pi] - [SERIAL/UART] - [SN75176A] - [DMX] -> [LED Bars] Baud: 250000 Data bit: 8 Stop bits: 2 Ist das so richtig oder habe ich was vergessen?
LOL schrieb: > Hab mir das so gedacht die DMX Adressen nach i2c Adressen umzusetzen. Du kannst das multiplexen. Einen PCF8574 für die DMX-Adresse und einen oder mehrere für die Daten. Das dann auf Schieberegister und mit DMX-Baudrate raustakten. Mit Mikrokontroller würden auch zwei PCF8574 reichen. Einen für Handshakesignale und einen für Daten incl Adresse.
@ LOL (Gast) >Was müsste ich beachten wenn ich es über die UART vom Pi machen will ? >[Pi] - [SERIAL/UART] - [SN75176A] - [DMX] -> [LED Bars] Ja. >Baud: 250000 >Data bit: 8 >Stop bits: 2 Ja. Zwischendurch muss man einen BREAK erzeugen. D.h. eine lange 0-Pause mit mehr als 88us. Einige UART-Treiber können das per Software. Wenn das nciht geht, muss man die Baudrate auf 1/4 runtersetzen und einen 0x00 senden, das wirkt auch wie ein BREAK.
LOL schrieb: > Hab mir das so gedacht die DMX Adressen nach i2c Adressen umzusetzen. Das geht so nicht. Du brauchst einen Protokollumsetzter UART - I2C. Also irgend einen MC mit etwas Firmware, die Du programmieren mußt. Die DMX-Adresse kann man z.B. in die ersten beiden Datenbytes des I2C packen. Und dann muß man noch das Ende eines DMX-Paketes erkennen. Für 250kBaud DMX braucht man mindestenes 400kHz I2C.
@ Peter Dannegger (peda) >Und dann muß man noch das Ende eines DMX-Paketes erkennen. Wozu? >Für 250kBaud DMX braucht man mindestenes 400kHz I2C. Nö. Der Witz von so einem Umsetzer ist es ja, daß er I2C und DMX mittels Zwischenpuffer entkoppelt. Damit kann man per I2C beliebig langsam und auch ungleichmäßig Daten schreiben.
Peter D. schrieb: > Du brauchst einen Protokollumsetzter UART - I2C. Nein. Er braucht einen I2C - UART Umsetzer. LOL schrieb: > Ziel des ganzen, ich will über ein Raspberry ein paar > RGB LED Bars per DMX steuern. Er muss nur 2 Bytes Daten (DMX Adresse +Wert) pro zu änderdem Kanal per I2C senden, das geht mit jeder Geschwindigkeit. Und noch ein Bit (zB über GPIO), um die DMX-Sendung anzustoßen.
Danke erst mal für eure hilfestellungen. Ich werde das mal ausprobieten und mich dann wieder melden wenn es nicht geht. Danke.
Mir war so als ob die UART des PIs nur 115200 baud kann und damit für DMX ausfällt. Aber man per DMA über die PIO das Signal erzeugen. Beispiele gibt es hierzu im Netz. Außerdem glaube ich das man die Bytes ohne DMA nach einander ausgespielt bekommt ohne das dass jitten zwischen den Paketen nicht zu Fehlfunktionen führt. Noch einfacher ist ein USB-> Dmx Interface oder per Artnet die Daten aus zuspielen. Oder wie schon oben genannt ein kleinen AVR der per SPI die Daten entgegen nimmt. I2c geht im Grunde auch aber du musst damit leben das die Framerate sehr niedrig sein wird.
:
Bearbeitet durch User
Also der UART kann so ziemlich jede Baudrate dank PLL. Ist eher die Frage ob der Linuxtreiber da richtig die Register streichelt. So siehts aus wenn man auf dem RasPI BareMetal proggt:
1 | //UART abschalten für config
|
2 | uart->cr = 0; |
3 | |
4 | /*
|
5 | UART Baudrate hat eine PLL die den Teiler als Integer und Nachkomma möchte
|
6 | UART_CLK = 3MHz, Baudrate = 115,2kbaud
|
7 | Teiler = UART_CLOCK/(16 * Baud)
|
8 | Nachkommateiler = (Nachkomamstelle*64) + 0.5
|
9 | |
10 | -> Teiler = 1,627
|
11 | -> Teiler Ganzzahl = 1
|
12 | -> Teiler Nachkomma = 40
|
13 | Quelle (Formel): PL011 UART Datenblatt (Kap 2.4.3)
|
14 | Quelle (3MHz): Internet!
|
15 | */
|
16 | uart->ibrd = 1; |
17 | uart->fbrd = 40; |
Mag sein aber haken ist glaube die Uart die mehr könnte auf den läuft die Konsole des Linux Kernel und die andere kann nur 115200 baud. Ich kann mich nur dunkel dran erinnern ....
Bitte 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.