Code für RGB Steuerung

08flyer schrieb:
> RGB Fading Steuerung
Kannst du das genauer spezifizieren? Eine Art rainbow-LED?

Ja, aber leider nur in PIC-asm. Vllt. kann ich den relevanten teil kurz 
übersetzten...

Such mal nach moodlight

Was genau verstehst du unter RGB-Fading.

Die Sache ist nämlich die, dass man selbstverständlich zwischen 2 
RGB-Datensätzen hin und her faden kann. Aber eigentlich liefert das 
Zwischenfarben, die nicht so wirklich dem entsprechen, was man nach 
landläufiger Meinung unter einem "Farbübergang" versteht.
Das liegt daran, dass es bei RGB keinen dezidierten Parameter gibt, der 
dem Konzept einer "Farbe" entspricht.
Daher werden derartige Farbüberblendungen normalerweise nicht im 
RGB-Raum gemacht sondern in einem anderen Farbschema, zb. HLS und dann 
die Zwischenstufen einzeln nach RGB transformiert.

Alternativ kann man sich auch ein einfaches RGB Schema zurecht legen, 
welches den Farbraum Rot->Grün->Blau->Rot in zb 360 Werten abbildet und 
näherungsweise einen Farbkreis ergibt, in dem man wiederrum relativ 
leicht zwischen 2 Farben überblenden kann. Das stimmt zwar nicht 
wirklich und ist einem HLS Zwischenschritt unterlegen, allerdings ist 
das auch nur theoretisch, da die meist verwendeten RGB LED sowieso nicht 
kalibriert sind und sich die theoretische Farbe auch nur angenähert aus 
den RGB Werten ergibt. Denn welches Rot ist den schon das richtige Rot? 
Für normale Farbübergänge, die entlang eines Farbkreises ein Rot in ein 
Grün überblenden sollen reicht diese genäherte Version vollkommen aus.

Den Code finde ich nicht mehr, wahrscheinlich auf der externen HDD die 
ich zu Hause habe. Ich weiß aber noch dass ich mich an dieser Site 
orientiert habe: 
http://www.ulrichradig.de/home/index.php/projekte/hsv-to-rgb-led

08flyer schrieb:

> der meinung bin ich auch, dass es so vollkommen ausreicht. so genau muss
> es ja nicht sein :)


Das ist dann nicht weiter schwer. Mehr als lineare Interpolation 
zwischen 2 Werten muss man dazu nicht können.

(siehe Bild)

Man teilt sich den 360 Farbkreis in 6 Abschnitte auf. In jedem Abschnitt 
wird irgendeiner der 3 Farbkanäle auf bzw. abgedimmt. Kennt man also die 
Farbnummer seiner Farbe, dann kann man ganz leicht bestimmen, wie die 
zugehörigen RGB Werte sind.

Beim Wert 0, den ich mal willkürlich als Rot angenommen habe, hat man 
also Rot. Mit steigenden Nummern kommt immer mehr Grün dazu, bis Grün zu 
100% aufgedreht ist. Man ist also bei der 60 angelangt und die Farbe, 
die man jetzt sieht (na ja, mehr oder weniger) ist Gelb. Bei einem 
Farbwert von 30 wäre also Rot immer noch bei 100% während Grün bei 
lediglich 50% dahin dümpelt. Blau ist dabei die ganze Zeit bei 0.

Der nächste Abschnitt ist der Übergang Gelb nach Grün, bei dem Grün auf 
100% bleibt, während Rot linear abnimmt (Blau ist die ganze Zeit auf 0).

Und so geht es weiter. In jedem der 6 Abschnitte wird eine der 3 Farben 
von 0 bis zu 100% aufgezogen bzw. von 100% bis auf 0 runtergezogen.

und das wars dann auch schon.

Nach allen 6 Abschnitten, die ich recht willkürlich mit jeweils 60 
Einheiten angenommen habe, landet man wieder bei Rot.

die 60, bzw. die 360 für einmal rundum sind recht willkürlich und 
stammen einfach nur daher, dass ein Kreis 360° hat. Aber im Grunde kann 
man das alles auch mit anderen Zahlen machen. Insbesondere mit Zahlen, 
die man dann komplett ohne lineare INterpolation mehr oder weniger 
direkt als PWM Werte benutzen kann.

Schreib dir eine Funktion, der du die Farbnummer 0 bis 359 übergibst und 
die dir die zugehörigen RGB Werte ausrechnet. Ist nicht weiter schwer

