Moin moin, ich suche nach einer kompakten Darstellung/Gegenüberstellung der Features und Daten der Atmel-Mikrocontroller? Wo kann ich eine solche Liste finden ? Vielen Dank schonmal im Voraus! Frohes neues Jahr! Gruß mcc
vielleicht beim Hersteller der Atmel-Mikrocontroller? guckst Du hier: www.atmel.com
Hi http://www.atmel.com/dyn/products/param_table.asp?family_id=607&OrderBy=part_no&Direction=ASC MfG Spess
Und immer noch dran denken: Atmel macht auch noch jede Menge sehr guter 8051er-µCs, nicht nur AVRs. (Denn es wurde ja nach Atmel-µCs gefragt) Hermann
Hi >Und immer noch dran denken: >Atmel macht auch noch jede Menge sehr guter 8051er-µCs, nicht nur AVRs. ist doch kein Problem http://www.atmel.com/dyn/products/param_table.asp?family_id=604&OrderBy=part_no&Direction=ASC http://www.atmel.com/dyn/products/param_table.asp?family_id=682&OrderBy=part_no&Direction=ASC http://www.atmel.com/dyn/products/param_table.asp?family_id=605&OrderBy=part_no&Direction=ASC MfG Spess
Hallo, OH YEAH! Herzlichen Dank! Das hat sehr geholfen ! :) Gruß mcc
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.
Vlad Tepesch schrieb: > AVR im DIP, der günstig und leicht > zu beschaffen ist > In den ganzen Tabellen hab ich keinen gefunden. Diese Kombination von Informationen wird in keiner Tabelle zu finden sein. Vor allem ist fraglich was denn konkret "leicht zu beschaffen" heisst. Es ist mir klar, das Du darauf eine Antwort hast, aber die Tabelle die diese Information enthält wirst Du wohl selbst zusammenstellen müssen.
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.
Hier gibt es mehr Details zu den Typen: http://www.avrfreaks.net/index.php?module=Freaks%20Devices&func=devCompare
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.
Hi! Habe letztens auch vergebens nach solch einem AVR gesucht. 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. http://de.farnell.com/atmel/atmega1284p-pu/mcu-8bit-avr-128k-flash-40pdip/dp/1715481 Das doofe ist nur, dass beide OCUs von einem dieser Timer mit den Pins des SPI-Moduls doppelt belegt sind (OC3A mit MISO und OC3B mit SCK)! Wenn man auf MISO und OC3B verzichtet, kann man dann eigentlich SPI (also nur MOSI und SCK) und den Timer (also nur OC3A) gleichzeitig verwenden? MFG vio
>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). >.... >Eigendlich liegt es ja nahe, für RGB-LED-Anwendungen einen solchen >controller zu bauen. Wozu braucht man so eine Genauigkeit? 8 Bit --> 256 Werte Drei Farben ist 256x256x256=16 Mio. Bunter geht es wohl kaum. Oder habe ich einen Denkfehler?
>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
> 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. > 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.
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
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. Wenn man einen AVR "anständig", also mit 20Mhz taktet, bleiben da noch wahnsinnige 3 Prozessor-Taktzyklen pro PWM-Takt. Das bekommt man nicht mal in einer möglichst kurzen Schleife in Assembler hin, die alles andere blockiert. Man kann sich da durchaus, z.B. mit Software-Erweiterung von 8-Bit-Timern, einige Tricks ausdenken, um's doch hinzubekommen, aber das wird eben, wie schon erwähnt "etwas komplizierter".
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
>Und die Bilder auf meinem Computer-Monitor sind mit 16.7 Mio. moeglichen >Farbkombinatinen auch recht ansehnlich. Hoffentlich erkennen das alle! Selbst wenn man ab PWM 50 bei LED ein Leuchten wahrnimmt, bleiben noch 20Mio übrig. Für eine Beleuchtung im Bad oder der Party mehr als ausreichend. Praktisch reichen 6 Bit aus, mehr braucht kein Mensch. So gut wie nötig, nicht so gut wie möglich!
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
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
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! Es sind physikalisch gesehen tatsächlich 16.7 Millionen Farben, allerdings kann das Auge davon nur sehr wenige unterscheiden, weil keine Linearisierung statt fand! 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! Ein 12bit Timer wäre vllt. auch okay, aber 10bit sind schon wieder knapp und mit 8bit hätten wir wieder überhaupt keine Linearisierung. Stimmt das so?
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
Bitte 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.