ATmel-uController Übersicht ?

was mir immer fehlt ist ein kleiner AVR im DIP, der günstig und leicht 
zu beschaffen ist und 3 16bit PWM-Kanäle bietet (von mir aus auch in 
einem Timer).

Unter klein verstehe ich maximal 28pins, am liebsten jedoch 8-16

Hat da jemand einen Tip?
In den ganzen Tabellen hab ich keinen gefunden.

Eigendlich liegt es ja nahe, für RGB-LED-Anwendungen einen solchen 
controller zu bauen.
zumal sowas in software mit einer vernünftigen Framerate so gut wie 
nicht möglich ist.

lassen wir die Attribute günstig und leicht zu beschaffen weg.

fällt dir dann ein passender AVR ein?

das
> In den ganzen Tabellen hab ich keinen gefunden.
bezog sich nämlich nur darauf

die "günstig" und "leicht zu beschaffen" Attribute verlangen natürlich 
die Kenntniss der richtigen Typen und Erfahrung mit Distributoren und 
meine Hoffnung war, das wenn jemand AVRs kennt, die die restlichen 
Bedingungen erfüllen, er auch Tips diesbezüglich geben kann.

das ding auf avr freaks kenn ich, das ist schrott.

Die skripte produzieren ständig fehler:

>Ein Skript auf dieser Seite ist eventuell beschäftigt oder es antwortet
>nicht mehr. Sie können das Skript jetzt stoppen oder fortsetzen, um zu
>sehen, ob das Skript fertig wird.
>Skript: http://www.avrfreaks.net/themes/FreakCyber/js/behaviour.js:100

Die ergebnisse sind unplausible:
AT90S4414-8: Package DIP8, aber angeblich 32IO-Pins

In den Listen sind die 16bit und 8bit PWM-Kanäle auch immer 
zusammengezählt, so dass man auch nicht sieht, wieviele 16bit Kanäle er 
hat.

Wie gesagt, ich hab bisher keinen gefunden, der die Anforderungen 
erfüllt.

>Bunter geht es wohl kaum. Oder habe ich einen Denkfehler?

Ja. In der Tat. Sicher geht es bunter. 3x16bit = 65k x 65k x 65k = 
280*10^12. Der Witz ist die begrenzte Anzahl Helligkeitsstufen, welche 
eben nur 256 ist im Falle von 8 Bit, und 65k im Falle von 16 bit.

Noch eine Liste (mit Angaben zu Speichergröße, Pinkompatibilität, Timern 
usw.): http://akapuma.info/software/vergleichsliste.html

vio schrieb:
> Es gibt allerdings bei Farnel den ATMEGA1284P-PU als DIP!
> Der ist zwar nicht klein, aber immerhin hat er zwei 16bit Timer mit
> jeweils zwei PWM-Channels.

ATMEGA1284P-PU als DIP
"Preis und Lieferzeit auf Anfrage"

Schön wärs, wenns den endlich mal gäbe. Seit 2 Jahren angekündigt.

Ich hätt so gern einen möglichst Kleinen (8-14 Pins) mit wenigstens 3 
16bit PWM Kanälen.
Flash wären 2k völlig OK.
Warum gibt es sowas eigendlich nicht?
Dsa wär so ideal für kleine LED Anwendungen.

Vlad Tepesch schrieb:
> Dsa wär so ideal für kleine LED Anwendungen.

Schreibfehler?

> Dsa wär so übertrieben für kleine LED Anwendungen.

ich halts da wie Michael_ (Gast).
wenn 8bit reichen wäre da noch der Attiny25.

Verschneiter Tag schrieb:
>>Bunter geht es wohl kaum. Oder habe ich einen Denkfehler?
>
> Ja. In der Tat. Sicher geht es bunter. 3x16bit = 65k x 65k x 65k =
> 280*10^12. Der Witz ist die begrenzte Anzahl Helligkeitsstufen, welche
> eben nur 256 ist im Falle von 8 Bit, und 65k im Falle von 16 bit.

