Hallo zusammen, für eine dekorative Beleuchtung stehe ich vor der Aufgabe etwa 300 RGB-LEDs anzusteuern. Ziel ist in dem Fall ganz klar die preisgünstigste Variante, weil das Projekt an sich schon teuer genug ist. Meine erste Idee war es, die LEDs in 10er Gruppen mit jeweiles einem ATmega16 z.B. anzusteuern und die AVRs mittels UART zu "vernetzen". Ich frage mich allerdings, ob es der ATmega16 schafft, 30x Software PWM für die 10 LEDs hinzubekommen. 30 Anoden oder Kathoden (LEDs sind mit gemeinsamer Anode oder gemeinsamer Kathode verfügbar) zu bestromen schafft er ja vermutlich auch nicht selber... Eine andere Möglichkeit wäre es, PWM-Treiber dafür zu nehmen. Ich habe hier ein paar Samples vom TLC5922 liegen. Ich habe den aber bislang noch nicht verbaut und habe auch noch nicht erkundet zu welchem Preis er bezogen werden kann. Jemand hier vielleicht noch eine Idee, wie man die Biester möglichst "billig" einzeln ansteuern kann? Mehrere LEDs fest zusammen zu fassen wäre die letzte Notlösung um am Preis zu schrauben. Danke und Gruß Dominique Görsch
Mit den PCA von NXP sollte das machbar sein. mit I²C Bus leicht als Module zu verdrahten z.B. der http://www.nxp.com/acrobat_download/datasheets/PCA9685_1.pdf Man hat pro Baustein 16 Kanäle a 12 BIT und kann ext. 64 Adressen einstellen. Klasse ist der Gruppenmode, also z.b. alle roten in eine Gruppe und mit nur einem Befehl zusammen einstellen. Wenn 25 mA Sink pro Kanal reichen keine weiteren Treiber nötig. avr
Das "Problem" bei diese 16-Kanal-Käfern ist halt, dass ich davon für 300 RGB-LEDs stolze 57Stk benötige... Ich denke ich werd mal im Versuchsaufbau testen ob ich dem mega16 30x Software PWM entlocken kann und er dabei noch UART schafft. Das ist wohl wirklich die günstigeste Variante mit rund 2 EUR für einen µC pro 10 LEDs. Wie sähe es denn da mit Treibern aus, was will man da nehmen? Gruß Dominique Görsch
Suche mal nach led driver rgb bei deine Lieferanten. TI, Toshiba, ... . 100mA, 16 ports, pwm, spi kosten bei 1k ca 16cent. Bei 19 Stück ca 42 cent.
Vielleicht kann du bit-angle-modulation brauchen http://www.artisticlicence.com/WebSiteMaster/App%20Notes/appnote011.pdf http://www.batsocks.co.uk/readme/art_bcm_1.htm mfg Bingo
@ Bingo (Gast) >Vielleicht kann du bit-angle-modulation brauchen >http://www.artisticlicence.com/WebSiteMaster/App%2... Ist auch "nur" eine etwas clevere PWM-Implementierung. Soft-PWM kann man aber noch besser optimieren, wenn man weiss wie ;-) @ OP Vielleicht ist das was für dich. Mit vier dieser Boards kann man bequem 324 RGB-LEDs per DMX512 steuern. Beitrag "LED-Matrix, 9x9 RGB, Voll dimmbar" MFG Falk
> Bit Angle Modulation (BAM) ist a new LED drive technique > invented by Artistic License. Ganz schön vollmundig.
Hallo Dominique, ich wollte schon lang für dieses RGB-Problem einen Artikel einstellen. Jetzt habe ich das etwas vorgezogen und auf die Grafik verzichtet. http://www.mikrocontroller.net/articles/%22Additive%22_PWM Mit dieser PWM-(Ab-)Art sollte es gut möglich sein, kleine MEGA (z.b. 8515) in Slaves für je 8 RGB-LEDs zu verwandeln. Gruß Hansl
@ Hans L. (hansl) >http://www.mikrocontroller.net/articles/%22Additive%22_PWM Naja, nicht wirklich ein brauchbarer Artikel. Gedankenfetzen in drei Sätze pressen macht keinen Artikel, schon gar keinen guten. >Mit dieser PWM-(Ab-)Art sollte es gut möglich sein, >kleine MEGA (z.b. 8515) in Slaves für je 8 RGB-LEDs zu >verwandeln. Das ist stinknormale Soft PWM in Assembler, nur mit einer kleinen Optimierung, dass die Dekodierung der Ausgänge über das Carry-Bit gemacht wird. Mit additiv etc. hat das rein gar nix zu tun. MFG Falk
@ falk Das es noch kein fertiger Artikel ist habe ich ja geschrieben. Mit 2-3 Grafiken die den Signalverlauf zeigen wäre das Prinzip auch deutlicher geworden. Mit einer Optimierung der "SOFT-PWM" hat diese Variante nichts zu tun. Es wird nicht in einem festen Zeitfenster für eine variable Zeit eingeschaltet, also mit einer festen Frequenz gearbeitet. Hier bestimmt der Additionswert nach einer festen Zeit ob eingeschaltet wird oder nicht. Die Signalfrequenz ist wertabhängig, es gibt auch Signalblöcke. Man benötigt hier auch keine Sortierung oder CTC-Eigenschaften. Einfach mal die Ausgabesignale beobachten um das Prinzip zu verstehen. Gruß Hansl
Ich hab grad mal meine simple 5-Kanal-PWM-Routine für den tiny2313 aus der Wolke (http://projekte.dgoersch.info/avr/wolke) aufgebohrt auf 24 Kanäle. Läuft auf 'nem mega16 bei 8MHz absolut problemlos. In C oder ASM würde das sicher noch effizienter gehen als in Basic. Wenn's mit UART dazu auch noch so sauber geht, habe ich wohl meine Lösung gefunden...
War zu erwarten... die Timer0_ISR ist natürlich viel zu lang, so dass UART nimmer geht, schade. Mit dem nächsten kleinsten Prescaler (8) isses nur noch Blinken...
Falk Brunner schrieb:
> Versuchs mal mit Soft-PWM
Ich bin zwar in C leider nicht sonderlich gut, aber das Ding macht doch
nix anderes als ich mache, mal davon abgesehen, dass dort die Frequenz
vorgewählt wird und bei mir die Frequenz so hoch wie möglich ist - was
die CPU halt hergibt. Oder seh' ich das grundlegend falsch? Da wird doch
auch nur auf Timer-Basis der Port getoggelt...
@ Dominique Görsch (dgoersch) >Ich bin zwar in C leider nicht sonderlich gut, aber das Ding macht doch >nix anderes als ich mache, > mal davon abgesehen, dass dort die Frequenz >vorgewählt wird und bei mir die Frequenz so hoch wie mögoch ist Was bringt das? 100 Hz reichen. > - was die CPU hergibt. jaja, diese Jugend wieder ;-) CPU überlastet aber cool! > Oder seh ich das grundlegend falsch? Da wird doch auch >nur auf Timer-Basis der Port getoggelt... Der "kleine" Unterschied ist die CPU-Belastung. Lies den Artikel mal bis zum Ende. MFg Falk P S Die Soft-PWM hab ich schon mal auf 32 Kanäle aufgebohrt, als DMX512 LED-Treiber. Lief problemlos, und der uC hat noch massig Rechenzeit übrig. MFG Falk
> wie man die Biester möglichst "billig" einzeln ansteuern kann? In dem man moeglichst wenig Elektronik drumrumbaut. Weder 38 ATMega8515 noch 57 PCA9685. Statt für jede LED einen Ausgang vorzusehen, sollte man nur für jede Zeile und jede Spalte einen Ausgang vorsehen, also Multiplexbetrieb machen. Die meisten LED vertragen den 10-fachen Strom fuer 1/10tel der Zeit, also werden aus deinen 300 LEDs 30 Spalten a 10 LEDs, oder 10 Reihen a 10 roten, grünen, blauen LEDs. Bei 20mA LEDs fliessen also 200mA pro Spalte, pro Zeile 6A, da braucht es mehr als den Ausgang eines Microcontrollers oder HCMOS-ICs. Die 200mA schafft ein (4) ULN2803, für die 6A sollte man einfach einen richtigen Transistor BD224C oder so nehmen, der seinen Basisstrom auch von ULN2803 bekommt. Zur Ansteuerung brauchst du 30 Ausgänge (Spalten) und 10 Ausgänge (Zeilen), zu dem muss du die 30 Spalten PWM dimmen. Ich geh mal davon aus, du willst 256 Dimmstufen, aber du weisst, dass LEDs unterschiedlich hell sind und jede einzelne LED in der Helligkeit kalibriert werden sollte (blöderweise ist die Helligkeit der billigen LED auch noch Blickrichtungsabhängig, es ist also eh immer ein Kompromiss und für Videowände nicht geeignet). Für eine Helligkeit kann bei der einen LED eine Dimmzeit von 106, bei der anderen von 122 notwendig sein. 40 Ausgangspins sind für viele Microcontroller schon knapp, es kann notwendig werden, extern Schieberegister wie TPIC6B595 einzusetzen. Du musst Software-PWM auf 30 Leitungen machen, der Code besteht aus einer engen (aufgerollten?) Schleife, die die Leuchtdauer der einzelnen LED mit dem aktuellen Zählerstand vergleicht und dann deren Ausgang aktiviert/deaktiviert, das macht man für die 30 LEDs und 256 mal, und dann schaltet man Multiplex-mässig um auf die nächste Zeile.
Falk Brunner schrieb: > Was bringt das? 100 Hz reichen. > jaja, diese Jugend wieder ;-) CPU überlastet aber cool! Nix, ich war beim schreiben der Routine einfach zu faul Rechenzeit übrig zu lassen. Sooo jugendlich bin ich ja nun auch nimmer... ;) > Der "kleine" Unterschied ist die CPU-Belastung. Lies den Artikel mal bis > zum Ende. Ja, werde ich tun. MaWin schrieb: > Statt für jede LED einen Ausgang vorzusehen, sollte man nur für jede > Zeile und jede Spalte einen Ausgang vorsehen, also Multiplexbetrieb > machen. Grundsätzlich gebe ich dir da recht, habe mich aber bewusst von vorneherein gegen's Multiplexen entschieden. Der Grund ist ganz einfach: Es ist keine Matrix, sondern ein Strang von LEDs im Wohnzimmer ringsrum an der Wand. Der Verkabelungsaufwand einer "abgerollten Matrix" wäre mir einfach zuviel. Weiterhin geht es tatsächlich um 300 RGB-LEDs, ergo 900 einzeln anzusteuernde Elemente, nicht um eine 10x10 Matrix aus 100 RGB-LEDs. Es soll so in etwa wie in [1] sein, jedoch nicht aus der Schattenfuge herab leuchten, sondern von einem Balken der auf 2m Höhe als Kranz an der Wand entlangläuft hinauf an die Decke strahlend. Gruß Dominique Görsch [1] http://onlineflvplayer.com/?video=http://www.terjung.net/test3.flv
@ Dominique Görsch (dgoersch) >Es ist keine Matrix, sondern ein Strang von LEDs im Wohnzimmer ringsrum >an der Wand. Der Verkabelungsaufwand einer "abgerollten Matrix" wäre mir >einfach zuviel. Logisch. Na dann nimm einen Mega16 und die Soft-PWM aus dem Tutorial, auf 32 Bit aubohren (einfach von uint8_t auf uint32_t ändern, Interruptroutine anpassen) und schwups kann man mit einem AVR 10 RGB-LEDs steuern. Davon 30 Stück gebaut macht 300 RGB-LEDs. Kosten sollten sich bei 5 Euro/Platine bewegen. MFG Falk
Nachdem ich erst heute Nachmittag ein paar Stunden damit verbracht habe, zu versuchen den C-Code zu Bascom zu portieren - mit mäßigem Erfolg - versuche ich es nun direkt mit C. Ich hab den Code aus deinem Link genommen (Variante 1 und 2 ersteinmal) und den Port entsprechend angepasst. Aber es tut sich nichts, absolut null. Ich kanns problemlos kompilieren und flashen, aber die LEDs bleiben aus. Muss man an dem Code noch weitere Änderungen vollziehen, damit er auf einem mega16 statt mega32 läuft? Gruß Dominique Görsch
100Hz PWM ist bei LEDs grenzwertig. 150 sollten es schon sein. Begründung: leds haben keine engbaute Trägheit. das heißt sie glühen nicht nach. wenn eine LED mir weniger als 150 Hz pulst und man bewegt seinen Kopf, gibt es den so genannten "Perlenschnureffekt". Besonders oft bemerkt man dies bei LED-Rückleuchten von Fahrzeugen. wenn die Nachts vor einem Fahren und man schaut nach rechts oder links, ist das bei älteren LED-Leuchten enorm störend. Das kommt daher, das normalerweise das Auge (eigendlich das Gehirn) das Licht über eine Weile integriert, wodurch man das flackern ab ca 100Hz nicht mehr sieht. Bewegt sich dieses Objekt aber im Gesichtsfeld funktioniert das nicht mehr so gut. Auch an manchen Beamer fällt das auf, wenn man direkt auf die Projektionsöffnung schaut (wenn man daneben, nicht davor, sitzt), sieht man einfach weißes Licht. Schaut man aber im Raum hin und her, nimmt man oft einen Regenbogen war. Zu Software-PWM: das ist nicht wirklich aufwändig, ich hatte das schon mal in nem anderen Thread vorgerechnet, dass man für 16 Kanäle (inklusive Multiplexing für LED-Matrix) bei 8Mhz ca 3% Rechenleistung braucht.
Kaum zu glauben, ich als C-Noob habs geschafft die 3. Soft-PWM-Variante aus dem Artikel auf mehrere File aufzuteilen, und Peter Fleurys UART-Lib hinzuzufügen. Was ich leider nicht schaffe ist, den PWM-Part soweit aufzubohren, dass ich statt einem drei Ports - und somit 24 Channels nutze. Mit dem einfachen ändern der Variablen von uint8_t auf uint32_t wars leider nicht getan, danach tats erstmal garnixmehr. Falk hast du vielleicht einen Tipp, was noch wo angepasst werden müsste? Gruß Dominique Görsch
Es ist lässtig 10 oder gar 30 µC per ISP zu programieren wenn du das programm ändern willst. Vielleicht wäre es sinnvoll einen Bootloader zu verwenden und die AVRs via UART zu verbinden. (so ala sensor-chain) MFG
ich bastel auch gerade an einer RGB Beleuchtung, d.h. schon etwas länger seit ich hier einige Osram Ostar 11W LEDs gekauft habe. Die Ansteuerung mache ich mit einer KSQ mit ZXLD1362, die lässt sich über einen Steuereingang modulieren. Für diese Powerteile möchte ich aber eine 256stufige PWM mit 16Bit Auflösung, weniger Stufen sind doch recht 'unsmooth' wenn es dunkel wird. Ich habe dazu die Hardware PWM mit der log. Tabelle von F.B. benutzt. Für einen RGB Kanal würde ich einen Mega128 nehmen, der hat ja 3x 16Bit PWM. Oder ein neuer Kandidat wäre ja der XMega128A1 mit 6x 16Bit PWM (wenn ich das richtig verstanden habe). Klar, der XMega hört sich erstmal wie Overkill an, aber der nackte µC kostet ja auch nur ca. 7€ und damit sogar noch weniger als Mega128. Der XMega64A1 wäre noch einen € billiger wenn man ihn denn hier bekäme, Bezugsquellen wie Farnell oder Mouser sind mit allen Nebenkosten deutlich teurer. Der einzige Haken am XMega ist der 0,5mm Pitch, dafür müsste man Platinen fertigen lassen. Ich weiss, die Optimierungskünstler F.B. oder PeDa schlagen da die Hände über dem Kopf zusammen, aber ich denke mit dem XMega kriegt man die PWM + Kommunikation schneller sauber hin. Nur so als Anregung. Im Anhang die Excel Tabelle für die log. Steuerung, ich habe noch einen Button eingebaut um die Werte als Includefile in den C-Code übernehmen zu können (könnte man auch einfach für ASM oder Bascom anpassen). In C nutze ich das dann so:
1 | uint16_t pwmtable_10[64] PROGMEM = { |
2 | #include "pwmtab64-1024.inc" |
3 | };
|
Die µC sollen alle über UART "vernetzt" werden. Vom TX des einen auf RX des nächsten, usw... Das Programm wird so aussehen, dass über UART die Werte für die angeschlossenen Segmente kommen, und über UART wieder an den nächsten gehen. Ich erwarte eigentlich nicht, dass ich an dem Programm nochmal was ändern muss. Denn es ist recht simpel: Ein Controller verschickt die Daten, dabei ist das erste Byte eine Adresse. Der empfangende AVR schaut, ob diese Adresse 0 ist, wenn ja setzt er die PWM-Werte die in den folgenden Bytes stehen. Ist die Adresse nicht 0, wird von der Adresse 1 abgezogen und das ganze wird weiter geschicht an den nächsten AVR. So kann ich die AVRs alle einzeln adressieren und die PWM-Werte gezielt setzen. Die Idee ist übrigens nicht von mir, ich habe mich lediglich von http://www.ledstyles.de/ftopic7948.html inspirieren lassen und das ganze etwas abgeändert (LEDs einzeln ansteuern, mega16 statt mega8, ...). Gruß Dominique Görsch
@Dominique Görsch (dgoersch) >Was ich leider nicht schaffe ist, den PWM-Part soweit aufzubohren, dass >ich statt einem drei Ports - und somit 24 Channels nutze. Mit dem >einfachen ändern der Variablen von uint8_t auf uint32_t wars leider >nicht getan, danach tats erstmal garnixmehr. Naja, nicht ALLE. Die richtigen. Hmmm. Ich geb dir einfach mal meine fertige Lösung, da sind noch ein paar zusätzliche Kniffe drin. Siehe Anhang. >Fralla (Gast) >Es ist lässtig 10 oder gar 30 µC per ISP zu programieren wenn du das >programm ändern willst. Das macht man aber nicht. Sinnvollerweise programmiert man erstz alle, wenn zwei, drei Prototypen sauber laufen. > Vielleicht wäre es sinnvoll einen Bootloader zu >verwenden und die AVRs via UART zu verbinden. (so ala sensor-chain) Overkill. Heute muss in jedem Firlefanz ne Onlinezugang rein, was? Wolfgang wirds freuen. @Jojo S. (jojos) >Ich weiss, die Optimierungskünstler F.B. oder PeDa schlagen da die Hände >über dem Kopf zusammen, Naja, so schnell schlage ich nicht. Da hab ich hier schon DEUTLICH unsinnigere Dinge gesehen. > aber ich denke mit dem XMega kriegt man die PWM >+ Kommunikation schneller sauber hin. Ist genehmigt ;-) >Die µC sollen alle über UART "vernetzt" werden. Vom TX des einen auf RX >des nächsten, usw... Grosser Unsinn. Wenn dir die Kette kaputt geht hast du viel "Spass" beim Fehlersuchen. Mach es richtig und nimm einen normalen Bus, an dem alle Teilenehmer parallel hängen. MAX485 ist deine Freund. Oder meinetwegen CAN. MFG Falk
Falk Brunner schrieb: > Naja, nicht ALLE. Die richtigen. Hmmm. Ich geb dir einfach mal meine > fertige Lösung, da sind noch ein paar zusätzliche Kniffe drin. Siehe > Anhang. Danke, schau ich mir morgen/nachher mal an. Gruß Dominique Görsch
Aufgrund des "zu teuer", denn 50er Stückzahlen lassen sich nun mal nicht sampeln, werden 900 Widerstände verlötet. Bei einer Ersparnis von vielleicht 60 Euro nenn' ich das doch mal ein SUPER Geschäft. :D Hier in diesem Thread: Beitrag "TLC5922, TLC5923, TLC5924 Ansteuerung für zB Mood Light" hat Kai einen Treiber für den TCL5922 geschrieben, zwar in Codevision, aber sicher auf GCC umstellbar. Wenn man ihn nett fragt, würde er vielleicht sogar helfen, möglicherweise hat er auch noch 5922 rumliegen und stellt sein Platinenlayout zur Verfügung. Wobei der MBI5030 von Macroblock noch ein Eck besser wäre, nur schwer zu beschaffen.
Um nochmal auf das Multiplexen zurückzukommen... > Grundsätzlich gebe ich dir da recht, habe mich aber bewusst von > vorneherein gegen's Multiplexen entschieden. Der Grund ist ganz einfach: > Es ist keine Matrix, sondern ein Strang von LEDs im Wohnzimmer ringsrum > an der Wand. Der Verkabelungsaufwand einer "abgerollten Matrix" wäre mir > einfach zuviel. > Weiterhin geht es tatsächlich um 300 RGB-LEDs, ergo 900 einzeln > anzusteuernde Elemente, nicht um eine 10x10 Matrix aus 100 RGB-LEDs. Du könntest ja auch jeden LED-Baustein einzeln ansteuern und nur RGB multiplexen. Damit könntest Du z.B. mit einem ATmega16 ohne externe Decodierelemente 24 RGB-LEDs komplett ansteuern und hast noch Reserven für die Kommunikation. Die Verdrahtung von solch einem Mini-Multiplex sollte auch weniger aufwändig sein als eine komplette Einzelverdrahtung mit der dreifachen Anzahl an Steuerprozessoren. > Es soll so in etwa wie in [1] sein, jedoch nicht aus der Schattenfuge Sieht gut aus, gefällt mir. Reinhard
MWS schrieb: > Aufgrund des "zu teuer", denn 50er Stückzahlen lassen sich nun mal nicht > sampeln, werden 900 Widerstände verlötet. In der Tat ein Punkt, über den ich auch schon mehrfach nachgedacht habe. Da das ganze für mich privat ist, hab' ich kein Problem damit, 'ne Woche lang Abends Widerstände zu verlöten. Jedoch vielmehr stört mich daran die über die Widerstände verbratene Energie.
> Jedoch vielmehr stört mich daran die über die Widerstände verbratene > Energie. Die "Constant-Current Sink" laut Datenblatt heist nicht, daß dort kein Strom verbraten wird, der wird nur im IC statt im Widerstand vernichtet. Bei den Stromsenken geht's nur darum den Aufwand für die Widerstände zu sparen. Mir wäre meine private Zeit zu schade, als daß ich 900 Widerstände für die paar Euros verlöten möchte, vor allem in Anbetracht der restlichen Kosten. Dann mal viel Erfolg damit und auf gute Stromzuführung achten, die ca. 20A wollen gut verteilt werden.
Hallo zusammen, @Falk: Du hast die Auflösung ja ziemlich kastriert in dem DMX-Led-Dimmer. Hast Du immer noch ein stufenloses Fading? Ansonsten finde ich die Unions eine gute Idee - ist wahrscheinlich nicht ganz eingängig für andere, beschleunigt aber den Zugriff :-) @Hans: Wenn ich das richtig sehe, erhält man bei Deinem Code keine konstante Frequenz mit einem variablen Tastverhältnis (Definition einer PWM) sondern eher einen konstanten Puls mit variabler Frequenz für jeden Kanal. Ist es nicht also eher eine Frequenzmodulation oder etwas Delta-Sigma-artiges? (Klingt zunächst philosophisch - könnte aber in Verbindung mit LEDs patentrechtliche Folgen haben...)
@ Henne (Gast) >Du hast die Auflösung ja ziemlich kastriert in dem DMX-Led-Dimmer. Warum? Weil dort "nur" 32 nichtlineare Stufen drin sind? > Hast >Du immer noch ein stufenloses Fading? Probiers aus ;-) Wenn es nicht zu langsam ist, dann auf jeden Fall. MFG Falk
Falk Brunner schrieb: > @ Bingo (Gast) > >>Vielleicht kann du bit-angle-modulation brauchen >>http://www.artisticlicence.com/WebSiteMaster/App%2... > > Ist auch "nur" eine etwas clevere PWM-Implementierung. Soft-PWM kann > man aber noch besser optimieren, wenn man weiss wie ;-) Bezieht sich deine Antwort auf die im Soft-PWM-Artikel beschriebenen Optimierungen, oder meinst du etwas darüber hinaus gehendes?
@ Alexander Horst (hoal) >Bezieht sich deine Antwort auf die im Soft-PWM-Artikel beschriebenen >Optimierungen, Ja. Aber ich bin offen für weitere Verbesserungen. MFG Falk
Zur BAM: Hat nicht das geringste mit PWM zu tun vom Algorithmus her. Die Implementierung ist in der Praxis allerdings deutlich frickeliger als in öffentlichen Papers dargestellt. Bei einer einzelnen LED fällt es nicht auf - aber schließt mal ein Panel >15W an... Zur additiven PWM / Carry-PWM: Ich habe den Algorithmus gestern Nacht auf einem Spot mit ca. 30W implementiert. Durch das delta-sigma ähnliche Verhalten gibt es - gerade bei größerer Helligkeit - kein Flimmern. Die Geschichte scheint bei sinnvoller Wahl der Basisfrequenz auch videofähig zu sein. Allerdings ist die Sache nicht im Mindesten performant. In größeren Firmwares oder auch nur bei mehreren Kanälen kann man nicht für jeden ch 2Register verbraten. Die Zugriffe auf das SRAM kosten selbst bei Assembler-Implementierung sehr viel Zeit. Auf Grund dieser Skalierung wird der Algo relativ schnell unbrauchbar. (Bei einer Implementierung in HW sieht das bestimmt wieder anders aus...) Zur (Soft-)PWM: ...dank Philips / Colorkinetics ein Minenfeld und verbrannte Erde... Leider hat diese Firma stapelweise Trivialpatente durchbekommen - das läuft wohl wie geschmiert ;-) VG, Hendrik PS: FM (fehlt hier noch) taugt bei hohen Intensitäten nichts.
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.