Rainbow-Fader mit Zusatzfunktionen - Neu: mit Dimmerkurve

EDIT: Thread hiess mal "Selbstbau: einfacher RGB-Fader" - das stimmt jetzt nicht mehr, sind einige Funktionen dazu gekommen...

Hallo,

hatte endlich wieder etwas Zeit zum Basteln... *eigentlich* bin ich ja dabei, einen 24-Kanal-Dimmer mit DMX zu entwickeln, aber ich habe vor zwei Wochen erst mit AVR angefangen, drum wollte ich nicht gleich ne "Riesen"-Platine ätzen und mich in ein Software-Abenteuer mit ungewissem Ausgang stürzen, sondern mal klein anfangen.

Dachte mir, so ein RGB-Fader wäre zum rumprobieren ganz gut - da brauch' ich schon mal PWM, Standalone-Programme soll der Dimmer ja auch haben, später kommt noch DMX dazu, Display, etc., das kann man alles da der Reihe nach ausprobieren (auch die Hardware-Bestandteile) und die "Einzelteile" dann später weiter verwenden/neu kombinieren...

Hier mal der Aufbau:

[Blockierte Grafik: http://www.noisepop.de/led-forum/RGB-Fader/RGB-Fader.jpg]

Wobei: 1=Trafo 12V 2A für LEDs, 2=Netzteil für µC, 3=Gleichrichter+Elko (für LEDs), 4=Spannungsregler 9V (für LEDs), 5=µC-Platine, 6=Endstufe mit KSQ, 7=RGB-Rebel auf Alurohr zur Kühlung.

Die (unbestückte) µC-Platine hab' ich beim Hendrik gekauft, ich wollte da nicht ätzen... wobei das Pinout des Mega 8515 so einfach ist, das hätte man auch (mach' ich auch noch für weitere Versuche) auf Streifenraster aufbauen können...

Ich habe erst mal ne Software-PWM-Routine programmiert, und dann ein Programm, das so nen Regenbogen-Fader macht... da auf der Platine eh' ein DIP-Schalter vorgesehen ist, habe ich den auch noch abgefragt, man kann dann umstellen, das Programm springt in eine Subroutine, in der man feste Farben einstellen kann... Schalter wieder aus, und es geht an der unterbrochenen Stelle weiter... wollte nicht neulich hier mal jemand sowas in der Art...?

Hier mal ein Video, wie das aussieht.

Schaltplan ("Brunzprimitiv") kann ich bei Interesse gerne mal reinstellen, ebenso wie den Quelltext...

Die verwendeten Mosfets können 14 A bei 50 V, da kann man bei entsprechendem Netzteil (und "externen" KSQ) schon einige Rebel-Sterne dranhängen... hier läuft das Ganze auf 200 mA/Farbe, weil die LM 317 keinen Kühlkörper haben...

Als nächstes kommt jetzt:

- Mehr Programme... z.B. Rot/Blau-Fader (die Indiefritzen wollen immer sowas), Geblinker in der Art eines Ami-Polizeilichts, Stroboskop in weiß, etc... Platz ist da genug, das Programm belegt im Moment nicht mal 400 Byte...

- Alternative Bedienung: einfach ein Taster, mit dem man die Programme der Reihe nach durchschalten kann... das wird dann ein "Nebenprodukt", ich hab' da so nen 60x5-mm-LED-RGB-Scheinwerfer, da kommt das dann rein... wohl mit nem Tiny

- Nächstes Lernvorhaben: EEprom ansprechen, damit das Teil sich die letzte Einstellung merkt... weil dann kann man das mit Strom an/Strom aus in der Stellung "Stroboskop" eben auch als solches benutzen...

- DMX- und evtl. RS-232-Schnittstelle für externe Ansteuerung, Programmwahl etc. (vom Lichtpult oder PC)

- Und dann vielleicht auch noch nen IR-Empfänger zur Fernbedienung...

- Und im Zuge dessen Umstellung auf Hardware-PWM... Momentan läuft der Timer0 mit einem Prescaler von 1 (bei 8 merkt man trotz 16 MHz Takt schon deutliches Flimmern), d.h. die ISR wird alle 256 Prozessortakte aufgerufen... die braucht ja selbst auch ein paar Takte, da bleibt nicht mehr soo viel übrig, und wenn da jetzt noch ein UART-Interrupt dazwischenfunkt...

- Und dann noch ein LC-Display (2 Euro, 2x16 Zeilen) für noch komfortablere Bedienung... und damit ich lerne, wie man das richtig anspricht...