Bunter geht immer, die Frage nach dem Sinn darf jedoch gestellt werden. 
Ich sehe bei einer 8-Bit-PWM jedenfalls keinen Unterschied zwischen zwei 
aufeinanderfolgenden Helligkeitsstufen. Und die Bilder auf meinem 
Computer-Monitor sind mit 16.7 Mio. moeglichen Farbkombinatinen auch 
recht ansehnlich.

Ansonsten kann man mit einem 16-Bit-Timer ja auch prima eine 
Software-PWM fuer die drei RGB-Kanaele basteln. In den allermeisten 
Faellen duerfte der Controller ja sonst nicht viel zu tun haben. ;)

Volker

Wenn DIP kein Ausschlusskriterium ist:

guck dir mal die
AT90PWMx Reihe an.

z.B. der AT90PWM1 hat (wenn ichs beim drüberfliegen richtig verstanden 
hab) 7 Kanäle 12Bit PWM...

Datenblatt:
http://atmel.com/dyn/resources/prod_documents/4378S.pdf

Ist halt SOIC, aber das ist selbst mitm Dachdeckerlötkolben lötbar

ps: wie der erhältlich ist bzw. wies mit den Kosten aussieht: keine 
Ahnung

Rolf Magnus schrieb:
>> Bunter geht immer, die Frage nach dem Sinn darf jedoch gestellt werden.
>> Ich sehe bei einer 8-Bit-PWM jedenfalls keinen Unterschied zwischen
>> zwei aufeinanderfolgenden Helligkeitsstufen.
>
> Das Problem bei der LED-Ansteuerung ist, daß man die Helligkeitsstufen
> nicht linear wahrnimmt. Man muß daher noch (z.B. mit einer Tabelle)
> korrigieren, damit die Helligkeiten linear erscheinen. Dann hat man aber
> im unteren Helligkeitsbereich eine viel zu grobe Abstufung.

Da man aber bei 8-Bit-PWM schon im unteren Helligkeitsbereich zwischen 2 
Werten kaum einen Unterschied (und schon gar keinen Sprung) sieht, waere 
das eher von Vorteil. Ich bin mir aber nicht sicher, ob man diese 
Tabellen analog zum Farbmischen ueberhaupt verwendet. Die 
Helligkeitsunterschiede sind ja linear vorhanden, ein Farbanteil wird 
also hoeher.


>> Ansonsten kann man mit einem 16-Bit-Timer ja auch prima eine
>> Software-PWM fuer die drei RGB-Kanaele basteln. In den allermeisten
>> Faellen duerfte der Controller ja sonst nicht viel zu tun haben. ;)
>
> Kommt drauf an, an welche Schnittstelle er angebunden ist. Wenn er die
> auch in Software machen muß, kann's evtl. schon etwas komplizierter
> werden, die Timings unter einen Hut zu bekommen.

Naja.. eine Software-PWM in dem Frequenzbereich duerfte einen anstandig 
getakteten Mikrocontroller wohl nich zu mehr als ein paar % auslasten. 
Da ist fuer Kommunikation mehr als ausreichend Spielraum.

Volker

Rolf Magnus schrieb:
> Volker Schulz schrieb:
>
>> Naja.. eine Software-PWM in dem Frequenzbereich duerfte einen anstandig
>> getakteten Mikrocontroller wohl nich zu mehr als ein paar % auslasten.
>
> Das sehe ich anders. Immerhin muß für eine 16-bit-PWM die
> PWM-Grundfrequenz 65536 mal so hoch sein wie die Frequenz das
> Ausgangssignals, was also z.B. für 100 Hz bereits eine Frequenz von über
> 6,5 Mhz bedeutet. [...]

