Hallo,
ich versuche gerade einen Transmitter zu bauen der einen DMX LED
Strahler ansteuert.
Adressen:
Rot CH1, Grün CH2 und Blau CH3.
Grundlage ist das Projekt folgender Seite:
http://www.hoelscher-hi.de/hendrik/light/ressources.htm
(AN013: DMX-Transmission mit AVRs)
Die Hardware wurde etwas abgespeckt.
Auf der Platine befindet sich folgendes:
Atmega 8515, 7805 mit den benötigten Kondensatoren und der 75176B.
Den Atmega habe ich auf den internen 8Mhz Generator gesetzt.
Das Demo-Programm (die C Version) habe ich aufgespielt und funktioniert
einwandfrei.
Jetzt kommt mein eigentliches Problem:
Ich habe nur die einfachsten Grundlagen von C und verstehe den Code
nicht ganz.
An folgenden Stellen scheitert es:
1
for(;;)
Warum eine for-Schleife und keine while?
1
=~(PINC)
Wenn ich mich richtig entsinne, hat das doch was mit einlesen eines
Ports zu tun. Warum lese ich was ein, wenn nur was ausgegeben wird?
Wie bekomme ich es hin, dass z.B. Rot für eine gewisse Zeit an ist und
dann Grün leuchtet? Also quasi die Kanäle explizit anspreche?
Danke im Vorraus.
Jürgen G. schrieb:> Den Atmega habe ich auf den internen 8Mhz Generator gesetzt.
Damit kann die Baudrate bei 8 Datenbits für DMX nicht genau genug
eingehalten werden. Du solltest besser einen Quarz benutzen.
Jürgen G. schrieb:> Warum eine for-Schleife und keine while?
Weil das ein Zeichen weniger ist? Gibt auch für Endlosschleifen mehr als
ein Konstrukt in C. Besorge Dir mal ein gutes Buch zu dem Thema.
Jürgen G. schrieb:> Wie bekomme ich es hin, dass z.B. Rot für eine gewisse Zeit an ist und> dann Grün leuchtet? Also quasi die Kanäle explizit anspreche?
Baue erstmal eine Schaltung mit 3 LEDs auf und überlege dann nochmal.
Jim M. schrieb:> Jürgen G. schrieb:>> Den Atmega habe ich auf den internen 8Mhz Generator gesetzt.>> Damit kann die Baudrate bei 8 Datenbits für DMX nicht genau genug> eingehalten werden. Du solltest besser einen Quarz benutzen.
Bei 8MHz und 250KB liegt UBRR Fehler bei 0.0%.
Bleibt nur der Fehler vom internen Clock.
Dieser kann aber auf 1% und besser kalibriert werden, was ja
ausreichend genau ist.
Danke für eure Antworten.
Jim M. schrieb:>> Warum eine for-Schleife und keine while?>> Weil das ein Zeichen weniger ist? Gibt auch für Endlosschleifen mehr als> ein Konstrukt in C.
Das dachte ich mir schon.
Jim M. schrieb:> Baue erstmal eine Schaltung mit 3 LEDs auf und überlege dann nochmal.
Was soll ich mit drei LED's machen? Sorry, aber der Komentar bringt mir
nichts
Marc V. schrieb:> Dieser kann aber auf 1% und besser kalibriert werden, was ja> ausreichend genau ist.
Wie geht das?
Kann mir jemand folgenden Befehl erklären:
Jürgen G. schrieb:> DmxField[0]= ~(PINC);
Da wird das erste Feld von DmxField mit dem Kehrwert des PINC Registers
beschrieben.
Edit: Hättest du dir das Beispiel mal durchgelesen, wäre dir klar
geworden, das du mit DIP Schaltern an Port C eben den Wert von DMX Kanal
0 einstellen kannst.
Jürgen G. schrieb:> Marc V. schrieb:>> Dieser kann aber auf 1% und besser kalibriert werden, was ja>> ausreichend genau ist.>> Wie geht das?
Mit OSCCAL Register.
Matthias S. schrieb:> Jürgen G. schrieb:>> DmxField[0]= ~(PINC);>> Da wird das erste Feld von DmxField mit dem Kehrwert des PINC Registers> beschrieben.
Was aber gleichzeitig bedeutet, dass dies nicht DMX-conform ist, da die
meisten DMX-Geräte bei Wert<>0 gleich einen Fehler melden, bzw. auf ein
neues BREAK warten.
> Edit: Hättest du dir das Beispiel mal durchgelesen, wäre dir klar> geworden, das du mit DIP Schaltern an Port C eben den Wert von DMX Kanal> 0 einstellen kannst.
DMX Kanal 0 muss immer (noch) den Wert 0 haben. DIP-Schalter sind dazu
da, um eigene Adresse einzustellen.
Marc V. schrieb:> DIP-Schalter sind dazu> da, um eigene Adresse einzustellen.
Ja klar - am Sender :-P Da spricht einer, der so richtig DMX kann.
Lies dir doch bitte mal das Programm oder wenigstens die Kommentare von
Hennes dazu durch. Dann hättest du gesehen, das nach dem Break als
erstes sowieso ein Nullbyte gesendet wird, das überhaupt nicht aus dem
Array kommt.
Mit den DIPs stellt man also den Wert für den ersten DMX Kanal ein.
Jürgen G. schrieb:> Kann mir jemand folgenden Befehl erklären: DmxField[0]= ~(PINC);
Die richtigen Stichworte hierfür sind Bitwise Operations oder logische
Operationen. Braucht man meistens nur bei Mikrocontrollern und sonst
nirgends.
Du weißt vielleicht: Ein Byte besteht aus Bits. So ist z.B. die Zahl 8d
= 1000b (d = dezimal, b = byte).
Das PINC Register beschreibt den Zustand der Pins an Port C. Hat es z.B.
den Wert 8, dann ist der "linkste" (Also hier der 4.te -> PIN3) an 5V
und die anderen alle an 0V.
Jetzt kann man aber die NOT Operation ~ durchführen. Damit wird aus
~1000b = 0111b
Der Sinn dahinter ist wohl, dass das erste Feld die Adresse kodiert über
ausgeschaltete Pins bekommt. Willst du also Kanal 3 (11b) einstellen,
brauchst du 11111100b an den 8 Pins.
Anm: Ich habe den Code nicht gelesen, es hängt also davon ab, was
DmxField wirklich tut, aber zumindest gebraucht es dafür die Inverse der
Pins, also alles was 0V hat ist "an"
Anders gesagt, wenn du am Port C einen 8-fach DIP Schalter hast, kannst
du mit dem die Helligkeit des Rot Kanals deines DMX Scheinwerfers
einstellen, vorausgesetzt, dessen DMX Adresse ist immer noch, wie im
Ausgangsposting, die Nummer 1.
Hennes' Sender wird deinen Scheinwerfer mit dem Wert aus DMXField[0] für
Rot ansteuern, Grün ist DmxField[1] und Blau ist DmxField[2].
Eine 255 macht die Farbe voll an und eine 0 schaltet sie aus.
Zwischenwerte dimmen die Farbe.
Der Vorschlag von Phil schaltet also im Sekundentakt Rot voll an und
dann wieder aus, während Grün an geht.
Student schrieb:> Der Sinn dahinter ist wohl, dass das erste Feld die Adresse kodiert über> ausgeschaltete Pins bekommt. Willst du also Kanal 3 (11b) einstellen,> brauchst du 11111100b an den 8 Pins.
Das ist nach wie vor Unsinn. Hier wird keine Adresse kodiert, denn es
ist der Sender!
Bist du sicher, dass du weisst, wie DMX funktioniert?
Es wird (wenn man's vollständig macht) immer zunächst ein Break gesendet
(damit die diversen Empfänger wissen, jetzt gehts los, quasi ein
Synchronzeichen) und dann 512 Bytes (ein sog. "Universum") und dann
gehts von vorne wieder los.
Den Break kann man übrigens als "dirty trick" auch dadurch erzeugen,
indem man zunächst die serielle Schnittstelle auf 50kBit/s setzt und
eine Null sendet, dann auf 250kBit/s umstellt und die 512 Bytes
rausbläst. Funktioniert sowohl bei Mikrocontrollern als auch bei
PC/Mac-Software, sogar durch Seriell-USB-Wandler hindurch.
Die Empfänger horchen und zählen die gesendeten Bytes ab dem Break mit.
Die sog. "Kanaladresse" ist nichts anderes als die Position des Bytes in
dem 512er Block das für Sie bestimmt ist. Dieses Byte holt sich dann das
jeweilige Gerät und wertet es irgendwie aus (z.B. Helligkeit eines
RGB-Kanales, Position bei Movigheads oder interne Programmnummer für
Blitzen usw.).
Ein DMX-Sender sollte also einerseits das zyklische Senden von Break und
den 512 Bytes immer schön stur als Parallelprozess oder im Interrupt
ausführen, während ein ander Prozess die Feldpositionen ("Kanäle") für
die jeweiligen Empfänger mit Werten 0...255 bestückt ...
Viele Geräte belegen mehr als nur einen Kanal, z.B. eine einfache
"RGB-Kanne" schon mal drei. Manche Movingheads bis zu 17 ... womit so
ein "Universum" mit 512 Kanälen oft schneller aufgebraucht ist, als man
zunächst glauben mag. Wenn sich Geräte synchron verhalten sollen, kann
man ihnen auch gleiche Kanaladressen geben, es wird ja nur gelesen.
Matthias S. schrieb:> Anders gesagt, wenn du am Port C einen 8-fach DIP Schalter hast, kannst> du mit dem die Helligkeit des Rot Kanals deines DMX Scheinwerfers> einstellen, vorausgesetzt, dessen DMX Adresse ist immer noch, wie im> Ausgangsposting, die Nummer 1.
Als anerkannter DMX-Fachman wirst du mir sicher den Sinn des Ganzen
erklären können ?
> Hennes' Sender wird deinen Scheinwerfer mit dem Wert aus DMXField[0] für> Rot ansteuern, Grün ist DmxField[1] und Blau ist DmxField[2].> Eine 255 macht die Farbe voll an und eine 0 schaltet sie aus.
Wozu ?
Rot hast du schon mit DIP-Schaltern eingestellt, oder ?
Matthias S. schrieb:> Lies dir doch bitte mal das Programm oder wenigstens die Kommentare von> Hennes dazu durch. Dann hättest du gesehen, das nach dem Break als> erstes sowieso ein Nullbyte gesendet wird, das überhaupt nicht aus dem> Array kommt.> Mit den DIPs stellt man also den Wert für den ersten DMX Kanal ein.
Gerade durhgelesen.
In seinem Programm wird mit DIP-Schaltern am Sender beim Empfänger
eine LED an- oder ausgemacht.
Hat mit RGB genau nichts zu tun.
Code ist gar nicht mal schlecht, funktioniert auch, aber was mir
nicht gefällt ist folgendes:.
DMX-Array ist gar nicht deklariert, sondern als feste Adresse
vorgegeben. So etwas wird funktionieren aber nur solange RAM-Adressen
ab 0x60 anfangen und überhaupt keine neuen Variablen deklariert
werden.
Da beim senden sowieso zuerst die Adressen abgefragt werden, hätte das
Ganze auch mit deklariertem Array funktioniert, etwa so:
1
.DSEG
2
DMX_FIELD:.byte50
3
.CSEG
4
...
Und man kann neue Variablen bedenkenlos deklarieren.
Auch ist seine Fehlerbehandlung nicht ganz optimal - sollte da ein
fehlerhaftes Paket mit mehr als 8 Kanälen und Fehler in z.B. Kanal
5 kommen, wird DMX_FIELD mit falschen Werten gefüllt.
Marc V. schrieb:> Als anerkannter DMX-Fachman wirst du mir sicher den Sinn des Ganzen> erklären können ?> Hat mit RGB genau nichts zu tun.
Das ist doch nur ein Beispielcode, RTFM. Der TE allerdings hat doch, wie
er schreibt, einen üblichen DMX Scheinwerfer, der drei
aufeinanderfolgende Kanäle belegt für R, G und B. Da die DMX Adresse des
Scheinwerfers auf 1 steht, steuert also DmxField[0] den R Kanal des
Schweinwerfers an.
Das haben auch alle bis auf dich kapiert.
Da der 8515 keinen AD Wandler hat, muss man auf Potis verzichten und
hantiert als Beispiel eben mal mit DIP Schaltern.
Marc V. schrieb:> DMX-Array ist gar nicht deklariert, sondern als feste Adresse> vorgegeben.
Blablabla. Das ist doch völlig egal, du kannst DmxField auch als
1
uint8_tDmxField[100];
erklären, am Programm ändert sich dadurch überhaupt nix.
?
Da er die größe des Buffers prüft und beim Ende die State Maschine auf
"Break" stellt werden hier 50 Channels ausgegeben. Macht man das Array
größer wird durch
1
if(CurDmxCh==sizeof(DmxField))
sichergestellt das dass Array nicht überläuft.
1
DmxField[0]=~(PINC);
Die DIPs werden immer in DmxField[0] gespeichert. Um das zu verhindern
muss die Zeile auskommentiert werden.
Das Invertieren ist in den Pullup begründet.
1
DDRC=0;//enable DIPs
2
PORTC=0xFF;
Auf Eingang schalten und Pull Up aktivieren, wenn man nun den Eingang
ließt ist dieser 1 und wenn man den Schalter auf On stell 0 .
Alles wichtige läuft komplett in der ISR ab. Nunja das ist einfach aber
nicht sehr performant, die Ansätze sind aber korrekt.
Das Problem ist wenn du ungeschützt den DMX Buffer schreibst das es
leicht zu Race Konditionen kommen kann. Ein AVR hat zwar nicht die
Problematiken eines Mehrkernprozessors. Aber du kannst die Daten immer
nur pro Frame a 44ms senden.
Probleme ergeben sich dann wenn du z.Bsp Strobe oder per fade etwas
stellst. Die ISR sendet bei channel 4 und du schreibst in Channel 1 der
Wert wird erst nach 44ms gesendet. Dann schreibst du in Channel 20 der
wird sofort gesendet.
Beim fade etc musst die den DMX Frame berücksichtigen in der Berechnung
und z.Bsp einen Doppel Buffer verwenden den du beim Break immer drehst
bzw. wenn der nicht fertig geschrieben wurde eben nicht.
Matthias S. schrieb:> aufeinanderfolgende Kanäle belegt für R, G und B. Da die DMX Adresse des> Scheinwerfers auf 1 steht, steuert also DmxField[0] den R Kanal des> Schweinwerfers an.> Das haben auch alle bis auf dich kapiert.> Da der 8515 keinen AD Wandler hat, muss man auf Potis verzichten und> hantiert als Beispiel eben mal mit DIP Schaltern.
LOL.
Hast du dir diesen Blödsinn selbst ausgedacht oder hat dir jemand
dabei geholfen ?
Und nochmals:
Kanal 1 schaltet ganz einfach eine LED an oder aus. Nicht mehr und
nicht weniger.
>> DMX-Array ist gar nicht deklariert, sondern als feste Adresse>> vorgegeben.>> Blablabla. Das ist doch völlig egal, du kannst DmxField auch als
uint8_t DmxField[100];
> erklären, am Programm ändert sich dadurch überhaupt nix.
Meine Kommentare bezogen sich auf ASM, nicht auf C.
Da du anscheinend nicht nur von C, sondern auch von ASM keine Ahnung
hast, sei dir verziehen.
Hi,
wie geht denn Ihr ab.
Danke.
So funktionierts:
1
DmxField[0]=0xff;
2
DmxField[1]=255;
3
_delay_ms(500);
4
...
Marco H. schrieb:> Probleme ergeben sich dann wenn du z.Bsp Strobe oder per fade etwas> stellst. Die ISR sendet bei channel 4 und du schreibst in Channel 1 der> Wert wird erst nach 44ms gesendet. Dann schreibst du in Channel 20 der> wird sofort gesendet.
Da hast du Recht. Genau das faden hatte ich vor und genau das
funktioniert nicht.
Kannst Du mir mehr Futter geben um es zu verstehen?
Jürgen G. schrieb:> Da hast du Recht. Genau das faden hatte ich vor und genau das> funktioniert nicht.
Weil alles in der ISR abgearbeitet wird. Wenn letztes Byte gesendet
wurde, geht es gleich wieder los mit Break und neuem Paket.
> Kannst Du mir mehr Futter geben um es zu verstehen?
Man deklariert gCurDmxCh als volatile und wartet in der main()
bis gCurDmxCh >= sizeof(DmxField). Erst dann schreibt man neue
Werte ins DmxField.
Eine andere Möglichkeit wäre, dass in der ISR nachdem letztes Byte
gesendet wurde, gDmxState auf z.B. EOP (EndOfPaket) gesetzt wird,
anstatt gleich wieder auf BREAK.
In der main() fragst du in der Statemachine den Zustand von gDmxState
und kannst in der Zwischenzeit etwas anderes tun oder neue Werte
vorbereiten.
Marc V. schrieb:> Meine Kommentare bezogen sich auf ASM, nicht auf C.
Wenn du den ersten Beitrag gelesen hättest, wüsstest du, das der TE die
C Variante benutzt - von ASM ist überhaupt keine Rede gewesen.
Jürgen G. schrieb:> Das Demo-Programm (die C Version) habe ich aufgespielt und funktioniert> einwandfrei.Marc V. schrieb:> Und nochmals:> Kanal 1 schaltet ganz einfach eine LED an oder aus. Nicht mehr und> nicht weniger.
Was faselst du die ganze Zeit von einer LED? Die ist nirgends erwähnt
und kommt nicht vor. Es ist immer nur vom Sender geredet worden.
Jürgen G. schrieb:> Kannst Du mir mehr Futter geben um es zu verstehen?
Du kannst in main() ganz einfach gDmxState abfragen und deine Werte ins
Array schreiben, wenn gDmxState == BREAK ist.
Nun ja aber dann muss auch sichergestellt sein das Innerhalb des breaks
das Array geschrieben wurde. Mit delay(); wäre ich mir da nicht mehr so
Sicher. Zummal man sich das sofort angewöhnen sollte solche Race
Konditionen vernünftig abzusichern.
Bei jeden durchlaufen der for schleife wird der PortC gelesen und ins
Array geschrieben. Das muss auskommentiert werden! Sonst überschreibt
diese Anweisung immer dein Value.
Marc V. schrieb:> Bei 8MHz und 250KB liegt UBRR Fehler bei 0.0%.> Bleibt nur der Fehler vom internen Clock.> Dieser kann aber auf 1% und besser kalibriert werden, was ja> ausreichend genau ist.
Die interne Clock ist beim 8515 werksseitig bei 1Mhz kalibriert. Für
8Mhz muss der TS die Kalibration selbst durchführen. Mein Eindruck ist,
dass der TS damit etwas überfordert sein dürfte.
Zudem hat der interne RC-Oscillator eine starke Temperatur- und
Spannungsabhängigkeit. Wenn nicht sichergestellt ist, dass das Gerät
später nicht ausschliesslich unter Bürobedingungen benutzt wird, dann
ist der RC-Oscillator für diese Anwendung nicht benutzbar.
Gruß, Stefan
Stefan K. schrieb:> Zudem hat der interne RC-Oscillator eine starke Temperatur- und> Spannungsabhängigkeit. Wenn nicht sichergestellt ist, dass das Gerät> später nicht ausschliesslich unter Bürobedingungen benutzt wird, dann> ist der RC-Oscillator für diese Anwendung nicht benutzbar.
Das kann man aber nicht so verallgemeinern.
Habe 8515 seit Jahren nicht mehr benutzt, aber die Messungen die ich
vor 7 Jahren gemacht habe, sagen anders.
Temperatur:
20 Grad = 8.025 MHz
25 Grad = 8.005 MHz
30 Grad = 7.980 MHz
Das sind etwa 25KHz / 5C oder 0.3125 % Fehler.
Spannung:
5.50V = 8.140MHz
5.25V = 8.080MHz
5.00V = 8.025MHz
4.75V = 7.980MHz
4.50V = 7.930MHz
Das sind etwa 50KHz / 0.25V oder 0.625 % Fehler.
Selbst wenn man die beiden zusammenzählt ergibt sich ein
Gesammtfehler von weniger als 1% pro 5C und 0,25V Abweichung.
Wobei ich noch sagen muss, dass man die Spannungsversorgung welche
z.B. von 5V auf 4,5V runtergeht, schnellstens auswechseln soll.
Mit 8515 kalibriert auf 1% sind das immer noch weniger als
2% - ausreichend genau.
Stefan K. schrieb:> Die interne Clock ist beim 8515 werksseitig bei 1Mhz kalibriert. Für> 8Mhz muss der TS die Kalibration selbst durchführen. Mein Eindruck ist,> dass der TS damit etwas überfordert sein dürfte.
Das kann allerdings sein.
Marc V. schrieb:> Habe 8515 seit Jahren nicht mehr benutzt, aber die Messungen die ich> vor 7 Jahren gemacht habe, sagen anders.> Temperatur:> 20 Grad = 8.025 MHz> 25 Grad = 8.005 MHz> 30 Grad = 7.980 MHz> Das sind etwa 25KHz / 5C oder 0.3125 % Fehler.
Sage ich doch, unter Bürobedingungen mag das ausreichend sein. Deine
Werte entsprechen ziemlich genau denen aus dem Datenblatt.
Die allermeisten DMX-Installationen werden allerdings unter wesentlich
härteren Umweltbedingungen betrieben als +/- 5 Grad: Bei +/- 20C hast Du
bereits nur durch die Temperaturänderung einen Fehler von 1,25%. Und
dieser Temperaturbereich ist unter Bühnenbedingungen eher moderat
angesetzt.
Dazu kommt, dass der RC-Osc selbst bei optimaler Kalibrierung einen
Fehler von +/- 0,5% hat (weil Einstellung in ca. 1% Schritten).
Der 7805 ist mit 5V +/- 0.2V spezifiziert, was einen zusätzlichen
Frequenzfehler von 0,5% verursacht.
Ergibt einen Gesamtfehler von 2,25%. Das Datenblatt gibt einen
Recommended Maximum Error von 1,5% an (Manual 8515, Table 62.
Recommended Maximum Receiver Baud Rate Error for Double Speed Mode).
Das sind dann die Geräte, die beim Soundcheck immer zuverlässig
funktionieren und nur dann ausfallen, wenn der Saal tobt und die
Temperatur entsprechend steigt.
Gruß, Stefan
Thread beobachten
Seitenaufteilung abschalten