1

void toRGB( uint16_t color, uint8_t* red, uint8_t* green, uint8_t* blue)

2

{

3

  if( color <= 60 )

4

  {

5

    *red = 255;

6

    *green = interpolate( color, 0, 255 );

7

    *blue = 0;

8

  }

9

10

  else if( color <= 120 )

11

  {

12

    *red = interpolate( color - 60, 255, 0 );

13

    *green = 255;

14

    *blue = 0;

15

  }

16

17

  else if( color <= 180 )

18

  {

19

    *red = 0;

20

    *green = 255;

21

    *blue = interpolate( color - 120, 0, 255 );

22

  }

23

24

  ....

Die Funktion interpolate musst du natürlich noch schreiben.
Sie macht nichts anderes als eine Zahl im Bereich 0 bis 59 auf die 
jeweils angegebene Gerade umzumappen. Aber das ist nicht weiter schwer. 
Ist einfach nur eine lineare Gleichung, die auf die 60 Intervallbreite 
abgestimmt ist.

1

uint8_t interpolate( uint16_t value, uint8_t intervallStartValue, uint8_t intervallEndValue )

2

{

3

  ....

4

}

Mike schrieb:
> Karl Heinz schrieb:
>> Aber das ist nicht weiter schwer.
>> Ist einfach nur eine lineare Gleichung, die auf die 60 Intervallbreite
>> abgestimmt ist.
>
> Dann wäre es doch viel einfacher, den Kreis auf 6*256=1536 aufzuteilen.

Naürlich.
Aber es ist ja nicht mein Projekt.
Ein bischen 'Entwicklungsarbeit' und Gehirnschmalz muss er schon auch 
selbst investieren.

Etwas sehr ähnliches machen auch beim Wordclock Projekt, insofern könnte 
sich ein Blick in die Quellen lohnen. Diese sind auch kommentiert 
;)</Eigenwerbung>.

Mit freundlichen Grüßen,
Karol Babioch

[1]: https://github.com/Wordclock/firmware/blob/master/src/color.c

Hallo,

Karl Heinz, ich befürchte, wer nicht "source code für RGB Steuerung" in 
Google eingeben kann und deswegen auch nicht eine der "ungefähr 205.000 
Ergebnisse" (laut Google) findet, von denen das erste gleich auf einen 
Thread mit zig Varianten hier auf mikrocontroller.net verweist, der wird 
sich nicht wirklich die Mühe machen wollen, auch nur irgendetwas an 
"Entwicklungsarbeit" hineinzustecken...

War aber gut erklärt, eventuell machst Du ja einen Artikel daraus? 
(kurze Suche hat weder HSV noch RGB-Fader bei den Artikeln gefunden).

Schöne Grüße,
Martin

Martin L. schrieb:
> Hallo,
>
> Karl Heinz, ich befürchte, wer nicht "source code für RGB Steuerung" in
> Google eingeben kann und deswegen auch nicht eine der "ungefähr 205.000
> Ergebnisse" (laut Google) findet, von denen das erste gleich auf einen
> Thread mit zig Varianten hier auf mikrocontroller.net verweist, der wird
> sich nicht wirklich die Mühe machen wollen, auch nur irgendetwas an
> "Entwicklungsarbeit" hineinzustecken...

Das mag sein.
Trotzdem gehe ich mehr und mehr dazu über, je nach Schwierigkeitsgrad 
keine Komplettlösungen mehr anzubieten, sondern nur noch den Weg dorthin 
in unterschiedlicher Detailierung aufzuzeigen.
So hab ich mir meine Sporen verdient, so haben es andere gemacht und ich 
denke, das das ein gangbarer Weg ist, wenn nicht sogar der einzige. Ja 
man muss zum Teil auch für sich das Rad neu erfinden. Nicht um danach 
ein Rad zu haben, sondern um zu lernen wie man Räder macht.
Bei Dingen, von denen ich denke, dass sie in der Tat schwierig 
umzusetzen sind, gehe ich auch schon mal weiter. Aber ich möchte mehr in 
die Richtung, eine mögliche Idee aufzuzeigen und die Leute dazu zu 
bringen, auch wirklich ihr Projekt selbst zu programmieren. Kann 
jemand das nicht, dann hat er eben Pech. Vor dem Wollen kommt immer noch 
das Können.

> War aber gut erklärt, eventuell machst Du ja einen Artikel daraus?
> (kurze Suche hat weder HSV noch RGB-Fader bei den Artikeln gefunden).

