wir hatten ja schon in einzelnen Beiträgen immer mal das Thema wie man am besten dimmt- linear, sinus, logarythmisch... Möglichkeiten gibt es viele... Und somit gibt es auch viele Möglichkeiten wie man es umsetzt, mit verschiedenen Anforderungen.
Um Rechenleistung zu sparen gibt es z.b. Lösungen mit Tabellen. Für das Dimmen von RGB- LEDs, wo es auf möglichst feine Farbverläufe ankommt, muss es nicht unebdingt die beste Lösung sein...
Ich möchte daher in dem Beitrag mal die Diskussion zu dem Thema anstoßen, damit man idelaerweise eine brauchbare Übersicht möglicher Lösungen mit Vor- und Nachteilen bekommt.
Ich fange mal mit einer Lösung an, die die Zeit der Dimmschritte variiert. Die Zeit, die ich gewählt habe sei nur als Beispielhaft zu betrachten- da kann man selbstverständlich variieren... Ich betrachte mich selbst als Laien- ich hab zwar etwas Erfahrungen, das Programmieren aber nicht vond er Pieke aufgelernt und somit "unwissend" was grundlegende Regeln beim Programmieren angeht. Verzeiht mir also Fehler. Der Wert für "Helligkeitneu" kann von außen kommen, er ist als Startwert auf 0 gesetzt.
int Zeitmarke;
float Intervall;
byte Helligkeitalt;
byte Helligkeitneu;
byte Tempo = 10;
loop()
{
Intervall = (256 - Helligkeitalt)/Tempo:
if (millis() - Zeitmarke > Intervall)
{ Zeitmarke = millis();
if (Helligkeitneu > Helligkeitalt) {Helligkeitalt++;}
if (Helligkeitneu < Helligkeitalt) {Helligkeitalt--; }
}
}
Beim hochdimmen von 0 auf X ist der Intervall also noch relativ groß und nimmt mit jedem Helligkeitsschritt linear ab. Bei 255 wäre dann der Intervall nur noch 0,1ms lang... in der Summe kommt man auf eine Zeit zwischen min und max von 3,2768 Sekunden. Will man das ändern, ändert man einfach "Tempo"
void Licht_A_fade_in() {
float T;
// Calculate the T variable
T = (pwmIntervals * log10(2)) / (log10(254));
// fade in from min to max:
for (int interval = 0; interval <= pwmIntervals; interval++) {
// Calculate the required PWM value for this interval step
brightness = pow (2, (interval / T)) - 1;
// Set the LED output to the calculated brightness
Serial.println(brightness);
analogWrite(LICHTAPIN, brightness);
delay(30);
Serial.println(brightness);
}
}
das gibt dir eine logarithmische Ausgabe und somit einen gefühlt linearen Helligkeitsverlauf. Ich war mit dem Ergebnis zufrieden, mir wurde aber damals empfohlen die Werte für das PWM in eine Array zu legen und nicht zu berechnen.
ein wirklich weicher Übergang ist mit 256 Stufen nicht hinzubekommen. Besonders die unteren Stufen werden wirklich und deutlich als "Stufen" wahrgenommen.
Ich habe mit der TimerOne.h eine 10-bit PWM generiert, die Werte in eine Tabelle abgelegt.
Das gibt ein schönes, sanftes, ruckfreies Dimmen.
Wenn ich wieder zuhause bin, suche ich mal den Code dazu raus.
man muss sich von dem Gedanken trennen bei 8Bit alle 256 (bei 10Bit alle 1024 usw.) Werte verwenden zu müssen. Die 256 Werte stehen Euch nur zur Auswahl. Aus diesem Werte-Pool muß man nun laut seiner Berechnung die wenigeren richtigen Werte nehmen damit es für unser Auge linear erscheint. Standard Gamma-Korrekturwert ist 2,2. Das kann man noch variieren, weil sich der Wert eigentlich auf die Bildschirmhelligkeit bezieht.
Vorberechnung und in ein Array legen ist immer die beste Methode, wenn sich zur Laufzeit nichts ändert, was meistens der Fall ist. Spart viel Rechenzeit. Der Link in #2 beschreibt es eigentlich komplett. Mal sehen was Gunther noch beisteuert. Ich berechne meine Werte in Excel und kann mir dazu gleich die Parabelform anschauen.
Wenn man aber RGB dimmt und nicht nur dimmt, sondern auch Farbverläufe umsetzen will bzw. Helligkeitsstufen dazwischen abdecken will sind die 256 Werte schon sinnvoll... daher war mein Ansatz nicht die Helligkeitswerte anzufassen, sondern die zeitlichen Schritte zwischen den jeweiligen Werten.
wenn du zeitliche Sprünge machst, dann kannste doch aber nicht sauber dimmen, sprich faden.
Überleg mal was passiert, wenn du deine Stubenlampe ruckartig in der Helligkeit veränderst.
Je schneller man dimmen/faden möchte, umso weniger Zwischenwerte benötigt man.
Umso langsamer das ablaufen soll, umso mehr Zwischenwerte benötigt man.
Das heißt aber nicht das man alle Werte verwenden darf. Dann wäre es ja wieder nicht linear fürs Auge.
Edit:
Oder reden wir aneinander vorbei? Klar sind viele Werte (deine 256) schon sinnvoll. Aber dann nicht 256 aus 256 sondern 256 aus 1024 oder besser 256 aus 65535. Nur das macht Sinn. Du mußt ja irgendwie die Parabel hinbekommen. Wobei 64 Werte auch schon viel sind.
naja, der ansatz von MaHa ist zumindest nicht uninteressant, aber was passiert dann wirklich bei RGB-LEDs? Du machst ja die zeit vom helligkeitswert abhängig. und der ist bei RGBs im allgemeinen unterschiedlich.
bei änderung von RGB(0, 100, 200) auf RGB(50, 150, 250) werden die jeweils 50 punkte ja sehr unterschiedlich schnell geändert.
andererseits ist das ein problem, das man auch auf die andere art in den griff bekommen muß, da ja da zwischen 0 und 50, sagen wir mal, 30 array-werte liegen und zwischen 200 und 250 nur etwa 4.
man müßte also die gewünsche "fade-zeit" IN DIESEM FALL auf 30 teile aufteilen und dort die 4 gleichmäßig unterbringen. kann das eigentlich die FastLED? oder macht die das über HSV?
FastLED macht das über HSV- das nutze ich auch bei mir bei Standard- RGB- LEDs... wäre in dem Fall unkritisch...
Bei meinem Beispiel addieren sich die Zeiten immer weiter auf (bzw. reduzieren sich)... von 0 auf 1 dauert es 25.5ms, der nächste Schritt 25.4ms der letzte 0.1ms - das hochfaden wird also immer schneller... das herunterfaden immer langsamer...
okay, muss mich revidieren. So dumm ist die Idee wirklich nicht. Der arme µC muß nur unnötig viel rechnen. Nur schnelles Fading ist unmöglich. Es dauert ja eine ganze Weile bis der alle Werte durch hat.
Ansonsten müßte man das mal praktisch testen.
Divisionen sind schon hartes Brot für den 8Bitter.
Und das für jeden Durchgang neu. Da gehen unendlich viele Takte drauf.
Bei RGB dann alles 3x je Durchgang. Wenn es gemütlich sein soll okay, wer Speed braucht, ne.
keine Sorge, ich verstehe auch nicht immer alles. Und wenn es auf das Detail drauf ankommt, dann wird getestet was das Zeug hält. Dabei wird man plötzlich kreativ und erhält ungeahnte Erkenntnisse.
Bei Dimming/Fading hat Helmuth und Eisebär schon lange Zeit Erfahrung.
Für einfaches hell-dunkel dimmen reicht der Link aus combies Antwort.
