Hallo zusammen, ich mache mir gerade Gedanken über die im Artikel http://www.mikrocontroller.net/articles/Soft-PWM unter "Intelligenter Lösungsansatz" vorgestellte Idee. Konkret denke ich darüber nach, die Software auf 10 Bit PWM statt 8 Bit aufzubohren, um beim ansteuern von Leds mehr Werte mit logarithmischem Verhältniss zur Verfügung zu haben. Eigentlich sollte das doch recht problemlos klappen oder? Nur weiß ich nicht, ob ich mit meinen Gedanken richtig liege. 1) Bei dieser Art von PWM ist es recht einfach, die Auflösung zu erhöhen, da die Anzahl an maximalen Interrupts von der Kanalzahl abhängt, und dadurch die CPU-Last nicht nennenswert zunimmt. Richtig? 2) Die möglichen "Schaltpunkte" liegen näher zusammen (Faktor 4), dadurch muss die ISR kürzer sein, um Jitter bei nah beisammen liegenden Werten zu vermeiden. Richtig? 3) Die Berechnung der Timerticks pro PWM-Schritt wird ungenauer durch den größeren Rundungsfehler. (Bei 8 Bit: T_PWM = 39,0625; bei 10 Bit: T_PWM = 9,765625) Diese Tatsache ist aber eigentlich nicht tragisch. Denn wenn ich den Wert wieder zurückrechne komme ich auf eine F_PWM von 108,5. Ist das nicht sogar noch ein Gewinn? 4) Das Problem aus 3) (so es denn überhaupt ein Problem ist) könnte man durch "cleveres Runden" teilweise abfangen. Aber eigentlich ja nicht nötig, solange man nicht auf eine exakte Frequenz angewießen ist. Sind meine Überlegungen denn einigermaßen richtig? Oder stelle ich mir die Erhöhung auf 10 Bit doch etwas zu leicht vor? Grüße, Karlo
Einfacher ist die Binary Code Modulation (BCM). Für 10 Bit sind nur 10 Interrupts nötig, Kanalzahl egal.
Naja, das kommt wohl eher auf den Anwendungsfall an. Viele Kanäle: BCM Hohe Auflösung bei konstanten Kanälen: PWM Hast du dir meinen ersten Beitrag ganz durchgelesen? Bei der Soft-PWM habe ich, nach Erhöhung von 8 auf 10 Bit, immer noch nur max. 9 Interrupts (bei 8 Kanälen). Außer natürlich ich habe nen Denkfehler und überseh was, deswegen auch der Beitrag.
Was du auch machen kannst, ist, das Tastverhältnis immer leicht zu variieren. Damit hast du deine Zwischenstufen. Habe das bei einer digitalen Schaltregler-Ansteuerung mal so umgesetzt, funktionierte wunderbar. Max
Ja, danke, schön und gut. Inwiefern hat das mit meinem ersten Beitrag zu tun? Ich möchte nur wissen: Habe ich das Prinzip dieses Artikels und den Quelltext richtig verstanden? Und sind meine Gedanken (siehe Eröffnungsbeitrag) dazu richtig?
@Karlo (Gast) >Konkret denke ich darüber nach, die Software auf 10 Bit PWM statt 8 Bit >aufzubohren, um beim ansteuern von Leds mehr Werte mit logarithmischem >Verhältniss zur Verfügung zu haben. Mach doch. Hab ich vor einiger Zeit gemacht, 24 Kanal DMX-Empfänger mit 10 Bit PWM. >Eigentlich sollte das doch recht problemlos klappen oder? Ja, der Interrupt muss halt schnell genug sein, sprich, der CPU-Takt möglichst hoch. für die 24 Kanäle brauchte ich 20 MHz. >1) Bei dieser Art von PWM ist es recht einfach, die Auflösung zu >erhöhen, da die Anzahl an maximalen Interrupts von der Kanalzahl >abhängt, und dadurch die CPU-Last nicht nennenswert zunimmt. Richtig? Falsch. Man muss den Worst case immer erfüllen, und da ist über 10 Bit schnell Feierabend. Siehe Artikel. >2) Die möglichen "Schaltpunkte" liegen näher zusammen (Faktor 4), >dadurch muss die ISR kürzer sein, um Jitter bei nah beisammen liegenden >Werten zu vermeiden. Richtig? Ja. >3) Die Berechnung der Timerticks pro PWM-Schritt wird ungenauer durch >den größeren Rundungsfehler. Ja. >Denn wenn ich den Wert wieder zurückrechne komme ich auf eine F_PWM von >108,5. Ist das nicht sogar noch ein Gewinn? Jain. >4) Das Problem aus 3) (so es denn überhaupt ein Problem ist) könnte man >durch "cleveres Runden" teilweise abfangen. Aber eigentlich ja nicht >nötig, solange man nicht auf eine exakte Frequenz angewießen ist. Eben. >Sind meine Überlegungen denn einigermaßen richtig? >Oder stelle ich mir die Erhöhung auf 10 Bit doch etwas zu leicht vor? 10 Bit geht noch, dann ist aber nicht mehr viel Luft.
Karlo schrieb: > ich mache mir gerade Gedanken über die im Artikel > http://www.mikrocontroller.net/articles/Soft-PWM unter "Intelligenter > Lösungsansatz" vorgestellte Idee. > 1) Bei dieser Art von PWM ist es recht einfach, die Auflösung zu > erhöhen, da die Anzahl an maximalen Interrupts von der Kanalzahl > abhängt, und dadurch die CPU-Last nicht nennenswert zunimmt. Richtig? Es ist nur so lange einfach, wie die Laufzeit der PWM-ISR kürzer ist als die kürzeste Einschaltzeit. > 2) Die möglichen "Schaltpunkte" liegen näher zusammen (Faktor 4), > dadurch muss die ISR kürzer sein, um Jitter bei nah beisammen liegenden > Werten zu vermeiden. Richtig? Es geht nicht um Jitter. Sondern darum, daß der nächste Timer-Interrupt erst dann kommen darf, wenn die ISR sicher wieder beendet ist. > 3) Die Berechnung der Timerticks pro PWM-Schritt wird ungenauer durch > den größeren Rundungsfehler. Das ist kein Problem. Das Auge ist kein Meßgerät. Deswegen ist auch Jitter eher kein Problem. > Oder stelle ich mir die Erhöhung auf 10 Bit doch etwas zu leicht vor? Meine 3-Kanal Soft-PWM aus diesem Projekt: Beitrag "noch ein AVR Moodlight" realisiert eine minimale Einschaltzeit von 61 Takten. Die PWM-Periode ist 2^16 = 65536 Takte, womit sich eine Variation von 1074:1 bzw. eine Auflösung von 10.07 Bit ergibt. Und mit 8MHz Taktfrequenz eine Wiederholrate von 122Hz. Die 10 Bit reichen für 205 Helligkeitsstufen mit einer Schrittweite (Faktor) von 1.02. Wobei ich hier schon mogele und am unteren Ende der Skala von antilogarithmisch auf linear ausweiche. Wesentlich besser wird es nicht, zumindest nicht ohne die ISR komplett in Assembler zu schreiben. Andere Alternative wäre BCM, wenn man die kurzen Bitzeiten mit busy waiting erzeugt. XL
Karlo schrieb: > 2) Die möglichen "Schaltpunkte" liegen näher zusammen (Faktor 4), > dadurch muss die ISR kürzer sein, um Jitter bei nah beisammen liegenden > Werten zu vermeiden. Richtig? Man könnte einen 74HC595 zur Ausgabe nehmen, der mit dem Compare-Pin gelatcht wird. Dann ist die PWM völlig jitterfrei. Das SRG muß nur bis zum nächsten Compare neu geladen worden sein.
Danke dir Falk! Dazu hätt ich aber noch eine Frage: Falk Brunner schrieb: > Ja, der Interrupt muss halt schnell genug sein, sprich, der CPU-Takt > möglichst hoch. für die 24 Kanäle brauchte ich 20 MHz. Das limitierende Element ist ja die Dauer der ISR. Diese muss kurz genug sein damit der nächste Interrupt nicht schon ansteht wenn die ISR returned. Denn im Worst Case haben zwei Kanäle einen nur um 1 verschiedenen Duty Cycle. Klar, eine Erhöhung der Kanäle bringt der ISR mehr Arbeit ein. Sie muss 3 Ports beschreiben anstatt nur noch einen (um bei deinen 24 Kanälen zu bleiben). Der Hauptschleife bleibt auch weniger Zeit (irgendwann ist deswegen mit diesem Verfahren Schluß, => BCM). Hast du bei dir denn eine höhere F_PWM? Denn ansonsten sehe ich nicht, wieso du für die 24 Kanäle 20MHz brauchst.
@ Karlo (Gast) >Das limitierende Element ist ja die Dauer der ISR. Ja. >Diese muss kurz genug sein damit der nächste Interrupt nicht schon >ansteht wenn die ISR returned. re-was? AUA! >Denn im Worst Case haben zwei Kanäle einen nur um 1 verschiedenen Duty >Cycle. Genau. >Der Hauptschleife bleibt auch weniger Zeit Die hat alle Zeit der Welt, der Aufwand zur Änderung der PWM-Daten ist gering im Vergleich zum engen PWM-Timing. >Hast du bei dir denn eine höhere F_PWM? 100Hz. >Denn ansonsten sehe ich nicht, wieso du für die 24 Kanäle 20MHz >brauchst. Ich schon, als ich den Code geschrieben und simululiert habe ;-) 100 Hz PWM mit 10 Bit macht 10us bzw 100kHz PWM Takt. Bei 20 MHz hat man da nur 200 Takte, meine IS braucht glaub ich um die 170. Nebenbei läuft noch ein UART RX Interrupt vom DMX mit bis zu 22kHz, sprich 44us/880 Takten Periodendauer, der soll sich auch nicht verschlucken, auch mit FIFO. Aber das Ergebnis kann sich sehen lassen. ;-) Beitrag "Re: DMX Steuerung 24 Kanal"
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.