- so ne Art Dimmerkurve... momentan zählen die Farben einfach von 0 bis 255 und wieder bis 0, man merkt schon, dass die LED gleich "anspringt", sich im letzten Bereich von ca. 200 bis 255 aber nicht mehr viel ändert...

Mal schauen, was ich davon heute noch schaffe ;o) - Jetzt mach' ich dann erst mal ne Abfrage für noch zwei DIP-Schalter, dass man damit die Fade-Geschwindigkeit zumindest in 4 Stufen einstellen kann... und noch einen für das "Stroboskop"-Programm...

Ach, der Vollständigkeit halber hier noch das Programm - ich habe es doch noch geschafft, das Tabulatoren-Chaos ausm AVR-Studio in eine saubere Form zu bringen... BBEdit sei Dank! ;o)

[code:1]; ***********************************************************************************************
; * Einfacher RGB-Fader Testversion *
; * *
; * für ATMega 8515 *
; * *
; * LEDs über Mosfet-Schalter an Port A *
; * *
; * PortA0 = Rot, PortA1 = Grün, PortA2 = Blau *
; ***********************************************************************************************

.include "m8515def.inc"

.equ XTAL = 16000000 ; nur zur Info

.def temp0 = R16 ; Register definieren
.def temp1 = R17
.def temp2 = R18
.def LED = R19
.def R = R20
.def G = R21
.def B = R22
.def PWM_Count = R23

.org 0x0000
rjmp Start ; Reset Handler

.org 0x000E
rjmp ISR_PWM ; Timer Overflow Handler für PWM

.org 0x0012 ; Hauptprogramm kommt nach Interruptvektortabelle

Start:

ldi temp0, LOW(RAMEND) ; LOW-Byte der obersten RAM-Adresse
out SPL, temp0
ldi temp0, HIGH(RAMEND) ; HIGH-Byte der obersten RAM-Adresse
out SPH, temp0

ldi temp0, 0b00000001 ; CS00 setzen: Teiler 1
out TCCR0, temp0

ldi temp0, 0b00000001 ; TOIE0: Interrupt bei Timer Overflow
out TIMSK, temp0

sei ; Interrupts aktivieren

ldi temp0, 0
out DDRC, temp0 ; PortC auf Eingang (DIP-Schalter)

ldi temp0, 0xff
out DDRA, temp0 ; PortA auf Ausgang setzen (PWM-Ausgang)
out DDRE, temp0 ; PortE auf Ausgang (Status-LED)
out DDRD, temp0 ; PortD auf Ausgang ("On"-LED)
out PORTC, temp0 ; Pull-Up-Widerst‰nde an PORTC aktivieren

rgb_fade:

ldi R, 255 ; erst mal Rot
ldi G, 0
ldi B, 0

ldi LED, 0 ; Status-LED an
out PORTE, LED

rot_gelb: ; dann Grün dazu --> Gelb

call warten
call Schalter ; Dip-Schalter abfragen

ldi LED, 255 ; Status-LED aus
out PORTE, LED

inc G
cpi G, 255
brlo rot_gelb

ldi LED, 0 ; Status-LED an
out PORTE, LED

gelb_gruen: ; Rot weg --> Grün

call warten
call Schalter ; Dip-Schalter abfragen

ldi LED, 255 ; Status-LED aus
out PORTE, LED

dec R
brne gelb_gruen

ldi LED, 0 ; Status-LED an
out PORTE, LED

gruen_cyan: ; Blau dazu --> Cyan

call warten
call Schalter ; Dip-Schalter abfragen

ldi LED, 255 ; Status-LED aus
out PORTE, LED

inc B
cpi B, 255
brlo gruen_cyan

ldi LED, 0 ; Status-LED an
out PORTE, LED

cyan_blau: ; Grün weg --> Blau

call warten
call Schalter ; Dip-Schalter abfragen

ldi LED, 255 ; Status-LED aus
out PORTE, LED

dec G
brne cyan_blau

ldi LED, 0 ; Status-LED an
out PORTE, LED

blau_magenta: ; Rot dazu --> Magenta

call warten
call Schalter ; Dip-Schalter abfragen

ldi LED, 255 ; Status-LED aus
out PORTE, LED

inc R
cpi R, 255
brlo blau_magenta

ldi LED, 0 ; Status-LED an
out PORTE, LED

magenta_rot: ; Blau weg --> Rot

call warten
call Schalter ; Dip-Schalter abfragen

ldi LED, 255 ; Status-LED aus
out PORTE, LED

dec B
brne magenta_rot

rjmp rgb_fade ; Fade-Zyklus von vorn

; ------------------------------------------------------------------------------------------------
ISR_PWM: ; PWM-Ausgabe

push temp0
push temp1 ; Statusregister + Temp0 sichern
in temp1, SREG

