Aller Anfang ist schwer. -> DMX

    Zitat von Pesi

    "com2" und "com3" sehe ich hier nicht.... ?( - aber zu der Frage allgemein weiss bestimmt das Bascom-Handbuch Rat.... ;)


    Ja klar weis die Bascom hilfe rat. ^^ und zwar sagt sie jedesmal das gleiche :D Ne die Frage war ja, was bedeutet die Zahl hinter "com". Sind die Zahlen fest U(S)ART schnittstellen zugeordnet, sprich wenn nur eine da ist MUSS man nur COM1 verwenden?


    Zitat von Pesi

    Das Ucsra.fe ist das Bit im USART-Statusregister für "Frame Error" - so wird ja der Anfang eines Datenblocks gekennzeichnet, indem ein längerer Break kommt, der eben einen Frame-Error erzeugt.... das wird hier ausgewertet


    Hm... cool, genau das was ich wollte. Hab schon ne weile nach dem begriff gegooglet, doch nix gefunden,


    EDIT: hab gerade nochmal im daten blatt geguckt und doch was gefunden: The USART Receiver has three Error Flags: Frame Error (FE), Data OverRun (DOR)
    and Parity Error (PE). All can be accessed by reading UCSRA.


    Zitat von Freaky91

    für was steht dieses dicke Ucsra.fe, muss ja ein feste befehl in bascom sein

    Nein! - das ist *kein* Befehl/Anweisung - die *Anweisung* ist "If (...) then", die

    Zitat

    kennst Du doch, oder....? Die *Bedingung* dazu ist dann "Ucsra.fe = 1", also das nach dem then wird ausgeführt, wenn Ucsra.fe gleich eins ist... so wie halt immer bei ner "if then"-Anweisung... ;)


    Das hab ich mir fast gedacht, kenne dann doch schon wie man EIN und Ausgänge setzt und wie ne If anweisung funktioniert. :sleeping:


    Zitat von Freaky91

    Des weiteren, man spricht ja immer von man muss einem gerät eine Addresse zuweisen. Schön. :thumbup: Rein vorm logischen her muss es ja das bestimmte Datenbyte sein, sprich Addresse 5 ist das 5. Gesendetste Datenbyte. Das dann von einem gerät weiter verarbeitet wird, oder? ( sprich Buffer(5) )

    Zitat

    Ja, bei dieser Routine hier exakt richtig - die empfängt immer stur alle 512 Byte (oder wie viele halt gesendet werden), Du kannst es Dir dann hinterher aussuchen, welche Du nimmst - braucht halt dann immer 512 Byte RAM, auch wenn Dich nur 3 Kanäle wirklich interessieren.... kleiner Vorteil: Du kannst z.B. bei nem 12-Kanal Dimmer jedem Dimmer-Kanal einen eigenen DMX-Kanal zuweisen, falls das warumauchimmer nötig sein sollte....


    Andere Routinen (z.B. die von mir verwendete) machen das anders, die zählen erst die Bytes runter, die vorbeirauschen sollen, und fangen erst bei der Startadresse an, in's RAM zu schreiben - also wenn Du bei meinem DMX-Receiver z.B. Adresse 17 einstellst, werden die ersten 16 Byte ignoriert, und dann nur die nächsten 5 in's Ram geschrieben, der Puffer ist also nur 5 Byte groß statt 512 (würde auf nem Tiny2313 auch gar nicht gehen....)


    Nunja hört sich gut an. DOch da ich eh fast immer nen ATmega verwende werde ich erstmal keine probleme mit dem Ram haben :whistling:

    Hallo,


    da ich zufällig auf diese Diskussion über meinen DMX-Code gestoßen bin, will ich auch ein bisschen helfen:


    Ucsra.fe = 1 liest ein Register des ATMega8 aus (zu finden im Datasheet des ATMega8). Am Anfang des DMX-Signals kommt erst ein dicker Reset, der länger als das erwartete Frame ist. Dadurch wird ein Frameerror ausgelöst. Damit kann hier der Anfang des DMX-Signals detektiert werden. Kanal 0 wird als erstes geschrieben, weil nach DMX-Protokoll erst das 2.Frame den Kanal 1 enthält.


    Alle 512 Kanäle werden im Buffer-Array abgelegt, das in einen ATMega8 passt. Klar könnte man die unnötigen Kanäle erst überspringen, ich wollte den Code aber nicht unnötig aufblähen. Außerdem ist ja genug Speicher da ;)


    wers gerne ein bisschen aufgeblähter hat findet auf meiner Homepage einen Empfänger mit Display zur Parametereingabe über I2C und einen D/A-Wandler zur 0-10 Volt Ausgabe. Zum Ansteuern von LEDs empfehle ich den PCA9635. Dieser kann auch über I2C 16 Ausgänge mit PWM versorgen.

    Hi guenter, willkommen im Forum!


    und Danke nochmal für die erneute Zusammenfassung dieser Sache - Freaky, wie Du siehst, ist da echt nix dabei bei dem DMX.... nur damit's genau ist: das erste Byte, das nach dem FE gesendet wird, ist das "Startbyte", das muss/soll bei Dimmer-Anwendungen "0" sein, die meisten Routinen werten das auch aus, wenn's nicht 0 ist, wird der Datenblock ignoriert - ist aber nicht wirklich nötig, kann man so wie hier auch einfach ignorieren...


    wegen dem Buffer: klar, wenn man RAM im Überfluss hat, ist das kein Problem - und wie schon gesagt, man hat dann auch (einfacher) die Möglichkeit, sich einzelne Adressen "rauszupicken", wie Du (guenter) das bei Deinem Dimmer ja auch machst....


    nur der Vollständigkeit halber: sooo viel "aufblähen" wäre das gar nicht, da von vornherein nur einen *Bereich* (z.B. 3 für ne RGB-Leuchte) der Kanäle abzuspeichern, sollte dann in Bascom so aussehen (mache kein Bascom, k.A., ob die If-Teile und das "kleiner/gleich" so stimmen...?):



    wobei DMX_Start die Startadresse ist und DMX_Kanaele die Zahl der Kanäle, "Zaehler" ist einfach ein temporärer Zähler... wenn man nur 3 Kanäle braucht, sind die dann halt in Buffer(1) bis Buffer(3), 12 Kanäle wären in Buffer(1) bis Buffer(12) usw. - egal, welche Startadresse eingestellt ist


    DMX_Start muss man sich halt irgendwoher holen (DIP-Schalter oder Taster+Display), das ist halt dann je nachdem noch mal ein paar Zeilen Code - den man aber *so und so* braucht zum Adresse einstellen, egal, ob man erst alle 512 Kanäle abspeichert und dann raussucht, oder gleich nur die benötigten speichert....


    Hoffe, das ist nicht zu sehr off-Topic, aber evtl. schaut ja auch mal jemand hier rein, der das für Bascom braucht und nicht so viel RAM über hat... ;)


    Übrigens, guenter, sehr interessant finde ich Deine Sende-Routine, auch ne witzige Idee, das serielle Signal per Bitbanging zu erzeugen... :thumbup: - wobei ich immer wenn's geht, da auch den USART zum senden benützen würde, ist auch sehr simpel (ähnlich wie die Empfangsroutine) und halt doch sicherer vom Timing her....

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

    Hi,


    ahhhh, da es hier grad so abgeht mit dem DMX Bascom Code will ich mich auch einklinken. Und naja, wie soll es anders sein, ich möchte auch den Code vom Günter verwenden :D


    Aber wie war das nochmal? Dieser Code empfängt stur alle Kanäle, aber mein DMX Sender sendet nur die Kanäle die auch tatsächlich belegt sind, geht das dann oder wird es da Probleme geben?


    Also ich habe kein Problem damit alle Kanäle einzulesen, aber nicht das der mir nachher falsche Werte irgendwo rein schreibt.


    Gruß, Benny.

    Also noch mal zur Erklärung:


    Dein Sender sendet im Normalfall irgendwas zwischen 4 und 512 Kanälen - soviele, wie halt gebraucht werden, bei nem 12-Kanal-Pult dann 12, der E:Cue Nano z.B. 256, bei uDMX ist es einstellbar...


    Ob die in der Steuer-SW belegt sind, ist wurscht - wenn z.B. kein Gerät gepatcht ist, dann schickt der Sender halt max. 512 mal "0" raus.... aber er fängt *immer* bei Kanal 1 an!


    Empfang: die Bytes trudeln einfach der Reihe nach ein - welcher Kanal das dann ist, hängt von der Position ab.


    Also: Du musst nix weiter machen, als mit dem AVR Bytes zu empfangen! Das macht der mit dem USART ganz automatisch! - Der wird dann so eingestellt (siehe Code von guenter auf seiner Seite), dass er eine ISR aufruft, wenn ein Byte angekommen ist.


    Zuerst kommt aber ein längerer Break (den erzeugt Dein Sender auch ganz automatisch) - Der ruft auch die ISR auf, hier ist dann das Frame-Error-Flag gesetzt - Du weisst also nun, dass ein neuer Datenblock beginnt. Dann kommen einfach der Reihe nach Bytes rein, die in der ISR immer sofort verarbeitet werden. Das erste wird ignoriert (Startbyte).


    Dann kommt das erste Datenbyte, das ist Kanal 1 - danach das nächste Byte, das ist Kanal 2 - usw.


    wenn Du also z.B. die Kanäle 7-9 brauchst, dann ignorierst Du die Datenbytes 1-6 einfach, schreibst dann 7-9 in den Puffer, und ignorierst 10 - x auch wieder - genau das macht die oben von mir geänderte Routine.... dadurch hast Du dann die DMX-Kanäle 7-9 in Buffer(1) bis Buffer(3). Setzt Du DMX_Start auf 24 und DMX_Kanaele auf 12, dann hast Du halt die Kanäle 24 - 35 in Buffer(1) bis Buffer(12) - Prinzip verstanden...?


    Die Original-Routine von guenter empfängt *alle* Bytes und legt sie in Buffer(1) bis Buffer(512) ab - hier wäre dann z.B. in Buffer(7) der DMX-Kanal 7 drin - falls das Pult nur bis 12 sendet, dann ist in Buffer(13) halt "nix" drin, aber muss ja auch nicht...


    da Dir doch eh' schon der Speicher knapp wird, würde ich Dir empfehlen, die geänderte Routine zu benutzen, dann brauchst Du für den Empfangspuffer wirklich nur soviele Bytes im RAM, wie Du Kanäle empfangen willst...

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

    Zitat von Pesi

    da Dir doch eh' schon der Speicher knapp wird, würde ich Dir empfehlen, die geänderte Routine zu benutzen, dann brauchst Du für den Empfangspuffer wirklich nur soviele Bytes im RAM, wie Du Kanäle empfangen willst...

    Hey, mach mich nicht wieder runter :P Ich hab mir anmerkungen zu Herzen genommen und meinen Code überarbeitet. Jetzt sind es statt 30% nur noch 14% und das sogar mit ner Farbe mehr :D Weitere Farben können nun ohne weiteren linearen Speicherzuwachs hinzugefügt werden. Solltest vielleicht mal wieder in den Beitrag rein schauen.


    Gruß, Benny.

    hab' ich schon - ist auch kein "runtermachen", sondern soll ne Hilfe sein: es schadet ja nix (daher eben der Hinweis) das hier *gleich von Anfang an* sparsam zu planen - und es wäre ja wirklich Quatsch, alle 512 Kanäle in's Ram zu puffern, wenn Du nur 3-5 davon brauchst....

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

    Hallo


    @ pesi die veränderte routine gefällt mir ja schon ganz gut. Mal sehen vielleicht baue ich sie ein :thumbup:


    Um euch sonst mal aufm laufenden zu halten. Hab mir das uDMX von wächter besorgt ( von chris16), werde es so in 2 wochen bekommen.
    Da ich ja nicht ganz so faul da rum sitzen will, hab ich mir schon gedanken über den empfänger gemacht.
    Bitte verbessert mich wenn ich was falsches erzähle.
    Für den Empfänger braucht man nur z.B. einen 75176 und daran wird das DMX+ und DMX- signal angeschlossen. Weitergehen wird vom 75176 noch ne Leitung zum AVR auf den RxD pin gezogen. Das wars auch schon?!


    Zur Software Seitigenverknüpfung werde ich erstmal das von der Günter Gerold seite benutzen ( das ist doch der günter der uns gerade mal besucht hat oder? )
    Allso sollte funktionieren, das so einzubinden. Die Baud rate wird dann an die Quarz frequenz angepasst.(oder muss die SENDER und EMPFÄNGER baud gleich sein==??) Dann hätten wir das ja auch schon alles. :thumbup: N Traum.


    Zwischen zeitlich hab ich mich schon mal bischen mit DMX Controll auseinander gesetzt. Dachte den Empfänger bauen, dass wird die schwierigkeit und DMXC wird schon gehen, doch hat sich wohl anders ergeben.
    Hab erstmal so leicht in DMXC reingeschaut und gleich gemerkt, dass ich für meine Zimmerlampen nen eigenes DDF anlegen muss.
    Naja gedacht, getan. ( :rolleyes: ) Fast. Hab schonmal bischen geschaut wie man das so macht, auf der DMXC wiki Seite gelesen. hat auch alles funktioniert, hab mir heute paar gedanken über das Layout der Funktionen gemacht.
    Das einzig schwierige wird wohl sein die Prozedur zu erzeugen. Hab gesehen, das ist einfaches IF nunja, mann muss damit ja nur die Variabelen aus den Slidern (z.B.) auf einen Kanal legen, und halt noch sagen, dass wenn eine sache betätigt ist eine andere nicht verändert werden darf.?!


    Nunja, dann konnte mich chris16 davon überzeugen, dass ich mir erstmal nen probe DMX Empfänger aubaue. hab mir mal den Pesi DMX-Reciever raus gesucht. Hört ja nur gutes von dem Ding. Wenn das dann geht, kann ich noch bischen in DMXC rumspielen und mich dann an meine Zimmerbeleuchtung machen.


    MfG

    Hi,


    also momentan tendiere ich ja eher wieder zu dem Max485. Wie sieht es denn da mit galvanischer Trennung aus? Wie sollte man sowas am besten aufbauen?


    Dann noch andere Frage, wäre es denn nicht auch möglich dieses DMX Signal anstatt über 2 Drähte auch über 2 Lichtleiter zu übertragen? Dann hätte man das mit der galvanischen Trennung automatisch erschlagen? Aber ist nur so ein Grundgedanke und nicht in die Schaltung eingeplant.


    Gruß, Benny.

    Hallo,


    mit dem Puffern aller 512 Kanäle hat folgenden Hintergrund:


    Die Interruptroutine wird ja bei jedem Kanal aufgerufen und das Hauptprogramm unterbrochen. Da dies ja (fast) pausenlos geschehen kann, wird der Interrupt ja auch (fast) pausenlos aufgerufen. Überspitzt gesagt hat der Microcontroller vor lauter Interrups gar keine Zeit fürs Hauptprogramm. Damit das nicht so ist, sollte die Interruptroutine so kurz wie möglich sein. Den Befehl


    If Kanal > DMX_Start And Kanal <= (DMX_Start+DMX_Kanaele) Then


    schätze ich jetzt einfach mal auf 50 Prozessortakte ein, die bei jedem Kanal verbraten werden. Das sind bei 62,5ns bei nem 16MHz! Quarz 3,125 us. Wenn man weiß, daß alle 44us ein Kanal eintreffen kann sind 3 us nicht wenig. Es gibt keinen universellen Idealweg, man muß im Einzelfall entscheiden was besser ist, alle Puffern oder nicht.


    Günter

    Und das ist *auch* ein Grund, warum ich das in Assembler mache... :D ;)


    Aber ehrlich: nen Quarz braucht man da eh,' also nehme ich immer 16 MHz, das ist doch nix arges (wegen dem Ausrufezeichen, meine ich jetzt...)


    3 µs alle 44 µs wären also ca. 7% mehr Prozessorauslastung - müsste man mal gucken, was die Routine insgesamt braucht....


    Wie Du schon sagst, hängt immer von der Situation ab: Die meisten hier machen ja 3-6 Kanäle HW-PWM, da muss der µC ausser DMX empfangen *eigentlich gar nix mehr* machen (halt die Werte in die Register schreiben) - sollte sogar noch locker genug Zeit überbleiben, um die Fernbedienung abzufragen, ob der DMX-Modus wieder beendet werden soll (dann deaktiviert man den Usart-Interrupt natürlich, um im Standalone-Modus nicht davon gestört zu werden...) und nebenbei im Display was einstellen o.ä. ist ja auch nicht zeitkritisch...


    Klar, DMX-Dimmer mit 12 Kanälen SW-PWM und das alles in Bascom, wird dann schon schwierig.. ;) - irgendwo sind halt immer Grenzen....


    Zitat von Freaky91

    Für den Empfänger braucht man nur z.B. einen 75176 und daran wird das DMX+ und DMX- signal angeschlossen. Weitergehen wird vom 75176 noch ne Leitung zum AVR auf den RxD pin gezogen. Das wars auch schon?!

    Genau - so wie z.B. in dem Schaltplan bei meinem DMX-Receiver.... Du kannst auch noch Pin 4 an den Tx anschliessen, und Pin 2und 3 dann statt an GND beide zusammen an einen Portpin (auf Ausgang), dann kannst Du per SW zwischen Senden umd Empfangen umschalten...


    Zitat von Freaky91

    Die Baud rate wird dann an die Quarz frequenz angepasst.(oder muss die SENDER und EMPFÄNGER baud gleich sein==??)

    Sowohl als auch - Baud-Rate bei DMX ist 250 k, wenn Du das in Bascom alles so einträgst, machtr er schon die richtigen Einstellungen, dass das für Deinen Quarz passt - 16 MHz passt ganz gut, bei bestimmten Frequenzen (siehe Tabelle im Datenblatt) gibt es leichte Abweichungen von der exakten Baudrate...


    Zitat von benkly

    also momentan tendiere ich ja eher wieder zu dem Max485. Wie sieht es denn da mit galvanischer Trennung aus? Wie sollte man sowas am besten aufbauen?

    Da habe ich Dir jetzt wohl nen Floh in's Ohr gesetzt... :D das ist hier wirklich nicht nötig, ich benutze DMX seit 15 Jahren auch in größeren Installationen, Bühnen mit "dreckigem" Strom etc., gab nie Probleme trotz fehlender galvanischer Trennung...


    Falls die sein soll, schau' Dir doch mal den Schaltplan von dem Waechter-uDMX an - Du brauchst dann noch nen DC/DC-Wandler, weil die Stromversorgung ja auch galvansich getrennt sein muss.. also, ob der Aufwand hier wirklich nötig ist....?


    was ich noch hinmachen würde (bzw. ist in meinem neuen Receiver schon drin), wäre ne Schutzbeschaltung, also Widerstände und Zenerdioden, damit halt Verpolung und Überspannung ggfs. keinen großen Schaden anrichten können...


    Zitat von benkly

    Dann noch andere Frage, wäre es denn nicht auch möglich dieses DMX Signal anstatt über 2 Drähte auch über 2 Lichtleiter zu übertragen?

    Da würde sogar einer reichen - ist ja nur ein simples serielles Signal....

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

    Einmal editiert, zuletzt von Pesi ()

    Hallo,


    mehrere PWMs im ATMega zusätzlich zu DMX zu erzeugen find ich eh keine gute Idee. Bei 8 Stück hab ich trotz 16MHz grade noch 50 Hz erreicht und wehe ein anderer Interrupt funkt dazwischen, dann flackerts auch noch. Da find ich den PCA9635 ideal: 16 PWMs und einen Summen-PWM anzusteuern über das timingunkritischere I2C. Nur löten sollte man können ;)


    Günter

    Hm... um mal wieder was zu sagen :rolleyes:


    Ich will damit 3 HW-PWM ausgänge mit werten bestücken, gegebenenfalls nen fader, strobo, ... so zeug da einbauen. Strobo, ist ja kein aufwand, mit dem fader könnte es meiner meinung nach schwierig werden, oder? Habe, so grob geschätzt 15-18 kanäle, die ich brauche.


    Ich hoffe das geht so, denn deswegen baue ich mir das zeug ja :D Allles nochmal ändern .... Muss nicht sein ;D .


    Grundsätztlich gefragt. ( das Schattenfugen projjekt hat mich dazu inspiriert) Wenn ich nen ATmega mit 2 USarts nehme und einen zum empfangen des DMX signals und den anderen zum weiter senden der Daten nehme, und so noch 2 weitere Megas bestücke, sollten doch die Zeit probleme wech sein oder? Da dann nur die Daten, die von nöten sind gesendet werden. Sprich so 10-15 Stück. Daher würde der ISR ja nur 15 mal aufgerufen werden. *träum*


    MfG

    Naja, der Biertrinker hat ja sein eigenes Protokoll - da kann er z.B. auch nur dann Datenblöcke senden, wenn sich grad was ändern muss...


    DMX sendet aber kontinuierlich, d.h., egal ob Du nur 3 oder 512 Kanäle benutzt, ob sich grad was ändert oder nicht, die ISR wird ca. alle 44 µs aufgerufen...


    Wie schon gesagt, 3 Werte in die HW-PWM-Register schreiben ist nun echt kein Ding, und wenn da in dem Teil der Fader läuft, dann schaltest Du (wie auch schon gesagt) die DMX-ISR einfach ab, dann hast Du da mehr Zeit über/wirst nicht unterbrochen....


    gleichzeitig senden und empfangen ist dann in Bascom wohl auch eher kontraproduktiv...


    Zitat von guenter

    mehrere PWMs im ATMega zusätzlich zu DMX zu erzeugen find ich eh keine gute Idee. Bei 8 Stück hab ich trotz 16MHz grade noch 50 Hz erreicht und wehe ein anderer Interrupt funkt dazwischen, dann flackerts auch noch.

    Das war dann aber auch in Bascom, oder....? - ich habe für diesen Dimmer hier (Quarz ebenfalls 16 MHz) die SW geschrieben (der 2bl hat mir dafür was anderes gemacht... ;)), das sind 24 Kanäle 8-Bit-SW-PWM mit 244 Hz, DMX-Empfang, nebenbei noch den DIP über Schieberegister abfragen, da flackert gar nix!


    Da habe ich aber auch vorher genau die benötigten Takte abgezählt (in asm geht das ja), ob das so hinhaut - der Prozessor ist hier schon gut ausgelastet (macht ja nix), aber das Ganze läuft einwandfrei ohne Timingprobleme... liegt wohl auch daran, dass hier die komplette DMX-ISR ca. 15 Takte braucht, wenn ich mir überlege, dass Du in Bascom für die einfache größer/kleiner-Abfrage schon 50 rechnest... 8o


    Da wurde mir im Forum ja auch schon widersprochen, als ich mal gewagt habe zu behaupten, dass Bascom den Code doch ziemlich "aufbläst", aber asm ist halt doch um *einiges* schlanker/schneller...


    So wie früher (k.A. wie alt Du bist...?) beim Commodore C64: in Basic schnarcht die Kiste elend vor sich hin, gekaufte Spiele in Assembler haben Sachen rausgeholt, die man nicht für möglich gehalten hat - daher habe ich ja damals mit Assembler angefangen...


    Heutzutage merkt man das ja nicht so, je nach Anwendung kann ein in VisualBasic geschriebenes Programm auf dem PC genauso schnell laufen wie ein in C++ erstelltes - das liegt dann daran, dass sich bei beiden Programmen die CPU zu 99,8% langweilt - aber bei µC, die ja oft voll ausgereizt werden, ist der Unterschied dann umso größer...


    Zitat von guenter

    Da find ich den PCA9635 ideal: 16 PWMs und einen Summen-PWM anzusteuern über das timingunkritischere I2C. Nur löten sollte man können ;)

    Und das wäre mir hierfür zu aufwendig - so ein Teil in der Art würde ich nur nehmen, wenn ich dadurch z.B. auch 12 Bit PWM habe o.ä. - oderaber der µC so viel andere Sachen machen muss, dass die PWM-Erzeugung nicht mehr die Hauptaufgabe ist (wie z.B. bei Nenis Moodmatrix) - aber nicht bei nem einfachen DMX-Dimmer...


    Ich bin auch gerade an einer 10-Bit-BCM (Bit Code Modulation, wurde hier schon mal unter "Bit Angle Modulation" drüber geredet) dran, da werde ich wohl mit 8 Kanälen auch ca. 240 Hz erreichen, sind dann aber 1.024 Helligkeitsstufen statt 256 - ohne externe HW... in Bascom bräuchte ich natürlich mit sowas gar nicht erst anfangen... ;)

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

    Hallo Pesi,


    klar geht manches in ASM schneller (wenn mans gut macht), ich dachte es ist Basic gewünscht?
    Zum Thema einfache größer/kleiner Abfrage:
    Es sind 5 Befehle:


    Dmx_start + Dmx_kanaele
    Kanal <= Ergebnis obere Zeile
    Kanal > Dmx_start
    das Ganze AND verknüpft
    und das eigentliche IF


    Das ist soviel auf einmal, daß sogar Bascom streikt. ;)
    Also ich hab nachgerechnet, jedoch musste ich erst den Code noch korregieren:


    Temp = Dmx_start + Dmx_kanaele
    If Kanal > Dmx_start And Kanal <= Temp Then


    Dieser Code benötigt tatsächlich 35 Prozessorschritte. Das finde ich nicht hübsch. Hier wäre ein Stückchen ASM schon schön... ... oder man puffert alle 512 Kanäle ;)


    Wenn du eine flotte Software-PWM in ASM hast, dann wäre es doch toll, daraus eine Library für Bascom zu machen.

    oh,


    Benny das hab ich doch glatt übersehen.
    Beim Sender müssen es 8 MHz sein, da der Code sich darauf verlässt, daß ein Prozessorschritt genau 125 ns dauert. Nur dann stimmt das Timing genau der Norm. Ob der interne Oszillator genau genug ist habe ich noch nicht probiert, theoretisch sehe ich keinen Grund warum es nicht gehen soll.
    Beim Empfänger ist nur darauf zu achten, daß die Frequenz zur Baudrate von 250000 passt.


    Die RC-Oszillatoren sollen inzwischen aber relativ genau und stabil sein. Aber wie gesagt, noch nie probiert.


    Günter

    Zitat von guenter

    klar geht manches in ASM schneller (wenn mans gut macht), ich dachte es ist Basic gewünscht?

    Naja, hier geht's ja auch eher allgemein um DMX etc. - das bezog sich auf die eher allgemein gemachte Aussage:

    Zitat von guenter

    mehrere PWMs im ATMega zusätzlich zu DMX zu erzeugen find ich eh keine gute Idee

    Die sich so angehört hat, als ob das *grundsätzlich* keine gute Idee wäre - ohne die Einschränkung, dass es nur in Bascom keine gute Idee ist... ;)


    echt jetzt....? Wahnsinn! 8o Hätte nicht gedacht, dass das dem schon zu arg wird....


    Zitat von guenter

    Also ich hab nachgerechnet, jedoch musste ich erst den Code noch korregieren:


    Temp = Dmx_start + Dmx_kanaele
    If Kanal > Dmx_start And Kanal <= Temp Then

    Optimierung: es ist ja eigentlich Quatsch, das *jedes mal* Rechnen zu lassen - kann man ja vorher ausserhalb machen:



    mit z.B. DMX_Start = 11 und DMX_End = 24 (in der Routine berechnet, in der man die Adresse einstellt) speichert z.B. die DMX-Kanäle 12 bis 23 in Buffer(1) bis Buffer(12)....


    einziger Unterschied zu Deiner Routine: statt Zahlen stehen da Variablen, k.A. ob das in Bascom *wesentlich* länger dauert, die zu Vergleichen...? - und ausserdem wird "Zaehler" noch inkrementiert, aber *das* kann ja auch in Bascom kaum das Kraut fett machen....?


    Zitat von guenter

    Hier wäre ein Stückchen ASM schon schön...

    Irgendwo in dem Dimmer- oder einem anderen Thread von 2bl ist so ne Bascom-Empfangsroutine verlinkt, in der 5 Zeilen asm mit drin sind - hatte mich schon gewundert wieso, aber wohl genau aus dem Grund.... ;)


    Aber wie schon gesagt, beim Freaky passiert ja sonst nicht viel ausser DMX-Empfang (v.a. nix zeitkritisches), da sollte das auch komplett in Bascom gehen wie oben... 35 Takte hin oder her.... ;)


    Zitat von guenter

    Wenn du eine flotte Software-PWM in ASM hast, dann wäre es doch toll, daraus eine Library für Bascom zu machen.

    Also, die PWM, die ich habe, ist 08/15: halt nen Zähler durchzählen, und mit den Helligkeitswerten vergleichen, ist der Zähler höher, geht die LED aus.... pro zu vergleichenden Kanal 5 Takte + etwas "aussenrum"...


    Mit der Library meinst Du aber schon Inline-Assembler, oder...? - kann gerne mal den asm-Teil hier reinstellen, und jemand der sich mit Bascom auskennt, bastelt dann das "Gerüst" drum rum...

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

    Zitat von Pesi

    einziger Unterschied zu Deiner Routine: statt Zahlen stehen da Variablen, k.A. ob das in Bascom *wesentlich* länger dauert, die zu Vergleichen...?

    Ich weiß nicht wie das in Bascom läuft, in C ist es auf jeden Fall so, dass Arrays immer im Block stehen, sodass er auf die Adresse des ersten Eintrags. D.h. er braucht bei jeder Belegung der Variable noch zusätzlich eine Hardware-Addition. Die sollte denke ich in 1 oder 2 Takten über die Bühne gehen. In der Theorie ist es also effektiver dafür einzelne Variablen zu nehmen. In wie weit das in der Praxis wichtig ist hängt immer davon ab wie zeitkritisch das ganze ist. Generell habe ich aber gelesen, dass Arrays und Mikrocontroller eigentlich zwei Tiere sind, die man nicht in einen Käfig lassen sollte.

    Zitat von Pesi

    und ausserdem wird "Zaehler" noch inkrementiert, aber *das* kann ja auch in Bascom kaum das Kraut fett machen....?

    Wäre dann ebenfalls nochmal eine Hardware-Addition.