Hallo alle miteinander! Ich brauche etwas Unterstützung, um den richtigen µC zu finden: Im Rahmen eines größeren Beleuchtungsprojekts möchte ich für einen unidirektionalen RS-485 Bus ein Slaveboard entwerfen, welches durch Steuerung über ein selbstentwickeltes Protokoll (kein DMX512!) 20 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. 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. Die PWM muss eine Auflösung von 16 bit haben, damit genug Spielraum für Gamma-Korrektur und subjektiv stufenloses Dimmen bleibt. Meine Suchkriterien zusammengefasst: 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. Hauptsache 20 x sauberes PWM und möglichst bezahlbar ;) Fällt da jemandem was zu ein? Darf auch etwas exotischer sein, Beschaffung ist dank guter Quellen kein großes Thema für mich… LG optiquenz
@ optiquenz (Gast) >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? >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. >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. >Die PWM muss eine Auflösung von 16 bit haben, damit genug Spielraum für >Gamma-Korrektur und subjektiv stufenloses Dimmen bleibt. ;-) Jaja. >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. >Hauptsache 20 x sauberes PWM und möglichst bezahlbar ;) TLC5940 & Co haben 16x 12 Bit PWM und 120mA Stromquellen dazu.
@ 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...
@ optiquenz (Gast) >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. Dann entwickelt man aber nciht einfach mal ein neues Protokoll sondern nimmt so weit wie möglich was fertiges! >> Doch. Nimm einfach zwei getrennte Busse. >Nicht gerade das, was ich mir unter Optimierung von Kosten und Aufwand >vorstelle. Aber ein Protokoll selber stricken wollen? >Da kommen nach meinen Suchergebnissen nur >100 pins in Frage. Ziemlicher >Overkill zum dimmen von 6 RGB- und 2 WW-Ketten... Was willst du? Einen optimal abgestimmten 16 Bit PWM-IC mit 20 Kanälen? Hmm, vielleicht gibt es den, vielleicht nicht. >In erster Linie ist das Protokoll auch total nebensächlich, es ist nicht >die Software, die mir Kopfzerbrechen bereitet... Was bereitet dir denn Kopfzerbrechen ? Der PWM-IC? Pah, da gibt es genug, wenn gleich vielleicht nicht für 1,50.
@ 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).
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.
Wenn du die Forderung von 16 Bit auf 13 Bit verringerst (damit wärst du immer noch bei 8000:1) und mit 100 Hz ansteuern willst, brauchst du alle 1,25µs ein Update. Mit einem µC mit 25 MHz kannst du also eine Main Loop bauen, die eine Soft-PWM in 38 Takten realisiert. Das klingt machbar, Assembler könnte aber hilfreich sein. MSP430G2012 wäre beispielsweise ein Ansatz (läuft aber nur mit 16 MHz). Kostet bei Digikey in deinen Stückzahlen knapp über einen Euro. Max
optiquenz schrieb: > @ 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. Ich hab den TLC5947 hier liegen und bin aktuell auch dran mir eine Ambient-beleuchtung zu bauen: Du erkennst bei 12bit keine Schritte mehr. Selbst wenn ich von 0 an langsam (50ms schritte) hoch Dimme und die ganze Zeit in die LED starre erkenn ich keinerlei sprünge. Ich war auch erst skeptisch (auch wegen des Artikels) Aber das geht wunderbar, auch mit der Anpassung der Werte damits Linear aussieht. Probier es einfach aus. Kauf dir den IC, löte schnell was zusammen und teste. Und dann halte eine 16bit (Soft-)PWM daneben, du siehst keinen (relevanten) Unterschied mehr.
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...
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. 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. Korrektur: Renesas hat was. Die 78K-Familie hat tatsächlich 16-Bitter mit 20 Timern. Viel Spaß, das ist recht exotisch. Max
Jaja, die LEDphilen, kommen gleich nach den Audiophilen . . .
Ja, die Beratungsresistenz und Esoterik-Affinität schonmal auf dem gleichen Niveau.
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.
@ 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.
Ich bin raus. Du willst keine pragmatische Lösung. Lass dir einen ASIC machen, es gibt genug Anbieter. Könnte nur dein Budget sprengen. Aber das supertolle Teil lässt sich dann sicher prima verkaufen. Max
Falk Brunner schrieb: > Jaja, die LEDphilen, kommen gleich nach den Audiophilen . . . :) Trotzdem schade, dass das Thema jetzt so beseite geschoben wird. Ich finde dieser Thread wäre eine gute Gelegenheit die Realität von der Esoterik abzugrenzen. Dafür braucht man aber sachliche Argumente, wie sie der TE meiner Meinung nach auch gebracht hat. Das Argument mit der Beschleunigung muss man gelten lassen, auch wenn ich nicht glaube, dass Optiquenz mit dem Auto durchs Wohnzimmer fahren wollte: optiquenz schrieb: > 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. Ich kann nur auf meine eigene Erfahrung zurückgreifen, und die beschränkt sich auf mehr oder weniger ortsfeste Bedienoberflächen mit LEDs als Anzeigeinstrument und nicht als Beleuchtung. Vielleicht kann ja noch jemand was zum Thema bewegte gepulste Leuchtmittel oder so sagen?
@Meister Eder (edson) >finde dieser Thread wäre eine gute Gelegenheit die Realität von der >Esoterik abzugrenzen. Dafür braucht man aber sachliche Argumente, wie >sie der TE meiner Meinung nach auch gebracht hat. Jo. Dann geh mal zum Artikel LED-Fading, ergänze 12Bit PWM und lass 12 und 16 Bit PWM parallel an zwei LEDs laufen. Das kann sich jeder zuhause selber anschauen und urteilen.
Falk Brunner schrieb: > Jo. Dann geh mal zum Artikel LED-Fading, ergänze 12Bit PWM und lass > 12 und 16 Bit PWM parallel an zwei LEDs laufen. Das kann sich jeder > zuhause selber anschauen und urteilen. Ich glaube die Erfahrung, dass da bei einer "statischen" Betrachtung kein Unterschied feststellbar ist, haben wir alle schon gemacht. Ein reproduzierbarer Test mit bewegter Lichtquelle ist mir für heute nach Feierabend zu aufwändig, da wär es wie gesagt praktisch wenn jemand mit entsprechender Erfahrung aus dem Nähkästchen plaudert. Aber du hast schon recht, keine Frage.
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
@ Meister Eder (edson) >> Jo. Dann geh mal zum Artikel LED-Fading, ergänze 12Bit PWM und lass >> 12 und 16 Bit PWM parallel an zwei LEDs laufen. Das kann sich jeder >> zuhause selber anschauen und urteilen. >Ich glaube die Erfahrung, dass da bei einer "statischen" Betrachtung >kein Unterschied feststellbar ist, haben wir alle schon gemacht. Was meinst du mit statisch? Mit konstantem PWM-Wert? Dann ist auch eine 4 Bit PWM OK ;-) Mit langsam veränderlichem PWM-Wert ist das schon anders. >reproduzierbarer Test mit bewegter Lichtquelle ist mir für heute nach >Feierabend zu aufwändig, Wir reden aneinander vorbei. Von einer örtlich bewegten LED sprach ich nicht, sondern von langsamen Dimmen einer ortsunveränderlichen LED.
Falk Brunner schrieb: > Was meinst du mit statisch? Mit konstantem PWM-Wert? Dann ist auch eine > 4 Bit PWM OK ;-) Nein, deshalb die Anführungszeichen ums Wort "statisch". Ich meinte wenn sich LED und Betrachter zueinander nicht bewegen, beispielweise wenn man vor einem Bedienpult steht oder vorm Fernseher sitzt. > Wir reden aneinander vorbei. Von einer örtlich bewegten LED sprach ich > nicht, sondern von langsamen Dimmen einer ortsunveränderlichen LED. So hatte ich dich auch verstanden. Anscheinend reden wir wirklich aneinander vorbei - und den Fall finde ich weniger interessant denn ich kann ja nur zustimmen wenn du sagst beim dimmen ist im Vergleich 12bit- zu 16-Bit PWM (vereinfacht gesagt) keine Abstufung erkennbar. Ich denke, dass es bei der bewegten Lichtquelle (oder eben sich bewegendem Betrachter/Passanten) vor allem auf die geringste nötige PWM-Frequenz ankommt und nach wie vor die Abstufung der Pulweite bei Auflösungen >= 12Bit keinen wahrnehmbaren Einfluss hat. Weil mir aber die Zeit fehlt das jetzt experimentell nachzustellen, wäre es nach wie vor schön wenn sich jemand findet der von seinen Erfahrungen berichten kann. Nur so aus Interesse, ich habe keinen konkreten Bedarf und der TE hat sich ja auch schon dankend verabschiedet wenn ich ihn richtig verstanden habe...
@Meister Eder (edson) >kann ja nur zustimmen wenn du sagst beim dimmen ist im Vergleich 12bit- >zu 16-Bit PWM (vereinfacht gesagt) keine Abstufung erkennbar. Das habe ich nicht gesagt! Ich sagt, man soll es einfach mal praktisch testen! >Ich denke, dass es bei der bewegten Lichtquelle (oder eben sich >bewegendem Betrachter/Passanten) vor allem auf die geringste nötige >PWM-Frequenz ankommt und nach wie vor die Abstufung der Pulweite bei >Auflösungen >= 12Bit keinen wahrnehmbaren Einfluss hat. Sehe ich auch so.
optiquenz schrieb: > 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. Der großen Hab ich hier einen Denkfehler? Ein Receiver auf dem Board kann doch auch mehrere mc-Eingänge ansteuern. Da ist dann die Wahl des MC völlig frei und ein paar kleine sind manchmal preiswerter als ein einzelner großer. z.B.LPC1111FDH20 für 0.71€ bei Elpro. Der hat 10! Mat-Ausgänge von den 16bit/32bit Timern nach aussen geführt bei 20Pin SOL20. Bei 48MHz und 16bit kommst du auf 732Hz. Wenn das ganze Unidirektional sein soll, dann kann ja auch der Tx des einen Controllers auf den Rx des anderen geschaltet werden. Eine Interrupt-Routine gibt es sowieso und das eine Byte Verzögerung dürfte wohl keine Rolle spielen.
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.
@ Nosnibor (Gast) >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. 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! Ganz im Gegensatz zu den Leuchtpunkten einer Röhre, die werden in Mikrosekunden vom Elektronenstrahl aufgepumpt und klingen dann schnell ab. Hier flimmern 60 Hz sehr, besonders bei einem statischen Bild! >Und dann ist da noch die Tastaturbeleuchtung am neuen Laptop, die mit >100Hz flimmert und damit praktisch unbrauchbar ist. ??? Probleme gibts. > 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. Aha, also 99% deiner Zeit. >Zu den Abstufungen: angeblich hat das menschliche Auge da eine Auflösung >von 8bit. Wer sagt denn sowas? Die Dynamik des menschlichen Auges geht an die 140dB!!!! > Nur ist die Skala nicht linear (Gammakurve) Eben! >Auf dem gut beleuchteten Schreibtisch reicht eine 8bit-PWM meiner >Erfahrung nach, um eine gewohnliche 5mm-matt-LED "stufenlos" zu dimmen; Bei 8 Bit sieht man noch Stufen, wenn man langsam dimmt, siehe LED-Fading. >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. >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. 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).
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. :)
@Nosnibor (Gast) >Nun, irgendwo müssen deine 140dB ja herkommen. Mit 16bit erreicht man >die jedenfalls nicht. :) Ganz "einfach", mit einer logarithmischen Kennlinie.
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.