20 x 16 bit PWM auf einem günstigen RISC-SoC!?

@ Falk Brunner

>>unidirektionalen RS-485 Bus ein Slaveboard entwerfen, welches durch
>>Steuerung über ein selbstentwickeltes Protokoll (kein DMX512!) 20
>
> Warum nicht? Zu einfach? Gibt es dafür zu viel Software?

Ich möchte mir die Möglichkeit behalten, die verbleibenden Busplätze mit 
Geräten zu belegen, die nichts mit Beleuchtung zu tun haben und somit 
anders als mit DMX angesprochen werden müssen.

>>unabhängige PWM-Signale generieren kann (6 x RGB + 2 x WW). Die Menge an
>>Slaveboards wird wohl um die 100 liegen und weil mit
>>1/4-unit-load-Receivern maximal 128 Teilnehmer am Bus hängen dürfen,
>>kann ich die PWM-Kanäle nicht auf mehr Controller aufteilen.
>
> Doch. Nimm einfach zwei getrennte Busse.

Nicht gerade das, was ich mir unter Optimierung von Kosten und Aufwand 
vorstelle.

>>Der großen
>>Menge wegen wärs natürlich super, wenn der µC (weit) weniger als 5 Euro
>>das Stück kostet, die LED-Ketten alleine gehen schon heftig ins Geld.
>
> Von nix kommt nix.

Ja, danke für den Tip.

>>20 Compare-Module für einen oder mehrere 16 bit Timer und UART
>>Betriebsspannung sollte auf TTL-Level liegen, 3,3 V würde notfalls auch
>>gehen.
>
> AtXmega haben verdammt viele Timer. ARM & Co auch.

Da kommen nach meinen Suchergebnissen nur >100 pins in Frage. Ziemlicher 
Overkill zum dimmen von 6 RGB- und 2 WW-Ketten...

>>Hauptsache 20 x sauberes PWM und möglichst bezahlbar ;)
>
> TLC5940 & Co haben 16x 12 Bit PWM und 120mA Stromquellen dazu.

LED-Ketten werden normalerweise über Festspannung angesteuert (allein 
der konstanten Wellenlänge wegen) und verbrauchen abhängig von ihrer 
Länge unterschiedlich viel Strom. KSQ ist keine Option.

optiquenz schrieb:
> @ Falk Brunner
>
>>>unidirektionalen RS-485 Bus ein Slaveboard entwerfen, welches durch
>>>Steuerung über ein selbstentwickeltes Protokoll (kein DMX512!) 20
>>
>> Warum nicht? Zu einfach? Gibt es dafür zu viel Software?
>
> Ich möchte mir die Möglichkeit behalten, die verbleibenden Busplätze mit
> Geräten zu belegen, die nichts mit Beleuchtung zu tun haben und somit
> anders als mit DMX angesprochen werden müssen.


In erster Linie ist das Protokoll auch total nebensächlich, es ist nicht 
die Software, die mir Kopfzerbrechen bereitet...

@ Falk Brunner
> Der PWM-IC? Pah, da gibt es
> genug, wenn gleich vielleicht nicht für 1,50.

Wäre ein Beispiel zu viel verlangt?

optiquenz schrieb:
>> AtXmega haben verdammt viele Timer. ARM & Co auch.
>
> Da kommen nach meinen Suchergebnissen nur >100 pins in Frage. Ziemlicher
> Overkill zum dimmen von 6 RGB- und 2 WW-Ketten...

Hallo Optiquenz,

STM32F103 mit 100 pin TQFP (z.B. F103VC). Haben 4 normale Timer mit je 4 
Kanälen und noch zusätzlich TIM1/TIM8. Alternative: TI C28 Piccolo 
Serie, die haben auch etwa diese Menge PWM, sind aber auch Meist 
100pinner.

Alternative:
CPU1 am Bus, macht Protokoll und Decodierung. Gibt Kanalinfo für die 
anderen PWMs an CPU2 weiter (UART/SPI, Kaskadierung).

rgds

Auf Grund der Fragestellung (LED-Ketten) gehe ich von einem relativ 
weiträumig verteilten Aufbau aus?
-> Gliedere das noch weiter auf (d. h. weniger Ausgänge pro µC - 20 
LED-Ketten klingt nach langen Leitungen vom µC zu den Ketten, klingt 
nach EMV-Schleuder).

