Hallo, ist es eigentlich möglich eine RGB-LED mit nur einem Timer (z.B. an einem ATTiny) anzusteuern? Ich stelle mir das so vor: Man nehme einen 8-Bit Timer. Dieser läuft von 0 bis 255. 1. Bei 0: Setze alle 3 Ausgänge auf HIGH 2. Bei Wert X, schalte 1. LED ab 3. Bei Wert Y, schalte 2. LED ab 4. Bei Wert Z, schalte 3. LED ab 5. Gehe zu 1. Dabei sei vorausgesetzt, dass die Werte X, Y und Z monoton aufsteigend geordnet sind. So kann also für jede LED der Abschaltzeitpunkt (und somit der Duty Cycle bzw. die gewünschte Helligkeit) mit 8 Bit Genauigkeit eingestellt werden. Würde das hinhauen?
Stichwort Soft-PWM und wie immer: gidf
Max D. schrieb: > Stichwort Soft-PWM > und wie immer: gidf OK, ich das scheint im Prinzip genau das zu sein, was ich mir auch überlegt hatte. Schön, dass ich nun den passenden Begriff dazu kenne ;-)
Boris P. schrieb: > Dabei sei vorausgesetzt, dass die Werte X, Y und Z monoton aufsteigend > geordnet sind. Das brauchst du nicht voraussetzen. Es sei denn, deine Denkweise ist falsch. Denn zb > 2. Bei Wert X, schalte 1. LED ab bedeutet ja nicht, dass auf das erreichen dieses Ereignisses gewartet werden soll. Du musst von deiner Denkweise 'Warte bis ...' wegkommen. Deine Denkweise muss sein: Wenn die Hauptschleife durchlaufen wird, was gibt es jetzt, genau in diesem Moment, zu tun? Also weg von "Warteauf" und hin zu "Ereignis und Zeitpunkt orientiert". Du bleibst ja auch nicht 2 Stunden naben dem Herd stehen, nur weil du Gluasch kochst.
Karl Heinz schrieb: > Also weg von "Warteauf" und hin zu "Ereignis und Zeitpunkt orientiert". Was mir vorschwebte war, das per Timer-Interrupt zu lösen. Ich vermute mal das ist das, was du mit "Ereignis und Zeitpunkt orientiert" meinst?
Boris P. schrieb: > Karl Heinz schrieb: >> Also weg von "Warteauf" und hin zu "Ereignis und Zeitpunkt orientiert". > > Was mir vorschwebte war, das per Timer-Interrupt zu lösen. Ich vermute > mal das ist das, was du mit "Ereignis und Zeitpunkt orientiert" meinst? Es ist eine Möglichkeit. FAQ: Timer
Karl Heinz schrieb: >> Dabei sei vorausgesetzt, dass die Werte X, Y und Z monoton aufsteigend >> geordnet sind. > > Das brauchst du nicht voraussetzen. Doch, durchaus. Aber natürlich wird man in der Praxis mit variablen Bitmasken arbeiten und bei z.B. 3 LEDs die 3 Masken so anordnen, daß sie in der richtigen Reihenfolge drankommen. Das schließt ein, daß man auch 2 oder 3 LED zum gleichen Zeitpunkt ausschalten können muß. > Du musst von deiner Denkweise 'Warte bis ...' wegkommen. Davon hat er doch gar nichts geschrieben? XL
Axel Schwenke schrieb: > Davon hat er doch gar nichts geschrieben? Das hier: Boris P. schrieb: > Dabei sei vorausgesetzt, dass die Werte X, Y und Z monoton aufsteigend > geordnet sind. impliziert aber die "warte bis" denkweise. Würde er es asynchron machen, dann wäre keine monotonie erforderlich.
Max D. schrieb: > Axel Schwenke schrieb: >> Davon hat er doch gar nichts geschrieben? > > Das hier: > > Boris P. schrieb: >> Dabei sei vorausgesetzt, dass die Werte X, Y und Z monoton aufsteigend >> geordnet sind. > > > impliziert aber die "warte bis" denkweise. Würde er es asynchron machen, > dann wäre keine monotonie erforderlich. Mit nur einem Timer? Und (mußmaßlich) nur einem Compare-Register? Natürlich muß er die Ausschaltzeiten dann sortieren, damit in der ISR wenn er z.B. LED #1 ausschaltet, den Zeitpunkt zum Ausschalten von LED #2 in das Compare-Register laden kann. XL
Axel Schwenke schrieb: > Mit nur einem Timer? Und (mußmaßlich) nur einem Compare-Register? > Natürlich muß er die Ausschaltzeiten dann sortieren, damit in der ISR > wenn er z.B. LED #1 ausschaltet, den Zeitpunkt zum Ausschalten von LED > #2 in das Compare-Register laden kann. Jo, das wollte ich auch gerade schreiben ;-) Anders klappt's nicht...
Axel Schwenke schrieb: > Mit nur einem Timer? Und (mußmaßlich) nur einem Compare-Register? > Natürlich muß er die Ausschaltzeiten dann sortieren, damit in der ISR > wenn er z.B. LED #1 ausschaltet, den Zeitpunkt zum Ausschalten von LED > #2 in das Compare-Register laden kann. Es kommt drauf an, wie er es konkret macht. So wie er fragt, denke ich nicht, dass er vor hatte die PWM mittels Mehrfachbenutzung eines Compare Registers zu machen.
Karl Heinz schrieb: > So wie er fragt, denke ich nicht, dass er vor hatte die PWM mittels > Mehrfachbenutzung eines Compare Registers zu machen. Doch, so hatte ich mir das gedacht. Den Wert des Compare Registers bei jedem Interrupt weiterschieben, für die nächste LED...
Boris P. schrieb: > Den Wert des Compare Registers bei > jedem Interrupt weiterschieben, für die nächste LED... Das ist bei vielen AVRs eine schlechte Idee weil die teilweise (je nach selektiertem Modus und AVR-Typ) das Compare-Reg (absichtlich) nur beim Rücklauf des Timers updaten. Man kann zwar wenn man gaaaaanz vorsichtig ist einen anderen Mode wählen usw. aber spätestens wenn man etwas ändert und nichtmehr an die Sache denkt, dann steht man da. Oder man verwendet einen anderen AVR-Typ und plötzlich hat der diese Sicherung drinne. z.B. der Mega88, der macht nur im "Normal" und im "CTC" Modus ein "immediate" OCR1X Update, alle anderen Modes haben diese Sicherung drinne. Man kann also so nicht die PWM Funktionen zusätzlich zu seiner Soft-PWM nutzen (muss jetzt grade nicht schlimm sein, kann aber später bei Erweiterungen Kopfzerbrechen geben). Und eines kannst du dir sicher sein: Wenn du wirklich irgendwo in deinem Entwicklungsprozess plötzlich so einen Hänger auslöst, dann suchst du überall nur nicht da wo er ist (Murphy kriegt dich immer)....
Boris P. schrieb: > Karl Heinz schrieb: >> So wie er fragt, denke ich nicht, dass er vor hatte die PWM mittels >> Mehrfachbenutzung eines Compare Registers zu machen. > > Doch, so hatte ich mir das gedacht. Den Wert des Compare Registers bei > jedem Interrupt weiterschieben, für die nächste LED... Das ist ja auch die Standard-Vorgehensweise, wenn man ein flexibles Timing bei minimalem Hardware-Einsatz erzeugen will. Der Knackpunkt bei dieser Implementierung ist die Laufzeit der ISR. Denn die muß wenigstens ein paar Bits an einem IO-Port wackeln lassen und das Capture-Register neu füllen. Das schafft sie nicht in Nullzeit, schon gar nicht wenn man sie in C schreibt. Die Mindest-Leuchtzeit einer LED und ebenso die minimale Differenz zweier Ausschaltzeiten muß länger sein als die Summe aus ISR-Laufzeit + Interrupt-Latenz. In diesem Beitrag "noch ein AVR Moodlight" habe ich die ISR so kurz wie möglich gehalten und sie braucht trotzdem ca. 50 Takte. Folglich habe ich die minimale Distanz zweier Punkte auf dem Zeitraster auf 61 Takte festgelegt. Das reicht für 204 gammakorrigierte Helligkeitsstufen bei 8MHz Takt und ~120Hz Wiederholrate. Ich wollte den Code schon lange mal auf einen ATtiny85 umstricken, allerdings ist mir etwas die Lust vergangen als ich gesehen habe daß der ja nur einen 8-Bit Timer hat. Als ob Atmel die paar Gatteräquivalente für einen 16-Bit Timer umgebracht hätten :-/ XL
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.