Universeller Controller mit ATmega8

Zitat von turi

Orca hatte hier im Forum den Wunsch, die RGB-Farben in der Helligkeit bei Farbtreue zu dimmen. Dies habe ich experimentell schon mal aufgebaut. Allerdings stößt man da teilweise an technische Grenzen. Aber die Ergebnisse waren z.T. besser als erwartet. Wenn ich z.B. einen gelben Farbton einstelle, kann ich die Helligkeit dessen sehr gut dimmen. Es hängt eben immer von der jeweiligen Farbzusammensetzung ab und davon, wie die Dimm-Strategie im Programm arbeitet.

Hallo,

hört sich gut an.
Ich habe mir zur oberen Problematik auch schon zwei drei Gedanken gemacht. Ich kam nur zum Ergebniss das prozentuall zu dimmen(runterzu fahren) , hatte es noch nie programmiert. Fänd es toll wenn du vielleicht über das Thema noch paar Wörter verlieren könntest, da hab ich sehr großes interesse dran.

MfG

Zitat von turi

Es gibt wie gesagt beim farbechten Dimmen technische Grenzen. Wenn z.B. die Farbe sich aus den Prozentwerten 80/60/10 zusammen setzt, kann man nur so lange einigermaßen farbgetreu dimmen, bis eine Farbe auf Null geht.

Ich hätte mir das so vorgestellt, dass man eine Farbe mit den 3 Kanälen(PWMs) einstellt und dann eine PWM vor die 3 Kanäle hängt und mit der dann dimmt. Allerdings habe ich keine Ahnung wie sich PWMs in Serie verhalten und ob das überhaupt möglich ist. Jedenfalls wäre es in diesem Fall auch egal, wie viele Schritte bis Null die jeweilige Farbe noch hat.
Ich hoffe ihr könnt verstehen wie ich das meine!?

lg
Simon

Ja, so funktioniert das

Die Farbe hängt ja vom *Verhältnis* der drei Grundfarben ab, dieses muss gleich bleiben - sehe ich das richtig, dass bei Dir, wenn Du z.B. diese 80/60/10 um 10 runterdimmst dass dann 70/50/0 rauskommt...? - und wenn's noch mal um 10 runtergedimmt wird, dann 60/40/0....? - dann kann das nicht funktionieren, weil Du ja das Verhältnis der Farben untereinander änderst.