optiquenz schrieb:
> Ich möchte mir die Möglichkeit behalten, die verbleibenden Busplätze mit
> Geräten zu belegen, die nichts mit Beleuchtung zu tun haben und somit
> anders als mit DMX angesprochen werden müssen.

Das verstehe ich nicht.
Damit wäre ja die erste Frage: WIE müssen diese angesprochen werden? 
Geht es um einen Rückkanal, d. h. bidirektionale Übertragung? 
Andererseits schreibst Du ja oben selbst "unidirektional".
Für das "gute Gefühl", keine Insellösung™ zu produzieren, würde auch ich 
zu DMX-512 greifen, evtl., falls notwendig, einfach die Anzahl der 
Kanäle "verlängern" bzw. vergrößern und einen Bus mit entsprechenden 
Repeatern zwischendrin benutzen.

BTW: Guter Baustein für I²C wäre z. B. PCA9685 - aber hier wohl nicht 
relevant.

Resümee: Weniger Kanäle pro µC, ein DMX-512-Bus mit entsprechenden 
Repeatern (gab doch auch mal Transceiver mit 1/8 Load oder sogar 
weniger, wenn ich das noch recht in Erinnerung habe), irgendeinen 
Wald-und-Wiesen-µC nehmen, dann könnte das mit 5€ pro Knoten evtl. sogar 
klappen (abh. vom LED-Treiber) und ist EMV- bzw. stromverteilungsmäßig 
wenigstens halbwegs safe™.

Falk Brunner schrieb:
> Der PWM-IC? Pah, da gibt es
> genug, wenn gleich vielleicht nicht für 1,50.

Den gibt es für 1€. Atmega48 mit Softpwm in Assembler.

Ah, ich dachte 12bit reichen. 16bit schafft der natürlich nicht. 14bit 
könnte man mit größerem Software Aufwand schaffen (aber das ist dann 
natürlich kein einfaches Assemblerprojekt mehr).

Patrick schrieb:
> 20 LED-Ketten

... soll natürlich "6 LED-Ketten" heißen...

optiquenz schrieb:
>
> LED-Ketten werden normalerweise über Festspannung angesteuert (allein
> der konstanten Wellenlänge wegen) und verbrauchen abhängig von ihrer
> Länge unterschiedlich viel Strom. KSQ ist keine Option.

äh, einfach ein mosfet dran und damit die ledketten mit konstanter 
spannung betreiben? beispiele gibt es im netz genug.

Weiteres beispiel: PCA9685

6A66 schrieb:
> optiquenz schrieb:
>>> AtXmega haben verdammt viele Timer. ARM & Co auch.
>>
>> Da kommen nach meinen Suchergebnissen nur >100 pins in Frage. Ziemlicher
>> Overkill zum dimmen von 6 RGB- und 2 WW-Ketten...
>
> Hallo Optiquenz,
>
> STM32F103 mit 100 pin TQFP (z.B. F103VC). Haben 4 normale Timer mit je 4
> Kanälen und noch zusätzlich TIM1/TIM8. Alternative: TI C28 Piccolo
> Serie, die haben auch etwa diese Menge PWM, sind aber auch Meist
> 100pinner.
>
> Alternative:
> CPU1 am Bus, macht Protokoll und Decodierung. Gibt Kanalinfo für die
> anderen PWMs an CPU2 weiter (UART/SPI, Kaskadierung).

Leider bleibt das Problem damit das gleiche... Hab gerade noch den 
ATxmega192A3 gefunden, der zählt nur 64 Pins, ist aber nicht für unter 5 
Euronen zu haben :/


Patrick schrieb:
> Auf Grund der Fragestellung (LED-Ketten) gehe ich von einem
> relativ
> weiträumig verteilten Aufbau aus?
> -> Gliedere das noch weiter auf (d. h. weniger Ausgänge pro µC - 20
> LED-Ketten klingt nach langen Leitungen vom µC zu den Ketten, klingt
> nach EMV-Schleuder).