ldi temp0, 0b00000111 ; Grundzustand 1 = LED an, 0 = LED aus (wegen FET)

inc PWM_Count ; den PWM Z‰hler von 0 bis
cpi PWM_Count, 255 ; 255 z‰hlen lassen
brne PWM_R
clr PWM_Count

PWM_R:

cp PWM_Count, R ; Ist der Grenzwert für Rot erreicht?
brlo PWM_G ; nein, weiter zu grün
andi temp0, 0b00000110 ; ja, LED Rot aus

PWM_G:

cp PWM_Count, G ; Ist der Grenzwert für Grün erreicht?
brlo PWM_B ; nein, weiter zu Blau
andi temp0, 0b00000101 ; ja, LED Grün aus

PWM_B:

cp PWM_Count, B ; Ist der Grenzwert für Blau erreicht?
brlo PWM_Ausgabe ; nein, weiter zur Ausgabe
andi temp0, 0b00000011 ; ja, LED Blau aus

PWM_Ausgabe: ; Neue Bitbelegung ausgeben

out PORTA, temp0

out SREG, temp1 ; Statusregister + Temp0 wiederherstellen
pop temp1
pop temp0

reti

; ------------------------------------------------------------------------------------------------
warten: ; 2 verschachtelte Warteschleifen

push temp2 ; Statusregister + Temp sichern
push temp1
push temp0
in temp0, SREG

ldi temp1, 0xff ; 255 Wiederholungen --> Geschwindigkeit Fader

loop1:

ldi temp2, 0xff ; 255 Wiederholungen --> Geschwindigkeit Fader

loop:

dec temp2
brne loop

dec temp1
brne loop1

out SREG, temp0 ; Statusregister + Temp wiederherstellen
pop temp0
pop temp1
pop temp2

ret
; ------------------------------------------------------------------------------------------------
Schalter: ; DIP-Schalter abfragen

push temp2 ; Temp2 sichern
in temp2, PINC ; DIP-Schalter an PortC
andi temp2, 0b10000000 ; Nur Schalter 8 ist interessant
breq Schalter_an ; Schalter ist an, weiter

rjmp Schalter_Ende ; Schalter aus, zurück

Schalter_an:

push temp1 ; Temp & Statusregister sichern
push temp0
in temp0, SREG

push R ; RGB-Werte sichern
push G
push B

Schalter_Loop:

in temp1, PINC ; DIP-Schalter an PortC
andi temp1, 0b00000001 ; Nur Schalter 1 ist interessant (Rot)
breq Rot_an ; Schalter ist an, weiter
clr R ; Schalter ist aus, Rot aus
rjmp Gruen ; und weiter zu grün

Rot_an:

ldi R, 255 ; Rot an

Gruen:

in temp1, PINC ; DIP-Schalter an PortC
andi temp1, 0b00000010 ; Nur Schalter 2 ist interessant (Grün)
breq Gruen_an ; Schalter ist an, weiter
clr G ; Schalter ist aus, Grün aus
rjmp Blau ; und weiter zu Blau

Gruen_an:

ldi G, 255 ; Grün an

Blau:

in temp1, PINC ; DIP-Schalter an PortC
andi temp1, 0b00000100 ; Nur Schalter 3 ist interessant (Blau)
breq Blau_an ; Schalter ist an, weiter
clr B ; Schalter ist aus, Blau aus
rjmp Schalter_Test ; und weiter zur Abfrage Schalter 8

Blau_an:

ldi B, 255 ; Blau an

Schalter_Test:

in temp1, PINC ; Schalter 8 immer noch an?
andi temp1, 0b10000000
breq Schalter_Loop ; Schalter ist noch an, von vorne

pop B ; RGB-Werte wiederherstellen
pop G
pop R

out SREG, temp0 ; Statusregister + Temp wiederherstellen
pop temp0
pop temp1

Schalter_Ende:

pop temp2

ret

; ------------------------------------------------------------------------------------------------
ende: rjmp ende

[/code:1]

Ist eigentlich selbsterklärend, ich kommentiere fast jede Zeile, damit ich später auch noch weiß, was ich da zusammengestrickt habe ;o)

Das mit dieser "Status-LED" kann man auch löschen, auf dem Board gehören halt zwei LEDs drauf, da hab' ich eine benutzt, die blinkt beim Faden im Takt und bei Festfarben leuchtet sie...

Das mit dem Schalter abfragen könnte man wohl mit SBIC und SBIS eleganter lösen, aber das geht bei mir nicht... ich vermute den Fehler in der Device-Definition, dazu gibt's dann einen extra Beitrag... aus dem Grund steht auch der Interrupt-Vektor für den Timer-Overflow bei $0E und nicht $07...