Das ist natuerlich korrekt. Du musst aber ja mit 16-Bit-Timer nicht die 
volle Breite abfahren. Fuer eine solche PWM waere das der ultimative 
Overkill. Man koennte aber, wenn man es als unbedingt noetig empfindet, 
noch auf 9 oder sogar 10 Bit gehen.

Volker

Bei einem sehr langsamen Fading sieh man bei 8bit einen deutlichen 
Unterschied zwischen den unteren Stufen.
Bei vielen Lichtanwendungen will man ja eher langsam und gemütlich 
faden.

und in SW bekommt man eine 16bit PWM auch nicht hin.
Hab das letztens mit einem 16bit Timer probiert (allerdings nur mit 
8Mhz).
Die ISR, die die entsprechenden Pins toggelt und den jewiligen nächsten 
Comparewert läd kriegt man nicht unter ~50 Takte (inkl. unvermeidlicher 
Takte bei einem Interuptaufruf).
Dh 2 PWM werte müssen mind. 50 Takte auseinander liegen.
man hat somit effektiv eine 10bit PWM.
Allerdings sind in dem Fall andere ISRs tödlich und verursachen Blitzer.


Allerdings sind auch 100Hz PWM schon grenzwertig.

Vlad Tepesch schrieb:
> Bei einem sehr langsamen Fading sieh man bei 8bit einen deutlichen
> Unterschied zwischen den unteren Stufen.
> Bei vielen Lichtanwendungen will man ja eher langsam und gemütlich
> faden.

Ich weiss natuerlich nicht, was mcc's Anwendungsidee ist, ich hab mir 
das ganze als RGB-Leuchte gebaut. Und da fade ich nur von der alten zur 
neuen Farbe, innerhalb von einer Sekunde. Das Ganze mit 8-Bit Soft-PWM 
(> 1KHz) und scheinbar ohne Spruenge. Die Farbkommandos nehme ich per 
serieller Schnittstelle in Empfang und komme mit meinem Baudraten-Quarz 
auf dem Mega8 ohne groessere Probleme hin.

Nun will ich nicht ausschliessen dass ausgerechnet meine Augen um ein 
vielfaches traeger sind als die der uebrigen Menschen, aber selbst die 
relativ teuren Kauf-RGB-Lampen bzw. Regler werden nicht selten mit etwas 
wie

[...]that can change to any of 16 million unique colors[...]

beworben...


> [...]
> Die ISR, die die entsprechenden Pins toggelt und den jewiligen nächsten
> Comparewert läd kriegt man nicht unter ~50 Takte (inkl. unvermeidlicher
> Takte bei einem Interuptaufruf).

Doch.. sogar inkl. Polling der seriellen Schnittstelle. ;)


Volker

Volker Schulz schrieb:
>> [...]
>> Die ISR, die die entsprechenden Pins toggelt und den jewiligen nächsten
>> Comparewert läd kriegt man nicht unter ~50 Takte (inkl. unvermeidlicher
>> Takte bei einem Interuptaufruf).
>
> Doch.. sogar inkl. Polling der seriellen Schnittstelle. ;)

vergiss es:
Beitrag "Re: erbitte Hilfe bei optimierung ISR"
das ist mein Versuch.
drunter sind noch ein paar kleine korrekturen.

Insgesammt kommt man auf 46 Takte für
+ ISR einsprung
+ register sichern
+ lesen der zu setzenden Pins
+ increment Pin-pointer für nächsten Compare
+ setzen der Pins
+ lesen des nächsten Compares
+ increment compare-pointer für nächsten Compare
+ setzen des compares
+ register wieder herstellen
+ iret +  nächster Befehl der Hauptroutine



Das setzten der PWM werte sieht so aus:
Wert/Kanal-Paare nach Werten sortieren.
Linearisierung (LUT)
gleiche/ähnliche Werte gruppieren und für ISR ablegen
Pointer initialisieren
ersten comparewert laden