Im Gegenteil ;)
Die Kettensegmente sind teils nur 16 cm lang (kleinste Teilung) und 
befinden sich in unmittelbarer Nähe zum Slaveboard. Für die räumliche 
Verteilung sorgt der Bus. Außerdem reden wir nicht von 20 Ketten, 
sondern von 4 normale RGB und 2 RGBWW. Es sind vor allem Platzgründe, 
die mich dazu bewegen, 20 PWM-Kanäle auf einem einzelnen kleinen Board 
unterzubringen.

> optiquenz schrieb:
>> Ich möchte mir die Möglichkeit behalten, die verbleibenden Busplätze mit
>> Geräten zu belegen, die nichts mit Beleuchtung zu tun haben und somit
>> anders als mit DMX angesprochen werden müssen.
>
> Das verstehe ich nicht.
> Damit wäre ja die erste Frage: WIE müssen diese angesprochen werden?
> Geht es um einen Rückkanal, d. h. bidirektionale Übertragung?
> Andererseits schreibst Du ja oben selbst "unidirektional".
> Für das "gute Gefühl", keine Insellösung™ zu produzieren, würde auch ich
> zu DMX-512 greifen, evtl., falls notwendig, einfach die Anzahl der
> Kanäle "verlängern" bzw. vergrößern und einen Bus mit entsprechenden
> Repeatern zwischendrin benutzen.

Wahrscheinlich würde ich jemand anderem auch zu DMX raten, allerdings 
stellen die paar Assemblerzeilen keine Herausforderung für mir da, es 
geht mir hier darum, die Kosten und die Baugröße klein zu halten. 
Außerdem ermöglicht(e) mein eigenes Protokoll die Nutzung eines 
Bootloaders auf jedem Slaveboard...

> BTW: Guter Baustein für I²C wäre z. B. PCA9685 - aber hier wohl nicht
> relevant.

Wenn ein günstiger "kleiner" Controller am Bus hängt, könnte er die 
Steuerbefehle nach I²C decodieren, verbraucht aber natürlich mehr Platz 
(und Strom) und müsste auf finanziellen Vorteil durchgerechnet werden...

@ EFA
> optiquenz schrieb:
>>
>> LED-Ketten werden normalerweise über Festspannung angesteuert (allein
>> der konstanten Wellenlänge wegen) und verbrauchen abhängig von ihrer
>> Länge unterschiedlich viel Strom. KSQ ist keine Option.
>
> äh, einfach ein mosfet dran und damit die ledketten mit konstanter
> spannung betreiben? beispiele gibt es im netz genug.
>
> Weiteres beispiel: PCA9685


12 bit, 16 Channel. Knapp daneben, sorry...

optiquenz schrieb:
> @ EFA
>
> 12 bit, 16 Channel. Knapp daneben, sorry...


Vielleich 2 oder mehr Bausteine verwenden? Zwischen 12 und 16 Bit wirst 
du keinen Unterschied sehen, das kann ich aus eigener Erfahrung 
bestätigen. Auch mit Gamma-Korrektur. Offensichtlich hast du in dem 
Gebiet noch keine Praktischen Erfahrungen, also mach es dir nicht 
schwieriger als es ist.

optiquenz schrieb:
> Die Kettensegmente sind teils nur 16 cm lang (kleinste Teilung) und
> befinden sich in unmittelbarer Nähe zum Slaveboard.

Gut, das ändert die Sache natürlich.
Mit Mikrocontrollern wird's hier wirklich dünn; ich kann hier leider 
auch nur mit den (bereits erwähnten) STM32 dienen.
Wie wäre es mit dem umgekehrten Weg: z. B. 40 Kanäle pro Knoten/Platine 
und diese per FPGA erzeugen?

optiquenz schrieb:
> Außerdem ermöglicht(e) mein eigenes Protokoll die Nutzung eines
> Bootloaders auf jedem Slaveboard...

Gut, DAS könnte ein Argument für etwas Selbstgestricktes sein...
Andererseits:
- Gab es doch irgendwo am Anfang des DMX-Frames eine ID, die per default 
0 ist (Bezeichnung grad vergessen) -> Mit abweichenden IDs könnte man 
DMX sehr schön "missbrauchen", um z. B. Konfigurationseinstellungen 
(Gamma-Tabelle) zu übertragen - Ist tatsächlich ein Bootloader je Knoten 
notwendig, oder reicht die Parametrierbarkeit?
- Ist DMX alles andere als ein komplexes Protokoll; simpler geht es 
eigentlich nicht mehr. Protokoll-Eigenbau lohnt sich daher wohl nur in 
der umgekehrten Richtung, d. h. mehr Komplexität notwendig (Höhere 
Übertragungssicherheit, Rückkanal/Quittierung, "echter" Bootloader)

