Hallo, ich habe es doch nun satt. Ich finde nichts passendes, um per Software PWM, mit einem ATMega8 z.B., 8 LEDs per Software PWM zu dimmen. Es gab da mal ein ledgame.c Code für das STK500, allerdings fehlt mir da eine Timer.h . Dann gabs mal eine pwm.c , die aber nur eine LED am ORC Pin dimmte. Kann mir evtl. jemand mal eine Software PWM für 8 LEDs posten, oder sagen, welche ich nehmen soll? Danke, Gruß Toby
Hi Toby, nicht so schnell verzweifelt sein ;) Ich kann dir zwar nicht in C helfen aber das Pronzip sollte doch überall gleich sein. Schau doch mal 1 Thread weiter unten, da hab ich meine Software PWM in ASM ebend mit angehängt. In der MainRoutine brauch ich nur noch die PWM Register mit einem Wert von 0-100 Laden und die PWM Routine im timer_overflow tut ihren Dienst. Das Prinzip ist eigendlich einfach du hast ein Timer z.B. Timer0 diesen lässt du so häufig wie möglich einen Interrupt bei Overflow durchlaufen. (Gesunde Mischung zwischen IRQ Last und Flackernen LED´s) ich habe z.b. den Timer0 ohne Prescaler zu laufen (1/1) Dann hast du ein Register (Variable ?!) Namens PWM_MaxSchritte welche du z.b. auf 100 Setzt Dann kommt ein PWM Zählregister (Variable?!) Welche zum Init genau so hoch ist wie PWM_MaxSchritte (in diesem fall auch 100) Jetzt brauchst noch 8 PWM Register (Variablen) in der für jede LED die Helligkeit festgelegt ist. ---- SCHNIPP --- Dann legst Du in der MainRoutine nur noch Fest wie Hell jede LED sein soll. (0-100) ---- SCHNIPP --- Und nun kümmerst dich um deinen Timer0 Overflow Interrupt: in diesem musst du als erstes dein PWM_ZählRegister Decrementieren (-1) Dann testen ob 0 Wenn 0 wieder mit PWM_MaxSchritte füllen (also wieder 100) ansonsten gehst weiter. Jetzt musst nur noch für Jeden PWM Kanal (PWM Register) also 8 mal nacheinander testen: PWM_x_Variable = 0 ? Wenn JA dann Schalte Portpin AUS und gehe zum nächsten PWM Kanal mit anderen Worten überspringe alles was jetzt kommt. Wenn NEIN dann weiter PWM_X_Variable >= PWM_Max_Schritte Wenn JA dann wieder PortPin AUS und ab zum nächsten Kanal (überspringen nächstes) Wenn NEIN dann Schalte PortPin EIN und ab zum nächsten Kanal Mehr ist es eigendlich nicht. Hoffentlich hab ich das jetzt nicht blöd geschrieben. Wusste nur nicht wie ich es anders schreiben kann weil ich kein C kann. Gruß Dennis
Ok fehlerlesen hätt ich ja doch noch mal gekonnt. Sorry für die vielen Rechtschreibfehler. Gruß Dennis
Schau mal das an: http://www.loetstelle.net/content/projekte/rgbdimmer/source/rgbdimmer.asm 3 Kanal PWM in Assembler. Kann leicht auf 8 erweitert werden. Beschreibung und Board gibts bei http://www.loetstelle.net/projekte/projekte.php dkm
Im Anhang ist ein ASM-Beispiel als Denkanstoß. Mit C kann ich dir nicht dienen. ...
Anbei ein Source der 16 RGB LEDs = 48 LEDs in 24 Bit Farbtiefe einstellen kann. In C sähe es inetwa so aus: (schlag mich nicht wenn der Source noch kleinere Fehler enthält ich habe in erst jetzt anch C transliert :=) #define REG_PORT PORTD #define REG_CLOCK PD3 #define REG_LE PD4 #define LED_COUNT 16 #define LED_GRAYSCALE 256 #define LED_INCREMENT LED_GRAYSCALE / LED_COUNT volatile uint8_t Pixels[0..LED_COUNT *3 -1]; volatile uint8_t Counter_R = 0; volatile uint8_t Counter_G = 0; volatile uint8_t Counter_B = 0; SIGNAL(COMPARE_OC2) { uint8_t Data; for (uint8_t i = 0; i < LED_COUNT * 3;) { Data = 0; if (Pixels[i++] < Counter_R) Data++; Data += Data; if (Pixels[i++] < Counter_G) Data++; Data += Data; if (Pixels[i++] < Counter_B) Data++; REG_PORT = Data; Counter_R += LED_INCREMENT; Counter_G += LED_INCREMENT; Counter_B += LED_INCREMENT; REG_PORT |= (1 << REG_CLOCK); } REG_PORT &= ~(1 << REG_CLOCK); REG_PORT |= (1 << REG_LE); Counter_R--; Counter_G--; Counter_B--; REG_PORT &= ~(1 << REG_LE); } An PortD liegen 3 Shiftregister, PD0 Register Rot, PD1 Register Grün, PD2 Register Blau, PD3 die Clock aller 3 Register und PD4 von allen 3 Registern der /OE und LE Eingang. Man stellt nun Timer2 OCR2 so ein das ein Compate Match IRQ ertzeugt wird und obige ISR aufgerufen wrid. Diese erzeugt 3 parallel 16 Bit Datenströme für die 3 Shiftregister. An den 3 Registern liegen jeweils 16 LEDs aber nach Farbe getrennt. Mit dem obigen Assembler Source ist ein ATMega8 mit 16Mhz ca. 28% ausgelastet. Die ISR wird mit 13Khz aufgerufen was bei 256 Farbabstufungen eine Multiplixingzeit von 50Hz ergibt. Bei dem Verfahren handelt es sich NICHT um herkömmliche PWM, sondern eher um ein gleichverteiltes Pulsmuster deren Verhältnis von On/Off Zyklen die Helligkeit bestimmt. Gruß Hagen
@Toby "Kann mir evtl. jemand mal eine Software PWM für 8 LEDs posten, oder sagen, welche ich nehmen soll?" Ich bin mir 100%-ig sicher, daß das überhaupt nicht nützen wird. Mit der Methode, irgendwo her Code zu nehmen und ihn irgendwie zusammen zu pappen, muß man unweigerlich auf die Schnauze fallen. Die in meinen Augen einzig erfolgversprechende Methode ist die, daß man einen Code nimmt und auseinanderpflückt, bis man ihn verstanden hat. Oder daß man sich mit den Grundlagen beschäftigt, d.h. was eine PWM ist und sich die dann mit einem Timerinterrupt selber bastelt. Programmieren heißt in der Regel, selber Programme schreiben. Peter
Ich bin mal gepannt, wann erwähnt wird, dass die PWM sehr schnell sein muss, weil die LEDs sich sehr schnell bewegen, da sie an der Unterseite eines Modell-Helikopter-Rotors angebracht werden. Dann ist nämlich die Aufgabenstellung eine ganz andere. ...
@ ...HanneS... nee soweit wird es nicht kommen. Immer dran denken fahre Modellautos keine Helis (wo bei ich das gerne mal machen würde aber seehr teuer der spaß) Gruß Dennis
@Dennis: Ich meinte nicht dich, sondern den Eröffner des Threads. Ich habe noch den Propellerclock-Thread in Erinnerung mit Fotos seines Helis. ...
Hm, ich sehe das nicht so verbissen. Jeder Programmierer hat schon einen fremden Code genommen, diesen zerpflückt, daraus gelernt, seine eigenen Gedanken gemacht und dann seinen eigenen Source entwickelt angepasst an seine Bedürfnisse. Ich sehe das als die effektiveste Art an etwas zu lernen. Auf alle Fälle besser als 8 Jahre Informatik zu studieren um dann feststellen zu müssen das Theorie und Praxis was Unterschiedliches sind. Was mich mehr stört ist im Grunde die Unfähigkeit der Leute einfach mal was ohne negativen Kommantar hinnehmen zu können (auch wenn solche Kommentare manchmal gerechtfertig erscheinen :=) Gruß Hagen
Hallo Hannes, was du wohl glaubst! Denkste ich will 16Bit Farben am Heli haben? Nee, so weit war ich auch schon! PWM ist nix anderes, als eine Spannung schnell an und wieder aus zu schalten. Je nach Pulsbreite ändert sich bei einer LED z.B. die Hellichkeit. Würde man die LED nun drehen lassen, würde man die an und aus Phasen sehen können! Es sei denn,..... .... die PWM Frequenz ist schneller als ... ... die Zeit einer Umdrehung ?! ... die Zeit einer Spalte ?! Darüber habe ich mir noch garkeine Gedanken gemacht! Peter, ich weiß, aber ich wollte ja nur mal meine RGB LED ausprobieren, daher ein fertiger Code. Ich habe übrigens schon den ASM Code von Dennis ausprobiert, danke dafür, mehr wollte ich gar nicht! Hagen, "Was mich mehr stört ist im Grunde die Unfähigkeit der Leute einfach mal was ohne negativen Kommantar hinnehmen zu können (auch wenn solche Kommentare manchmal gerechtfertig erscheinen :=)" >>> siehe Doppelklick und co !!! Seltsam, das man was fragt, und alle denken, das man es gleich für sein Projekt von früher nutzen will! Ach, Hannes, wie schließe ich ein LCD an meine Rotorblätter an? Ich will damit meine Flughöhe und Geschwindigkeit angezeigt bekommen! Und warum kommt bei XP immer die Meldung : Drucker reagiert nicht, Datei wurde an den Scanner weitergeleitet. ????? Gruß Toby
"Ich habe übrigens schon den ASM Code von Dennis ausprobiert, danke dafür, mehr wollte ich gar nicht!". Meinst Du wirklich, der Code von Dennis ist DER ideale Code? Er hat ja noch nicht mal in seinem Thread ein paar Verbesserungsvorschläge zur Kenntnis genommen, aber gleich weitergeben, ja ja! Dafür hat sich jemand anderes bedankt der das zufällig gefunden hat! MfG Andi
@Andreas, bitte nicht gleich an die Decke gehen ! Schaue bitte erst auf die Veröffentlichungszeiten. Deine Vorschläge waren GUT und ich habe sie mir zu Herzen genommen und gehe diese natürlich durch. Vergiss bitte nicht nahezu JEDER Code ist Verbesserungswürdig (denk daran das ein Teil des Sources eigendlich auch von Dir stammt) Ich habe meinen Source nicht in diesem Thread veröffentlicht sondern nur die einzelnen Schritte versucht zu erklären ! Das man diese auch anders umsetzen kann ist mir klar. (wie du ja in dem anderen Thread bewiesen hast) Ich bedanke mich immer über eure hilfe gehört zum guten Umgang dazu, nur hatte ich bis jetzt noch nicht die Zeit alles wieder durchzugehen. Also auch in diesem Thread schonmal ein Danke an Dich, HanneS und vielen anderen aus diesem Forum. Gruß Dennis
Guten Abend. Andy, ich habe nur den Code von Dennis genommen, da ich ihn nunmal hatte. Ich wollte nur mal eben meine neuen LEDS ausprobieren. Dafür brauche ich keinen "idealen Code", d.h. ich kann damit doch frei definieren, wie hell meine 3 Diaoden sein sollen. Ich will den Code auch für nix anderes nutzen. Nur sollte meine LED nicht imer an sein, um zu sehen, welche Farben, bzw. wie sich die Farben ändern. >> komischer Satz! Das Dennise keine Vorschläge nutzt, kannst Du so nicht sagen, 1. Ist er blutiger Anfänger, wie ich, und kann die Vorschläge bestimmt nicht so schnell umsetzen. ( Von Heute auf Heute !!! ) 2. Hätte er sonst bestimmt nicht gefragt. 3. Hat er seinen Code nicht mir zur Verfügung gestellt, sondern wollte Tips von Euch bekommen. Aber wozu gibt es dieses Forum überhaupt?! Immerhin schreiben wir hier nicht in Threads, wie z.B. "Wie setze ich einen Port" oder "Wo ist das Tutorial" geschweige denn "Was ist ein Tutorial". Ich danke natürlich auch immer allen, bzw. glaube ich es. Schaue jetzt nicht jeden Thread von mir nach, ich bitte um Verständniss! Zum Schluß: seid nicht so miteinander. Lasst mal 5 gerade sein, trikt nen Kaffee miteinander.... Bald ist Wheinachten, der Schnee kommt, was solls! Gruß Toby
Hallo Toby... > Seltsam, das man was fragt, und alle denken, das man es gleich für > sein > Projekt von früher nutzen will! Also dein Rotorblatt-Projekt hatte ich aufmerksam und mit Hochachtung verfolgt. Nix liegt näher, als bei deiner jetzigen Frage zu schlussfolgern, dass du dieses Projekt jetzt "in Farbe" angehen willst. Daher "wartete" ich auf die Angabe, dass die PWM doch sehr schnell sein müsse. Ich bitte dich um Entschuldigung, dass ich dir das überhaupt zugetraut habe. Das wird (hoffentlich) nicht wieder vorkommen. Jedenfalls war es nicht so arrogant gemeint, wie es im Nachhinein scheinen mag. Ursache für diesen Einwurf ist aber auch die Tatsache, dass hier im Forum von den Hilfesuchenden sehr oft wichtige Informationen zurück gehalten werden und erst genannt werden, wenn es so aussieht, als wäre das Problem bereits gelöst. Dann fängt man wieder von vorne an. Das wollte ich hier vermeiden. Dass ich mich dabei irrte, freut mich jetzt sogar, so es war halt keine vertane Mühe und Zeit der Helfer. In letzter Zeit gibt es hier zu viele Doppelposts, manchmal sogar Dreifachposts. Es ist ätzend, beim Lesen der Threads festzustellen, dass das nur eine Widerholung ist. Wenn man dann noch liest, dass es ja nicht am Verfasser liegt, sondern an einer untauglichen Maus, dann regt sich Widerspruch, dann provoziert das solche Äußerungen wie meine. Ich hatte auch schon Mäuse, deren Mikrotaster durch Verschleiß so laberig wurden, dass sie Doppelklicks verursachten. Diese wurden dann aber außer Betrieb genommen oder repariert. Oft half das Wechseln der Mikrotaster, wobei der verschlissene Taster für die (meist) mittlere oder (seltener) rechte Taste benutzt wurde, da diese je viel weniger benutzt werden. Eine Maus, die Unsinn macht, ist einfach wertlos, da kann sie noch so gut aussehen oder teuer gewesen sein. Daher meine Antwort auf deinen Beitrag mit der Schuldabwälzung auf die Maus. Nun zu deiner Frage mit dem LCD im Rotorblatt. Wenn du das LCD mit einer sehr starken Hintergrundbeleuchtung benutzt, dann könnte das funktionieren. Es kommt nur darauf an, dass du die Hintergrundbeleuchtung immer an der gleichen Position des Rotors extrem kurz aufblitzen lässt. Ich würde dir aber von diesem Vorhaben abraten. Deine XP-Frage kann ich leider nicht beantworten, dazu bin ich zu doof. Aber bei M$ wundert mich eine Fehlermeldung dieser Art nicht besonders. Vor vielen Jahren hat mich ein (damals neuer) 386er (unter M$-DOS) gebeten, ich möge doch bitte die Programmdiskette Nummer 2 in das Laufwerk C: einlegen. Nach kurzer Überprüfung des Sachverhaltes musste ich dem 386er Recht geben. Aus seiner Sicht war die Meldung korrekt. Ein Spiel (auf Festplatte C:) verlangte sie Soundtreiber, nachdem ich eine Soundkarte eingebaut hatte. Die Treiber befanden sich auf Programmdiskette 2 des Spiels. Ich hatte das Spiel über ein Jahr nicht gespielt und den Soundkarteneinbau (als mögliche Ursache) vergessen. Alles Gute und Bit- & Bytebruch... ...HanneS...
Vielleicht kann ich mich jetzt mal revangieren, Toby :-) (Die erste LCD-Zeile spinnt zwar immer noch - aber die zweite werkelt wenigstens...) Hier ist u.a. ein netter schlanker asm-Code mit ein paar Erklärungen: www.hoelscher-hi.de/hendrik/light/asm.htm (das 5. isses ;-) Viel Erfolg, Hendrik
Hallo Hannes, nun bin ich ja wirklich Sprachlos! Ich habe zwar vor, die RGB LEDs in Rotorblätter zu montieren, aber eine Farbmischung mit "immer an" macht schon 7 Farben. Das ist doch auch schon ein Fortschritt, gegenüber den 32 LEDs in einer Farbe. Das mit dem LCD und der Meldung war auch nicht so gemeint, ich wollte nur mal darstellen, worauf manche hier so anspringen! Quasi völlig dämliche Sachen! Also auch eine große Entschuldigung meiner seits! Die Maus ist eine Nagelneue. Es liegt aber nicht an der Maus, sondern daran, das ich nicht die Einstellungsmöglichkeiten wie bei meinem Dektop habe. Dort kann ich nämlich die Doppelklickgeschwindigkeit ändern. Es kennt bestimmt jeder, da ist so nen "Kasper" auf dem man es testen kann. Da aber mein Notebook diesen "Punkt" in der Mitte der Tastatur hat, komme ich nur in die Einstellungen für dieses Teil, obwohl ich eine USB Maus dran hab. Ich suche mal nach der Treiber CD der Maus, vielleicht ändert sich dann etwas, oder ich kann zumindest die Einstellungen ändern. Hendrik, schön, das wenigstens etwas geht! Ich werde trotz, das ich "nur" ein Programm zum "testen" gesucht habe, welches für meine "Testzwecke" gereicht hat, ALLE EUERE Tips und Hilfen beachten, und meine LEDs damit testen, auch wenn ich erstmal keine weitere Verwendung dafür habe! Danke an Alle !!!! Gruß, und gute Nacht Toby
@Tobi: Es ist ganz einfach: Was man beim Leden eines Beitrags denkt ist nicht immer mit dem identisch, was der Autor beim Schreiben denkt... Und so entstehen Missverständnisse. Wie deine Beispiele mit LCD und WINDOOF-Meldung gemeint waren, ist mir völlig klar. Auch ich verstehe Spaß. Es war mir daher ein Vergnügen, halbwegs passende Antworten zu suchen, ohne Smilies einzusetzen. Mit den Farb-LEDs und den Rotorblättern lag ich also garnicht so falsch. Klar, PWM bringt da nix, aber woher soll ich denn wissen, dass du die PWM nur zum vorherigen Testen haben willst? Also: Viel Erfolg mit dem Teil... ...
"Leden" sollte "Lesen" heißen... Übrigens hat mein oller Lappi auch diesen Gnubbel zwischen den Tasten g, h und b, ich habe aber keine Maus angeschlossen. Ich arbeite zwar viel mit der Tastatur, nutze diesen Gnubbel aber auch zum Zeichnen von Schaltplänen und Layouten von Platinen mittels Eagle. Das geht aber nur, wenn ich entspannt und gerade vor dem Rechner sitze. ...
Noch einen Tipp zwecks PWM. PWM = Pulse-Weitem-Modulation, d.h. innerhalb eines Zyklus wird die Breite eines Pulse variiert um dann meistens durch einen nachgeschalteten Tiefpassfilter eine analoge Spannung zu erhalten. Im Falle aller LED Ansteuerungen mit "PWM" ist der Tiefpassfilter unser Auge. Desweiteren sind LEDs quasi digitale Bauelemente die nur ON/OFF kennen und nicht wie ein Tiefpassfilter eine Spannung oder eben Licht "glätten" können. Die Ansteuerung per PWM ist daher wenig sinnvoll. Bei vielen LEDs die mit herkömmlicher PWM angesteuert werden verteilt sich die Strombelastung dann abhängig von der gewählten Helllgkeit nicht gleichmäßig. Beispiel: 8 LEDs und 256 Farbabstufungen pro LED und angesteuert durch herkömmliche PWM. Die 8 LEDs haben die Helligkeiten, 16, 32, 48, 64 usw. usw. und jede zieht 20mA Strom. Zerlegen wir die PWM in 256 einzelne Schritte pro Zyklus so heist dies 0-16 = 8 * 20mA = 160mA 17-32 = 7 * 20mA = 140mA 33-48 = 6 * 20mA = 120mA 49-xx = 5 * 20mA = 100mA Mit normaler PWM sieht man das zum Begin eines Zyklus die Stromlast immer am höchsten sein wird und am Ende des Zyklus fast immer gegen 0 mA absinkt. Die Stromlast ist also niemals gleichverteilt. Desweiteren erkennen wir das die OFF Zeit als zusammengesetze zeitliche Spanne immer nach der ON Zeit den kompletten restlichen Zyklus darstellt. Das bedeutet, je geringer die Helligkeit der LED sein soll desto kürzer wird die ON Zeit im Ratio zu der OFF zeit der LED, und ergo müssen wir die Gesamtmultiplexing Frequenz stark erhöhen damit die LEDs nicht beginnen zu flackern. Wir wissen aber das bei LEDs und dem menschlichem Auge als Filter, die ON/OFF Zeiten das einzigste Kriterium darstellen für die Helligkeit. Es ist NICHT die ON/OFF Verteilung entscheidend. Für zb. eine Ansteuerung der LEDs mit 256 Helligkeiten, zerlegen wir also die "PWM" in 256 einzelne Zeitscheiben. Nur das Verhältnis der Anzahlen von ON/OFF Zeitscheiben bestimmt die effektive Helligkeit aber eben NICHT die Positionierung der ON/OFF Zeitscheiben. Man könnte also zuerst all ON und dann OFF Zeitscheiben multiplexen, was dann wieder normale PWM ergäbe. Man kann aber auch die ON Zeitscheiben immer gleichmäßig über alle 256 Slots verteilen. Macht man dies clever so leuchten in jedem Slot immer nur die minimal nötige Anzahl der LEDs relativ betrachtet zum kompletten 256 Slot Zyklus. Ergo: die Stromlast ist absolut gleichverteilt, die LEDs werden nicht mit zu hohen Pulsströmen überlastet und die minimal nötige Frequenz damit die LED nicht flackern kann geringer ausfallen als bei herkömmlicher PWM. Das was dann aber als "Pulsemuster" entsteht ist keine PWM mehr. Soweit zu Theorie, aber wie siehst in der Praxis aus ? Garnicht so schlecht meine ich, denn jeder schon jetzige Mehrkanal PWM Algorithmus kann mit ganz wenigen Änderungen umgewandelt werden. In den meisten Sourcen findet man einen "Counter" der mit mehreren "Sollwerten" verglichen wird. Dieser Counter wird meistens um +1 inkrementiert. Das wird zb. in +15 abgeändert. Möchte man bei Mehrkanal eine noch bessere Verteilung erreichen dann wird der Counter nach jedem Vergleich=pro Kanal sofort um zb. +32 bei 8 LEDs inkrementiert und am Schluß der Funktion um -1 dekrementiert. Der nun geänderte Source erzeugt keine PWM mehr sondern einen relativ gleichmäßig verteilten Pulsestrom, bei dem nur die Anzahl der ON/OFF Zeiten das Ratio zu entsprechenden Helligkeit darstellt. Gruß Hagen
Hallo allerseits, ich möchte mich mal in die Diskussion einreihen (allerdings leicht Off-Topic). Mir ist bei meinen Experimenten mit PWM aufgefallen, dass beim Dimmen von LEDs in den unteren Helligkeitsstufen z.B. beim Übergang von 1/256 auf 2/256 sehr starke Unterschiede in der Helligkeit zu sehen sind, wohingegen bei einem Übergang von z.B. 150/256 auf 151/256 kaum Unterschiede sichtbar sind. Wenn ich beispielsweise eine Rampenzeit (von dunkel nach hell) von 1 Minute ansetze, dann sieht es untenrum stufig aus und obenrum tut sich kaum etwas. Ich habe auch diverse Dimmerbausteine (z.B. MAX6966 [das hat einen Spaß gemacht, den zu löten ;-)) {QSOP-16 0.5 mm} ]) ausprobiert, aber auch dort existiert das Problem. Hat jemand vielleicht ähnliche Erfahrungen gemacht, oder es bereits geschafft, dieses Problem zu 'umschiffen'? Mir schwebt da eine 32-bit PWM ganz ohne µC vor, allerdings hatte ich noch keine Zeit, das umzusetzen. Denkbar wäre auch ein D/A-Wandler mit anschließendem Vergleich einer Sägezahnspannung. Gibt es vielleicht einfachere Möglichkeiten? Gruß, Florian
Wie sieht es mit dem Vorwiderstand aus? Wenn der zu klein oder nicht vorhanden ist, ist der Stromfluß so hoch, das schon bei Änderungen im unteren Bereich starke Unterschiede zu sehen sind. Ansonsten kann man das auch rechnerisch, logarythmisch regeln wobei sich allerdings die Anzahl der Stufen verringert. MfG Andi
@Hagen: Deine Rechnerei ist mir unklar; wenn man eine LED per Vorwiderstand auf 20mA einstellt, brennt sie nicht durch, wenn das PWM-Siganl 100% vorgibt. @Florian: Du hat es an den Augen; das macht aber nichts, wir alle haben es an den Augen :-) Wir haben es auch alle an den Ohren; darum darf einen Volumen-Einstellung bei Verstärkern auch nicht linear erfolgen. Das mit der 32 Bit PWM aber solltest Du lassen, sonst bekommst Du es im Kopf :-) Rechne mal die Taktfrequenz dazu aus. 16 Bit hingegen könnten Sinn machen, je nach dem, was man vorhat.
@Michael: Warum sollte ich es an den Augen haben? Es sieht einfach stufig aus, probier' es doch einfach mal selbst aus. Die 32-bit nur für die Auflösung der unterschiedlichen Stufen. Ich würde dann aber tatsächlich nur 100 bzw. 128 Stufen verwenden wollen. Von der Idee her: Ein Taktgenerator, ein Zähler, ein Flash und ein Schieberegister (abgesehen von ein paar Oder-Gattern). Mit den restlichen Adressleitungen vom Flash die Stufen anwählen. In der Simulation könnte das so klappen. Gruß, Florian
> Warum sollte ich es an den Augen haben?
Wir haben es alle mit den Augen und Ohren.
Weder die Helligkeit noch die Lautstärke empfinden wir liear.
...
@Michael: >>Deine Rechnerei ist mir unklar; wenn man eine LED per Vorwiderstand >> auf 20mA einstellt, brennt sie nicht durch, wenn das PWM-Siganl >> 100% vorgibt. Jo, dein WENN ist ja auch richtig. WENN ICH aber meine LEDs mit 100mA pulsen möchte und der Hersteller sagt "möglich aber nur 10% der Zeit", dann ist es besser diesen "Dutycycle" nicht zu überschreiten. Nehmen wir mal eine PWM mit einstellbaren Duty von 0 bis 99. Bei herkömlicher PWM kann man dann nur bis 10 einstellen, bei einem verteilten Pulsemuster kann man das Ratio höher einstellen, weil sich eben die Stromlast der LED gleichmäßiger verteilt. Zb. bei 50 mal ON-OFF ist die Strombelastung der LED längst nicht so hoch wie bei 50 mal ON und danach 50 mal OFF. Ehrlich gesagt möchte ich mich auch nicht darüber streiten, es soll jeder das machen was er für richtiger hält. @Florian: probier doch mal meinen oben beschriebenen Trick aus. Er wird dieses "Stufenverhalten" zumindestens teilweise beseitigen. Probiers einfach mal aus und vergleiche mal die minimal notwenige "PWM" Frequenz. Gruß Hagen
@Michael: desweiteren geht es auch nicht so sehr um die Stromlast für die LED ansich sondern die sich ergebende Stromlast vieler so angesteuerter LEDs. Bei normaler PWM würden bei jeder Hellikeit ausser 0 alle LEDs mit Begin des PWM Zyklus mit einem Schlag leuchten. Angenommen 256 LEDs die mit 256 Helligkeiten geregelt werden sollen. Wir lassen sie mit Helligkeit 1 leuchten. Bei normaler PWM würden also gleich zu Begin der PWM für 1/256'tel der PWM zeit alle LEDs gemeinsam leuchten, macht sagen wir mal 256 * 20mA = 5.1A. Was spricht aber dagegen unterscheidliche Pulsemuster pro LED zu benutzen ? Nun würde die Verteilung der ON Zeiten unterschiedlich sein, im Bestfalle mit obigen Beispiel leuchten alle LEDs für 1/256'tel nacheinander über 256 Zeitscheiben der PWM Frequenz verteilt. Also immer nur 1 *20mA aber über 256 Zeitscheiben verteilt. Das ergäbe ein Dauerstrom von 20mA und eine maximalen Impulsstrom von 20mA. In deinem Falle ergäbe sich ein 1/256'tel langer Impulsstrom von 5120mA und dann 255/256'tel 0mA, macht einen Durchschnittsstrom von 5120 / 256 = 20mA. Gruß Hagen
@Florian: natürlich sieht es stufig aus; jeder sieht das ! Eine Änderung von 1/256 nach 2/256 ist eine Änderung um 100%; von 150/256 auf 151/256 nur noch 0,67%. Um diesen 'Effekt' zu korrigieren könnte man jetzt einen konstanten Faktor für die Stufen wählen: sagen wir 1,1. Von Stufe 10 wird auf 11 erhöht; von Stufe 50 auf 55. Wenn man einen großen Regelbereich haben möchte, muß man dann nach unten feiner auflösen: Bits bei die LEDs. Die Augen selbst bewerten die Geschichte dann noch einmal auf eigene Weise. Dabei gibt es interessante Effekte. Blendet man z.B. eine Leuchtfläche zügig auf (0,3 Sekunden), so meint man, die Fläche würde aufblitzen und dann wieder dunkler werden. Macht sie aber nicht, sondern die Iris verengt sich zeitverzögert: man hat es eben an den Augen :-) @Hagen: Die von Dir erwähnte Art der Impulsverteilung verstehe ich schon. Ich hatte weiter oben die Suche nach pwm_8avr.ass angeregt. Damit Du nicht suchen mußt, stelle ich es einmal in den Anhang.
@Hagen: Verstehe ich dich richtig, dass man den Tastgrad (z.b. 2/256) gleichmässig über die 256 Schritte des Timers verteilt, in dem man die Vergleichswerte bei jedem positiven Vergleich um die entsprechende Schrittzahl erhöht? Bei 2/256 wäre dann der eine Vergleichspunkt bei 127 und der andere bei 255? Könntest du das an Hand eines Beispiels vielleicht erklären? Gruß Rahul
@Rahul, ja so ist es. Deswegen ist ja der Begriff PWM dann schon wieder fehl am Platze da man nicht mehr die Weite der Pulse moduliert sondern das ON/OFF Verhältnis. Die Sache ist ganz einfach. Bei normalem Software PWM wird ein Counter in einem Timer immer +-1 inkrementiert. Dieser Counter wird mit allen gewünschten Dutycyclen der einzlenen PWM Kanäle verglichen und abhängig vom Vergleich des PWM Kanal ON/OFF geschaltet. Durch die Inkrementation um +1 werden alle PWM Kanäle immer kontinuierlich eine ON Phase und eine OFF Phase besitzen wobei die Länge der ON Phase eben variabel ist. Nimmt man nun aber einen anderen Inkrement zb. +15 so läuft unser Counter bei 256 ja über. Dies macht aber nichts da so mathematisch ein modularer Ring entsteht. Man inkrementiert also einen Counter für 256 Schritte modular mit Counter = (Counter + 15) mod 256. Wenn du jetzt mal eine kleine Software schreibst und auf diese Weise einen Counter 256 mal um +15 inkrementierst so wirst du sehen das der Counter-Wert denoch alle 256 möglichen Werte zwischen 0 bis 255 annehmen wird. Aber diese Werte sind nicht mehr sequentiell eine Zahlenreihe jeweils um +1 inkrementiort sondern eher eine Periodeische Zahlenreihe. Der Erfolg dessen ist das nun die 256 Zeitscheiben der PWM quasi "zerstückelt bzw. umgeordnet" werden, es entsteht ein Pulsemuster dessen Anzahl ON/OFF Staties identisch ist mit der Pulseweite der PWM. Diese einfache Methode bewirkt das sich für alle Kanäle deren Pulseweite gleichermaßen zerstückelt wird. Um ein noch besseres Ergebniss zu erzielen müssen wir aber noch den "Startzeitpunkt" des Pulsmuster pro Kanal separat und unterschiedlich zu den anderen Kanäle einstellen. D.h. wenn Kanal 0 und 1 die gleiche "Pulseweite" haben sollen == Helligkeit = Anzahl der ON-OFF Zyklen, so müssen sich deren Pulsemuster leicht zeitlich verschoben überlappen. Man erreicht dies nun indem man den Counter für JEDEN Kanal nach dem Vergleich inkrementiert. Beispiel 8 Kanal und 256 PWM Stufen, ergo wird Counter um +16 inkremeniert nach jedem einzelnen Vergleich. Bei einem einzigsten Aufruf der TimerISR wird also Counter um +128 inkrementiert und jeder Kanal bekommt einen eigenen Vergleichswert. Einen Source habe ich oben schon gepostet. Im Attachment mal eine kleine Anwednung die die PWM im Vergleich zum Pulsemuster grafisch gegenüberstellt. 4 Kanäle mit jeweils 256 Stufen werden dargestellt. Oben die blauen 4 Kanaäle stelen die methode mit den verteilten Pulseen dar. Darunter in Rot der Gesamtstrom der sich ergäbe. Die grünen Kanäle sind die Anzeige einer herkömmlichen PWM und wiederum darunter die Stromlast. Gruß Hagen
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.