edit:
der Overflow setzt dann nur alle Pins zurück und setzt die Pointer 
wieder an den Anfang der Liste



damit hat man eine SW-PWM mit beliebig vielen Kanälen.


Edit:
wenn ma das ganze Programm in ASM schreibt kann man ein paar register 
exclusiv für die ISR abstellen und womöglich ein paaar push/pops sparen.
aber das ganze Programm in ASM hab ich kein Bock drauf, zumal man auch 
sämtliche Bibliotheksfunktionen nicht aufrufen darf.

Vlad Tepesch schrieb:
> Volker Schulz schrieb:
>>> [...]
>>> Die ISR, die die entsprechenden Pins toggelt und den jewiligen nächsten
>>> Comparewert läd kriegt man nicht unter ~50 Takte (inkl. unvermeidlicher
>>> Takte bei einem Interuptaufruf).
>>
>> Doch.. sogar inkl. Polling der seriellen Schnittstelle. ;)
>
> vergiss es:

Hab ich tatsaechlich schonwieder fast vergessen, denn ich hab das Ding 
ja schon vor einer halben Ewigkeit fertiggestellt! ;) Habe leider gerade 
weder Zugriff auf Programm noch Hardware, aber ich bin mir ziemlich 
sicher dass ich ein 11.0592 MHz Quarz benutzt habe und bei ueber 1KHz 
PWM-Frequenz war. Muesste also auf so 40-50 Takte pro Interrupt gekommen 
sein. LUT benutze ich nicht, ob das fuer die Mischung von Farben 
sinnvoll ist, daran scheiden sich ohnehin die Geister. Ich benuzte das 
Ganze ja auch als Effekt-Leuchte und nicht als Farbreferenz. ;) Spart 
vermutlich ordentlich Takte ein. Wenn ich im Kopf ueberschlage, brauche 
ich (nur fuer die 8-Bit-3-Kanal PWM) ca. 15 Takte pro Interrupt. Dann 
noch ein paar fuer das Polling und Faden, aber ich hab ja auch noch mehr 
als 50% uebrig. ;)


> wenn ma das ganze Programm in ASM schreibt kann man ein paar register
> exclusiv für die ISR abstellen und womöglich ein paaar push/pops sparen.
> aber das ganze Programm in ASM hab ich kein Bock drauf, zumal man auch
> sämtliche Bibliotheksfunktionen nicht aufrufen darf.

Ich mache sowas generell in ASM um volle Kontrolle oder zumindest ein 
besseres Gefuehl ueber die Timings zu haben. Der Timerinterrupt ist der 
einzige; Keine wilden Spruenge oder aehnliches. Laesst sich ja auch 
alles innerhalb abarbeiten. Also auch kein Stack noetig. Dedizierte 
Register habe ich auch, ja.


Koennen uns da ja mal genauer austauschen... Zur Not auch weiterhin in 
diesem Thread... Nu isser ja eh zweckentfremdet. ;)

Volker

Volker Schulz schrieb:
> LUT benutze ich nicht, ob das fuer die Mischung von Farben
> sinnvoll ist

die ISR sieht von der Look-Up-Table ja auch nix.
Da wird aus dem Array mit den Kanälen nur der nächste Schaltzeitpunkt 
rausgesucht.

Volker Schulz schrieb:
> brauche
> ich (nur fuer die 8-Bit-3-Kanal PWM) ca. 15 Takte pro Interrupt
8bit ist klar, da muss ja nur ein Wert gelesen und geschrieben werden 
werden

trotzdem reichen 15 Takte nicht.
7 brauchts ja überhaupt erst mal, vom Eintreffen des Interupts bis zum 
Anfang der ISR und 4 zum Rausspringen, dazu kommen im ungünstigsten Fall 
nochmal 4 (mindstens jedoch einer), da noch ein Befehl des 
Hauptprogramms ausgewertet wird, bis der nächste Int eintreffen kann.