Echt?
(Ich hab nicht gesucht)

Es müssten ein paar Forenbeiträge existieren, in denen genau diese 
Methodik vorkommt. Zum Teil auch mit genau demselben Diagramm :-)

Karl Heinz schrieb:
> Ist einfach nur eine lineare Gleichung, die auf die 60 Intervallbreite
> abgestimmt ist.
Wäre es nicht besser die Rampen logarithmisch zu machen, da das Auge ja 
logarithmisch sieht. Ich habe damals eine Lookup Table verwendet 
(LED-Fading).

Karl Heinz schrieb:
> Man teilt sich den 360 Farbkreis in 6 Abschnitte auf. [...]

Ich mache es noch einfacher:

Nehmen wir an, ich hätte 64 PWM-Stufen für jede Farbe - angepasst an das 
menschliche Auge. Nehmen wir noch zusätzliche an, ich hätte eine 
Timer-ISR, die 128 mal pro Sekunde aufgerufen wird.

Wenn man nun vom RGB-Wert (besser: PWM-Index: 0 bis 63))

   F1 = (10, 63, 40)

auf den Wert

   F2 = (33, 10, 45)

faden will, berechnet man erstmal die 3 Differenzen:

DiffR = 23  (rot)
DiffG = -53 (grün)
DiffB = 5   (gelb)

Soll nun die Fading-Zeit z.B. 1 Sekunde betragen, dann muss Rot 
innerhalb von einer Sekunde 23 Schritte, Grün 53 Schritte und Blau 5 
Schritte durchlaufen.

Also teilen wir die 128 Aufrufe pro Sekunde durch die Anzahl der 
Schritte:

128 / 23 = 5 (Integerdivision)
128 / 53 = 2
128 / 5 = 25

Wenn wir jetzt 3 Zähler in der ISR verwenden (für R, G und B), dann 
müssen wir bei Rot immer bis 5 zählen, bis wir R um eine Stufe erhöhen, 
bei Grün bis 2 zählen, bis wir G um eine Stufe erniedrigen usw. Das 
geht soweit, bis wir den gewünschten Zielwert F2 erreicht haben.

Da alle 3 Zähler simultan in der ISR laufen, erreichen wir dadurch auch 
ein "zeitgleiches" Faden aller 3 Farben, wobei diese 3 Farben 
unterschiedliche lange "Strecken" (mit verschiedener Geschwindigkeit) 
zurücklegen müssen, bis sie ihren Endwert erreicht haben.

Je öfter die Aufrufe der Timer-ISR geschehen (128 war nur ein Beispiel), 
desto genauer wird die Geschichte. Ich benutze diese Methode bei meiner 
Equinox-Uhr (60 ATTinys) und bin mit den Ergebnissen mehr als zufrieden.

Max H. schrieb:
> Karl Heinz schrieb:
>> Ist einfach nur eine lineare Gleichung, die auf die 60 Intervallbreite
>> abgestimmt ist.

> Wäre es nicht besser die Rampen logarithmisch zu machen, da das Auge ja
> logarithmisch sieht.

Jein. Mein bevorzugter Ansatz ist, daß das Software-Modul zur LED- 
Helligkeitssteuerung die Gammakorrektur intern macht. Auf der Schnitt- 
stelle zum Rest (RGB-Rampengenerator, HSV->RGB Wandler, etc.) sind die 
Werte dann linear. Ein linearer Sweep erzeugt dann eine als linear 
wahrgenommene Helligkeitsänderung.

Wie man das dann intern umsetzt, ist wieder eine andere Frage. Aber da 
255 Helligkeitsstufen i.d.R. vollkommen ausreichen, bietet sich eine 
Tabelle natürlich an.

In der https://www.mikrocontroller.net/forum/codesammlung gibts von mir 
auch ein RGB-Moodlight. Mit Skript zum Generieren der Gammatabelle.


XL

Axel Schwenke schrieb:
> Aber da
> 255 Helligkeitsstufen i.d.R. vollkommen ausreichen,

Wobei man in der Praxis nur wirklich 255 Helligskeitsstufen hat. Mit 
einer 8 Bit PWM schafft man realistisch gesehen nicht mehr als 32 oder 
64 Stufen. Oder hast du da irgendwelche Tricks, die ich noch nicht kenne 
;).

Mit freundlichen Grüßen,
Karol Babioch