optiquenz schrieb:
>> BTW: Guter Baustein für I²C wäre z. B. PCA9685 - aber hier wohl nicht
>> relevant.
>
> Wenn ein günstiger "kleiner" Controller am Bus hängt, könnte er die
> Steuerbefehle nach I²C decodieren, verbraucht aber natürlich mehr Platz
> (und Strom) und müsste auf finanziellen Vorteil durchgerechnet werden...

Naja, in dem Fall ist das höchstwahrscheinlich Käse - wollte nur der 
Vollständigkeit halber erwähnt sein.

@ EFA
> optiquenz schrieb:
>> @ EFA
>>
>> 12 bit, 16 Channel. Knapp daneben, sorry...
>
> Vielleich 2 oder mehr Bausteine verwenden? Zwischen 12 und 16 Bit wirst
> du keinen Unterschied sehen, das kann ich aus eigener Erfahrung
> bestätigen. Auch mit Gamma-Korrektur. Offensichtlich hast du in dem
> Gebiet noch keine Praktischen Erfahrungen, also mach es dir nicht
> schwieriger als es ist.

Bei der Gelegenheit möchte ich dir 
http://www.mikrocontroller.net/articles/LED-Fading ans Herz legen, denn 
bei extrem langsamen Überblendungen macht es einen Unterschied. Deine 
praktische Erfahrung in Ehren.

Patrick schrieb:
> optiquenz schrieb:
>> Die Kettensegmente sind teils nur 16 cm lang (kleinste Teilung) und
>> befinden sich in unmittelbarer Nähe zum Slaveboard.
>
> Gut, das ändert die Sache natürlich.
> Mit Mikrocontrollern wird's hier wirklich dünn; ich kann hier leider
> auch nur mit den (bereits erwähnten) STM32 dienen.
> Wie wäre es mit dem umgekehrten Weg: z. B. 40 Kanäle pro Knoten/Platine
> und diese per FPGA erzeugen?

Klingt eigentlich super, nur leider kenn ich von FPGAs nicht mehr als 
die grobe theoretische Zusammenfassung ihrer Funktion :/ Und von 
günstigen Preisen habe ich in dem Zusammenhang auch noch nichts 
gelesen...

> optiquenz schrieb:
>> Außerdem ermöglicht(e) mein eigenes Protokoll die Nutzung eines
>> Bootloaders auf jedem Slaveboard...
>
> Gut, DAS könnte ein Argument für etwas Selbstgestricktes sein...
> Andererseits:
> - Gab es doch irgendwo am Anfang des DMX-Frames eine ID, die per default
> 0 ist (Bezeichnung grad vergessen) -> Mit abweichenden IDs könnte man
> DMX sehr schön "missbrauchen", um z. B. Konfigurationseinstellungen
> (Gamma-Tabelle) zu übertragen - Ist tatsächlich ein Bootloader je Knoten
> notwendig, oder reicht die Parametrierbarkeit?
> - Ist DMX alles andere als ein komplexes Protokoll; simpler geht es
> eigentlich nicht mehr. Protokoll-Eigenbau lohnt sich daher wohl nur in
> der umgekehrten Richtung, d. h. mehr Komplexität notwendig (Höhere
> Übertragungssicherheit, Rückkanal/Quittierung, "echter" Bootloader)

Durchaus richtig, an dieser Stelle aber nicht von Bedeutung, da ich mir 
erst mit der PWM-Hardware sicher sein muss, bevor ich mir konkrete 
Gedanken über die praktische Ausgestaltung des Protokolls mache...

> optiquenz schrieb:
>>> BTW: Guter Baustein für I²C wäre z. B. PCA9685 - aber hier wohl nicht
>>> relevant.
>>
>> Wenn ein günstiger "kleiner" Controller am Bus hängt, könnte er die
>> Steuerbefehle nach I²C decodieren, verbraucht aber natürlich mehr Platz
>> (und Strom) und müsste auf finanziellen Vorteil durchgerechnet werden...
>
> Naja, in dem Fall ist das höchstwahrscheinlich Käse - wollte nur der
> Vollständigkeit halber erwähnt sein.