Bei mir werden die Grundfarben mit dem Dimmer-Wert multipliziert - dabei bleibt das Verhältnis gleich, da R:G:B mal Dimmer = R mal Dimmer : G mal Dimmer : B mal Dimmer - dabei gehen sowohl die Farben wie der Dimmer-Wert jeweils von 0 - 255, weil der µC direkt damit rechnen kann - für den Dimmer (was Du als "Faktor" bezeichnest) 0-1 zu nehmen, wäre eher ungeschickt/unmöglich, weil der µC ja nur mit ganzen Zahlen rechnen kann (direkt, intern, k.A. ob's in C auch Fließkomma-Rechnungen gibt, aber die werden wenn dann auch nur irgendwie emuliert und sind eher ungenau...)

da hier (bei mir) dann Werte bis 65.025 (255 x 255) rauskommen, wird anschließend wieder durch 255 geteilt (EDIT: OK, damit kommt das unterm Strich auf's selbe raus, wie wenn ich die Kanäle mit einem Wert zwischen 0 und 1 multiplizieren würde ;)), damit ich wieder auf 0-255 pro Kanal (8-Bit-PWM) komme... (also die PWM-Werte, 255 = 100%) - wenn man 16-Bit-PWM nehmen würde, könnte man diese Werte direkt benutzen, hätte dann auch ne höhere Auflösung... bei mir wird's halt schon etwas arg abgestuft, wenn sowohl Dimmer als auch Farbwert sehr niedrig sind...

*ganz exakt* funktioniert das auch nicht, da ich aus programmiertechnischen Gründen durch 256 teile, ausserdem gibt's ja Rundungsfehler, z.B. wenn Blau den Wert 2 hat und auf 2 gedimmt wird, dann kommt 0 dabei raus, ebenso wie wenn es 2 hat und auf 120 gedimmt ist - also z.B. die Farbe 255/255/2 (gelb mit klitzekleinem Blau-Anteil) auf 25% (64) gedimmt ergibt 63/63/0, also gelb ganz ohne Blau - nur, 2 Blau bei 255 rot und grün fällt eh' unter den Tisch...

schwieriger ist das bei Dir, weil Du die PWM mit Helligkeitskorrektur benutzt - die ist ja *pro Kanal* und haut Dir damit die Verhältnisse auch wieder durcheinander - musst Du mal ausprobieren, wie stark sich das auswirkt - wenn der Effekt zu krass ist, dann müsste man die Korrektur nur auf den Helligkeitskanal anwenden, und anschließend die korrigierte Helligkeit mit den Farbkanälen verrechnen, diese dann ohne Korrektur ausgeben...

aber so (multiplizieren) wird's auf jeden Fall schon mal *wesentlich* besser, als nur die einzelnen Kanäle jeweils um den selben (EDIT: Absolut-)Wert rauf- und runterzudrehen...

Nochmal EDIT: aber schönes Gerät übrigens! - und da stimme ich Dir zu, für sowas (Helligkeit rauf- und runterstellen etc.) sind Potis echt schöner als Taster - ich baue (nebenbei, neben x anderen Baustellen) auch so nen kleinen RGB-Controller, da aber mit Encoder statt Poti... jedenfalls halt auch zum drehen statt drücken...

Das klingt, als ob ihr nach nach dem HSV-Farbraum sucht
HSV Farbraum in Bascom per Wii-Nunchuck nutzen

Der Bascom-Code ist kommentiert...

nee, nee, denn kenn ich schon - hier geht's (zumindest vom Ansatz her) um was anderes: eine eingestellte Farbe (hier in RGB) *nochmals* in der Helligkeit *extra* zu dimmen, und das geht nur mit einem 4. ("Dimmer")-Kanal, mit dem man diese Werte multipliziert. So wie bei meinem DMX-Receiver auch.

Da hat das einen bestimmten Grund, dass da (bei mir) nochmal ein extra Dimmer-Kanal dabei ist (den man ja "eigentlich" nicht braucht): Es erleichtert wesentlich die Programmierung einer Lightshow - ich kann z.B. ein Bild erstellen mit 4 Leuchten nebeneinander, die erste hat 25% Blau, die 2. 50%, die 3. 75% und die 4. 100% - nun kann ich mit einem 4. Kanal (Gesamtdimmer) dieses komplette "Bild" heller und dunkler machen - oder es läuft ein Rainbow-Fader synchron auf allen 4 Leuchten, es sind aber nicht alle immer an, sondern "springen" hin und her - da mache ich einen Fader, der die Farbkanäle für alle Leuchten synchron ändert, und ein 2. Programm ändert die Dimmerkanäle so, dass die Leuchten an- und ausgehen - unabhängig voneinander... wenn alle 4 leuchten sollen, ziehe ich bei allen 4 den Dimmer-Kanal hoch, aber das Programm, das die Farben steuert, bleibt das selbe...

mit HSV würde das nicht gehen, ausser man macht da auch einen 4. Kanal, den man dann nur mit V verrechnet... das wäre dann "das selbe in grün"

Aber, Stefan, das war ein guter Hinweis mit dem Farbraum, weil das wäre für Dich, Turi, eigentlich besser geeignet - Du willst ja keine Lightshow programmieren, sondern eine Farbe und deren Helligkeit einstellen - und da ist HSV wesentlich intuitiver (wohl auch ein Grund, dass dieses Philipps-Teil recht beliebt ist): Du stellst einen Farbton ein (z.B. Orange) und den dann in der Sättigung (von "kräftig" über Pastell bis weiß) und in der Helligkeit - das ist viel besser, als mit RGB rumzumachen ("welche RGB-Werte hat gleich noch mal Flieder"..?) - und ausserdem brauchst Du nur 3 Potis (Farbton, Sättigung, Helligkeit) statt 4 (RGB + Dimmer)...

Schau' Dir doch das vom Stefan mal an - das sollte sich auch in C umsetzen lassen - im wesentlichen sind das auch nur Multiplikationen und Divisionen, womit HSV letztlich wieder in RGB umgerechnet wird... Die Formeln dazu gibt's auch bei Wikipedia...

Ansonsten: Auch in C geht das ganz einfach und macht Sinn, erst mal zu multiplizieren und dann wieder zu teilen, weil's der Prozessor intern dann auch so macht - also auch, wenn man in C mit Kommazahlen (z.B. einen Wert mit 0,7 multiplizieren) rechnen kann/könnte (weiß nicht, ob das geht...?), der Prozessor selbst kann das nicht, also wird das dann letztlich auch wieder so umgesetzt.....

Und, richtig, die Korrektur macht bei RGB oder HSV nicht so viel Sinn, wie bei einer weißen LED rauf- und runterdimmen - wie gesagt, bei HSV könnte man diese Korrektur dann im Helligkeitskanal anwenden - Prinzip hast Du ja verstanden: Du bekommst einen Wert vom Poti, schaust dann in der Tabelle nach, da kommt dann ein Helligkeitswert raus, den Du für Deine HSV-in-RGB-Umechnung benutzt...

EDIT: ach, übrigens, Orca, das mit dem 2 PWMs überlagern würde schon auch gehen, da muss halt nur eine davon eine wesentlich höhere Frequenz als die andere haben - also theoretisch, bei nem AVR auf drei Ausgängen die RGB-Werte mit 244 Hz SW-PWM ausgeben, und auf einem HW-PWM-Kanal die Helligkeit mit 64 kHz, das Ganze mit nem AND-Glied verknüpft, dann werden die "an"-Phasen der Farben nochmal in 256 Stufen "zerhackt" und damit nochmals gedimmt... kommt dann unterm Strich von der Auflösung her auch auf das selbe raus wie ne 16-Bit-PWM - aber ist EMV-technisch usw. nicht mehr so einfach, mit 64 kHz...

Hach, ich propagiere ja schon seit je her den HSB-Farbraum (resp. HSV-Farbraum) .

Ich habe mir mal die Mühe gemacht, einen C-Code für die Umrechnung hier zu posten, und zwar so, dass nur maximal 16-Bit-Integer (signed oder unsigned) verwendet werden, und dass keine Divisionen durchgeführt werden (Divisionen werden durch Right-Shifts ersetzt). Wenn der C-Compiler auch noch optimiert, dann ersetzt er einen 8-fachen Right-Shift im resultierenden Assembler-Code sogar noch dadurch, dass er einfach nur das High-Byte der entsprechenden Variable weiter verwendet. Ganzzahl-Multiplikationen sind bei den Mega-AVRs grundsätzlich sehr schnell in der Verarbeitung, da hier eine Hardware-Implementation vorhanden ist. Für den Hue-Wert (Farbkreis) ist jeweils mit dem angegebenen Wertebereich zu arbeiten, da sonst in der Umwandlungsfunktion zusätzliche Faktor-Berücksichtigungen nötig sind. Wenn ein Hue-Wertebereich von 0 - 255 gewünscht ist, sollte man den hue-Wert dann vor der Umwandlungsfunktion entsprechend mit 6 (Fall 1) oder mit 3 (Fall 2) multiplizieren, das ist auf jeden Fall zeitsparender.

Fall 1: Hier ist die klassische Umwandlung.
hue (Farbkreis) = 0 bis 1529, sat (Sättigung) = 0 bis 255, bri (Helligkeit) = 0 bis 255; alle Variablen unsigned int (word).

if (hue > 1529) hue = 0;


if (hue < 255) {
   red_val = 255;
   green_val = (65280 - sat * (255 - hue)) >> 8;
   blue_val = 255 - sat;
}
elseif (hue < 510) {
   red_val = (65280 - sat * (hue - 255)) >> 8;
   green_val = 255;
   blue_val = 255 - sat;
}
elseif (hue < 765) {
   red_val = 255 - sat;
   green_val = 255;
   blue_val = (65280 - sat * (765 - hue)) >> 8;
}
elseif (hue < 1020) {
   red_val = 255 - sat;
   green_val = (65280 - sat * (hue - 765)) >> 8;
   blue_val = 255;
}
elseif (hue < 1275) {
   red_val = (65280 - sat * (1275 - hue)) >> 8;
   green_val = 255 - sat;
   blue_val = 255;
}
else {
   red_val = 255;
   green_val = 255 - sat;
   blue_val = (65280 - sat * (hue - 1275)) >> 8;
}

Fall 2: Hier ist die Umwandlung auf möglichst gleichbleibende Lichtemissionsleistung (mW, nicht Lumen) der Farben normalisiert (Die Summe der RGB-Werte darf max. 255 betragen). Diese Umwandlung verwende ich bei meinen RGB-Wall-Modulen, vor allem um Gesamtstrom zu sparen, aber auch das allgemeine Erscheinungsbild der Animationen scheint mir dadurch homogener zu wirken. Der Preis ist aber eine verringerte Anzahl der theoretisch maximal darstellbarer Farben, und zwar ca. 85^3 + 127^2 + 256 = 630'510, und eine leicht verlängerte Berechnungsdauer. Bei Einzel-RGB-Lichtquellen (oder generell wenigen nicht flächig angeordneten Lichtquellen) ist es aber nicht unbedingt von Vorteil, dieses Verfahren zu verwenden.
hue = 0 bis 764, sat = 0 bis 128, bri = 0 bis 255; alle Variablen signed int (signed ist hier wichtig).

if (hue > 764) hue = 0;


if (hue < 255) {
   red_val = (10880 - sat * (hue - 170)) >> 7;
   green_val = (10880 - sat * (85 - hue)) >> 7;
   blue_val = (10880 - sat * 85) >> 7;
}
elseif (hue < 510) {
   red_val = (10880 - sat * 85) >> 7;
   green_val = (10880 - sat * (hue - 425)) >> 7;
   blue_val = (10880 - sat * (340 - hue)) >> 7;
}
else {
   red_val = (10880 - sat * (595 - hue)) >> 7;
   green_val = (10880 - sat * 85) >> 7;
   blue_val = (10880 - sat * (hue - 680)) >> 7;
}

Für beide Fälle gelten die gleichen Formeln für die Berücksichtigung des bri-Wertes (Brightness; Helligkeit). Der bri-Wert könnte natürlich noch vor der Applikation in den Formeln aus einer Exponentialtabelle (zur linearisierung des Helligkeitsempfindens) herausgelesen werden, wenn man das will.

red = ((bri + 1) * red_val) >> 8;
green = ((bri + 1) * green_val) >> 8;
blue = ((bri + 1) * blue_val) >> 8;

Ich hoffe, das alles nützt jemandem was .

Gruss
Neni

Sehr schön, Neni macht's wieder sehr ausführlich!

die letzte Berechnung ist ja dann die selbe wie von mir oben erläutert, die RGB-Werte mit der Helligkeit verrechnet, damit man diese noch gesamt beeinflussen kann - OK, Du addierst zuerst noch 1 zur Helligkeit dazu, das könnte ich eigentlich auch mal machen, um wieder auf 0 - 255 zu kommen (bei mir ja nur 0 - 254)

also im Endeffekt dimmst Du dann genauso wie ich die Gesamthelligkeit per Multiplikation der RGB-Werte mit dem Helligkeitswert, hier kommt halt *davor* noch die Umrechnung von HSB in RGB...

Zitat von synvox

... Bei meiner RGB-Wall-Plasma-Software ist Fliesskomma erforderlich, da ich trigonometrische und andere, komplexe Berechnungen benötige, ...

Zumindest die trigonometrischen Funktionen bekommt man aber auch mit Ganzzahlen und einer Tabelle hin. Das braucht sogar weniger Speicher, weil Tabelle und Code kleiner ist, als die entsprechenden Fließkommafunktionen.

Ja klar, aber die Spannweite der Zahlen in den Zwischenresultaten der verwendeten Formeln sind relativ gross, so dass sich Fliesskomma geradezu aufdrängt. Ausserdem wollte ich das Rad nicht neu erfinden bzw. irgendwelche eigenen Implementationen 'ausprobieren', wenn ja sowohl in BASCOM als auch in den gängigen C-Compilern für AVR entsprechende, gut funktionierende Fliesskomma-Libraries vorhanden sind, wärend Ganzzahl-Implementationen von Trig-Funktionen und anderen zumindest standardmässig nicht vorhanden sind. Und nicht zuletzt war eben für meinen Anwendungsfall (gewünschte Frame-Rate) die Geschwindigkeit der Berechnungen pro Frame mehr als ausreichend (auch wenn ein Sinus so um die 2000 Taktzyklen benötigt), so dass sich jegliche Gedankenspiele von Spezialimplementationen erübrigten. Hätte es nicht gereicht, hätte ich andere Wege gesucht.

Aber eigentlich ist das ja OT in diesem Thread.

Gruss
Neni

Zitat von Pesi

also im Endeffekt dimmst Du dann genauso wie ich die Gesamthelligkeit per Multiplikation der RGB-Werte mit dem Helligkeitswert, hier kommt halt *davor* noch die Umrechnung von HSB in RGB...

Ja genau, bzw. wird eben vorher HS (ohne B bzw. bei B = 255) in RGB und danach noch B in RGB gewandelt. Das hat sich als code-sparender und schneller erwiesen, als B auch noch in die Formeln in der If-Kette einzubeziehen.

Gruss
Neni

Hab mal ne Frage zur Platine: Wo hast du die denn anfertigen lassen, und was wurde dafür berechnet?

mfg
Tommy