Bastle an einer Moodlampe rum. Drei RGB-LEDs (Seoul P5) werden jeweils von einem Mega8@16MHz angesteuert. Das Programm zählt in zwei Registern von 0 bis 1023 hoch und aktiviert bei jedem Überlauf alle PWM-Pins (wenn Helligkeitswert ungleich Null). Eine andere Routine fragt ständig ab, ob der Zähler den zum Helligkeitswert entsprechenden Wert (abgelegt in einer Tabelle) erreicht hat und schaltet den passenden PWM-Pin ab. In der Tabelle steigt die Pulsweite exponentiell. Das funktioniert alles prima. Die drei Mega8 werden von einem Mega16 durch SPI mit Helligkeitswerten gespeißt. An den Mega16 sind auch alle Taster und der Drehencoder angeschlossen. (Ich weiß, dass die Mega8 hier ein Overkill sind ... aber die Hardware ist schon verlötet und daran ist nichts mehr zu ändern). Jetzt gibt es einen Modus, in welchem die LEDs einer Sinuskurve folgend die Helligkeit ändern. Und genau hier stört mich diese relativ grobe Auflösung. Hätte nicht gedacht, dass 64 Stufen zu wenig sein könnten. Vielleicht könnte ich noch 128 Stufen rausquetschen, aber ab 12 Bit wird das Flimmern dann schon erkennbar. Könnte man das mit Spulen beseitigen? Bevor ich jetzt anfange alles zu verändern, würde ich geren wissen, ob 128 Stufen überhaupt eine deutliche Besserung gegenüber 64 wären. Welche Auflösung sollte man für eine Moodlampe nehmen? Hängt wahrscheinlich auch von der maximalen Helligkeit ab, oder?
Für einen wirklich fließenden Übergang solltes es schon mindestens 8bit sein. Probiers mal aus: Zeige am PC einfach einen Farbbalken an, mit jeweils 64, 128 oder 256 Farben. Bei 64 Farben sieht man deutlich die Stufen (je nach Monitor natürlich unterschiedlich stark). Bei 256 auch noch wenn man genau sucht.
Maxim S. wrote: > Jetzt gibt es einen Modus, in welchem die LEDs einer Sinuskurve folgend > die Helligkeit ändern. Und genau hier stört mich diese relativ grobe > Auflösung. Der Fehler ist nicht die Auflösung, sondern die Sinusfunktion ansich. Eine Sinusfunktion widerspricht völlig dem menschlichen Helligkeitsempfinden. Gibt man einen Sinus auf eine LED, hat man zu Anfang einen sehr starken Anstieg des Helligkeitseindrucks und dann über weite Bereiche eine fast konstante Helligkeit. Ein Erhöhung der Auflösung nützt also genau 0,nix. Peter
Hallöchen Ich habe vor kurzem auch eine LED gedimmt. Für das PWM hab ich 10 Bit verwendet. Um den unlinearen Anstieg der Lichtstärkre auszugeleichen habe ich diesen Code verwendet: ------------------------- ' Lichtstärke endlos von 0 auf 100% If Pwm_level <= 1020 Then Select Case Pwm_level Case 0 To 768 : Pwm_level = Pwm_level + 16 Case 769 To 896 : Pwm_level = Pwm_level + 4 Case 897 To 1023 : Pwm_level = Pwm_level + 2 ' + 1 End Select Else Pwm_level = 0 End If ------------------------- Vielleicht hilfts hmg Mandi
> Der Fehler ist nicht die Auflösung, sondern die Sinusfunktion ansich. > > Eine Sinusfunktion widerspricht völlig dem menschlichen > Helligkeitsempfinden. > Gibt man einen Sinus auf eine LED, hat man zu Anfang einen sehr starken > Anstieg des Helligkeitseindrucks und dann über weite Bereiche eine fast > konstante Helligkeit. > > Ein Erhöhung der Auflösung nützt also genau 0,nix. > > > Peter Ich weiß, was du meinst. Du hast aber überlesen oder nicht verstanden, dass die Helligkeit auf die 64 Stufen nicht linear, sondern exponentiell verteilt ist. Erhöht man die Helligkeitsstufe kontinuierlich, so steigt auch die wahrgenommene helligkeit etwa linear. Die Sinusfunktion steuert nicht die Pulsweite direkt, sondern die Helligkeitsstuffe. Das Resultat ist eine wahrnehmbare Sinusfunktion. Außerdem sieht man die einzelnen Stufen auch dann, wenn man die Helligkeit selber mit dem Drehencoder reguliert. > Für einen wirklich fließenden Übergang solltes es schon mindestens 8bit > sein. Probiers mal aus: Zeige am PC einfach einen Farbbalken an, mit > jeweils 64, 128 oder 256 Farben. Bei 64 Farben sieht man deutlich die > Stufen (je nach Monitor natürlich unterschiedlich stark). Bei 256 auch > noch wenn man genau sucht. 8 Bit -> 256 Stufen, klingt verlockend, aber wie soll man das realisieren? Das Augen nimmt die Helligkeit logarithmisch wahr. Für lineare Helligkeitsverteilung auf die 256 Stufen bräuchte ich eine wesentlich höhere PWM-Auflösung, etwa bis 16 Bit. Welche uC schafft es, etwa 100 Mal in der Sekunde ein Register von 0 bis 65000 durchzuzählen, gleichzeitig drei PWM-Kanäle zu bedienen und noch ein paar kleinere Aufgabe zu erledigen? Eine 16-bittige CPU mit etwa 25MHz? Aber es wäre eben sehr schade um die Hardware, die ich schon aufgebaut habe. Also zusammengefasst lohnt sich die Arbeit gar nicht, um auf 128 Stufen zu kommen?
Lies dir mal den Wiki Artikel hier von der Seite zum Thema LED-Fading durch, da wird eine sehr effiziente software PWM vorgestellt, die deinen Ansprüchen genügen sollte.
Hauke Radtki wrote: > Lies dir mal den Wiki Artikel hier von der Seite zum Thema LED-Fading > durch, da wird eine sehr effiziente software PWM vorgestellt, Wo ? Ich sehe da nur Hardware PWM.
Hauke Radtki wrote: > Lies dir mal den Wiki Artikel hier von der Seite zum Thema LED-Fading > durch, da wird eine sehr effiziente software PWM vorgestellt, die deinen > Ansprüchen genügen sollte. Danke für den Hinweis. Meine Lösung ist jedoch noch effizienter, da sie ohne Timer auskommt und keinen Takt ungenutzt lässt. In dem Wiki wird auch nur eine 8-bittige PWM realisiert ... Ich brauche mindestens 12 Bit, wenn nicht mehr. Vor langer Zeit hat jemand mal einen Vorschlag gemacht, die PWM als eine Zustandsmaschine zu realisieren. Aber ich habe nicht so recht verstanden, wie das funktionieren soll. Geht es wirklich noch effizienter, als meine Lösung?
Ups, hatte ich falsch in Erinnerung, hier der richtige Artikel: http://www.mikrocontroller.net/articles/Soft-PWM Die letzte PWM-Variante ist wohl ziemlich Effizient, auf jeden fall effizienter als deine ;)
Hauke Radtki wrote: > Ups, hatte ich falsch in Erinnerung, hier der richtige Artikel: > http://www.mikrocontroller.net/articles/Soft-PWM > > Die letzte PWM-Variante ist wohl ziemlich Effizient, auf jeden fall > effizienter als deine ;) Ja, das ist schonmal was. :) 16.000.000 Hz / 65536 = 244 Hz Falls diese Rechnung aufgeht, könnte eine 16-bit-PWM bei mehr als 200 Hz laufen. Das klingt zu schön, um wahr zu sein. Aber selbst die Hälfte wäre super. Dann mach ich mich mal an die Arbeit. ps: Dieser Ansatz erinnert mich an den Vorschlag mit der Zustandsmaschine. Dort sollten ebenfalls Zeitpunkte berechnet werden, wann der nächste PWM-Kanal abzuschalten ist ...
@ Maxim S. (maxim) Benutzerseite >> Die letzte PWM-Variante ist wohl ziemlich Effizient, auf jeden fall >> effizienter als deine ;) Ja, aber 16 Bit kann man da vergessen. >Ja, das ist schonmal was. :) 16.000.000 Hz / 65536 = 244 Hz >Falls diese Rechnung aufgeht, könnte eine 16-bit-PWM bei mehr als 200 Hz >laufen. Das klingt zu schön, um wahr zu sein. Eben. Ist es auch ;-) >Zustandsmaschine. Dort sollten ebenfalls Zeitpunkte berechnet werden, >wann der nächste PWM-Kanal abzuschalten ist ... Es geht einfacher. Man muss nur den richtigen Artikel erwischen. LED-Fading Soft-PWM 8 Bit reicht, 10 Bit ist schon fast Luxus. Das kann man mit Soft-PWM schaffen. MFG Falk
Es gibt ein Problem, wenn ein PWM-Kanal sofort nach dem anderen abgeschaltet werden soll (z.B. Rot bei Timer = 35.000 und Blau bei 35.002), weil der uC in die ISR springt und der Timer nach der Rückkehr aus der ISR schon über den Wert des zweiten PWM-Kanals drüber ist. Wenn ich den Timer während der ISR anhalte, wird sich das vor allem auf sehr kurze Puslweiten auswirken. Die kürzeste Pulsweite wäre also die Dauer der ISR und das sind grob geschätzt auch schon mindestens 100 Takte (Assembler). 65000/100 oder 650:1 wäre das kleinste Verhältnis und entspräche der niedrigsten Leuchtstufe, was in Wirklichkeit aber schon ziemlich hell wäre (für die niedrigste Stufe). Trotzdem ist der Ansatz vielversprechend, hoffentlich wird's was.
> 8 Bit reicht, 10 Bit ist schon fast Luxus. > Das kann man mit Soft-PWM schaffen. Beziehen sich die 8 Bit auf den Zähler oder auf die Helligkeit? 8 Bit Helligkeit würde mir ausreichen, immerhin 256 Helligkeitsstufen. Aber um diese fürs Auge linear aussehen zu lassen, braucht man dann eben doch ein Vielfaches davon. Die Artikel habe ich ja alle schon gelesen.
Sortieren in Assembler (AVR) ist gar nicht so ohne. Mit einem Haufen Verzweigungen ist das zwar machbar, aber irgendwie zu einfallslos. Überlege gerade folgendes: R-G -> C1 = Carry R-B -> C2 = Carry G-B -> C3 = Carry Nach jeder Operation wird das Carry-Bit gesichert. Die Werte in R, G und B sollen vor der Subtraktion in temporäre Register, sodass ihr Wert unverändert bleibt. Es zählt ja nur das Carry-Bit, welches gesetzt wird, falls bei der Subtraktion ein Underflow stattfindet. Dann kann man die Bits C1 bis C3 in ein Register schieben und dieses als Offset für einen indirekten Sprung nutzen. Beim jeweiligen Sprungziel ist dann ja schon bekannt, welche Farbe den höchsten/niedrigsten Wert hat. Dann muss nur noch auf Gleichheit geprüft werden (oder vielleicht sogar vor dem indirekten Sprung?).
@ Maxim S. (maxim) Benutzerseite >> 8 Bit reicht, 10 Bit ist schon fast Luxus. >> Das kann man mit Soft-PWM schaffen. >Beziehen sich die 8 Bit auf den Zähler oder auf die Helligkeit? Auf den Zähler. Damit hat man dann 32 Helligkeitsstufen. Das passt schon ganz gut. > 8 Bit >Helligkeit würde mir ausreichen, immerhin 256 Helligkeitsstufen. Das schafft man rein rechnerisch nicht mal mit ner 16 Bit PWM. UNd wie bereits gesagt, in Software ist bei ca. 10 Bit Schluss. Siehe Artikel, dort ist das vorgerechnet. >ein Vielfaches davon. Die Artikel habe ich ja alle schon gelesen. Und auch verstanden? ;-) Falk
Man kann auch eine Tabelle mit 256 Hlligkeitsstufen und 10 Bit PWM Auflösung benutzen. Allerdings werden dann nicht mehr alle Stufen zu verschiedenen PWM Werten führen. Bei den geringen Helligkeiten werden ein paar fehlen, aber bei den höheren Helligkeiten passiert nichts. Mit Hardware PWM wäre auch 16 Bit PWM drin. Aus einem 8 Bit Hardware PWM Kanal läßte sicher per Software ein 16 Bit Kanal machen, indem man zwischen zwei PWM werten hin und her schaltet so wie sonst beim Soft PWM. Wenn man wirklich beim Software PWM bleiben will, kann man noch fast 1 Bit gewinnen, wenn man am Anfang einen halb-langen Zeitschritt einfügt. Die LEDs fangen dann halt nicht ganz syncron an, sondern zum Teil etwas später.
@ ulrich (Gast) >Mit Hardware PWM wäre auch 16 Bit PWM drin. Aus einem 8 Bit Hardware PWM >Kanal läßte sicher per Software ein 16 Bit Kanal machen, indem man >zwischen zwei PWM werten hin und her schaltet so wie sonst beim Soft >PWM. Nur dass dann die effektive PWM-Frequenz ziemlich niedrig ist, 1 Hz und weniger! MFG Falk
Ja ich bin gerade an einer Assembler-Version der "intelligenten Lösung" (http://www.mikrocontroller.net/articles/Soft-PWM#Intelligenter_L.C3.B6sungsansatz) dran. Möglicherweise haue ich mit Assembler noch etwas an Leistung raus. Muss allerdings ziemlich rumtricksen. Vielleicht schaffe ich es, die Timer-ISR auf weniger als 10 Takte zu drücken, indem so viel wie möglich außerhalb der ISR errechnet wird und in der ISR nur noch ein indirekter Sprung und ein OUT-Befehl abgearbeitet werden müssen. Dann dürfte die Abweichung wegen des gestoppten Timers während der ISR nicht so große Auswirkung auf die niedrigsten Helligkeitsstuffen haben. Die 65536 Timerwerte verteile ich mit y=1.044451146^x-1 auf die 256 Helligkeitsstufen: X Y gerundet 0 0 1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 9 0 10 1 11 1 12 1 13 1 14 1 15 1 16 1 17 1 18 1 19 1 20 1 21 1 22 2 23 2 24 2 25 2 26 2 27 2 28 2 29 3 Y ist also der Timerwert. Die ersten acht Stufen sind also identisch in der Helligkeit. So gesehen sind 256 Stufen bei einer intern 16-bittigen PWM zu viel. Diese Lösung wird im unteren Helligkeitsbereich also fast genauso grob arbeiten, wie die 10-Bit-Variante. Aber bei den höheren Helligkeiten sollte es trotzdem besser werden. Welche ICs können hardwareseitig 16-Bit-PWM? Nur so, für's nächste Projekt ...
@ Maxim S. (maxim) Benutzerseite >dran. Möglicherweise haue ich mit Assembler noch etwas an Leistung raus. Ich geb dir mal bestenfalls 30% Einsparung, macht dann 70 statt 100 Takte. >Timer-ISR auf weniger als 10 Takte zu drücken, indem so viel wie möglich Na das wollen wir mal sehen. Allein das Anspringen dauert 4 Takte, das Reti ebenso. Bleiben noch 2 für deine "ISR". Ein Out und ein Pointerincement ;-) >Sprung und ein OUT-Befehl abgearbeitet werden müssen. Dann dürfte die >Abweichung wegen des gestoppten Timers während der ISR nicht so große >Auswirkung auf die niedrigsten Helligkeitsstuffen haben. Der Timer muss gar nicht gestoppt werden. Deine PWM ist aber dennoch meilenweit von 16 Bit entfernt. Denn 16 MHz/ 10 (Takte / ISR) /100 (Hz) = 1600 ISRs pro PWM-Periode. Sind nicht mal 11 Bit Auflösung. Real sind wie bereits gesagt bestenfalls 10 Bit drin, alles andere ist schlicht nicht machbar. Nimm einen Spezial-IC oder CPLD. Die 65536 Timerwerte verteile ich mit >der Helligkeit. So gesehen sind 256 Stufen bei einer intern 16-bittigen >PWM zu viel. Diese Lösung wird im unteren Helligkeitsbereich also fast Nicht wahr? Steht sogar im Artikel ;-) >genauso grob arbeiten, wie die 10-Bit-Variante. Aber bei den höheren >Helligkeiten sollte es trotzdem besser werden. Aber genau der Bereich ist unkritisch, der Logarithmus lässt grüssen ;-) >Welche ICs können hardwareseitig 16-Bit-PWM? Nur so, für's nächste >Projekt ... Nimm nen kleinen Tiny2313 für jede LED. MFg Falk
> Nimm nen kleinen Tiny2313 für jede LED.
Gibt's keine kleineren uCs, die 16-bit-PWM können? Ein 8-pinner wäre
schon deutlich besser. Aber eigentlich müsste es doch speziell dafür
ausgelegte ICs geben, die gleich mehrere Kanäle haben?!
Wäre es hier nicht einfacher, pro Farbkomponente 2 Ausgänge zu nehmen, so dass die Helligkeit nicht nur über PWM geht sondern auch über die angesteuerten Ausgänge? Damit hätte man 4 Stufen, wenn man unterschiedliche Widerstände nimmt. Der kleiner R würde hell machen und der grosse könnte zum Feintunen dienen. Ist wohl etwas schwerer zu kalibrieren, aber spart das Rumgefrickel in der Software.
Der MBI5030 wäre bestens für solche Aufgaben geeignet, aber ich finde niemanden, der ihn in Deutschland verkauft.
Der hat nur eine 12-bittige Auflösung und die Verfügbarkeit scheint auch nicht besser zu sein.
kannst dir 5 sample bestellen. Oder direct bei Ti bestellen. lg, markus
5 Samples? Wo? Durch die Webseite von TI habe ich einen Distributor in Europa gefunden. Der verkauft allerdings erst ab 50 Stück.
Hab's gefunden. Irgendwie ist das zu schön, um wahr zu sein. Aber vielleicht klappt's ja.
Im Datenblatt des TLC5943 steht, dass er intern einen Schmitt-Trigger am Takteingang hat. Ist also nicht für einen Quarz-Schwingkreis geeignet? Wie soll man den Takt dann erzeugen? Extra einen Tiny dafür nehmen?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.