Max H. schrieb:
> Karl Heinz schrieb:
>> Ist einfach nur eine lineare Gleichung, die auf die 60 Intervallbreite
>> abgestimmt ist.
> Wäre es nicht besser die Rampen logarithmisch zu machen, da das Auge ja
> logarithmisch sieht. Ich habe damals eine Lookup Table verwendet
> (LED-Fading).

Kann man natürlich auch.
Allerdings hab ich auch bei meinen Versuchen gemacht, dass das alles 
recht akademisch ist, da RGB Led keineswegs die idealen 'Farberzeuger' 
sind. Steuere ich eine RGB LED mit 255,255,255 an, dann sollte da 
eigentlich weiß rauskommen, in der PRaxis (bei meinen LED) haben die 
aber alle einen unterschiedlichen Farbstich. Die einen ins rote, die 
anderen ins blaue.

Die Frage ist auch immer, was will man eigentlich machen. Stelle ich mir 
die Farben sowieso per Hand ein, dann interessiert es im Grunde nicht 
wirklich, ob ich da jetzt am Drehencoder noch 5 Tacken weiter drehen 
muss oder nicht. Ich seh ja die Zahlenwerte sowieso nicht und drehe so 
lange bis es mir gefällt. Genauso beim Fading: Ob das Gelb im 
Fading-Verlauf jetzt wirklich ein sauberes Gelb ist oder doch einen 
leichten Braunstich hat, wird niemand merken, wenn es im Farbverlauf von 
Rot auf Cyan als Zwischenstufe auftritt.
Baue ich ein Ambilight, bei dem sich das Bild am Fernseher in den 
LED-Farben wiederspiegelt, dann ist die Sache natürlich anders. Da bin 
ich dann selbstverständlich daran interessiert, dass die wahrgenommenen 
Farben tatsächlich denen entsprechen, die im Bild zu sehen sind.

Frank M. schrieb:
> Je öfter die Aufrufe der Timer-ISR geschehen (128 war nur ein Beispiel),
> desto genauer wird die Geschichte. Ich benutze diese Methode bei meiner
> Equinox-Uhr (60 ATTinys) und bin mit den Ergebnissen mehr als zufrieden.

Mit wie vielen Aufrufen arbeitest du denn, wenn man fragen darf?

Mit freundlichen Grüßen,
Karol Babioch

Karol Babioch schrieb:
> Frank M. schrieb:
>> Je öfter die Aufrufe der Timer-ISR geschehen (128 war nur ein Beispiel),
>> desto genauer wird die Geschichte. Ich benutze diese Methode bei meiner
>> Equinox-Uhr (60 ATTinys) und bin mit den Ergebnissen mehr als zufrieden.
>
> Mit wie vielen Aufrufen arbeitest du denn, wenn man fragen darf?

Es sind 3906 Aufrufe (statt 128 wie im obigen Beispiel) pro Sekunde. Die 
krumme Zahl kommt zustande, weil ich diese ISR zusätzlich nutze, um die 
Hardware-8-Bit-PWMs (ATTiny85) softwaremäßig auf drei 12-Bit-PWMs 
hochzuschrauben.

Aber nur jedes zweite Mal werden die RGB-Indices hoch- bzw. 
runtergezählt, d.h. das Fading hat eine Aufrufrate von 1953 pro Sekunde. 
Bei RGB-Indexwerten von 0-63 erhält man bei der oben erwähnten Division 
schon ziemlich genaue Zählwerte - auch wenn die Fadingzeit mal nur eine 
Zehntel- statt ganze Sekunde dauern soll. Tatsächlich rechne ich dort in 
10tel-Sekunden Einheiten. Aber das gehört nicht unbedingt hierher ;-)

Hallo,

zum Thema Linearisierung durch Logarithmierung ist noch zu sagen, dass 
die vorgestellte Methode erhebliche Helligkeitsschwankungen aufweist, 
wobei die Grundfarben (rot, grün, blau) dunkler und die Mischfarben 
(gelb, cyan, magenta) jeweils bis zu doppelt so hell sind.

Möchte man also ein wirklich gleichmäßiges durchlaufen des Farbkreises 
erreichen muss man also entweder eine echte HSV-RGB-Wandlung machen oder 
aber die vorgestellte Kurve entsprechend anpassen. Das sieht dann eher 
so aus wie im Anhang, wobei natürlich gelb, cyan und magenta nicht so 
hell dargestell werden, wie sie an sich könnten.

Schöne Grüße,
Martin