Die Faderei ginge bestimmt mit einer Art mathematischen Funktion auch einfacher/eleganter, hat da jemand ne Idee dazu? - ich habe es auf die Schnelle nur so hinbekommen...

ja, das sieht im Video so aus - das dimmt ja per PWM mit einer bestimmten Frequenz (ca. 244 Hz), die Kamera tastet den CCD-Sensor ebenfalls mit einer bestimmten Wiederholrate ab, dadurch gibt es Interferenzen....

das ist so ähnlich wie bei Western im Fernsehen oft die Wagenräder optisch stillstehen...

zusätzlich "ruckelt" es ab&zu auch noch etwas, da das Video im Interesse einer kleinen Dateigröße nur ne Framrate von 15 fps hat...

Aber "in echt" fadet's glatt ohne Flimmern.... das Auge ist halt nicht so schnell wie ein CCD-Sensor ;o)

Das ist übrigens für mich auch ein Grund, auf Hardware-PWM zu setzen, da bekomme ich dann ne höhere PWM-Frequenz... Profi-Geräte für Fernsehstudios haben aus o.g. Gründen auch höhere PWM-Raten oder werden gleich über den Strom gesteuert...

Ich brauch' das zwar nicht für Filmaufnahmen, aber soll ja schon "anständig" werden... ;o)

Zuerst hatte ich nur 64 Stufen für die PWM, da ist die Wiederholrate natürlich 4x höher, dafür wird's da wegen der geringeren Auflösung im unteren Bereich doch etwas, naja, stufig...

hier übrigens gleich noch ne kleine Optimierung (spart 6 Byte und 3-4 Taktzyklen), die Zeilen

[code:1] cpi PWM_Count, 255 ; bis 255 zählen lassen
brne PWM_R
clr PWM_Count

PWM_R:
[/code:1]

Kann man rausstreichen, da der Zähler ja bei 255 eh' überläuft und wieder bei 0 beginnt - das stammt eben noch aus der Zeiit, als da "64" statt "255" stand...

P.S.: Wenn Du Ideen hast, wie man das noch besser machen könnte, immer her damit!

Zitat von "photonz"

Das Auge ist analog... also nicht vergleichbar.

Erbsenzähler! - vielleicht hätte ich da auch schon nen Smiley hinmachen sollen....? - Die Aussage an sich stimmt so, das Auge ist zu träge, um das Flimmern wahrzunehmen, egal ob analog oder nicht... und wenn wir schon beim Haare spalten sind: Informationen werden in Nerven über Impulse weitergeleitet, die sich sowohl in der Stärke als auch in der Frequenz ändern können - genauer wäre es also eine Mischung aus analoger und digitaler Signalverarbeitung... :wink:

Zitat von "Fistandantilus"

Optimal wäre natürlich, wenn man nur ein Netzteil bräuchte.
Kannst du die Schaltung trotzdem mal reinstellen?

Man braucht auch nur ein Netzteil - hier sind's deswegen zwei: das µC-Board hat ein eigenes Netzteil, weil ich das auch für andere Sachen verwende, und damit ich es abstecken kann und nicht den ganzen Verhau mit hoch zum PC nehmen muss... da dieses Netzteil aber für die LEDs nicht mehr reicht, ist da noch ein eigenes vorhanden... man kann das schon alles an ein genügend starkes 5V-Netzteil hängen, wobei es bei den LEDs schon etwas knapp werden könnte, da an der KSQ ca. 2 V abfallen....

Schaltung mal hier:

[Blockierte Grafik: http://www.noisepop.de/led-for…/RGB-Fader-Schaltplan.jpg]

Zitat von "Fistandantilus"

Da ich mit µc bisher noch nichts weiter gemacht habe, eine kurze Frage. Muß der EEprom mit spezieller Harware geschrieben werden, oder reicht es, ihn direkt mit der RS232 zu verbinden?

Weder noch - das ist kein EEprom, sondern ein Mikrocontroller mit ISP-(In-System-Programming)-Schnittstelle... die ist auf meinem Plan mit eingezeichnet... (bei mir ist es ein 6-poliger Pfostenverbinder. Da kommt ein (am einfachsten) Kabel zum Parallelport dran (mal danach googeln), dann kann man das Teil mit PonyProg beschreiben...

Zitat von "LedBob"

Welche AVR-Studio Version verwendest du? Ich bekomme das Programm nur kompiliert wenn ich call durch rcall ersetzte.

Das ist die Version 4.13 mit Service Pack 2 - hab' ich vor drei Wochen runtergeladen... hat aber auch Ihre Fehler...

Zitat von "LedBob"

Was mir noch aufgefallen ist: Zum setzen des Timer-Interrupts müsste es doch
[code:1]ldi temp0, 0b00000010
out TIMSK, temp0[/code:1]

heissen oder? Ich benutze meistens diese Syntax:

[code:1]ldi temp0, (1<<TOIE0)[/code:1]

das ist weniger fehlerträchtig.

Alles anzeigen

Hm, ja, hast eigentlich recht - bei mir ist jetzt versehentlich der Output Compare Interrupt gesetzt, aber da das entsprechende Register leer ist, kommt' s auf (fast) das selbe raus wie ein Overflow... daher stammt auch das oben erwähnte "Problem" mit dem Interrupt-Vektor... :wink:

Und ich bin das von früher (da habe ich von Hand kompiliert) halt so gewohnt, dass ich gleich die entsprechende Zahl nehme statt Definition, da muss ich mich auch noch Umstellen - v.a. weil's das ja doch sehr erleichtert, wenn man das auf nen anderen µC portieren will.... Hab's jetzt mal umgeschrieben für's nächste Update...

Zitat von "LedBob"

Zum Fading schau mal hier:

http://www.mikrocontroller.net/articles/LED-Fading

Exponentielles Fading wirkt wesentlich natürlicher. Es reicht aber schon wenn man die Phasen geringer Helligkeit etwas verlängert.

Danke, das ist mir schon klar - steht ja auch auf meiner To-Do-Liste ("Dimmerkurve") - da das Ganze ja auch mal über DMX steuerbar sein soll, möchte ich die Korrektur "direkt an der Ausgabe" machen, nicht in der Fade-Routine... soll heissen dass z.B. 128 von den Werten her dann die halbe Helligkeit ist, damit's für's Auge auch halb hell erscheint, wird's nachher korrigiert, aber nicht schon in der Fade-Routine....

EDIT: ah, sorry, Synvox ist mir jetzt zuvorgekommen mit der Erklärung des Interrupts...

Synvox: gibt's da / Hast Du ne Formel zum Umrechnen von HSB in RGB...? - Das wollte ich nämlich später auch noch implementieren, aber möglichst ohne irgendwelche Tabellen... das müsste ja auch nicht wissenschaftlich exakt sein, halt näherungsweise...

Hi Neni,

vielen Dank! - da schau' ich mal, dass ich das in Assembler umschreibe...

Übrigens: Da hast Du schon recht mit deinem HSV-Farbmodell, nur habe ich hier ja nicht den Fall, dass ich eine bestimmte Farbe habe und die heller oder dunkler ohne Verschiebung des Hue haben will, sondern es ändert sich ja immer nur entweder R oder G oder B, die anderen Kanäle bleiben... von daher könnte das (zumindest hier) schon einfach mit einer Korrektur pro Kanal funktionieren...

Ich werde das mal mit einer zeibasierten Variante machen, so ähnlich wie von LedBob vorgeschlagen - Ich nehme einfach die Kanal-Helligkeit die sich grad ändert, ziehe diese von 255 ab, und nehme das als Start für die Warteschleife... d.h. je heller die Farbe, desto kürzer läuft die Schleife, desto schneller ändert sich die Intensität...

Ein Problem wird bleiben: wegen der "höheren Augen-Empfindlichkeit" bei kleineren Helligkeiten werden die ersten paar Werte wohl trotzdem etwas "abgestuft" aussehen... hier müsste man wohl die Ausgangs-Werte 0-255 in z.B. 10-Bit-PWM-Werte umrechnen... da wird's mit der Software-PWM dann aber schon mau... (ca. 60 Hz)

Die Formeln bei Wikipedia sind wirklich etwas... naja - Interessant ist aber dieses Bild hier.

Da ist oben ein schöner "Regenbogen" (Es ist natürlich kein Regenbogen, nicht dass Photonz wieder "meckert" :wink: , und unten die zugehörigen RGB-Werte - und das sind genau die Kurven, die mein Programm erzeugt... ich finde ja den Farbwechsel an sich schon recht harmonisch, das einzige ist, dass der Übergang zwischen "Aus" und "ganz leicht an" manchmal etwas abrupt erscheint (je nach Farbe)...

Das ist schon seltsam mit der Farbwahrnehmung - z.B. kann ich ja mit den Dip-Schaltern 7 Farben einstellen (wenn man weiß dazu zählt), aber kein Orange - und das ist schon ne wichtige Farbe (für mich jedenfalls) - Und auch die einzige Zwischenfarbe, die nen "richtigen Namen" hat...

Wenn man die Farben mal so durchschaltet, werden wohl die wenigsten die Zwischenstufe zwischen Magenta und Blau ("Dunkelviolett"..?) oder Grün und Cyan ("Bläuliches Hellgrün"...?)vermissen, aber viele werden nach Orange fragen, weil das ne "richtige Farbe" ist...

Ebenso wie diese Aculed (und auch viele 4er-Bar-Lichtanlagen) mit Rot, Grün, Gelb und Blau bestückt sind... wobei Gelb die einzige Mischfarbe ist... anscheinend ist es so, dass man in dem Bereich zwischen Rot und Grün Farben am besten unterscheiden kann, bzw. es am meisten vermisst, wenn ne Mischfarbe aus diesem Bereich fehlt....?

Übrigens, Neni, LedBob: Ich habe durch Eure Beiträge hier den Eindruck gewonnen, dass Ihr hier die AVR-Spezialisten seid (Ernst gemeint) - vielleicht kann mir einer zwei leicht o.T.-Fragen beantworten:

Welcher ist denn der Nachfolger vom Atmel 89C2051..? ist das der Mega8? - ich brauche da was, um einen 89C2051 in einer bestehenden Schaltung pinkompatibel zu ersetzen...

Und, diese Frage habe ich schon mal gestellt, blieb bis jetzt unbeantwortet: In einer Übersicht habe ich gelesen, dass der ATTiny 48 6 hardware-PWM-Kanäle hat, aus dem Datenblatt werde ich aber nicht ganz schlau, ob das nun so stimmt... ich wollte halt den nehmen, um zwei RGB-Leuchten unabhängig voneinander jeweils mit Hardware-PWM anzusteuern, geht das mit dem..?

Ach, Fistandantilus, das habe ich in meinem letzten Beitrag vergessen: bei dem Schaltplan, den Teil in dem gestricheltem Kastl brauchst Du natürlich insgesamt 3 mal....

Zitat von "synvox"

Die Funktion hat eigentlich genau den umgekehrten Zweck, nämlich Hue und Sättigung zu verändern, ohne die Gesamthelligkeit zu beeinflussen. Obwohl sie Color_set heisst ist sie für dynamische Zwecke konzipert . Im Prinzip bekommst du den gleichen wunderbaren Regenbogen wie bei dir, wenn du z.Bsp. Sättigung auf 255 stellst und in einer Schleife den Hue von 0 bis 1529 (und wieder von vorne) durchläufst und bei jedem Schleifendurchlauf Color_set aufrufst.

Hm, ja, das mit dem Umrechnen (dass das auch dynamisch geht, war mir schon klar ;o) brauche ich dann später, weil ich bei diesem DMX-Dimmer einen Modus einbauen will, in dem man am Lichtpult nicht R,G,B einstellt, sondern eben H,S und B - weil es einfacher ist: ich such' mir ne Farbe aus, dann die Sättigung und Helligkeit dazu, und muss nicht erst überlegen, welche RGB-Werte z.B. "Flieder" haben muss...

Aber um nochmal sicher zu gehen, mit der Gesamthelligkeit: Bei mir ist (Royal)Blau die dunkelste Farbe... das würde dann bedeuten, dass Deine Routine z.B. Gelb dran anpasst (dass es "gleich hell" aussieht), dass das also nicht 100% R und 100% grün ist, sondern gedimmt, damit es eben nicht heller als das Blau wirkt...? - Da ist's mir aber so wie momentan ehrlich gesagt lieber, das soll ja auch in der Helligkeit je nach Farbe schwanken (also dass Gelb z.B. mehr "reinknallt" als Blau)

Zitat von "synvox"

Das kannst du so gar nicht sagen. Obwohl er auch von Atmel ist, beruht der 89C2051 auf einem ganz anderen Kern als die AVRs. Der 89C2051 ist ein Vertreter der vor zwei bis drei Jahrzehnten begründeten CISC-µC-Reihe von Intel (8031 bzw. 8051). In der Folge hab.....

F***k, das ist blöd - mit 8051 hatte ich vor 15 Jahren zuletzt zu tun... wie's da softwaremäßig aussieht, keine Ahnung - ich habe ja die Vermutung, dass das Teil nicht mal nen ISP-Port hat und wohl eh' schreibgeschützt wäre... drum wollt ich da einfach nen Mega8 reinmachen, müssen halt nur die Pins passen (Pinout vom AT89 hab' ich schon gefunden, muss mal vergleichen)... es handelt sich - Oh Wunder! ;o) - um einen kleinen RGB-Scheinwerfer, der eben die Fader-Software verpasst bekommen soll.... keine Ahnung, wo der Hersteller noch nen Restposten von den AT89 aufgetrieben hat, die Leuchte ist relativ aktuell....

Zitat von "synvox"

Du meinst wahrscheinlich den ATmega48 (ATtiny48 gibt's nicht), und ja, der hat 6 Hardware-PWM-Kanäle verteilt auf drei Time...

Ja, war ein "Verdenker", natürlich meine ich Mega48.. ;o) - vielen Dank für die Info! Und für den Link auf Deine Seite, wieder Zeit gespart, da brauch ich nicht erst nach der Pinbelegung suchen....

EDIT: habe Ersatz für den AT89 gefunden... zuerst mal bei den Pins verzählt (mega8 hat ja 28)... ;o) Hat sich jetzt rausgestellt, dass ein ATtiny2313 von der Pinbelegung da rein passt... sehr gut, mit dem wollte ich mich eh' auch noch beschäftigen...

So, es gibt ein Update mit Frage und eine Erklärung zur PWM - da wurde nochmal nachgefragt...

Ich habe ein paar Verbesserungen gemacht, und wollte das nun als "Version 2 " abspeichern - also einfach Speichern unter, neuer Name "RGB-Fader-2.asm" im selben Ordner...

Nur zeigt's mir das jetzt nicht in dem "Project"-Fenster unter "Source Files" an, und wenn ich es kompiliere, heisst das HEX-File immer noch "RGB-Fader.hex" - ohne "-2"...

Das kann doch nicht sein, dass ich da jetzt ein neues Projekt anlegen muss...? - Wie bekomme ich die neue .asm-Datei in das Projekt rein? - Habe leider nichts gefunden...

Und zur PWM, die funktioniert folgendermaßen:

Der Timer0 läuft immer in einer Schleife, aber nicht DIREKT für die PWM (die ist ja per Software, ich benutze nicht die PWM-Funktion des Timers!).

Er löst einfach alle 256 Durchgänge (62.500 mal in der Sekunde) einen Interrupt aus, dadurch springt der µC in die Interrupt-Routine:

[code:1]; ------------------------------------------------------------------------------------------------
ISR_PWM: ; PWM-Ausgabe

push temp0
push temp1 ; Statusregister + Temp0 sichern
in temp1, SREG

ldi temp0, 0b00000111 ; Grundzustand 1 = LED an, 0 = LED aus (wegen FET)

inc PWM_Count ; den PWM Zähler erhöhen

PWM_R:

cp PWM_Count, R ; Ist der Grenzwert für Rot erreicht?
brlo PWM_G ; nein, weiter zu grün
andi temp0, 0b00000110 ; ja, LED Rot aus

PWM_G:

cp PWM_Count, G ; Ist der Grenzwert für Grün erreicht?
brlo PWM_B ; nein, weiter zu Blau
andi temp0, 0b00000101 ; ja, LED Grün aus

PWM_B:

cp PWM_Count, B ; Ist der Grenzwert für Blau erreicht?
brlo PWM_Ausgabe ; nein, weiter zur Ausgabe
andi temp0, 0b00000011 ; ja, LED Blau aus

PWM_Ausgabe: ; Neue Bitbelegung ausgeben

out PORTA, temp0

out SREG, temp1 ; Statusregister + Temp0 wiederherstellen
pop temp1
pop temp0

reti [/code:1]

Hier wird das Register PWM_Count erhöht. Da es bei einem Überlauf (größer 255) wieder auf Null gesetzt wird, zählt das also ständig in einer Schleife von 0 bis 255 hoch... eine Schleife läuft 244 mal in der Sekunde durch, also PWM-Frequenz 244 Hz.

Das einstellen des Taktverhältnisses geschieht nun durch einen Vergleich von PWM_Count mit der entsprechenden Farbe (z.B. "R").

Dazu wird erst mal in temp0 das Bitmuster 00000111 geladen - heisst alle 3 LEDs (sind an PINA0 - PINA2) AN (aber noch nicht "in echt, erst mal nur "gemerkt").

Als nächstes sind die drei Zeilen wichtig:

[code:1]
cp PWM_Count, R ; Ist der Grenzwert für Rot erreicht?
brlo PWM_G ; nein, weiter zu grün
andi temp0, 0b00000110 ; ja, LED Rot aus[/code:1]

Das heisst, falls der Zähler unter dem Wert für Rot ist (z.B. R=187, PWM_Count=100), passiert gar nix, es geht weiter zur selben Abfrage für grün... die LED bleibt also an.

Ist der Zähler aber gleich oder höher (wieder Beispiel, R=187, der Zähler ist auch bei 187 angelangt), wird eine Und-Verknüpfung mit temp0 und 0b00000110 ausgeführt, Bit 0 (für Rot) wird also gelöscht, die anderen bleiben unangetastet (Es geht hier ja nur um Rot).

D.h. in dem Beispiel bleibt von PWM_Count 0 bis 186 die Rote LED an, von 187 bis 255 ist sie aus - so wird das Taktverhältnis eingestellt...

Die selben Abfragen gibt's dann noch für Grün und Blau...

Und da das Ganze ja erst im temp0 zamgebastelt ist, muss es noch ausgegeben werden, damit die LEDs dann wirklich machen, was sie sollen:

[code:1] out PORTA, temp0[/code:1]

Dann werden noch die gesicherten Register wieder hergestellt, und die ISR beendet.

Beim nächsten Interrupt dann das selbe Spiel von vorne: PWM_Count erhöhen, mit den Farb-Registern vergleichen, ggfs. Bit löschen und am Schluß das Ganze dann an PORTA ausgeben...

Zitat von "LedBob"

Rechtsklick auf Source Files - "Add Files to Project". Und dann Rechtsklick auf die neue Datei und "Set as Entry File". Einfacher ist's vermutlich das als neues Projekt abzuspeichern....

Hey, super, vielen Dank! - Hat ganz easy funktioniert - einfacher als ein neues Projekt anzulegen... ausserdem wär's ja doof, für die selbe Sache in leicht geänderter Version schon wieder ein anderes Projekt zu haben...

Kleines Update:

- Es gibt einen neuen, sauber gezeichneten Schaltplan (unten)

Fistandantilus: falls Du hier noch mitliest, ich habe bei dem alten Schaltplan Blödsinn erzählt, auf dem Geschmiere (ist schon ersetzt) war die besagte ISP nicht dabei (einfach vergessen)... hier ist sie nun aber drin:

[Blockierte Grafik: http://www.noisepop.de/led-forum/RGB-Fader/RGB-Fader-Schaltplan.jpg]

das ist das gelbe Teil - eine 2x3-Pfostenleiste, einen Stift habe ich entfernt, im Stecker ein Loch zugeklebt, dass man das nicht verkehrt herum draufstecken kann... Stecker siehe unten... Das Kabel geht dann zu nem Parallelport-Stecker, da sind noch 4 Widerstände drin....

Schaltplan dafür gibt es dutzenderweise im Netz - von 2-4 Widerständen mit div. Werten...

Zum Programmieren (also Software schreiben) brauchst Du dann noch AVR Studio oder Bascom, um die Daten dann auf den Chip zu bekommen und Fusebits zu setzen z.B. Ponyprog... das (und Anleitungen dazu) gibt's auch alles im Netz (z.T. auch hier), ich habe das damit auch auf einen Abend - ohne nachfragen zu müssen - geschafft...

Ausserdem hat die Software nun mehr Funktionen:

- es gibt einen Schalter, mit dem man grün auf "halb" schalten kann, um Orange zu erzeugen... lustig: ich war letzten Samstag als LJ in ner Disco gebucht, da hatten Sie in der Steuersoftware sowohl für die LEDs, wie auch Scanner und Washlights, neben den Grundfarben rot, grün, blau, cyan, magenta, gelb (und weiß) eben auch - Orange - als Schnellzugriffs-Pads definiert... das stützt irgendwie meine "Orange-These" von weiter oben :wink:

- Da die Rebel-Sterne einen Rosastich haben, wird der Sonderfall "weiß" abgefragt, hier wird dann rot etwas zurückgenommen... läßt sich auch abschalten

- über die letzten zwei Schalter läßt sich die Geschwindigkeit des Fadens in 4 Stufen einstellen...

- Es gibt einen Strobo-Effekt, also die eingestellte Farbe blitzt dann - Geschwindigkeit ebenfalls in 4 Stufen einstellbar...

- Für den Fader ne Zeitkorrektur, dass der "harte" Übergang, wenn eine Farbe nahe Null ist, etwas gemildert wird - zum Umbau der HSV-Routine von synvox bin ich leider noch nicht gekommen...

- Und ein neuer Modus namens "Disco" - hier gibt es einfach "wüstes buntes Geblinke" - der funktioniert aber noch nicht richtig, daher steht die Software hier noch nicht drin... wenn sie fertig ist, gibt's nen Link zum download...

Als nächstes gibt's dann noch ne Version, bei der man die Programme per Taster durchschalten kann, dann ist der "RGB-Fader mit Zusatzfunktion" an sich erst mal fertig... Bestandteile davon werden dann bei meinem 24-Kanal-Dimmer weiterverwendet.... in ("ferner") Zukunft kommt an den Fader evtl. noch ne IR-Schnittstelle für einfache Fernbedienung....

jetzt muss ich aber echt in's Bett - Gute Nacht, der Pesi