Soft-PWM und Schieberegister / Multiplexen

@ 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?

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 ;-)

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.

@ 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.

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

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

@ 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 ;-)

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

Danke!

So ists einleuchtend!

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