3x LED-PWM-Faden

Hallo,

es sind 3 HW PWM Kanäle vorhanden.

Timer 1 + OC1A und OC1B (8Bit Timer)
Timer 2 + OC2 (16Bit Timer, als 10 Bit PWM konfigurierbar)


hth
Maik

jna380 schrieb:
> Bei beiden steht auf dem Deckblatt "Three PWM-Channels".

Der 3. ist aber nur 8 Bit, das könnte schon sichtbare Übergänge 
bedeuten.
10..12 Bit wären besser.

Aber man kann in SW leicht 8 PWM-Ausgänge realisieren, die gleich 
schnell, wie die Fast-PWM sind:

Beitrag "AVR: Fast-PWM (BAM) 12 Bit für 8 Kanäle"

Einfach mal hier gucken:
http://www.zabex.de/site/sofabeleuchtung.html

jna380 schrieb:
> Leider war der Einwand richtig, dass 8-bit da nicht wirklich ausreichend
> sind. 10-bit sieht da schon wesentlich schöner aus.

 Auch 10-bit reichen nicht aus, bei den ersten 16 Helligkeitsstufen
 muss man mit mindestens 2 Stellen hinterm Komma rechnen.
 Ich hoffe, du verwechselst nicht PWM-Frequenz und PWM-Auflösung.
 Für deine LEDs reicht eine PWM-Frequenz von 200Hz (5mS) vollkommen,
 aber die PWM-Auflösung sollte so groß wie möglich sein. Mit Timer1 hat
 die MEGA8 16-bit Auflösung, also genug für normales dimmen.
 Problem ist aber, dass es nur einen 16-bit Timer gibt.

 Du könntest auch Timer1 als 16-bit Counter in CTC Mode für alle
 3 LEDs nacheinander benutzen:
 OCR auf gewünschte PWM-Frequenz einstellen.
 Timer1 starten, ISR abwarten.
 In der ISR LEDs (falls nötig) einschalten, neue Endwerte laden.
 Danach TCNT Zustand in einer Schleife in main() ständig abfragen,
 falls >= LED_Endwert, LEDs eine nach der anderen, je nach Endwert
 ausschalten. Die paar uS Ungenauigkeit fallen kaum ins Gewicht...

 Am besten ist aber Software-PWM mit BAM.
 Lese doch mal
 Beitrag "AVR: Fast-PWM (BAM) 12 Bit für 8 Kanäle"
 von peda, das ist mehr als genug für deine 3 LEDs.

jna380 schrieb:
> Ich möchte gerne mit 3 LEDs (Grün,Blau,Rot) einen Sockel zum Beleuchten
> eines Gegenstandes bauen. Diese 3 LEDs sollen jeweils paarweise
> ineinander überfaden, sprich: Grün nimmt ab, Blau nimmt zu. Wenn Blau
> dann abnimmt, nimmt Rot zu,usw.

Such nach "Moodlight". Meins z.B. verwendet einen ATmega8.


XL

jna380 schrieb:
> Danke für den Tipp mit den Strömen, habe ich schon überprüft. Meine LEDs
> sollen maximal 20mA kriegen, die Ausgänge liefern bis zu 40mA.

Für deine Anwendung jetzt vielleicht weniger wichtig, aber als Tipp für 
die Zukunft:

Bedenke bitte, dass nicht nur der Strom über einem Ausgang beschränkt 
ist, sondern auch der Strom über einem ganzen Port sowie der Strom für 
den ganzen uC.

Sprich, wenn du 8 Ausgänge pro Port hast die 40mA liefern können, wärst 
du ja theoretisch bei
40mA * 8 = 320 mA.

Heisst jetzt aber auch, dass dein Port gesamt 320 mA liefern können 
muss. Das müsste man dann auch noch überprüfen. Wie gesagt für deine 
jetzige Anwendung vielleicht weniger wichtig, aber irgendwann für die 
Zukunft.. ;) zu meinen Anfangszeiten mit uC's haben mir wegen dieser 
fehlenden Information ein paar Controller lebewohl gesagt :P