Trotzdem danke ;)

optiquenz schrieb:
> @ EFA
> Bei der Gelegenheit möchte ich dir
> http://www.mikrocontroller.net/articles/LED-Fading ans Herz legen, denn
> bei extrem langsamen Überblendungen macht es einen Unterschied. Deine
> praktische Erfahrung in Ehren.

Schlechtes Beispiel, in diesem Beispiel wird eine 12-Bit-PWM nicht 
erwähnt.
Nicht ohne Grund haben die meisten KSQs eine dimming range um die 1000:1 
bis 5000:1.....

Die Empfehlung an der Stelle war auch nur, das wirklich mal 
auszuprobieren, bevor man solche Annahmen trifft. Eine Gammakorrektur 
(bzw. das höhere Ziel des gleichmäßigen Dimmens) hängt ja auch stark von 
den verwendetetn Teilen bzw den Kennlinien der LEDs ab. Deswegen lohnt 
es, solche Annahmen im Vorfeld zu verifizieren.

Max G. schrieb:
> Mit einem µC mit 25 MHz kannst du also eine Main Loop
> bauen, die eine Soft-PWM in 38 Takten realisiert.

Beim Avr schafft es in 9 Takten im Interrupt (mit maximaler 
Optimierung). Dafür benötigt man Loop-unrolling (20-fach) und eine 
Jitter-Korrektur. Damit wäre dann die 14bit PWM @136Hz machbar. Halbiert 
man die Wiederholfrequenz kann man auch 15bit schaffen. Mit dem Xmega 
wären 16bit @54Hz oder 15bit @109Hz möglich.

Hmm, viele viele Vorschläge, aber sie liegen noch zu weit von meiner 
Vorstellung entfernt.

Ich will schon meine 20 Channel 16 bit Hardware PWM ^^

Gerade zum xten mal gesucht und den ATxmega64A3U bei Digikey für 1,86 € 
das Stück (bei n>100) gefunden. Besser/exakter wirds wohl nicht mehr, 
was?

Mit einer Mischung aus Soft- und Hardware-PWM ist es noch einfacher 
machbar:
Bspw.: Atxmega16d4 mit 14 PWM-Kanälen. 12x HW-PWM - 8xSoft-PWM. Kosten 
unter 2€. Die Soft-PWM Frequenz kann bei guter Implementierung bei 160Hz 
liegen.

optiquenz schrieb:
> 16 bit Hardware PWM

Bei richtiger Implementierung ist da absolut kein Unterschied vorhanden. 
Jetzt musst du dich entscheiden zwischen günstig und wenig 
Programmieraufwand.

avr schrieb:
> Mit einer Mischung aus Soft- und Hardware-PWM ist es noch einfacher
> machbar:
> Bspw.: Atxmega16d4 mit 14 PWM-Kanälen. 12x HW-PWM - 8xSoft-PWM. Kosten
> unter 2€. Die Soft-PWM Frequenz kann bei guter Implementierung bei 160Hz
> liegen.


Ich hätte wohl noch erwähnen sollen, dass die PWM-Frequenz schon 
vierstellig sein sollte, Regenbogeneffekt/Flimmern muss im Wohnzimmer 
nicht sein.

Tut mir leid, dass diese Info erst jetzt kommt...

Ja, die Beratungsresistenz und Esoterik-Affinität schonmal auf dem 
gleichen Niveau.

@ Max G.
> Das musst du mir erklären, wie das Auge Frequenzen bis 1 kHz wahrnehmen
> kann. Ich bin mir sicher, dass du auch bei 100 Hz kein Flimmern sehen
> wirst. Sonst gäbe es ja einen Markt für 1 kHz-Fernseher, ich habe aber
> immer nur 100 Hz-Teile gesehen.

