mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik DMX-Empfang klappt nicht


Autor: Christoph S. (mixer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe einen DMX-Empfänger mit einem 75176 und einem Mega8 so wie hier 
beschrieben:
http://www.mintiworld.de/wiki/index.php?title=DMX_...
aufgebaut.

Als Software hab ich eine Routine von H.Hölscher, die s auf der Seite 
von
http://www.hoelscher-hi.de/hendrik/light/ressources.htm
gibt.

Hab sie an den Mega8 angepasst.
Nun empfange ich allerdings nur "0".
Ich habe aber keine Ahnung wie ich bei der Fehlersuche vorgehen soll. Im 
Simulator vom AVR-Studio klappt alles soweit.
Ist die Schaltung vom 75176 vielleicht so nicht i.O.??
Wäre dankbar für ne gute Hilfe!

MFG Mixer

Autor: Michael Wilhelm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Hardware mit dem 75176 sieht soweit ganz gut aus, aber:

niemals einen 3-pol Steckverbinder verwenden. Die DMX-Specs sehen eine 
5-pol vor.

Bist du sicher, dass der Sender richtig arbeitet?

Hast du einen Quarz eingebaut und die Baudrate richtig berechnet?

Greifst du aus dem Datenstrom auch das richtige Byte raus?

MW

Autor: Christoph S. (mixer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Hab noch keinen Stecker, ist bis jetzt 
Steckbrett/Streifenraster-Version.
Ja, der hat mit anderen DMX-Geräten schon problemlos funktioniert, der 
sollte in Ordnung sein.
Quartz hab ich und Baudrate wird auch richtig berechnet. Ich verändere 
alle 512 Bytes vom PC aus mit einer Testsoftware vom Sender.
Weiß nicht was ich sonnst noch falsch gemacht haben könnte!

MFG Mixer

Autor: PeggySue (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael: Das mit dem 5-poligem Stecker ist so nicht ganz richtig. Man 
kann wunderbar auch den 3-poligen verwenden. Nur halt nicht die 
Standard-Mikrofon-Kabel nehmen, sondern richtige DMX-Kabel. Das mit dem 
5-poligen hat nur zwei zusätzliche Leitungen, für zusätzliche 
Funktionen. Diese sind allerdings weder standardisiert noch werden sie 
von allen Geräten unterstützt. 3-polig reicht für eine 
Standard-DMX-Kommunikation also vollkommen aus.

Was mich aber mal interessieren würde... von wo sendest du eigentlich? 
und was sendest du? Vielleicht ist ja der Empfänger in Ordnung nur der 
Sender nicht?

Gruß
PeggySue.

Autor: PeggySue (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mixer: Hast du schonmal ein Oszi drangeklemmt?

Autor: Christoph S. (mixer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Sender ist das hier:
http://www.digital-enlightenment.de/usbdmx.htm

mit einem Testprogramm kann man alle 512 Kanäle verändern. Dies mache 
ich, aber was anderes als 0 kommt einfach nicht an.
Und wie gesagt: Es hat bei anderen DMX-Geräten schon wunderbar 
funktioniert!
MFG Mixer

P.S. Oszi: Würd ich gern aber hab keins!!

Autor: Michael Wilhelm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ PeggySue,

such hier im Forum mal nach DMX. Irgendwo habe ich die Specs mal 
reingestellt. Und das mit dem 5-pol Steckverbinder wurde damals von der 
USITT* vorgeschrieben. Nur weil solche Flachköppe wie z. B. Martin ihre 
Geräte mit 3-pol Verbindern ausstatten, macht die Sache nicht besser.

Wenn due das Dokument nicht findest, mach 'ne Meldung. Dann lade ich es 
noch mal hoch.


MW

*United State Institude for Theater Technology

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PeggySue wrote:
> @Michael: Das mit dem 5-poligem Stecker ist so nicht ganz richtig. Man
> kann wunderbar auch den 3-poligen verwenden.
Jubb, das spart vorallem im semi-professionellen Bereich reichlich an 
Adapterkabeln von 3 auf 5 und umgekehrt.

> Nur halt nicht die > Standard-Mikrofon-Kabel nehmen, sondern richtige DMX-Kabel.
Bei semi-professionell eigentlich auch kein Thema, ich nehm seit Jahren 
stinknormales Mikrofonkabel. Zwei, dreihundert Meter sind da kein 
Problem. Dafür isses ja RS485.

> Das mit dem 5-poligen hat nur zwei zusätzliche Leitungen, für zusätzliche
> Funktionen. Diese sind allerdings weder standardisiert noch werden sie
> von allen Geräten unterstützt.
Geenau..also d.h., die Leitungen (Talkback) sind sehr wohl 
standardisiert, nur das, was drüber gesendet wird, halt nicht ;-)

> 3-polig reicht für eine
> Standard-DMX-Kommunikation also vollkommen aus.
JJ.

Autor: juppi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mixer S. (mixer)


>niemals einen 3-pol Steckverbinder verwenden. Die DMX-Specs sehen eine
>5-pol vor.



Sender sind fast immer 5Polig
Endgerät 3P.
hat den Vorteil das du XLR-Kabel auch benutzen kannst.
Der 5P Standart wird nach meinen wissen noch nicht benutzt.

http://www.discotechnik.com/proshop/product_info.p...

http://www.discotechnik.com/proshop/product_info.p...

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber bitte nich so billige Links...
http://www.soundlight.de/techtips/dmx512/dmx512.htm

Autor: Christoph S. (mixer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

es ist mir eigentlich recht egal was standard bei den Steckern ist oder 
nicht...
Die Anlage soll mal fest installiert werden (Partykeller) und dafür 
sollte sie hald mal laufen!!
Hat jemand Tipps für mich, wie ich feststellen kann wo der Fehler ist??
MFG Mixer

Autor: PeggySue (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mixer: Was heißt bei dir eigentlich nun genau, dass er bloß "0" 
empfängt. Vor der Auswertung, oder danach in der Software?

Wenn du ihm mal "per Hand" eine "1" gibst, erkennt er denn wenigstens 
den 0-Durchgang erstmal korrekt? Also den Start einer neuen Sequenz?

Autor: Michael Wilhelm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Evtl. in dem du mal dein Programm postest.

MW

Autor: Christoph S. (mixer) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
hier mein Programm.
Sieht ein wenig unübersichtlich aus, weil es umgeschrieben ist von M8515 
auf M8, aber sollte doch das meiste erkennbar sein.
Der Timer lässt eine LED blitzen, die Blitzfrequenz sollt abhängig sein 
von dem Byte das per DMX empfangen wird!

@PeggySue: Es wird entweder immer 0 als Byte empfangen oder gar nix 
empfangen!

MFG

Autor: Christoph S. (mixer) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Und hier die Empfangsroutine

Autor: juppi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sven Pauli (haku)

Bedeutet: Teure Endgeräte  billige 3P (damit er nicht 5P anfängt)


...aber hier geht es um den Fehler

Autor: PeggySue (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mixer: Also der "Protokoll-Rahmen" stimmt soweit? Nur im Byte steht 
halt jeweils ne "0"? Versteh ich das jetzt richtig?

Für die Blitzgeschwindigkeit der LED wertest du aber nur einen Kanal 
aus, oder?

Autor: Christoph S. (mixer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf jeden Fall blitzt die LED gar nicht, was heißen muss, dass im 
Register fstat eine 0 ist.
Und da das Register mit dem DMX-Byte geladen wird kommt entweder immer 0 
oder gar nichts.
Ja, werte einen Kanal aus. Bei 0 - Aus, bei nicht 0 - Wert als 
Verzögerung für den Blitzer (Frequenz)

Autor: PeggySue (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst du Debuggen? Denn: "Auf jeden Fall blitzt die LED gar nicht, was 
heißen muss, dass im Register fstat eine 0 ist." Mag zwar richtig sein, 
jedoch kannst du daraus ja gar nicht schließen woran es liegt, dass dort 
0 steht. Wäre schon interessant, ob am Eingang das richtige Ankommt und 
an welcher Stelle dann letztendlich der Wert verloren geht.

Könntest statz LED-togglen ja auch vorerst versuchen bei einem Wert 
größer 0 einfach die LED zu aktivieren. Vielleicht stimmt ja auch bei 
deinem "Blick-Mechanismus" irgendwas nicht.

Autor: Christoph S. (mixer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Könnt ich, aber denk nicht dass hier der Fehler ist.
Wenn ich für die Blinkfrequenz n festen Wert eingebe, dannn funktioniert 
das auch so! Sprich die Timer-Routine ist so in Ordnung!
MFG

Autor: Jürgen Berger (hicom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich würde mir erstmal ein paar Debug Zeilen
einbauen um zu prüfen ob das Startbyte korrekt
empfangen wurde und danach bis zur DMX Adresse
hochgezählt wird.

Jürgen

Autor: Christoph S. (mixer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab das mit dem simplen Einschalten von der LED ausprobiert, das gleiche 
Ergebnis: Byte wird nie anderst als "0".

@Jürgen Berger:
wie mach ich das mit den debug Zeilen? Bin noch nicht so lange am 
Programmieren, drum kenn i mich da no net so aus!
Ein paar Tipps würden net schaden!

MFG Mixer

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mixer S. wrote:
> Könnt ich, aber denk nicht dass hier der Fehler ist.

Passt zwar nich ganz, aber ich komm eben von der Führerscheinprüfung, da 
fällts mir halt ein:
Schüler denkt - Gott lenkt, Schüler dachte - Gott lachte!

Nich denken, sondern prüfen!

Autor: Jürgen Berger (hicom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
du fragst doch den DMXState ab und springst dann  vom Wert
abhängig z.B. nach dmx_startadr:
An dieser Sprungmarke dann z.B einen Ausgang (LED)setzen: sbi PORTA,0

Autor: Christoph S. (mixer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hab jetzt 2 Debug-LEDs drangehängt (PB1 und PB2)
eine schalte ich ein, wenn der Frame Error empfangen wird, die andere 
wenn das Startbyte korrekt empfangen wird.
Die vom Frame Error geht ein, die vom Startbyte geht nicht.
Also: Startbyte ein wenn startbyte falsch empfangen - geht auch nicht 
ein!
Dann: einschalten wenn auf dmx_startbyte gesprungen wird, was ja normal 
immer wenn der frame error richtig erkannt ist.
Allerdings leuchtet die LED wieder nicht!
Das ist jetzt recht komisch!!

Vor jemand auf die Idee kommt: Led funktioniert, hab sie software-mäßig 
vertauscht und genau das gleiche rausbekommen!

MFG Mixer

Autor: Michael Wilhelm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vorweg, ich bin nicht der ASM-Freak, aber deine Baudratenberechnung 
verstehe ich nicht. Du teilst 16000 durch 8000. Ergebnis sollte 2 sein. 
Dann saubtrahierst du noch eine 1, bleibt also 1 übrig.
Bei 16MHz muss aber eine 3 in das Baudratenregister.

MW

Autor: Christoph S. (mixer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

na da schau hin! Richtige Baudrate und schon funktioniert das ganze!!
allerdings die Übergabe passt anscheinend noch nicht, aber des sollt ich 
doch noch in Griff kriegen!

DANKE AN ALLE DIE MIR GEHOLFEN HABEN!!

MFG Mixer

Autor: Henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Die Formel für die Baudratenberechnung lautet:
(F_OSC/4000)-1

Wenn Du sie nicht verändert hättest, käme auch brav die 3 raus ;-)

Ansonsten brauchst Du nicht die DIPs von Hand auskommentieren, da ich 
hierfür bereits ein Compiler-Flag vorgesehen habe.

Wird das ein Interface für analoge Strobes?

Viele Grüße,
Hendrik

Autor: Henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei Problemen mit den Kanälen:

Setz mal am Besten direkt die Startadresse auf 1 (ich vermute hier noch 
einen Denkfehler):

ldi XL, 1
clr XH

Ansonsten scheint der Code zwar etwas ungewöhnlich aber korrekt zu sein. 
(Ich würde die Rate über eine Lookup-Table direkt für den 16bit-Timer 
generieren...)

Viele Grüße,
Hendrik

Autor: Christoph S. (mixer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

das soll n Stroboskop mit LEDs werden.
Das mit der Startadresse hab ich schon gesehen und geändert!

Was verstehst du unter einer Lock-up Tabelle???

MFG Mixer

Autor: Henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

ähm - das sind Grundlagen...
Schau Dir noch mal kurz das ASM-Tut von hier durch. Dort waren glaube 
ich auch Tabellen im Flash beschrieben.

Da kannst ja mal die Sourcen von meinem Strobo-Mod anschauen:
www.hoelscher-hi.de/hendrik/light/pimpstrobe.htm

Viel Erfolg,
Hendrik

Autor: Big_Daddi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich habe ebenfalls das gleiche problem!!

Im Anhang mal ein Ausschnitt aus dem Code!

Ich habe einen externen Quarz mit 8MHz
folgende fuses sind gesetzt CKSEL = 1111 und SUT = 01
Stimmt das alles soweit. Ich hab im Frame_Error mal den ausgang gesetzt 
jedoch kommt das Programm anscheindend gar nicht soweit!!!

Gruß
Joachim

Autor: Big_Daddi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
weiß keiner eine lösung?????

Autor: Henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Joachim:
Natürlich kommst Du nicht soweit.

Simulier die ISR doch einfach, dann merkst Du, dass eine der ersten 
Zeilen fehlt und im Handling der Bytes fehlt auch was... (Wahrscheinlich 
hakelt es noch an mehr stellen - aber ich habe jetzt gerade keine Lust 
deinen Job zu machen ;-)

Abgesehen davon existiert seit Monaten eine neuere Version als Lib, die 
einfach eingebunden werden kann. Da dürften solche Fehler nicht mehr 
vorkommen...

Die Lib werkelt mittlerweile in ein paar Tausend Geräten - einige von 
Euch sind einfach etwas nachlässig beim Abtippen oder ändern etwas ohne 
die Folgen wirklich zu verstehen. (Insofern habt Ihr wirklich das 
gleiche Problem.)

Hendrik

Autor: Henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falls es hilft:

Der aktuelle Link lautet
http://www.hoelscher-hi.de/hendrik/light/ressources.htm

VG,
Hendrik

Autor: Big_Daddi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für deine glorreiche Hilfe. Ohne dich wäre ich jetzt nicht weiter 
gekommen!!!

Wenn man dabei etwas lernen möchte, so wie ich, dann ist es auf jeden 
Fall sinnvoll sich fertige Programme zu laden. Denn wenn man die 
Programme selber schreibt, versteht man den Hintergedanken nicht. Ich 
weiß nicht wie du studierst. Wahrscheinlich auch alles nur die Lösung 
abschreiben und sagen ja ich kann es!!! SUPI!!!

Das ist genau mein Problem jetzt. und überdings deine lösung hab ich 
auch schon ettliche zeit und ich habe es mit der von www.mit... 
verglichen.

Trotzdem danke für deine Hilfe. Foren gibt es ja nicht um Fragen zu 
stellen, sondern seine eigene Meinung zu sagen und dass ich auf dies und 
das kein bock hab.

Autor: Henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ähh - bitte?

Ich bin mir nicht ganz sicher, ob ich Dich beleidigt habe, indem ich 
schrieb, dass ich keine Zeit habe, für Dich den Code nach (weiteren) 
versteckten Fehlern zu durchsuchen...

Falls es keine Ironie war:

Ich studiere Maschinenbau an einer TU, Vertiefungsrichtung Konstruktion 
und Automatisierung und bin soweit scheinfrei.

Meine Arbeitsweise bei privatem Gebastel:
Ich suche, ob jemand schon etwas Fertiges hat. So muss ich nicht den 
Kreis neu erfinden. Ist eine Änderung nötig, bau ich die Vorlage nach, 
mache mir die betroffenden Abhängigkeiten und Funktionsweisen klar und 
schreibe dann schrittweise um. Durch Versionierung und zwischenzeitliche 
Simulationen / Tests versuche ich permanent die Funktionalität 
beizubehalten. (Nicht, dass ich drauflos werkel und es tut am Ende 
einfach nicht mehr...)

meine Arbeitsweise für richtige Aufgaben:
Ich suche nach Vorlagen und versuche sie mir herzuleiten, so dass ich 
möglichst nicht mit Black Boxes arbeite. Wo ich Neuland betrete, gehe 
ich halt von den Grundlagen aus und versuche möglichst viel in kleinen 
Schritten zu verifizieren.

Das ist ansich trivial und dürften die meisten hier machen.


Wenn ich Deinen Post richtig interpretiere, möchtest Du zum tieferen 
Verständnis richtig einsteigen.
In diesem Fall empfehle ich das Datenblatt zu Deinem AVR und die 
offiziellen DMX-Spezifikationen.
Die ANSI E1.11 kannst Du als Draft bei Soundlight laden.
Für die E1.20 sind ein paar Euro an die ESTA fällig.

Diese Dokumente haben mir damals viel gebracht.


Falls der Post Ironie war:
Du hattest falsch "abgeschrieben" und ich wollte einen Tipp geben, wie 
Du Dir das "Abschreiben" komplett sparen kannst. Für das, was Du 
scheinbar tun möchtest, lege bitte meinen Code beiseite und beginne 
selbst auf Basis der Grundlagen (s.o.)
In einigen Monaten können wir dann vielleicht etwas voneinander lernen.


Viel Erfolg und Alles Gute bis dahin,
Hendrik

PS: Mit Minti hatte ich damals an älteren Versionen gearbeitet, die ich 
später noch etwas verbessern konnte. Es war ein schönes Arbeiten und ich 
finde es schade, dass er nun scheinbar weniger Zeit für seine Site 
findet.

Autor: Henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ansonsten auf den ersten Blick:

Prüfe mal die Baudratenzuweisung: Wenn in UBRRL 1 steht, ist sie OK.

Du überschreibst Pin2 an PortD. Hängt da noch die Empfangsumschaltung 
dran oder nicht?

Der Sprungvektor im Falle eines Overruns fehlt. Momentan dürfte alles ab 
der Stelle daneben gehen.

Mir ist so, als gäbe es damals Probleme mit dieser Art 16bit-Variablen 
zu inkrementieren. Teste lieber explizit auf Null.

Du speicherst alle Bytes ab Startadresse bis zum nächsten Break.

Das wäre dann der DMX Part.

(Sieh also bitte ein, dass da noch mal simuliert werden sollte...)

VG,
Hendrik

Autor: Big_Daddi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

also jetzt wirklich DANKESCHÖN! Das ist eine Antwort mit der man weiter 
machen kann!! Danke für den Tip.

Ich will ja nicht das Rad neu erfinden. Ich möchte verstehen was da 
passiert damit ich auf deinem Programm aufbauen kann. Deshalb möchte ich 
versuchen das selber zu schreiben!!!

Kurz zu DMX:
der aufbau ist mir eigentlich soweit klar. aber wenn der die datenbytes 
der kanäle sendet ist doch zwischen den bytes auch ein Brake oder nicht. 
somit empfängt der uc ja immer nur einen "kanal" und dann den nächsten!! 
Der Wert des Kanals steht dann in UDR oder?? Somit springt der uc nach 
empfangen aus der ISR raus und dann beim nächsten kanal wieder rein 
oder???

Autor: Michael Wilhelm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zwischen den Daten wird kein break gesendet. DMX sieht so aus:

IDLE  (high-kann, muss aber nicht)
BREAK (low-mindestens 88µs, also so lang wie 2 Daten, µC "sieht einen 
Framing Error, darauf wird synchronisiert)
MARK AFTER BREAK (high-ich glaube so um die 8µs)
STARTBYTE(muss immer 0 sein)
Daten (zwischen 1 und 512)
IDLE  (high-kann, muss aber nicht)

usw...

MW

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Big_Daddi (Gast)

>der aufbau ist mir eigentlich soweit klar. aber wenn der die datenbytes
>der kanäle sendet

Komischer Satz. Du meinst den DMX-Master, welcher den DMX-Rahmen mit bis 
zu 512 Kanälen sendet.

> ist doch zwischen den bytes auch ein Brake oder nicht.

Einmal pro Rahmen, am Anfang. Danach kommen die Byte praktisch ohne 
Pause.

>somit empfängt der uc ja immer nur einen "kanal" und dann den nächsten!!

Wie sonst?

>Der Wert des Kanals steht dann in UDR oder??

Ja.

> Somit springt der uc nach empfangen aus der ISR raus und dann beim
> nächsten kanal wieder rein

Das ist der Sinn vom UART-Interrupt

MFG
Falk

Autor: Big_Daddi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber nach jedem Byte springt der uc wieder aus der ISR raus und dann 
wenn RXC wieder gesetzt ist wieder rein und das ist dann einfach der 
nächste Kanal oder?????

Autor: Michael Wilhelm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richtig, wie ich schon schrieb musst du auf das FE-Bit synchronisieren 
und in jedem Interrupt einen Zähler inkrementieren. Entweder das ganze 
Paket abspeichern oder den Zähler mit der eingestellten Startadresse 
vergleichen und dir die Nutzdaten rausfiltern.

MW

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beitrag "DMX512 Empfänger mit Relaisansteuerung für 20 Kanäle"

Dort ist ein recht anschauliches Beispiel drin.

MFG
Falk

Autor: Big_Daddi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich hab jetzt mal den rxd vom Henne versucht und das klappt genauso 
nicht.

ich setzt einfach den PinC0 -> somit DMX adresse 1 oder???


aber der compiler springt dann immer weiter!!!!

Autor: Christoph S. (mixer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

um den Fehler suchen zu können solltest du erstmal verstehen wie die 
Empfangsroutine prinzipiell funktioniert. Dafür gibts glaub auch beim 
Henne was auf der Internetseite.
Dann solltest du auch mal den Code genauer anschauen und zumindest 
verstehen, was für welchen Teil ist. Dann kannst du im Simulator 
anschauen was da genau passiert und weist ob das richtig so ist oder 
nicht!

MFG Mixer

Autor: Big_Daddi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also vom DMX Ablauf her:

RXC + FE wird gesetzt -> UCSRA wird gespeichert -> reti -> RXC wird 
gesetzt -> UDR wird gelesen und verglichen -> startbyte = 0 -> reti -> 
RXC wird gesetzt -> UDR Daten gespeichert und dann startadresse 
vergleichen -> wenn gleich, UDR in dmx_field speichern -> reti -> RXC 
wird gesetzt -> UDR Daten in dmx_field speichern -> .... bis zur letzten 
dmx-adresse


So ungefähr sollte es doch ablaufen oder lieg ich da falsch????
Also nur die Routine was beim DMX empfang abläuft und nicht was genau 
mit der verarbeitung passiert!

Autor: Christoph S. (mixer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Bytes werden nicht alle im SRAM gespeichert, nur die Anzahl die du 
definierst.
Aber sonnst solltest du des schon verstanden haben. Dann kannst du ja 
mal simulieren und schauen ob das so funktioniert!

Autor: Big_Daddi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja schon klar wenn ich 5 kanäle hab dann speichert der auch nur 5 kanäle 
im sram ab.

So simulier ich des die ganze zeit schon einmal mein programm und einmal 
das rxd programm, bei meinem funktioniert in der simulation alles die 
daten werden gespeichert und weiter verarbeitet. Aber wenn ich es auf 
den uc lad kommt da nix raus auf dem led port bzw ich komm gar nicht 
soweit!

Autor: Christoph S. (mixer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Setz mal LEDs wenn du n FE bekommst, oder wenn du das Startbyte 
empfängst und so weiter, dann siehst du wo s hängt!

Ich geh jetzt mal davon aus, dass die Hardware funktioniert!
MFG

Autor: Big_Daddi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also den ersten punkt hab ich schon mal gefunden im Code vom Henne:
ifdef USE_DIP
    sbr    temp, (1<<0)     ;hab ich nur zu testzwecken, DMX-Adresse = 1
    out    PinB, temp
    in     XL, PinB         ;get start address

    com    XL               ;muss raus, dann geht es!

    clr    XH
    sbic  PinE, PE2         ;9th bit; hier steht normal sbis aber er sollt
    inc    XH                "skippen" wenn das bit nicht gesetzt ist

Irgendwie komm ich nicht mal bis zum frame Error. Welche Fuses habt ihr 
denn da gesetzt für den externen quarz???

Autor: Christoph S. (mixer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau hald in s Datenblatt welche Fuses du setzen musst. Oder nimm das 
AVR Studio dann macht es das automatisch!

Solange das externe Quartz noch nicht läuft ist es auch kein Wunder dass 
der DMX-Empfang nicht funktioniert!!

Autor: Big_Daddi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber ich find zu dem quarz kein vernünftiges datenblatt, wo drin steht 
welche START-UP-TIME und ADDITIONAL-DELAY er hat.

Hier geht es um das CKSEL0 und die SUT Bits

Autor: Christoph S. (mixer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://www.atmel.com/dyn/resources/prod_documents/...

Ab Seite 35 gehts um den Takt. Da findest du wie du die Fuses für das 
externe Quartz einstellen musst!

Autor: Big_Daddi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja schon klar aber woher weiß ich welchen SUT wert ich nehmen soll 258CK 
oder 1K , 4,1ms oder 65ms??

also inzwischen komm ich bis zum Frameerror! den erkennt er richtig aber 
das startbyte noch nicht wirklich!!

kann das an der Quarzeinstellung liegen?? Weil im Simulator funktioniert 
alles einwandfrei!

Autor: Christoph S. (mixer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Zweifel immer mehr Verzögerung, auf die paar Milisekunden nach nem 
Reset oder nach dem Einschalten wirds normal nicht drauf ankommen!

Autor: Joachim Geiger (big_daddi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich glaub der dmx-controller sendet eine nicht sauberes startbyte 
aus, weil wenn ich den startbyte wert erhöhe, sprich tempH = ox02 als 
beispiel und dann auf größer oder gleich verlgeiche, dann setzt er mir 
das led für den erfolgreichen empfang des startbytes.
Jetzt gehts weiter, eigentlich müsste ja jetzt nochmal ein interrupt 
kommen mit dem ersten kanal oder?? weil die led bleibt jetzt aus, wo ich 
die startadresse überprüfe. Richtig geladen ist die adresse da ich an 
der stelle auch ein LED schalte!!!

Autor: Henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK - ganz von vorn.

Falls Du meinen Transceiver nutzt, bügle eine fertige Firmware drauf und 
bringe die erst mal zum Laufen.

Dann stimmen schon mal Verkabelung und Fuses.

Wenn Du auf ein anderes Target aufsetzt, nutze erst einmal dessen 
fertige FW. (Wenn Du völligen Eigenbau betrieben hast, kann ich Dir nur 
noch viel Glück wünschen...)

Dann schaust Du, ob Daten eintrudeln.
Dann schaust Du, ob ein FE kommt.
Dann schaust Du, ob Startbytes korrekt erkannt werden.
Dann guckst Du Dir die Adressierung an.
Dann wird das Puffern der Daten interessant. (Derzeit würde ich noch die 
Finger vom SRAM lassen...)

und vorher simulierst Du die gesamte FSM komplett durch.

Und wenn Du dann immer noch nicht lauffähig bist, schreibst Du den 
aktuellen Code vollständig hier rein.

(Ich neige auch oft zum Raten und bin ziemlich oft damit auf die Fresse 
geflogen - sei klug und systematisch ;-)

Viel Erfolg,
Hendrik

PS: Am WE habe ich vor, im Forum von DMXControl interessierten Leuten 
das Arbeiten mit meinen C-Libs zu erklären und gemeinsam was zu proggen.
(Das ist zwar C und nicht AVRASM - aber vielleicht könnte das was für 
Dich sein...)
Voraussetzung ist natürlich, dass Du bereits die fertigen FWs korrekt 
geflasht bekommst - sonst machen mich wieder einige mit den PonyProg 
Dongles wahnsinnig ;-)

Autor: Joachim Geiger (big_daddi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi henne,

also es läuft alles super und ohne probleme im Simulator. Doch in 
realität nicht so ganz.

Den FE empfang ich und das Startbyte auch, die Adresse wird auch 
eingelesen. Aber er springt nicht in das programm für den vergleich der 
startadressen.

Zwischen startbyte und 1.kanal trifft doch auch ein interrupt ein oder?? 
sonst würde es gehn!!!! Nur daran scheiter ich gerade, der rest 
funktioniert einwandfrei auch die PWM!!!

Autor: Sven K. (svenk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey Joachim,

teste doch mal wie empfohlen ein fertiges Hex-File von Hendrik !!!
Damit stellst Du sicher, dass Dein Atmel richtig arbeitet, etc.
(Fuses, Verdrahtung)
Danach machst Du weiter mit Deinem eigenen Programm.
Der Simulator merkt nicht, ab was an der Verkabelung nicht stimmt.....

Gruß Sven

Autor: Michael Wilhelm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein oft gemachter Fehler: DMX + und - Leitung vertauscht. Bitte prüfen.

MW

Autor: Joachim Geiger (big_daddi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Juhu es geht soweit!!!!

Ich hab nur ein Problem, dass ich beim Dimmen ein extremes Flackern hab. 
Besteht die möglichkeit das zu glätten?? Vlt. mit nem Condensator oder 
so???

Ich fahr vom uC raus und auf nen irlz34n drauf. Als pwm_frequenz hab ich 
20 us.

Gruß

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Joachim Geiger (big_daddi)

>Ich hab nur ein Problem, dass ich beim Dimmen ein extremes Flackern hab.
>Besteht die möglichkeit das zu glätten??

Ja.

> Vlt. mit nem Condensator oder so???

Nein. Bring deine Software in Ordnung.

>Ich fahr vom uC raus und auf nen irlz34n drauf. Als pwm_frequenz hab ich
>20 us.

Kaum. Das ist eine Zeit. Und du hast sicher keine 20uS Periodendauer, 
das wären 50 kHZ. Ein "wenig" viel das guten.

MFG
Falk

Autor: Joachim Geiger (big_daddi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

jetzt hät ich nochmal eine Frage, und zwar hab ich jetzt mal eine andere 
Steuerung auseinander gebaut! jetzt seh ich dass der uC auf 16MHz mit 
einem Quarz getaktet ist. Ich dachte DMX braucht 8 MHz????

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Joachim Geiger (big_daddi)

>Steuerung auseinander gebaut! jetzt seh ich dass der uC auf 16MHz mit
>einem Quarz getaktet ist. Ich dachte DMX braucht 8 MHz????

Um Gottes Willen! Das KANN gar nicht funktionieren!
Oder einfach denn doppelten Teiler für die Baudrate programmieren, 
um auf 250 kBit/s zu kommen? Siehe Baudratenquarz

MFG
Falk

Autor: Henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
UBRRL= 3;

Rest dürfte passen.
Alternativ F_OSC auf 16000 [kHz] setzen.

Mich wundert, dass bislang niemand "rtfm" gepostet hat. Find ich nett.

VG,
Hendrik

Ansonsten ist übers Wochenende bei DMXControl ein kleines Tutorial über 
DMX-Empfang mit der C-Lib entstanden. Ich denke, mehr geht nicht.

(Somit ist dies mein letzter Post zu den Libs.)

Autor: Joachim Geiger (big_daddi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wiel 16MHz würde mir besser gefallen bezüglich der PWM!!!!

Danke Hendrik für die Info!!!

Autor: Joachim Geiger (big_daddi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

so jetzt läuft meine Software eigentlich schon gut aber ich hab noch ein 
Problem. Der Dimmbereich 0-50% Flackerfrei, dann fängt es an zu flackern 
und ab ca. 80% hört es wieder auf zu flackern. Das kann doch eigentlich 
nicht an der Software liegen oder?????

Es könnte doch sein dass der IRFZ34N Transistor nicht so ganz gut 
geeignet ist.

@Henne:
Sorry aber ich find leider nix auf der dmxcontrol homepage. Wo ist da 
des turorial drin????

gruß

Autor: Henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://dmxcontrol.de/wbb2/board.php?boardid=24&sid...

(Falls der Link nicht geht: Forum->Selbstbau)

Autor: Deffy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rauskram,

auch bei mir klappt der DMX Empfang nicht wie er sollte. Ich habe mich 
an die C Version gehalten und das ganze für einen AT90PWM3B 
umgeschrieben. Nur wird bei mir nie die ISR für den USART ausgelöst. Das 
einstellen der Adresse klappt und auch läuft mein Programm an der Stelle 
vorbei, wo der Reciever enabled wird. Dann habe ich mir mal in die ISR 
Routine als erstes an Anweisung geschrieben um einen Port zu setzten. Da 
dieses nie geschieht, gehe ich davon aus, daß die ISR auch nie ausgelöst 
wird. Ich verstehe auch momentan nicht, welche Bedingung erfüllt sein 
muss, damit die ISR überhaupt ausgelöst wird. Vielleicht kann mir da 
jemand von euch einen Hinweis geben, wie das ganze funktioniert.

Grüße Christian

Autor: Christoph S. (mixer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau mal hier in s Tutorial, da findest du die Sachen die passieren 
müssen dass ein Interrupt ausgelöst werden kann. Weis jetzt nicht wie 
das in C ist aber in Assembler müssen z.B. generell Interrupts 
freigegeben werden über
 sei 

MFG Mixer

Autor: Deffy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also,

ansich habe ich den Quelltext der C Version genommen und da werden die 
globalen Interrupts per SEI auch aktiviert. Ansonsten ist eigentlich 
alles wie im Quellcode. Ok man musst ein wenig anpassen, damit die 
Register mit dem AT90 übereinstimmen, aber das Compilieren geht 
fehlerfrei. Dennoch spring das Programm nicht in den USART Interrupt und 
ich weiß nicht warum. Auch verstehe ich die Funktion halt nicht ganz. 
Was mir zum Verständiss fehlt, ist der Punkt, wo der Interrupt in 
Quelltext ausgelöst wird.

Grüße Christian

Autor: Sven K. (svenk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Taucht ein Warning beim Bauen auf ?
Falls nicht, ist nicht doch ein Register falsch gesetzt ?

Kannst Du nicht den geänderten Quellcode mal zippen und zeigen ?
So rät man mehr herum.....


Gruß Sven

Autor: Deffy (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So,

hier habe ich mal den Quelltext dran gehangen. Wenn man daß mit dem 
original Quellcode vergleicht gibt es eigentlich keinen großen 
Änderungen. Das Einlesen der Startadresse ist etwas anders, liegt daran, 
daß ich über 2 Ports verteilt gehen musste. Ansonsten ist es die selbe 
Technik wie im Original Quellcode für das neunte Bit der Startadresse. 
Das Einlesen klappt auch fehlerfrei. Ich hatte das mal anhand von Ports, 
die ich bei bestimmten Adressen habe setzten lassen getestet.

Die einzige wirkliche Änderung betrifft das UCSRC Register denn der 
AT90PWM hat im gegensatz zum 8515 dort kein Bit für URSEL. Da die 
Initalisierung dort aber den selben Modus herstellt wie das URSEL Bit im 
8515 habe ich dort keine weiteren Maßnahmen getroffen. Vielleicht ist 
das ja der Fehler und ich muss dieses unbenannte Bit7 trotzdem nochmals 
setzten, was ich mir aber nicht vorstellen kann.

Zur Hardware, meine Platine ist per Optokoppler und DC/DC Wandler 
galvanisch vom DMX Bus getrennt. Ich weiß aber das ein DMX Signal am RX 
Pin ankommt. Oszilloskop sei dank, von daher schließe ich einen Fehler 
in der Hardware mal aus.

Grüße Christian

Autor: Sven K. (svenk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Christian,

also ich habe mal mit einem Makefile die sourcen versucht zu 
compilieren.
Das war soweit erfolgreich.

Jetzt kann ich mir nur noch erklären das Du die FUSE Bits nicht richtig
eingestellt hast.

CKDIV8 ist default auf 0 (also programmiert)

Die muss bei 16Mhz auf jeden Fall auf 1 (also nicht programmiert),
ich vermute das deswegen die ISR nicht anspringt....
Bist Du sicher das die Fuse-Bits richtig gesetzt sind ?

Gruß Sven

P.S.: Leider habe ich keinen AT90PWM als Hardware hier um das zu testen.

Autor: Deffy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So,

jetzt wird schonmal die ISR ausgeführt. Frag mich nicht woran es genau 
gelegen hat. Ich habe einemal das Bit7 im UCSRC Register von Hand auf 
Null gesetzt und seitdem läuft die ISR. Die Bits des DMX Stream werden 
wohl richtig erkannt, zumindest kann man Ports zu ihrem Eintreffen 
toggeln. Einzig die Daten werden nicht richtig gespeichert. Ich 
überlege, ob ich das DMX Protokoll nichg genau genug einhalte. In meiner 
Schaltung gibts eine galvanische Trennung. Der Optokoppler ist ein Open 
Collector, der dann gegen Masse durch Schaltet. Da man zwar im Atmel 
einen Pull-Up aktivieren kann um den Open Collector zu versorgen man 
dann aber ein invertiertes Signal am Pin hätte, habe ich noch einen 
Inverter dazwischen geschaltet. Muss ich mir mal auf dem Oszi genauer 
angucken wie da das Signal aussieht. Vielleicht stimmen die Timeings 
nicht mehr. Ansonsten währe es auch mal ganz interressant zu wissen, ob 
man die Routine auf ein invertiertes DMX Signal umprogrammieren kann, 
würde etwas Schaltungsaufwand sparen.

Grüße Christian

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Deffy (Gast)

>man die Routine auf ein invertiertes DMX Signal umprogrammieren kann,

Nein, das kann der UART nicht. Man kann einen Optokoppler auch 
NICHT-invertierend betreiben. Statt Pull Up einen Pull down an den 
Emitter, Kollektor an Vcc.

MFG
Falk

Autor: Deffy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt wohl,wohlnur habe ich momentan einen 6n136 drin und der hat 
keinen nach außen geführten emitter, sondern ist intern auf Masse 
geführt. Und ehe ich einen neuen optoklopper raussuche, hätte es ja 
einfacher sein können den quellcode anzupassen. Aber dennoch Danke, 
werde dann mal die Hardware anpassen

Autor: Deffy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moinsen,

ich krame das Thema hier nochmal raus. Inzwischen habe ich meine 
Hardware angepasst und mein Signal nach der galvanischen Trennnug per 
Optokoppler nochmal invertiert. Am RX Pin meines AT90PWM kommt also das 
DMX Signal jetzt genau so an, wie es sein sollte. Trotzdem klappt die 
ganze Sache immer noch nicht. Ich habe mir in den Quellcode mal ein paar 
Flags gesetzt, die mir Pins toggeln. Den Frameerror am Anfang eines 
Frames erkennt die Routine wohl noch richtig. Das Break danach schon 
nicht mehr. Jetzt kommt das komische an der ganzen Sache, wenn ich meine 
DMX Karte richtig stresse und auf allen 512 Kanälen einen Wert ausgeben 
lasse erkennt er auch das Break, Startbyte jedoch immer noch nicht. 
Meine Überlegung währe jetzt, daß meine Bautrateneinstellungen 
vielleicht nicht richtig sind. Könnte da mal jemand einen Blick drauf 
werfen?
Ich sehe mal zu, daß ich im Laufe der Woche mal eine paar Bilder vom 
Signal mit nem Oszi mache und hier rein stelle.

Grüße Christian

Autor: Michael Werner (michelw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Deffy wrote:
> Meine Überlegung währe jetzt, daß meine Bautrateneinstellungen
> vielleicht nicht richtig sind. Könnte da mal jemand einen Blick drauf
> werfen?
Schreib doch mal eine Endlosschleife, und sende einen wert, z.B. AA oder 
55.
Und messe dann mal mit dem Oszi die Baudrate nach.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.