Dh. dein Interupt braucht schon mal 30 Takte.
Sichern von Registern ist da noch gar nicht drin

und du kannst mir nicht erzählen, dass du in 16 Takten das Fading und 
die UART handlen kannst.

Vlad Tepesch schrieb:
> trotzdem reichen 15 Takte nicht.
> 7 brauchts ja überhaupt erst mal, vom Eintreffen des Interupts bis zum
> Anfang der ISR und 4 zum Rausspringen, dazu kommen im ungünstigsten Fall
> nochmal 4 (mindstens jedoch einer), da noch ein Befehl des
> Hauptprogramms ausgewertet wird, bis der nächste Int eintreffen kann.

Ich weiss ja dass das Ding einwandfrei funktioniert, also werde ich 
damals auch eine Loesung gefunden haben. Die 4 Takte fuer den 
Ruecksprung hatte ich gerade schon eingerechnet und die Interrupt 
Response Time liegt idealerweise bei 4 Cycles. Ich weiss nicht ob der 
Einsprung das Ganz nur nach hinten schiebt oder mit eingerechnet werden 
muss. Aber im worst case liege ich so bei 21/22 cycles fuer die PWM. 
Bliebe immernoch >50% frei. Byte von der UART holen kostet nicht mehr 
als 2 cycles. Dann muss ich ja noch irgendeine Logik gehabt haben, damit 
das Byte im richtigen Register landet... Bin gerade aber echt 
ueberfragt.

Wenn ich das selbst so lese, ueberlege ich gerade ob ich ueberhaupt 
einen Timer benuzt habe. Ist ja eigentlich voellig sinnfrei... Ich kann 
mich erinnern dass ich nach Fertigstellung simuliert und Takte gezaehlt 
habe um dann die schnellstmoegliche PWM einzustellen.

Wie auch immer, ich muss mir meinen "Mist" von damals nochmal anschauen. 
Will das Ganze ja jetzt nicht im Kopf neu entwickeln... ;)


> Dh. dein Interupt braucht schon mal 30 Takte.
> Sichern von Registern ist da noch gar nicht drin

Wir sind jetzt irgendwo zwischen 10-22 Takten nur fuer die PWM...


> und du kannst mir nicht erzählen, dass du in 16 Takten das Fading und
> die UART handlen kannst.

Zwischen 24 und 36 haette ich jetzt noch... ;)


Volker

Achso, was den eigentlichen Thread angeht... ;)

Man koennte den Takt im Vergleich zu meinem Projekt ja noch fast 
Verdoppeln und die PWM-Freqenz 10-fach kleiner machen und haette 
vermutlich immernoch ein ansehnliches Ergebnis (und mehr als 800 Takte 
pro Interrupt zur Verfuegung)...

Volker

Wie wär es mit einer PDM anstatt einer PWM?

Da lassen sich auch in SW einige von mit überschaubarem Aufwand 
realisieren.
Einem 20MHz ATmega traue ich bis zu 6  16-Bit-PDMs zu - Dann wird es mit 
den Registern eng (4 werden pro Kanal dauernd benötigt) (8 Register 
wären dann noch über).

Bei dem Szenario, welches mir gerade durch den Kopf geht, hat man eine 
Mindestfrequenz von ca. 4Hz bei 0x0001 (die LED 'leuchtet' dann gerade 
mal 4µs)

Bei 0x0002 alle 1/8s 4µs
Bei 0x8000 alle 8µs 4µs
Bei 0xFFFF ist sie alle 1/4s 4µs aus


Allerdings ist die CPU beschäftigt und (weitere) IRQs sind nicht drin.
Die Hälfte der Zeit hat man dann noch die Möglichkeit, die 
Helligkeitswerte zu aktualisieren, etc.


Funktionsweise:

a = Helligkeitswert
b = Additionsregister
(jeweils 16Bit)