Es gibt schon lange 400 Hz-TVs und wenn du einen  Führerschein besitzt, 
wird dir in den letzten Jahren sicher schon mal ein Auto mit 
LED-Bremslichtern aufgefallen sein, die bei "bewegtem Blick" flackern, 
weil sie zur Helligkeitssteigerung gepulst werden, was du selbst bei 5 
kHz noch wahrnehmen kannst, wenn du drauf achtest.
LEDs kann man als superflinke Luminenzstrahler bis in den MHz-Bereich 
modulieren und wenn du 100 Hz da nicht wahr nimmst, würd ich ganz 
schnell den Besuch beim Optiker/Neurologen empfehlen.

> Mein Eindruck ist, dass du dich gerade in etwas verrennst. 20+ Timer
> gibt es nur in den großen 32-Bit-µCs, z.B. LPC2900. Oder du nimmst ein
> FPGA/CPLD. Dann musst du es aber auch zahlen.

Wie schon geschrieben, ist das beste, was ich bisher gefunden hab, ein 
ATxMega64A3U, ein 8-Bitter mit 7 16-bit Timern und insgesamt 22 
Compare-Interrupts, das ganze für 1,86 € das Stück. 32-Bit-µC? Wozu?


Besser wirds wohl wirklich nicht mehr, dann muss es eben 3,3 V sein. 
Trotzdem danke ich allen für ihre Hilfe, ich habe das Gefühl, eine gute 
Lösung für mein Problem gefunden zu haben.

@ Frank K.
> http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en557404
>
> 16* 16bit PWM laut Datenblatt, ich glaube, viel besser wirst Du es nicht
> bekommen, wenn Du Dir nicht einen eigenen Chip bauen lässt.

4 PWM zu wenig für 5 € das Stück? Nein danke.

Hallo,

komisch, dass es bisher noch nicht erwähnt wurde:

Nimm nicht PWM, nimm BCM (Bit Coded Modulation). Damit ist mit einem 16 
MHz ATMega/ATTiny 24 * 16 Bit mit 244 Hz Grundfrequenz darstellbar 
(wobei in der Regel ein Vielfaches der Grundfrequenz während des Dimmens 
auftritt, lediglich bei Dimmstufe 1,2,4,8,...32768 schlägt die durch). 
Kann jedenfalls neben einem 3D-TV betrieben werden, ohne dass es durch 
die Shutter-Brille flimmert.

Ach ja, wenn Deine Stromquelle schnell genug ist (muss dann auch 16 MHz 
können...)


Zu finden unter

http://www.ledstyles.de/ftopic18687.html

Schöne Grüße,
Martin

Bei PWM kann man anscheinend sehr gut aneinander vorbeireden, einerseits 
bezüglich Frequenz/Stufenzahl, andererseits bei Einsatzzweck 
(Bilddarstellung/Dekoration/Signalisierung/Beleuchtung) und Umgebung 
(Tageslicht... Dunkelheit).

Zur Frequenz: das Auge ist da im Randbereich empfindlicher als in der 
Mitte. Und Flimmern fällt bei Bewegung stärker auf. Und wenn die 
Flimmerquelle die einzige Lichtquelle ist. Und dann spielt 
Gewohnheit/Übung auch noch eine Rolle.
Ein Fernseher im angemessen beleuchteten Zimmer hat es da also leicht: 
zentral im Blickfeld, weder der Betrachter noch das Gerät bewegen sich. 
Gegenbeispiel ist das Auto-Rücklicht, wenn es sich im peripheren 
Gesichtsfeld bewegt und dabei die einzige Lichtquelle weit und breit 
ist.

Dazu zwei eigene Erfahrungen: vor Zeiten hat sich ein Kommilitone über 
die flimmernden Computermonitore (60Hz) in der Uni beschwert, während 
ich sie sehr stabil fand. Damals hatte ich zu Hause 60Hz am Computer und 
50 am Fernseher; für mich waren 60Hz also OK, während er von der Arbeit 
85Hz gewohnt war. Als ich dann selber zu Hause 85Hz und bei der Arbeit 
100Hz hatte, fand ich die 50Hz vom Fernseher unerträglich, und 60Hz sah 
mir wackelig aus.
Und dann ist da noch die Tastaturbeleuchtung am neuen Laptop, die mit 
100Hz flimmert und damit praktisch unbrauchbar ist. Jedenfalls wenn ich 
damit abends auf dem Sofa sitze, es allmählich immer dunkler wird, und 
sich der Laptop gelegentlich in meinem Gesichtsfeld bewegt, weil ich 
mich nach Getränk, Knabberkram oder irgendeinem Kabel bücke. Und selbst 
das wäre mir nicht als Mangel aufgefallen, wenn das Vorgängermodell 
nicht eine absolut flimmerfreie Tastaturbeleuchtung gehabt hätte.

