Hi zusammen, ich möchte 16 bzw. 32 LEDs über einen IC ansteuern. Bisher habe ich das mit Schieberegistern gemacht. Nun möchte ich aber jeder LED noch eine PWM zuweisen, um sie nach eigenen Wünschen zu dimmen. Nun bin ich mir aber nicht sicher, wie ich das mit den Schieberegistern regeln soll. Natürlich kann ich pro "PWM Takt" die Schieberegister neu beschreiben, aber das Schubsen der Bits in die Schieberegister kostet ja auch Zeit und an der Stelle komme ich ins Straucheln. Wie berechne ich die Zeit, die das Beschreiben der 32 Bits bei 4 Schieberegistern kostet? Für das Soft-PWM orientiere ich mich an der (dritten, effizienten) Vorlage, die auch hier auf der Seite verwendet wird (http://www.mikrocontroller.net/articles/Soft-PWM). Eine Alternative wäre natürlich nun das Soft-PWM direkt am IC durchzuführen, aber das ich möchte -sofern möglich- vermeiden. Was haltet ihr von diesem Thread zu diesem Thema: Beitrag "16 Bit Soft-PWM auf (fast) beliebig vielen AVR-Ports" Habt ihr eine Idee, was ich mir diesbezüglich mal anlesen sollte?
@ Durokh (Gast) >ich möchte 16 bzw. 32 LEDs über einen IC ansteuern. Dann nimm einen PWM-Fähigen IC ala TLC5940. >aber das Schubsen der Bits in die Schieberegister kostet ja auch Zeit >und an der Stelle komme ich ins Straucheln. >Wie berechne ich die Zeit, die das Beschreiben der 32 Bits bei 4 >Schieberegistern kostet? Im Simulator. >Für das Soft-PWM orientiere ich mich an der (dritten, effizienten) >Vorlage, die auch hier auf der Seite verwendet wird >(http://www.mikrocontroller.net/articles/Soft-PWM). Gut ;-) >Eine Alternative wäre natürlich nun das Soft-PWM direkt am IC >durchzuführen, aber das ich möchte -sofern möglich- vermeiden. Warum? Welcher IC? >Was haltet ihr von diesem Thread zu diesem Thema: >Beitrag "16 Bit Soft-PWM auf (fast) beliebig vielen AVR-Ports" Naja, ein Ansatz, wenn gleich etwas komplizierter. Mit Soft-PWM aus dem Artikel schafft man 10 Bit Auflösung bei 100Hz und 32 Kanälen auf einem 20 MHz AVR, und der hat dann noch MASSIG CPU-Leistung frei, wenn gleich er stoßweise nahe 100% ausgelastet ist. Beitrag "Re: DMX Steuerung 24 Kanal" > Habt ihr eine Idee, was ich mir diesbezüglich mal anlesen sollte?
>Warum? Welcher IC? Ich nutze im Moment einen Atmega8. Notfalls würde ich eben einen atmega nehmen, der mehrere Ports hat. Die Lösung gefällt mir aber nicht, da 32 LEDs anschließen möchte --> das wären dann ja 4 Ports, und ich möchte noch ein paar andere Sachen anschließen :) Den TLC5940 habe ich mir gerade angeschaut und der scheint ja schonmal sehr geeignet zu sein. Dazu aber noch eine sehr wichtige Frage: Ich muss die LED sehr zeitgenau ansteuern. Sprich, LED1 geht an und 2 millisekunde später geht LED2 an. Nach 1 ms geht LED 1 wieder aus. Für jede Änderung eines Zustandes muss ich natürlich den ganzen IC neu mit Daten versorgen, was natürlich Zeit kostet. Mein Atmega läuft mit rund 14 Mhz. Ist das zeitlich noch möglich? Ansonsten werde ich wohl kaum darum herum kommen, die Ports direkt vom IC zu nutzen, oder?
Durokh schrieb: > Den TLC5940 habe ich mir gerade angeschaut und der scheint ja schonmal > sehr geeignet zu sein. Dazu aber noch eine sehr wichtige Frage: > Ich muss die LED sehr zeitgenau ansteuern. > Sprich, LED1 geht an und 2 millisekunde später geht LED2 an. Nach 1 ms > geht LED 1 wieder aus. Wo kommt diese Information her? Wenn die von extern kommt, dann braucht ja auch das Übermitteln der 'Befehle' seine Zeit. Abgesehen davon: Millisekunden sind für einen µC schon eher in der Kategorie - gähn, wars das oder kann ich zwischendurch noch ein Nickerchen machen? > Für jede Änderung eines Zustandes muss ich natürlich den ganzen IC neu > mit Daten versorgen, was natürlich Zeit kostet. Mein Atmega läuft mit > rund 14 Mhz. Na dann rechne mal, wieviele Befehle dein µC in 1 Millisekunde durchackern kann. So als Schnitt kannst du überschlagsmässig rechnen, dass ein einzelner Befehl um die 1.2 bis 1.5 Takte braucht (es gibt welche die laufen in 1 Takt ab und es gibt welche die laufen in 2 Takten ab. Eine Mischung wie sie in einem typischen Programm vorliegt läuft ungefähr auf die 1.2 Takte raus. So genau braucht man das aber auch nicht, wenn man mal grob überschlagen möchte was da so rauskommt. Ob das jetzt 12-tausend Befehle sind oder 10-tausend, ist herzlich egal, wenn du gerade mal ein paar 100 alle Millisekunden brauchst)
@ Durokh (Gast) >Ich muss die LED sehr zeitgenau ansteuern. >Sprich, LED1 geht an und 2 millisekunde später geht LED2 an. Nach 1 ms >geht LED 1 wieder aus. Propelleruhr? >Für jede Änderung eines Zustandes muss ich natürlich den ganzen IC neu >mit Daten versorgen, was natürlich Zeit kostet. Mein Atmega läuft mit >rund 14 Mhz. >Ist das zeitlich noch möglich? Problemlos. 16 LEDs a 12 Bit macht 192 Bit / 24 Byte, die taktet der AVR mit SPI-Modul bei 7 MHz in 27,4us raus, bei 32 LEDs halt in 54,8us. Man schafft also bis zu 18 kHz Updatefrequnenz ;-) Die zeitliche Genauigkeit der Sache liegt ohne Mühe bei 10us, mit Aufwand vielleicht bei 1us. Sollte reichen ;-)
Karl Heinz Buchegger schrieb: > Wo kommt diese Information her? > Wenn die von extern kommt, dann braucht ja auch das Übermitteln der > 'Befehle' seine Zeit. > > Abgesehen davon: Millisekunden sind für einen µC schon eher in der > Kategorie - gähn, wars das oder kann ich zwischendurch noch ein > Nickerchen machen? Mein Atmega hat eine Art "Zeitplan" (der Zeitplan wird aus einem Stream über die serielle Schnittstelle geneiert; der Zeitplan wird vom Nutzer festgelegt), wann welcher Pin/Kanal/LED (kommt ja nun auf den Lösungsansatz an, was zutrifft) mit welcher PWM belegt werden soll. Vielleicht habe ich das undeutlich ausgedrückt, aber genau das Übermitteln meinte ich als Problemquelle. Ich bin nun leider noch nicht genug in dem Thema (mit ICs beschäftige ich mich erst seit kurzem), um die Dauer der Übertragung zu brechnen. Oder besser gesagt, ich weiß nicht genau, woran ich mich da orientieren bzw. welche Schritte ich alle durchgehen soll. Ich glaube, da muss ich mich nochmal hinsetzen und lernen :)
Falk Brunner schrieb: > Problemlos. 16 LEDs a 12 Bit macht 192 Bit / 24 Byte, die taktet der AVR > mit SPI-Modul bei 7 MHz in 27,4us raus, bei 32 LEDs halt in 54,8us. Man > schafft also bis zu 18 kHz Updatefrequnenz ;-) > > Die zeitliche Genauigkeit der Sache liegt ohne Mühe bei 10us, mit > Aufwand vielleicht bei 1us. Sollte reichen ;-) Sorry für Doppelpost, du hast geantwortet während ich geschrieben habe :) Ok, danke für das Rechenbeispiel! Wie würdest du die Version "mit Aufwand" angehen? Auch wenn ich das vielleicht nicht jetzt sofort verstehe bzw. umsetzen kann, kann ich mir das ja als späteres Ziel nehmen. Danke für die hilfreichen Antworten übrigens!
Durokh schrieb: > Mein Atmega hat eine Art "Zeitplan" (der Zeitplan wird aus einem Stream > über die serielle Schnittstelle geneiert; der Zeitplan wird vom Nutzer > festgelegt), wann welcher Pin/Kanal/LED (kommt ja nun auf den > Lösungsansatz an, was zutrifft) mit welcher PWM belegt werden soll. Aber dieser Plan wird einmalig übertragen? Während die Sequenz läuft wird der Plan 'nie leer', sondern von der Gegenstelle immer rechtezitig aufgefüllt. > Vielleicht habe ich das undeutlich ausgedrückt, aber genau das > Übermitteln meinte ich als Problemquelle. Bitte präzise sein. Welches Übermitteln? Das vom Benutzer zum µC oder das vom µC an den TLC5940? Letzteres dauert immer gleich lang und geht rasend schnell. Byte in die SPI Einheit einschreiben und Übertragung starten. Während die SPI Einheit die Bits raustaktet, kann der µC schon das nächste Byte besorgen. Über den Daumen dauert das keine 10 Takte pro Byte wenn die SPI Vollgas fahren kann. Bei 14Mhz sind 10 Takte ca. 0.1µs oder 0.0001 Millisekunden. Weit weg von deinen 1 Millisekunden. Noch Fragen?
Durokh schrieb: > Wie würdest du die Version "mit Aufwand" angehen? Machs erst mal normal. Es bringt nichts, wenn du das Ausleeren des Mistkübels um 10 Sekunden beschleunigen kannst, wenn du sowieso 24 Stunden Zeit hast, bis die nächste Entleerung ansteht und du Zwischendurch nur Däumchen drehst. Nicht päpstlicher als der Papst sein. Erst mal so einfach wie möglich, dafür aber korrekt implementieren. Und dann sieht man nach, ob man sich ein Zeitproblem eingehandelt hat und löst dieses. Hat man kein Problem, dann braucht man auch nichts lösen.
Karl Heinz Buchegger schrieb: > Bitte präzise sein. > Welches Übermitteln? > Das vom Benutzer zum µC oder das vom µC an den TLC5940? Jup, meinte das letztere. Die Übertragung vom Benutzer an den Atmega findet nur ein Mal statt, danach geht er den Zeitplan durch. Karl Heinz Buchegger schrieb: > Nicht päpstlicher als der Papst sein. > Erst mal so einfach wie möglich, dafür aber korrekt implementieren. Und > dann sieht man nach, ob man sich ein Zeitproblem eingehandelt hat und > löst dieses. Hat man kein Problem, dann braucht man auch nichts lösen. Zu Befehl :) Gebe ich dir vollkommen Recht. Ich besorg mir dann mal den TLC5940 und spiele mal damit rum. Besten Dank!
und zum Thema Tellerrand: schau dir auch mal diesen Ansatz an http://www.batsocks.co.uk/readme/art_bcm_1.htm Sehr einfach umzusetzen und der overhead steigt kaum mit der Anzahl der Soft_PWMs. MfG
@ Durokh (Gast) >Wie würdest du die Version "mit Aufwand" angehen? Auch wenn ich das >vielleicht nicht jetzt sofort verstehe bzw. umsetzen kann, kann ich mir >das ja als späteres Ziel nehmen. Naja, die Frage ist, ob dur WIRKLICH PWM braucht/willst. Ich höre eher raus, dass du LED-Sequenzen im 1ms Raster ausgeben willst. Während dieser 1ms ist die jeweilie LED immer an oder aus, es läuft keine PWM. Ist das richtig? Wenn ja, brauchst du keine TLC, dann reichen normale IO-Pins oder normale Schieberegister ala 74HC595. AVR-Tutorial: Schieberegister Wenn nein, geht Soft-PWM sowieso nicht, weil die Zeiten einfach zu kurz werden.
Falk Brunner schrieb: > Naja, die Frage ist, ob dur WIRKLICH PWM braucht/willst. Ich höre eher > raus, dass du LED-Sequenzen im 1ms Raster ausgeben willst. Während > dieser 1ms ist die jeweilie LED immer an oder aus, es läuft keine PWM. > Ist das richtig? Ich möchte bspw: - LED1 zum Zeitpunkt 0 ms mit einer bestimmten Helligkeit anstellen - LED2 zum Zeitpunkt 3 ms mit einer bestimmten Helligkeit anstellen - LED1 zum Zeitpunkt 5 ms mit einer bestimmten Helligkeit ausstellen - LED2 zum Zeitpunkt 5 ms mit einer bestimmten Helligkeit ausstellen Bisher habe ich die LEDs ohne Modulation der Helligkeit betrieben und habe dafür auch den 74HC595 verwendet. Falk Brunner schrieb: > Wenn nein, geht Soft-PWM sowieso nicht, weil die Zeiten einfach zu kurz > werden. Was genau meinst du damit? Karl Heinz hat doch vorgerechnet, wo die zeitlichen Grenzen liegen, oder verstehe ich das falsch?
Bugs schrieb: > und zum Thema Tellerrand: > > schau dir auch mal diesen Ansatz an > http://www.batsocks.co.uk/readme/art_bcm_1.htm > Sehr einfach umzusetzen und der overhead steigt kaum mit der Anzahl der > Soft_PWMs. > > MfG Sehr interessanter Artikel! Nur diese Formel ist mir nicht ganz klar: >The code runs on an 8Mhz Mega8 and uses a 'tick' of 64 processor cycles. >That means a base frequency of 488hz for the binary code. For reasons why >even this speed might not be fast enough, see the "Complications: How fast >to (not) flicker" section. 8 Bit bedeutet, es gibt 8 mögliche Schaltpunkte. Dazwischen liegen jeweils 64 Clocks: 8 * 64 = 512 Diese Sequenz passiert 488 mal pro Sekunde: 488 * 512 = 249856 Wo bleiben die restlichen 7,7 Millionen Takte?
Durokh schrieb: > Was genau meinst du damit? > Karl Heinz hat doch vorgerechnet, wo die zeitlichen Grenzen liegen, oder > verstehe ich das falsch? Langsam. Wenn PWM ins Spiel kommt um damit unterschiedliche Helligkeiten zu erreichen, dann steigern sich deine Timing Anforderungen gleich mal ordentlich. Da ist dann nichts mehr mit alle Millisekunde muss eine andere LED leuchten können. Bei einer 10 Bit PWM kannst du alle Zeiten gleich mal durch 1024 dividieren und dann wirds tatsächlich eng.
le x. schrieb: > Wo bleiben die restlichen 7,7 Millionen Takte? Vergesst es, hab meinen Fehler gefunden :-)
@ Durokh (Gast) >- LED1 zum Zeitpunkt 0 ms mit einer bestimmten Helligkeit anstellen >- LED2 zum Zeitpunkt 3 ms mit einer bestimmten Helligkeit anstellen >- LED1 zum Zeitpunkt 5 ms mit einer bestimmten Helligkeit ausstellen >- LED2 zum Zeitpunkt 5 ms mit einer bestimmten Helligkeit ausstellen >Bisher habe ich die LEDs ohne Modulation der Helligkeit betrieben und >habe dafür auch den 74HC595 verwendet. Aha. >> Wenn nein, geht Soft-PWM sowieso nicht, weil die Zeiten einfach zu kurz >> werden. >Was genau meinst du damit? Wenn du im 1ms Raster deine LEDs mit verschiedenen Helligkeiten betrieben willst, so ist das MINDESTENS 1kHz PWM-Frequenz. Bei 8 Bit bedeutet das aber 256 kHz PWM Takt. Das will/kann man nun wirklich nicht mehr in Software erledigen, es sein denn man nimmt nen 1 GHz DSP. Nicht sinnvoll. >Karl Heinz hat doch vorgerechnet, wo die zeitlichen Grenzen liegen, oder >verstehe ich das falsch? Da wusste auch noch keiner, welche PWM-Frequnz du haben willst. Normale Leute kommen mit 100-200 Hz aus.
le x. schrieb: > Vergesst es, hab meinen Fehler gefunden :-) Sorry es artet grad aus. Ich verstehs doch nicht. Bei dieser Technik hab ich doch bei 8 Bit nur 8 mögliche Schaltpunkte. Die Zeiten dazwischen verändern sich halt, je nach "Wertigkeit" des Bits...
le x. schrieb: > le x. schrieb: >> Vergesst es, hab meinen Fehler gefunden :-) > > Sorry es artet grad aus. Ich verstehs doch nicht. > Bei dieser Technik hab ich doch bei 8 Bit nur 8 mögliche Schaltpunkte. > Die Zeiten dazwischen verändern sich halt, je nach "Wertigkeit" des > Bits... Du hast eine komische Definition einer PWM. Eine 8 Bit PWM erlaubt dir 256 Abstufungen. Bei lediglich 8 'Schaltpunkten' hast du eine 3 Bit PWM. Führen wir mal einen weiteren Begriff ein. Den 'Pixeltakt'. Das ist das Zeitraster, das du brauchst, damit dir eine LED bei einer Umdrehnung entsprechend viele 'Punkte' um Umfang erzeugen kann. Willst du also eine Umdrehung deines Propellers in 1000 Punkte auflösen können, dann brauchst du einen Pixeltakt von 1kHz. Da stecken die 1 Millisekunde drinnen. Das ist für einen µC noch kein Problem. Aber jetzt kommt PWM ins Spiel. Willst du einen dieser Punkte in 8 Helligkeitsabstufungen darstellen, dann brauchst du eine PWM Frequenz die um das 8-fache höher ist als dieser Pixeltakt. Denn du musst ja diese 1 Millisekunde in 8 Zeitabschnitte aufdröseln können, damit die LED je nach Anforderung eben nicht 1 Millisekunde leuchtet, sondern in 1/8 Abstufungen davon. Damit sind wir bei einem 125µs Zeitraster zur Behandlung der LED. Jetzt fängt die notwendige PWM Frequenz an in die Höhe zu klettern. 8kHz PWM Frequenz sind schon sportlich. Reichen die 8 Abstufungen nicht (und das ist wirklich etwas wenig), dann schraubt sich diese Anforderung an die PWM Frequenz ganz schnell soweit hoch, dass man sie mit dem µC nicht mehr realisieren kann.
@le x. (lex_91)
>Bei dieser Technik hab ich doch bei 8 Bit nur 8 mögliche Schaltpunkte.
Falsch. 2^8=256
Ich habe mich auf den von Bugs verlinkten Artikel bezogen, keine "herkömmliche" PWM...
Hallo, erstmal: Sehr interessanter Thread. Zufällig habe ich selber in naher Zukunft vor, ein Matrixdisplay zu bauen. Mit 8-bit PWM und und 32 Spalten * 8 Reihen wird das dann ein Pixeltakt von knapp 16 kHz. Aber erstmal les' ich hier weiter mit. :) Leonhard K
Karl Heinz Buchegger schrieb: > Du hast eine komische Definition einer PWM. > Eine 8 Bit PWM erlaubt dir 256 Abstufungen. > Bei lediglich 8 'Schaltpunkten' hast du eine 3 Bit PWM. > > Führen wir mal einen weiteren Begriff ein. Den 'Pixeltakt'. Das ist das > Zeitraster, das du brauchst, damit dir eine LED bei einer Umdrehnung > entsprechend viele 'Punkte' um Umfang erzeugen kann. > Willst du also eine Umdrehung deines Propellers in 1000 Punkte auflösen > können, dann brauchst du einen Pixeltakt von 1kHz. Da stecken die 1 > Millisekunde drinnen. > Das ist für einen µC noch kein Problem. > > Aber jetzt kommt PWM ins Spiel. Willst du einen dieser Punkte in 8 > Helligkeitsabstufungen darstellen, dann brauchst du eine PWM Frequenz > die um das 8-fache höher ist als dieser Pixeltakt. Denn du musst ja > diese 1 Millisekunde in 8 Zeitabschnitte aufdröseln können, damit die > LED je nach Anforderung eben nicht 1 Millisekunde leuchtet, sondern in > 1/8 Abstufungen davon. Damit sind wir bei einem 125µs Zeitraster zur > Behandlung der LED. > Jetzt fängt die notwendige PWM Frequenz an in die Höhe zu klettern. 8kHz > PWM Frequenz sind schon sportlich. Reichen die 8 Abstufungen nicht (und > das ist wirklich etwas wenig), dann schraubt sich diese Anforderung an > die PWM Frequenz ganz schnell soweit hoch, dass man sie mit dem µC nicht > mehr realisieren kann. Ok, das verstehe ich. Das bedeutet, entweder wähle ich das minimale Zeitfenster also größer, oder ich verringere die Anzahl an möglichen Abstufungen. --> Für meine derzeitigen Zwecke sind 8 Abstufungen vollkommen ausreichend. Die 1ms wird zwar nur sehr selten vorkommen (wahrscheinlicher: 5ms), aber die zeitliche Auflösung ist mir wichtiger als die Anzahl der Abstufungen. Nun ist die Frage also: Sind denn 8Khz pwm mit der im PWM-Tutorial angegeben Lösung (Ansatz Nr. 3) möglich? Hier nochmal der Link; http://www.mikrocontroller.net/articles/Soft-PWM Zweite Frage: Inwiefern kann ich den TLC5940 als Alternative dafür nutzen? Ich bin leider in meinem Verständnis noch nicht so weit, wo ich einsehen kann, ob er meinen Anforderungen (1ms / 8 Abstufungen) gerecht wird. Da stellt sich ja die Frage, ob er die 8khz schafft... Das hineinschubsen des gewünschen PWM pro Pin sollte aber doch in dem Zeitfenster möglich sein, oder?
@ Durokh (Gast) >--> Für meine derzeitigen Zwecke sind 8 Abstufungen vollkommen >ausreichend. Also eine 3 Bit PWM mit 1 kHz. >Nun ist die Frage also: Sind denn 8Khz pwm mit der im PWM-Tutorial >angegeben Lösung (Ansatz Nr. 3) möglich? Dafür lohnt das nicht. Das macht man mit dem einfachen (2.) Ansatz. >Inwiefern kann ich den TLC5940 als Alternative dafür nutzen? Kann man. >ob er meinen Anforderungen (1ms / 8 Abstufungen) gerecht wird. Ja. >sich ja die Frage, ob er die 8khz schafft... Ja. >Das hineinschubsen des gewünschen PWM pro Pin sollte aber doch in dem >Zeitfenster möglich sein, oder? Den kann man mit bis zu 30 MHz takten. Das reicht ;-)
Dann ist ja alles geklärt :) Danke! Heute habe ich eine Menge dazugelernt :)
Falk Brunner schrieb: > @le x. (lex_91) > >>Bei dieser Technik hab ich doch bei 8 Bit nur 8 mögliche Schaltpunkte. > > Falsch. 2^8=256 Doch. Nochmal: ich bezog mich auf den verlinkten Artikel. Da gehts um BCM - Binary Code Modulation. Und da hab ich - bei 8 Bit - doch nur 8 mögliche Schaltpunkte. Diese variieren allerdings in ihrem "Abstand".
@ le x. (lex_91) >>>Bei dieser Technik hab ich doch bei 8 Bit nur 8 mögliche Schaltpunkte. >> Falsch. 2^8=256 >Nochmal: ich bezog mich auf den verlinkten Artikel. >Da gehts um BCM - Binary Code Modulation. Dann sollte man das auch deutlich schreiben, denn Hellsehen können die Wenigsten hier.
Ohne einen Kleinkrieg anfangen zu wollen, mein erster Beitrag hier: Beitrag "Re: Soft-PWM und Schieberegister / Multiplexen" Aber der Thread is eh gelaufen, schönen Tag noch :-)
le x. schrieb: >>>Bei dieser Technik hab ich doch bei 8 Bit nur 8 mögliche Schaltpunkte. >> >> Falsch. 2^8=256 > > Nochmal: ich bezog mich auf den verlinkten Artikel. > Da gehts um BCM - Binary Code Modulation. Den Begriff als solchen kannte ich zwar nicht (und schon gar nicht "Bit Angle Modulation"). Das Verfahren habe ich aber schon vor 20 Jahren "erfunden" und damit 8 LEDs mit 7-Bit PWM am C64-Userport betrieben. Ich würde das eher "binär gewichtete PWM" nennen. Spaßeshalber hänge ich das Programm mal an (6502 ASM für Profi-Ass). > Und da hab ich - bei 8 Bit - doch nur 8 mögliche Schaltpunkte. Diese > variieren allerdings in ihrem "Abstand". "variieren" ist mißverständlich. Die Schaltpunkte liegen schon auf einem festen Raster, aber die Abstände zwischen den Schaltpunkten sind eben nicht konstant, sondern binär gewichtet. Im Prinzip wird der PWM-Wert bitseriell auf den Ausgabepin geschoben. Die einzelnen Bits liegen dabei nicht gleich lange an, sondern entsprechend ihrer Wertigkeit. Und nun zu deiner Frage: t_min = 64 Takte ist die Länge des kürzesten Zeitschlitzes (für das LSB des PWM-Wertes). Das nächsthöhere Bit liegt doppelt so lange an: 128 Takte. Der dritte Umschaltpunkt ist dann bei 64+128=192 Takten und der folgende Zeitschlitz ist wieder doppelt so lang wie der vorhergehende: 256 Takte. usw. usf. Der Gesamtzeitbedarf (Periodenlänge) für eine n-Bit PWM mit kürzestem Zeitschlitz t_min ist dann
für die 8-Bit PWM mit t_min=64 also t_periode = 64*255 = 16320. Mit 8MHz Takt kommen wir auf eine Wiederholrate von 490Hz. Die 488Hz aus dem verlinkten Artikel sind falsch. Anscheinend rechnen sie da mit 2^n statt dem korrekten (2^n-1). XL
Bugs schrieb: > schau dir auch mal diesen Ansatz an > http://www.batsocks.co.uk/readme/art_bcm_1.htm Diese Methode würde ich auch empfehlen, sie hat die geringste CPU-Last. Das Updaten mit neuen PWM-Werten muß in der Zeit des höchstwertigsten Bits erfolgen, sonst kann es flackern. Man kann sogar die Dauer des kleinsten Bits so wählen, daß der Timerinterrupt nicht erst verlassen werden muß. Es lassen sich also bequem flimmerfreie 10 Bit erreichen.
Peter Dannegger schrieb: > Das Updaten mit neuen PWM-Werten muß in der Zeit des höchstwertigsten > Bits erfolgen, sonst kann es flackern. Genau genommen sollte man die PWM-Werte nur einmal in der PWM-Periode verändern (wie bei klassischer PWM auch). Und es bietet sich natürlich an, das in die längste "arbeitsfreie" Zeit zu legen. Also mit dem LSB anfangen und dann wenn man das MSB ausgegeben hat und t_periode/2 Zeit bis zum nächsten Start ist, hat man Gelegenheit die neuen Bits zurecht zu legen. Also genau so, wie ich es vor 20 Jahren schon gemacht habe :) > Man kann sogar die Dauer des kleinsten Bits so wählen, daß der > Timerinterrupt nicht erst verlassen werden muß. Es lassen sich also > bequem flimmerfreie 10 Bit erreichen. Jep, das ist ein weiterer Vorteil. Man kann die kurzen Zeitschlitze ohne großen Nachteil mit busy waiting verbringen. Wenn man es darauf anlegt, kann man durchaus einstellige Zyklenzahlen für das LSB erreichen. XL
@ Axel Schwenke (a-za-z0-9) >Jep, das ist ein weiterer Vorteil. Man kann die kurzen Zeitschlitze ohne >großen Nachteil mit busy waiting verbringen. Wenn man es darauf anlegt, >kann man durchaus einstellige Zyklenzahlen für das LSB erreichen. Ja, aber. . . Wenn man nebenbei noch ein paar echt zeitkritische Sachen machen will/muss, kommt man da an Grenzen. Praktisches Beispiel. DMX512 Empfang und PWM-Ausgabe. Aber dennoch ist die Methode recht clever.
Falk Brunner schrieb: > Praktisches Beispiel. DMX512 Empfang > und PWM-Ausgabe. Die AVR-UART puffert bis zu 3 Byte, d.h. Du hast bei 16MHz/250kBaud bis zu 1920 Zyklen, das sollte doch dicke reichen.
Falk Brunner schrieb: > @ Axel Schwenke (a-za-z0-9) > >>Jep, das ist ein weiterer Vorteil. Man kann die kurzen Zeitschlitze ohne >>großen Nachteil mit busy waiting verbringen. Wenn man es darauf anlegt, >>kann man durchaus einstellige Zyklenzahlen für das LSB erreichen. > > Ja, aber. . . > > Wenn man nebenbei noch ein paar echt zeitkritische Sachen machen > will/muss, kommt man da an Grenzen. So wild ist das gar nicht. Wenn im Original der kürzeste Zeitschlitz mit 64 Takten festgelegt wurde, dann ist das ja ungefähr die Zeitdauer der ISR (plus etwas Sicherheitszuschlag). Das heißt dann aber auch, daß man überall im Programm damit rechnen muß, die CPU mal für ca. 64 Takte weggenommen zu kriegen. Wenn man jetzt alle kürzeren Zeitschlitze mit busy waiting implementiert, dann dauern die in Summe auch nur maximal 64 Takte. OK, unmittelbar danach kann (wird) dann die ISR zuschlagen. Aber länger als 128 Takte am Stück wird die CPU nicht blockiert. XL
Ingrid schrieb: > Wenn man alle kürzeren Zeitschlitze mit > busy waiting implementiert, dann dauern die in Summe auch nur maximal 64 > Takte. OK, unmittelbar danach kann (wird) dann die ISR zuschlagen. Aber > länger als 128 Takte am Stück wird die CPU nicht blockiert. Nachtrag: Tatsächlich sind (knapp) 128 Takte bereits die längste Blockage ohne busy waiting. Denn wenn die ISR für das LSB durch ist, löst das NSB ja praktisch gleich im Anschluß aus (die Zeitpunkte liegen 64 Takte auseinander). Wenn man jetzt noch 64 Takte für busy waiting drauf packt, kommt man mit 128/192 Takten Blockade ohne/mit busy waiting raus. XL
Kritisch ist aber der Fall, der UART-Interrupt läuft gerade und der PWM-Interrupt will zuschlagen, da der AVR keine Interruptlevel hat. Der UART-Interrupt darf daher nur die Daten in nen FIFO schieben und kein lang dauerndes Parsen machen. Und die PWM muß damit rechnen, daß sie um die Dauer des UART-Interrupts verzögert wird. Z.B. löst man den PWM-Interrupt mit dem COMPA-Register aus und pollt dann darin auf das COMPB-Flag.
Was mir gerade auffällt, die SW-PWM mit Schieberegister ist genial, man hat keinerlei Jitter! Der Timerinterrupt schiebt irgendwann das nächste Bitmuster rein und der Output-Compare-Pin latcht es auf den Zyklus genau. Also RCLK aller 595-er an OC1A (PB1) des ATmega88.
>Die AVR-UART puffert bis zu 3 Byte, d.h. Du hast bei 16MHz/250kBaud bis >zu 1920 Zyklen, das sollte doch dicke reichen. >weggenommen zu kriegen. Wenn man jetzt alle kürzeren Zeitschlitze mit >busy waiting implementiert, dann dauern die in Summe auch nur maximal 64 >Takte. OK, unmittelbar danach kann (wird) dann die ISR zuschlagen. Aber >länger als 128 Takte am Stück wird die CPU nicht blockiert. OK, überzeugt ;-) Dann könnte ich ja vielleicht meinen DMX PWM Empfänger von 10 auf 12 und mehr Bit aufbohren. Mal schauen, was drin ist. 8-0
Sorry bin grad erst wieder zum reinschauen gekommen. Wie ich lese habt Ihr alle Fragen soweit geklärt, gut. Eins noch: um die UART_Interrupte würd ich mir keine Sorgen machen, die Timerinterruptfunktion ist vernachlässigbar kurz aktiv. Sie muss ja nur noch das nächste Bitmuster auf die Ausgänge werfen, also entweder Port- oder Pinweise und wie lange dauert wohl ein " PORTB |= values[count++]; " ?? in der Zwischenzeit kann der UART in ruhe parsen und die Main die PWM_Werte mal um 90° drehen ;-)
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.