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_Empf%C3%A4nger_mit_einem_AVR#Blockschaltbilder 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
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
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
@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.
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!!
@ 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
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.
@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.php?info=p3542_ADJ-ACCU-SPOT-575-movinghead.html http://www.discotechnik.com/proshop/product_info.php?info=p3049_EUROLITE-TS-155-DMX-Scan--mit-rotierenden-Gobos.html
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
@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?
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
@Sven Pauli (haku) Bedeutet: Teure Endgeräte billige 3P (damit er nicht 5P anfängt) ...aber hier geht es um den Fehler
@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?
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)
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.
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
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
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
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!
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
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
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
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
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
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
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
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
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
@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
Falls es hilft: Der aktuelle Link lautet http://www.hoelscher-hi.de/hendrik/light/ressources.htm VG, Hendrik
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.
ä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.
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
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???
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
@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
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?????
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
Beitrag "DMX512 Empfänger mit Relaisansteuerung für 20 Kanäle" Dort ist ein recht anschauliches Beispiel drin. MFG Falk
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!!!!
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
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!
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!
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!
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
also den ersten punkt hab ich schon mal gefunden im Code vom Henne:
1 | ifdef USE_DIP |
2 | sbr temp, (1<<0) ;hab ich nur zu testzwecken, DMX-Adresse = 1 |
3 | out PinB, temp |
4 | in XL, PinB ;get start address |
5 | |
6 | com XL ;muss raus, dann geht es! |
7 | |
8 | clr XH |
9 | sbic PinE, PE2 ;9th bit; hier steht normal sbis aber er sollt |
10 | 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???
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!!
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
http://www.atmel.com/dyn/resources/prod_documents/doc2512.pdf Ab Seite 35 gehts um den Takt. Da findest du wie du die Fuses für das externe Quartz einstellen musst!
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!
Im Zweifel immer mehr Verzögerung, auf die paar Milisekunden nach nem Reset oder nach dem Einschalten wirds normal nicht drauf ankommen!
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!!!
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 ;-)
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!!!
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
Ein oft gemachter Fehler: DMX + und - Leitung vertauscht. Bitte prüfen. MW
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ß
@ 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
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????
@ 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
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.)
wiel 16MHz würde mir besser gefallen bezüglich der PWM!!!! Danke Hendrik für die Info!!!
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ß
http://dmxcontrol.de/wbb2/board.php?boardid=24&sid=f82c2c770d4343b7567488595fd49573&PHPSESSID=9e035de7524052639732023ba0aaac35 (Falls der Link nicht geht: Forum->Selbstbau)
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
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
1 | sei |
MFG Mixer
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
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
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
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.
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
@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
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
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
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.
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.