Also 100Hz mag für Bildschirme angehen, und für irgendwelchen Spielkram 
oder Kontrolleuchten, auf die man nur selten oder nur in gut 
beleuchteter Umgebung sieht, aber zur Beleuchtung halte ich das für 
ungeeignet, sofern sich in dem so beleuchteten Raum irgendetwas auch mal 
bewegen soll.

Zu den Abstufungen: angeblich hat das menschliche Auge da eine Auflösung 
von 8bit. Nur ist die Skala nicht linear (Gammakurve) und bezieht sich 
auf das gesamte Blickfeld, weshalb die ideale Gammakurve eines 
Bildschirms immer von der Umgebungshelligkeit abhängt.

Auf dem gut beleuchteten Schreibtisch reicht eine 8bit-PWM meiner 
Erfahrung nach, um eine gewohnliche 5mm-matt-LED "stufenlos" zu dimmen; 
die Gammkurve ist dann nötig, damit einem im Bereich über 150 nicht 
langweilig wird. Das liegt hauptsächlich daran, daß die LED bei Stufe 0 
nicht komplett schwarz wird.
Wenn man das Licht ausmacht, sieht die Sache natürlich ganz anders aus.

Für die Raumbeleuchtung ist das natürlich einerseits einfacher, weil man 
ohne Rücksicht auf Umgebungshelligkeit immer dieselbe Gammakurve 
verwenden kann, denn die Raumbeleuchtung ist ja die 
Umgebungshelligkeit... andererseits hat man das Problem, daß es bei 
Stufe 2 immer doppelt so hell ist wie bei Stufe 1, und daß man das 
immer sehen kann, egal wie fein die Stufen sind. Naja, fast egal, 
irgendwo hat auch das Auge seine untere 
Wahrnehmungsschwelle/Rauschgrenze.
Ich fürchte, 16bit sind da noch lange nicht zu viel verlangt.

Falk Brunner schrieb:
>Naja, auch hier muss man GANZ klar zwischen Röhrenmonitor und TFT
>unterscheiden. Die meisten TFTs laufen "nur" mit 60 Hz, flimmern aber
>praktisch nicht, weil die TFT-Zellen ihren Pegel halten. Hier fillmert
>bei einem statischen Bild gar nichts!

OK, da habe ich zu erwähnen vergessen, daß das natürlich alles 
Röhrenmonitore waren. Daß bei korrekt angesteuerten LCDs höchstens die 
Hintergrundbeleuchtung (und dann meist nicht mit der Bildfrequenz) 
flimmert, ist klar.

>>langweilig wird. Das liegt hauptsächlich daran, daß die LED bei Stufe 0
>>nicht komplett schwarz wird.
>
>Dann ist deine PWM unzureichend programmiert. Ja, der AVR hat hier ein
>kleines Problem, aber das ist lösbar. Die Suche im Forum ist dein
>Freund.

Noch eine Verdeutlichung scheint nötig: "nicht komplett schwarz" heißt 
nicht, daß da noch irgendetwas leuchtet. Sondern, daß die LED, wie alles 
andere auf dem Tisch, beleuchtet ist und aufgrund ihrer Material- und 
Oberflächeneigenschaften nicht alles Licht absorbiert. Eine 
ausgeschaltete matte LED sieht also bei guter Beleuchtung irgendwie grau 
aus (und nicht schwarz, wie z.B. viele IC-Gehäuse). Ob zu diesem grau 
dann eine oder zwei Stufen PWM-Helligkeit dazukommen, macht eben keinen 
so großen Unterschied wie im Dunkeln.

>Du vermischt hier massiv diverse Dinge. Und morgen müssen es 24 Bit PWM
>sein, so wie es bei Digital Audio schon lange der Fall ist (über dessen
>Wert man vortrefflich streiten kann).

Nun, irgendwo müssen deine 140dB ja herkommen. Mit 16bit erreicht man 
die jedenfalls nicht.              :)