Desweiteren:
Wenn deine LED mit 20mA angegeben wird, bedeutet das nicht dass du diese 
mit 20mA bestromen musst. Die heutigen LEDs leuchten meist auch schon 
bei 5-10mA stark genug. Also vielleicht zu Beginn ruhig mal einen etwas 
grösseren Vorwiderstand wählen und schauen, ob es so schon reicht. 
Gewechselt wäre er ja ansonsten schnell ;)

jna380 schrieb:
> Das trotzdem mit dem Atmega8 zu realisieren finde ich gut, hätte es
> irgendwie nicht eingesehen für so eine Aufgabe einen Controller jenseits
> 5€ zu benutzen.

Das ehrt dich. Allerdings solltest du gleich wissen, daß ein ATmega8 
dafür einfach zu wenig PWM-Kanäle hat. Die 256 linearen(!) Stufen einer 
8-Bit PWM sind zu wenig. Man braucht wenigstens 10 Bit (besser 12) bei 
linearer Abstufung. Mit Soft-PWM kann man das aber hinbekommen. Es 
erfordert nur halt ein wenig mehr Hirnschmalz als einfach nur 3 
PWM-Register der Hardware zu beschreiben.


XL

Vielleicht als weitere Anregung:

Externer Baustein für PWM verwenden.

PCA9685 Beispielsweise.

Ich hatte doch weiter oben was verlinkt ;)
Atmega88, der hat so schon 2x16 bit PWM und die dritte 16bit PWM wurden 
mit 2 Timern erzuegt.
Gucks dir mal an.