Bei jedem Zyklus wird nun a auf b addiert (b=b+a). Läuft b (MSB) über, 
wird der Port auf H gesetzt, sonst auf L (also einfach C-Flag kopieren) 
- that's all ...
Bei kleinen Werten entstehen weniger Überläufe, bei großen Werten 
häufiger.


Vielleicht hilft es ja weiter ...


Gruß

Jobst

vio schrieb:
> Es geht nicht um die Anzahl der Farben, sondern um die der Schritte! Für
> lineares und langsames Fading, braucht man mehr als 8bit, ansonsten
> ruckelt es im unteren Bereich! Siehe
> http://www.mikrocontroller.net/articles/LED-Fading

Das wird auch nicht richtiger nur weil man es oefter schreibt... ;)

1. Die Anzahl der Schritte pro Farbe bestimmen die Anzahl der Farben.

2. Fuer lineares (auch langsames) Fading reichen die 8-Bit, man sieht 
auch im unteren Bereich keine Einzelschritte. Wie ich bereits schrieb, 
werben auch die professionellen Kauf-Regler mit 16.7 Mio Farben. Das 
sind 8 Bit pro Farbe.

3. Der oben verlinkte Artikel geht auf die Wahrnehmung der Helligkeit 
des menschlichen Auges ein. Will man also ueber die wahrgenommene 
Helligkeit faden, muss man logarithmisch erhoehen. Hier reicht dann 
ein 8-Bit-Zaehler (aufgrund der groesseren Schrittweite) vermutlich 
nicht mehr aus.

4. Das Mischungsverhaeltnis der Farben wird aber nach wie vor linear 
bestimmt.


Beim Faden muss man also erstmal unterscheiden, ob man von einer zur 
anderen Farbe oder ueber die Helligkeit fadet. Das sind zwei Paar 
Schuhe. Richtig kompliziert wird es dann natuerlich wenn man RGB mischen 
UND gleichzeitig die Helligkeit regeln will. Das ist aber mit einer PWM 
ohnehin nicht mehr (uber den vollen Bereich) machbar.

Volker

vio schrieb:
> Hm, also ich hab mir das so vorgestellt:
>
> Zu 2:
> Wenn man mit 8bit, das sind 256 Schritte, 16.7 Millionen Farben
> darstellt, hat man gar keine Schritte mehr übrig die man überspringen
> könnte um eine LUT zu verwenden, d.h. man fadet die Farben nicht linear!
> Wenn man keine LUT verwenden, stellt man in der Tat kein Ruckeln bei
> 8bit fest, aber es ist eben auch kein lineares Faden!

Wenn man keine LUT verwendet, fadet man linear. Es sieht fuer das 
menschline Auge nur nicht so aus. Das nur zur Begriffsbestimmung.

> Es sind
> physikalisch gesehen tatsächlich 16.7 Millionen Farben, allerdings kann
> das Auge davon nur sehr wenige unterscheiden, weil keine Linearisierung
> statt fand!

Die Anzahl sowohl der physikalisch darstellbaren wie auch der 
wahrnehmbaren Farben bleibt die gleiche. Der Sinn der LUT ist dass man 
im helleren Bereich (wo das Auge ohnehin weniger Unterschiede erkennt) 
einige Stufen rausnimmt, die man dafuer im dunkleren Bereich einfuegen 
kann, um dort eine bessere Aufloesung zu bekommen. Wenn Du aber selbst 
schon sagst dass man auch im unteren Bereich kein Ruckeln feststellt, 
sind diese zusaetzlichen Stufen gar nicht noetig. Und dann hat die LUT 
nur noch einen einzigen Vorteil: Die angegebenen 8-Bit-Werte verlaufen 
proportional zu den wahrgenommenen, man kann also davon ausgehen, dass 
0xFF doppelt so hell wahrgenommen wird wie 0x7F.


> Zu 4:
> Aber es sieht nicht linear aus, desswegen brauchen wir doch die LUT!
>
> Ich würde das gar nicht auf gleicher Ebene zwischen Farb-Fading und
> Helligkeits-Fading unterscheiden, sondern das transparent betrachten:
>
> Wenn wir drei 16bit Timer verwenden, können wir R, G und B z.B. mit
> einer LUT welche 256 Einträge hat, deren Werte von 0 bis 65535 reichen,
> linearisieren! Dann hätte man zwar wieder nur 8bit, aber diesmal
> linearisiert und somit echte 16.7 Millionen Farben!

Wie gerade schon geschrieben, die Anzahl der Farben (auch der 
wahrnehmbaren) ist mit oder ohne LUT die gleiche. Lediglich die 
Verteilung auf die 8-Bit-Werte ist eine andere.


Wenn also die Abstufung im unteren (dunkleren) Bereich schon klein genug 
ist (an oder unter der Wahrnehmungsgrenze), braucht man auch keinen LUT, 
der alles auf 16 Bit aufblaest. Will man die wahrgenommene Helligkeit 
linear zu den angegebenen Werten haben, koennte man eher an einen LUT 
denken, der z.B. 6 Bit auf 8 Bit lagarithmisch umrechnet. Braucht man 
diese Linearitaet zwischen Angabe und Wahrnehmung nicht (was in sehr 
vielen Faellen der Fall sein duerfte), laesst man den LUT ganz weg.


Volker

bei einer 8bit PWM sieht man sehr wohl einen Unterschied zwischen stufe 
1 und 2. erst recht, wenn man sehr langsam faded und jede Stufe 0,5s 
oder länger angezeigt wird.
Da ist eine 16bit PWM angenehmer, da dort in der selben Zeit 255 stufen 
angezeigt werden, was einem Übergabg zwischen 8bit Stufe 1 und 2 
entspricht.

will man die 8bit für das auge linearisieren, bleiben nur noch 32 Stufen 
(eigendlich sogar weniger) übrig, so dass ein bei gleichbleibender 
Gesamt-Fadeing-Dauer bei 8bit einer Stufe 4s angezeigt wird.

Eine für das Auge linearisierte 16bit PWM hat höchstens 255 sinnvolle 
Stufen, bei der kann man den Unterschied zwischen 2 Stufen dann wirklich 
so gut wie nicht  unterschieden und ist somit optimal für langsame 
Fadings, egal ob hell-dunkel, oder Farb-Wechsel (der ja auch nur ein 
Hell-Dunkel-Fading einzelner Kanäle ist)


Es hängt natürlich vom Anwendungsfall ab, je schneller man faded, desto 
weniger Stufen braucht man.
Solls was Moodlight-ähnliches mit extrem langsamen Übergängen werden, 
braucht man schon mindestens 8bit Auflösung und am besten auch 
linearisiert (also 16bit)
Ansonsten sind Übergänge zu den reinen Farben sehr schnell und dann 
verweilt es dort recht lange.

Ja, natuerlich haengt es vom Anwendungsfall ab. Auch beim Moodlight gibt 
es verschiedene Anwendungsfaelle. Ich benutze dieses z.B. zum Beleuchten 
(wer haette das gedacht?), es kommt also ohnehin nicht vor, dass alle 
Farben im unteren Bereich haengen. Und wenn Deine rote LED gerade 
ziemlich hell vor sich hinleuchtet, sieht man insgesamt auch keine 
Abstufung zwischen Stufe 1 und 2 der blauen... Eigentlich sieht man da 
bei der Gesamtfarbe gar keinen Unterschied. Nur so als Beispiel. ;) Dazu 
kommt ja, wie erwaehnt, dass ich binnen max. einer Sekunde zur neuen 
Farbe fade, in der das Ding dann verharrt bis ein neuer Befehl kommt. 
Also so, wie die RGB-Regler mit manueller Steuerung auch.

Volker