Der dritte PWM hat nur leider Timingprobleme im Bereich ab 60000 (da 
gibt es ein paar Werte, wo er komplett aus geht) und kleine Werte 
(0...256) bekommt er auch nicht richtig hin (zu grob abgestuft und "zu 
hell").

jna380 schrieb:
> Okay, die Rechnung oben war natürlich quatsch, es ist natürlich nicht
> jeder 400. Takt sondern jeder 40000. der einen Interrupt auslöst um auf
> 200 Hz PWM zu kommen...Periodendauer bei 8MHz ist natürlich 0,125 µs...

 Und damit hast du ja mehr als 15-bit PWM-Auflösung bei einer
 PWM-Frequenz von 200Hz...
 Nur aufpassen bei kleineren Werten, dass du nicht die ISR blockierst.
 Am besten deine Werte aus der Tabelle * 16 (oder sogar 32), und noch
 feinere, bzw. genauere Abstufung.

jna380 schrieb:
> if(TCNT1 >= next)
>  next = values[i];


  Ooops.
  next ist 8-bit.
  values sind 16-bit.
  Timer1 ist 16-bit.

jna380 schrieb:
> Die Frequenz bleibt gleich...die Bitbreite bzw Abstufung ist direkt
> abhängig von der Frequenz, muss ich dann immer meine Wertetabelle ändern
> um die Steig- und Fallgeschwindigkeit zu beeinflussen?

 Wie bei Radio Eriwan
 Im Prinzip ja, aber...
 Sagen wir mal, du hast deiner ISR eine Mindestzeit von 32 Cycles
 gegeben. Damit fängst du also an, das ist die erste Stufe, die sichtbar
 sein soll. Bei einem Endwert von 40000 kommst du auf etwa 59 Stufen.
 Deinem compiler sagst du das die erste Stufe 32 ist, jede weitere
 Stufe 1,13 mal grösser sein soll als die vorhergehende und lässt ihn
 die Arbeit machen. Das wars.
 Und glaube mir, unteres Drittel ist wichtig, da must du genau sein.
 Lieber im oberen Drittel etwas gröber abstufen.

jna380 schrieb:
> Trotzdem hab ich selbst bei einer großen Tabelle wie values3 oder der
> von dir vorgeschlagenen values11 ein sehr unruhiges faden, viel zu
> schnell und außerdem sieht man flackern...langsam bin ich mit meinen
> Ideen am Ende...

 Auweiea.
 Du sollst nicht die Tabelle durchfahren, sondern nur die entsprechenden
 Werte daraus entnehmen.
 Also:
>     next = values[i];
 i ist die Helligkeitsstufe, Tabelle values hast du mit 59
 dimensioniert, da stehen die Werte für OCR1.
 i änderst du aber in main() oder nimmst Timer0 dafür, d.h. i kann
 unverändert bleiben für 5 oder 500 CTC-Aufrufe des Timer1 oder sich
 bei jedem Aufruf ändern, was aber zu schnell ist.
 Wenns immer noch unklar ist, versuche ich später mit einem Beispiel.

jna380 schrieb:
> Hast du noch Ideen, wie ich das verlangsamen kann ohne ganze Tabellen zu
> ändern, bzw warum es immernoch unrund läuft?

 Das hat mir Excel ausgerechnet:

32, 36, 41, 46, 52, 59, 66, 75, 85, 96, 108, 123, 139, 157, 177, 200, 
226, 255, 289, 326, 369, 416, 471, 532, 601, 679, 767, 867, 980, 1107, 
1251, 1414, 1598, 1806, 2040, 2306, 2605, 2944, 3327, 3760, 4249, 4801, 
5425, 6130, 6927, 7828, 8846, 9996, 11295, 12764, 14423, 16298, 18417, 
20811, 23517, 26574, 30029, 33932, 38344

 Versuchs mal damit.

jna380 schrieb:
> zu niedrig. Es sieht einfach wahnsinnig ruckelig aus und wird auch im
> Verlauf selbst blitzartig heller und dunkler...Warum?

 Muss jetzt gehen, versuch mal in der Zwischenzeit das Ganze in
 Atmel Studio laufen zu lassen, kannst auch logfile machen mit PortB.

Probiere es mal mit angehängter Datei, sollte eigentlich gehen. Habe
 da ein paar Sachen geändert, CTC-ISR rausgeschmissen, hoffe das es
 funktioniert.

 mfg
 Marc

 P.S.
 Auch wenn es funktionieren sollte, ist es trotzdem ziemlich nutzlos,
 rauf- und runterdimmen auf diese Art ist vielleicht zum üben gut, hat
 aber keinen praktischen Wert.
 Deswegen rate ich dir wieder, den Beitrag
 "AVR: Fast-PWM (BAM) 12 Bit für 8 Kanäle" von peda zu lesen. Laut
 Autor beträgt die Last nur etwa 9%.
 Mit BAM kann der uC auch andere Sachen machen - ich habe hier eine
 10 Kanal RGB-BAM rumstehen, da werden die Sequenzen locker von
 der SD-Karte gelesen - mit 8MHz M328, allerdings in Assembler und
 mit mehr als 60% Last.
 Aber auch das ist ziemlich nutzlos, den mit WS28xx geht das alles
 viel einfacher...

Marc Vesely schrieb:
> Aber auch das ist ziemlich nutzlos, den mit WS28xx geht das alles
>  viel einfacher...

Hi, ich glaub' der Mann hat recht. Im Bascom-forum wurde eine tolle 
WS2812 lib entwickelt, und schon mit der ersten Version dieser lib lässt 
sich dein Beleuchtungsprojekt mit einem Attiny13 ! realisieren. Die 
Ws2812 hat zwar 'nur' 8bit pro Farbe, aber ich versteh' das ganze Gedöns 
mit 10bit und mehr nicht. Wenn du dein Teil mit einer Überblendungszeit 
von ca. 5 sec anstrahlst, hast du dabei 512 Farben durch zu laufen, 
macht pro sec 100 Farben. Wie viel Bilder/sec kann das menschliche Auge 
als Einzelbilder wahrnehmen? 10? 12?.
Hier mal mein Versuch: https://www.youtube.com/watch?v=aHS61jRsjqQ
Grüße von tschoeatsch

N. Rokpop schrieb:
> Fällt Dir bei den dunkeln Farben
> etwas auf? Da fehlen ein paar Stufen...

Hi, ich dachte, hier wird ein Objekt beleuchtet und nicht verdunkelt. So 
wie ich das verstanden hab', wird die Beleuchtung des Objektes nie auf 
schwarz gedimmt, sondern es leuchtet eine Farbe mindestens mit 50%. Klar 
kann man alles bis auf's letzte Tüpfelchen ausreizen. Das Ding läuft 
hier vor sich hin und mir fällt keine Lücke auf.
Grüße von tschoeatsch

N. Rokpop schrieb:
> Mach doch mal ein Fade von 0 bis 255. Fällt Dir bei den dunkeln Farben
> etwas auf? Da fehlen ein paar Stufen...
>
> Das liegt daran, dass das Auge die Helligkeit nicht linear wahrnimmt.
> Für die dunklen Bereiche benötigt man eine höhere Auflösung.

 Ja, und da kann man quasi interpolieren. Mit PWM-Frequenz von 1KHz
 hast du 1mS Zeit, die Farbe oder Intensität zu wechseln. Kürzer als
 20mS hat kaum Sinn, also hast du 20*1mS Zeit. Damit ist man auf 0,05
 genau.
 Als Beispiel: (17*3 + 3*4) / 20 ergeben 3,15.
 Wo sollen da paar Stufen fehlen ?

 P.S.
 PWM bzw. BAM macht es genauso und du merkst es trotzdem nicht.
 Ausser logarithmischer Wahrnehmung gibt es so etwas wie Trägheit
 des Auges...

jna380 schrieb:
> Also bei 8-bit z.B. Wert 200, Binär: 11001000. Also sind red0-2 0, red3
> ist 1, red4,5 wieder 0, red6,7 1, korrekt?

 Korrekt.

jna380 schrieb:
> Und dann lade ich mir im nächsten 128ms-delay zB. den Wert 204 rein?

 Wie kommst du überhaupt auf 128mS ?

jna380 schrieb:
> Wie kann ich innerhalb des 128ms-Delay-Slots neu initialisieren und
> trotzdem sichergehen, dass genau 128ms vergehen? Dazu müsste ich ja die
> genaue Dauer meiner Initialisierung kennen, und die Restzeit mit
> _delay_ms "auffüllen",oder?

 Also, ich kann dir nur sagen, wie ich es mache:
 main() setzt die entsprechenden RGB-Werte, eine funktion rechnet diese
 RGB-Werte in bit-Zustände um, schreibt diese in einen Array.
 ISR nimmt die bit-Zustände und setzt die Ports dementsprechend.
 Für die ersten 4 bits wird die ISR überhaupt nicht verlassen (bei mir).
 Wichtig ist, dass die ISR genau ist - ob du LEDs nach 128mS oder 127mS
 die Farbe oder Helligkeit wechseln lässt, ist ziemlich unwichtig und
 keiner wird es merken. Ich lasse meine BAM mit etwa 1KHz laufen
 (1012Hz, um genau zu sein), da habe ich auch gleichzeitig einen Timer
 für mSec. Natürlich kann man es auch genauer machen - Timer0 in CTC,
 Clock / 64, TOP auf 124, ganz schnell eine Variable in der ISR erhöhen
 und raus aus der ISR...

jna380 schrieb:
> da ich irgendwo im Verlauf einen kurzen Helligkeitseinbruch
> habe.

Das Updaten der PWM-Daten muß in mit der letzten Bitzeit erfolgen.

jna380 schrieb:
> Bin momentan jetzt dran, das ganze mittels MIBAM (mirrored BAM) zu
> verbessern, da ich irgendwo im Verlauf einen kurzen Helligkeitseinbruch
> habe.

 Wie schnell ist deine BAM ?
 Mit 500Hz und schneller merkt man das überhaupt nicht, es sei denn, du
 wechselst ständig zwischen 128 und 127. Dann scheint es als ob die LED
 mit etwa 170 angesteuert wird. Aber wie oft wird das passieren und wie
 lange wird das dauern ?
 Es ist mehr eine theoretische als eine praktische Frage. Der Aufwand
 lohnt sich bestimmt nicht.

 EDIT:
 peda's BAM läuft mit 2 KHz, da hast du es bestimmt nicht gemerkt.

jna380 schrieb:
> Gibt es abgesehen von int0 und int1 noch weitere Ports, die im laufenden
> Betrieb einen Interrupt z.B. für den Moduswechsel auslösen können?

 Nein.
 Nimm M88, dann hast du an jedem Pin ein Interrupt.

 Muss aber nochmals meinen Senf zu MIBAM zugeben:

 |_______|-------|-------|_______|
 |   0    1111111|   1    0000000|
 |      127      |      128      |
 | 250uS   250uS | 250uS   250uS
 Anstatt 250uS Off - 250uS On - 250uS Off - 250 uS On, hat man
 250uS Off - 500uS On - 250uS Off. Wegen Trägheit des Auges wird
 das aber als ein Wert von... ?
 Genau, es wird als ein Wert von 128 empfunden.
 Schlimmstenfalls wird es für 750uS als ein Wert von 170 empfunden.
 Da das menschliche Auge pro Sekunde maximal 30 Lichtreize voneinander
 unterscheiden kann (und zwar nur als nervöses Flackern), ist das mit
 MIBAM nur für PWM-Frequenzen unter 100Hz interessant...
 Selbstverständlich kann man auch kürzere Impulse sehen - Impulse mit
 einer Länge von etwa 75mS werden sogar als doppelt so hell empfunden.
 Danach muss aber eine Pause folgen, ansonsten geht der Effekt
 verloren...

jna380 schrieb:
> Was genau ist M88? Konnte da beim googlen kaum was finden.

 MEGA88 = MEGA8 Nachfolger.

jna380 schrieb:
> Hab jetzt aber schon öfter gelesen, dass Taster an Interrupt-Ports wohl
> überhaupt nicht gut sind wegen dem Prellen. Wie mache ich das denn dann,
> wenn ich einen Tastendruck abfragen will, ohne diesen ständig im
> Programm zu überwachen?

 Also, ganz ohne überwachen wirds wohl kaum gehen...
 Ich habe das früher so gemacht (wow, lange nicht mehr gemacht), dass
 ich in der ISR ( PCIx heist es bei M88), einen Flag gesetzt habe und
 Zähler für Prellen auf 50 gesetzt habe (mein Systemzähler läuft immer
 mit 1mS). Beim Eintritt in die ISR wird zuerst geprüft, ob der
 Zählerstand > 0mS ist (Zähler fürs Prellen läuft rückwarts bis Null).
 Wenn ja, wird einfach zum ISR-Ende gesprungen.
 Wenn nein, handelt es sich wahrscheinlich um einen neuen Tastendruck.
 Nachdem dein Tastendruck abgearbeitet ist, Flag wieder zurücksetzen.

jna380 schrieb:
> Momentan war mein erster Ansatz eine "state"-Variable, die durch
> Interrupts gesetzt wurde, und in der main() dann mittels switch etwas
> unterschiedliches ausgeführt wurde...funktioniert aber nicht wie es
> soll.

 Probiere es mal wie oben.

jna380 schrieb:
> Ahh, okay, gut zu wissen! Du kennst dich ja aus...

 Habs auch erst kürzlich im Forum gelesen, musste es aber gleich
 ausprobieren. Da war von 50mS die Rede, bei mir waren es so um 75mS,
 ist aber natürlich subjektive Empfindung.

Gaestchen schrieb:
> Er schrieb von Millisekunden, wie kommst Du jetzt auf Millisiemens? Das

 Gaestchen mit seinem Gehirnchen.
 Wieder einmal zu feige, um deinen richtigen Namen zu schreiben ?
 Was bringt dich zu der idiotischen Annahme, dass deine IP-Adresse
 als Gast nicht rübergekommen ist ?