Hallo, ich habe mal eine Grundsatzfrage zum LED - Fading. Entweder habe ich ein Brett vorm Kopf oder es ist doch gar nicht ganz ohne. Und zwar habe ich bereits die Software - PWM. Mit der kann ich die LED's gewissermaßen unterschiedlich hell leuchten lassen. Zum Faden muss ich nun das Tastverhältnis der Soft PWM verändern. Im Artikel wird das ja mit einfachen Warteschleifen gemacht. Ich möchte allerdings den µc noch was andres machen lassen, also die ganze Zeit in Warteschleifen hängen geht nicht. Also müsste ich das Fading über einen Timer realisieren. An sich ist das nicht das Problem, jetzt kommt das aber: ich möchte alles recht universell gestalten, d.h. alle Kanäle unterschiedlich schnell und das auch zur gleichen Zeit faden können. Hintergrund: ich will später verschiedene Lichtprogramme einstellen können, da muss das alles recht unabhängig sein. Allerdings fehlt mir bis jetzt der Ansatz, wie ich die ganzen Kanäle mit 1 Timer realisieren kann, der immer gleich schnell läuft. Hat soetwas schon jemand gemacht, wie müsste denn das Grundprinzip aussehen. Aber ich glaube wohl, ich kann den Timer nur als Zähler verwenden und muss dann alle Lichtprogramme einzeln programmieren. Ich hatte mir das so gedacht, das ich die Lichtprogramme dann einfach in einer Tabelle speichern kann, in der die dann nur die Zeiten der einzelnen PWM - Stufen für jeden Kanal liegen, aber das wird wohl nichts werden.
ungefähr so: (pseudo c code)
1 | ledDelay[0] = 10; |
2 | ledDelay[1] = 20; |
3 | ledDelay[2] = 30; |
4 | ...
|
5 | |
6 | ISR timer() |
7 | {
|
8 | uint8_t i; |
9 | for (i = 0; i < sizeof(ledDelay); i++) |
10 | if (timerValue % ledDelay[i] == 0) toggleLed(i); |
11 | }
|
Blödsinn, was ich gerade geschrieben habe... Sorry, neuer Versuch:
1 | ledFadeSpeed[0] = 10; |
2 | ledFadeSpeed[1] = 20; |
3 | ledFadeSpeed[2] = 30; |
4 | ...
|
5 | |
6 | ISR timer() |
7 | {
|
8 | uint8_t i; |
9 | for (i = 0; i < sizeof(ledDelay); i++) |
10 | if ((timerValue % ledFadeSpeed[i] == 0) && (ledPwmValue[i] > 0)) |
11 | ledPwmValue[i]--; |
12 | }
|
Auch dein PC hat nur einen Timer, und da blinkt und dreht sich auch alles. Irgendetwas auf deinem uC ist das Hauptprogramm, und irgendetwas anderes sind Interrupt-Routinen. Soft-PWM kann man sowohl im Hauptprogramm (synchronisiert sich durch Abfrage des aktuellen Timer-Standes) als auch in einer Interrupt-Routine (wird vom Timer aufgerifen) implementieren. Ich kann dir sagen, daß es technisch möglich ist, 1024 LEDs mit einem uC unabhängig voneinander zu dimmen - und das Bild währenddessen über UART zu empfangen. Allerdingd sollte man daür programmieren können und es nicht mit BASCOM probieren. Richtig ist, daß man es NICHT mit langen Warteschleifen macht. Besser ist es, die aktuelle Zeit aus einem Timer abzuholen und mit den Dimmwerten zu vergleichen und dadurch zu bestimmen, welche Ausgänge nun ein- oder ausgeschaltet sein sollen. Wenn das zu viel Zeit in Ansruch nimmt, kann man es auch vorausgerechnen und zu den jeweils nötigen Zeitpunkten nur noch die für den Zeitpunkt vorausberechneten Portzustände an die Ausgabeports übertragen. Statt z.B. bei 8 bit diese 256 mal pro PWM Zyklus zu machen, braucht man es nur 8 mal zu machen - mit einer Wartezeit von 1, 2, 4, 8, 16, 32, 64, 128 (welcher Zeitmasstab auch immer) dazwischen in der man anderes tun kann. Dann spart man sich sogar vergleichen und umrechnen und schiebt nur die Bits der aktuellen Dimmwerte raus.
> Allerdings fehlt mir bis jetzt der Ansatz, wie ich die ganzen Kanäle > mit 1 Timer realisieren kann, der immer gleich schnell läuft. > > Hat soetwas schon jemand gemacht, wie müsste denn das Grundprinzip > aussehen. Das wichtigste Grundprinzip ist, dass dieser Ablauftimer deine Untergrenze der zeitlichen Auflösung definiert. D.h. Du kannst nicht jede Fading-Fahrt realisieren sondern nur welche, die ein Vielfaches dieser Grundzeit sind. Das ist das eine, und das ist noch relativ leicht. Das andere ist das Problem, dass von einem Zeitschritt zum nächsten nicht unbedingt ein ganzzahliges Inkrement der Helligkeit erhältst. Da gibt es mehrere Ansätze, die du gehen kannst * du kannst einen Bresenham adaptieren (bitte danach googeln. Auch wenn es auf den ersten Blick nicht danach aussieht, ist es doch möglich einen Bresenham Algorithmus auf dieses Problem anzusetzen) * du kannst die jeweilige Helligkeitstufe in der Fading-Fahrt nach jedem Zeitschritt neu ausrechnen. Nach dem Muster: Wenn sich die Helligkeit in 200 Zeitschritten um 45 Helligkeits- stufen ändern soll, dann muss die Zunahme vom Ausgangswert im Schritt 87 gleich 45 * 87 --------- 200 sein * Oder aber man kann auch das tun, was in der DDA gerne gemacht wird. Man kann sich sowas wie 'künstliche Nachkommastellen' erzeugen. Anstatt zb in 16 Bit, rechnet man in 32 Bit, wobei die unteren 16 Bit die 'Nachkommastellen sind'. Im Grunde machst du zb Anstatt auszurechnen, um wieviel die Helligkeit bei einer Fading Fahrt 200Schritte und 85 Helligkeitsstufen in einem SChritt zunehmen soll, rechnest du einfach so, als ob die Helligkeit um 850 (also das Zehnfache) zunehmen soll. Du musst dir nur merken dass deine Helligkeiten immer das Zehnfache dessen sind, was du eigentlich brauchst und bei der Ansteuerung der PWM Das entsprechend berücksichtigen (im Rechner nimmst du natürlich nicht das 10-fache sondern eine 2-er Potenz) Tja. UNd der Rest ist dann ein Lichtprogramm, welches in einer Tabelle steckt, und in dem verzeichnet ist, welche Helligkeitsstufe ein Kanal haben soll, wie lange diese Stufe einzuhalten ist und wie lange das Fading auf die nächste Stufe dauern soll.
Hallo, ersteinmal vielen Dank für die überwältigende Resonanz auf meine Frage! Also nochmal zum Artikel Soft - PWM: den habe ich gelesen und auch - allerdings nur Variante 2 - umgesetzt. Hier geht es ja aber erstmal nur um die PWM - und nicht um das Fading an sich, richtig? Denn wie die Soft - PWM funktioniert ist ja klar, aber das ist ja gewissermaßen ein abgeschlossenes Modul für sich. Und das wollte ich dann mit dem Fader über die entsprechenden Werte füttern. Mit dieser Überlegung kann ich ja ran gehen, nehme ich an, oder? Und nun zum Fading: Da gibt es auch einen Artikel, der läuft auch schon auf meinem µc, zusammen mit der Soft - PWM 2. Variante. Allerdings läuft es noch mit Wartezeiten zwischen Stufenwechsel, die müssen aber raus. Hier kommt nun der Timer ins Spiel, welcher mir eine Zeitbasis vorgibt, womit ich die Warteschleifen ersetzen kann. Das an sich geht auch noch klar. Jetzt mein aktuelles Verständnisproblem: Wo schaue ich, ob meine Wartezeit um ist, denn wenn das der Fall ist müsste ja nun eine neue Lichtstufe geladen werden. Erfolgt das Laden dann nun im Hauptprogramm oder in der ISR. Ich wöllte das ja eigentlich nicht in die ISR haben, das wird dann sicherlich etwas groß, oder? Naja irgendwie habe ich zur Zeit eine Blockade, ich hoffe ihr könnt mir die aus dem Kopf schlagen, bis jetzt ist sie leider noch nicht so richtig verschwunden. LG Edit: Nochetwas zu Karl-Heinz seiner Aussage: Karl Heinz Buchegger schrieb: > Tja. UNd der Rest ist dann ein Lichtprogramm, welches in einer Tabelle > steckt, und in dem verzeichnet ist, welche Helligkeitsstufe ein Kanal > haben soll, wie lange diese Stufe einzuhalten ist und wie lange das > Fading auf die nächste Stufe dauern soll. Wie Lange die Stufe einzuhalten ist und wie lange das Fading zur nächsten Sufe dauern soll ist doch eigentlich das Gleiche, oder irre ich mich? Weil man kann ja schlecht zwischen 2 Helligkeitsstufen faden, das ist ja schon die kleinste Einheit, die einfach umgeschaltet wird, oder haben wir unterschiedliche Auffassungen von Helligkeitsstufen?
Martin K. schrieb: > den habe ich gelesen und auch - allerdings nur Variante 2 - umgesetzt. > Hier geht es ja aber erstmal nur um die PWM - und nicht um das Fading an > sich, richtig? Denn wie die Soft - PWM funktioniert ist ja klar, aber > das ist ja gewissermaßen ein abgeschlossenes Modul für sich. Und das > wollte ich dann mit dem Fader über die entsprechenden Werte füttern. Mit > dieser Überlegung kann ich ja ran gehen, nehme ich an, oder? Richtig. Die PWM-Sache ist eine Sache für sich. Sozusagen das ausführende Organ. Die andere Frage ist: wo kriege ich eigentlich die 'Befehle' für dieses ausführende Organ her - die Ablaufsteuerung, die die gewünschten Lichtänderungen realisiert und in Form von (wie auch immer) Daten der PWM Stufe zur Verfügung stellt. > Jetzt mein aktuelles Verständnisproblem: > > Wo schaue ich, ob meine Wartezeit um ist, Deine Timer-ISR kannst du dir wie eine Uhr vorstellen. In regelmässigen Zeitabständen hast du die Möglichkeit etwas zu tun. reales Leben: Wenn du eine Uhr mit Sekundenzeiger hast (regelmässiges Ereignis mit bekannter Zeitdauer zwischen den Ereignissen) und du sollst 2 Lampen bedienen, die eine soll 4 Sekunden leuchten und die andere 7, wie machst du das mit dieser Uhr? (und von mir aus gibt es noch einen Kumpel, der dir regelmässig einen Tritt gibt, damit du auf die Uhr schaust) > müsste ja nun eine neue Lichtstufe geladen werden. Erfolgt das Laden > dann nun im Hauptprogramm oder in der ISR. Ich wöllte das ja eigentlich > nicht in die ISR haben, das wird dann sicherlich etwas groß, oder? 'Groß' ist ein relativer Begriff. Wenn du heftige Berechnungen involviert sind, dann haben die in der ISR nichts verloren. Wenn es aber nur darum geht ein paar Zahlenwerte zu inkrementieren (oder dekrementieren) und ein paar Werte von A nach B umzukopieren, dann ist das auch in einer ISR kein Problem. > Naja irgendwie habe ich zur Zeit eine Blockade, Ich hab so das Gefühl, dein Denken kreist um diese eine ISR, die für PWM benutzt wird. Du hast auch noch andere Timer, die auch eine ISR haben können! Stellst du dir den so ein, dass seine ISR beispielsweise alle 0.1 Sekunden ausgeführt wird (und die dann nachsieht ob ein bestimmtes Licht schon seine Leuchtdauer erreicht hat und auf einen anderen PWM Wert gesetzt werden muss), dann ist das wohl kurz genug, so dass du jede für dich relavante Lichtsteuerung erreichen kannst. 0.1 Sekunden sind für dich als Mensch kurz. Für einen µC ist es aber eine halbe Ewigkeit. Da kann er dazwischen noch ein paar 'teuflisch schwierige quadratische Gleichungen lösen' (tm: Douglas Adams) > Wie Lange die Stufe einzuhalten ist und wie lange das Fading zur > nächsten Sufe dauern soll ist doch eigentlich das Gleiche, oder irre ich > mich? Das kann #ich# nicht sagen. Das musst du entscheiden. Du bist der Programmierer und du triffst die Designentscheidungen. Aber im Allgemeinen würde ich das nicht für gleich halten. Wenn das Licht von halber Helligkeit in 2 Minuten auf voll gehen soll und dann 30 Minuten voll halten soll ehe es dann in 8 Minuten auf 1/10 Helligkeit runterfadet, dann sind da 2 verschiedene Vorgänge involviert. Das eine mal wird eine Helligkeit gehalten, das andere mal wird sie zeitlich verändert. Gut, man kann natürlich den Mittelteil auch als "In 30 Minuten von 'voll' auf 'voll' faden" auffassen. So gesehen hast du recht und das eine ist ein Sonderfall vom anderen. > Weil man kann ja schlecht zwischen 2 Helligkeitsstufen faden, das > ist ja schon die kleinste Einheit, die einfach umgeschaltet wird, oder > haben wir unterschiedliche Auffassungen von Helligkeitsstufen? Ich denke der Auffassungsunterschied besteht darin, dass du dich (als Benutzer) um Einzellichtstufen kümmern willst, was mich nun gar nicht interesiert. Ich als Benutzer würde es vorziehen, wenn ich dem Rechner sagen könnte: In 2 Minuten 15 Sekunden von Lichtstufe 10 auf Lichtstufe 189 faden. Und wie das dann in Einzelschritten ausgeführt wird (welche Zwischenstufe zu jedem 0.1 Sekunden Zeitpunkt eingestellt werden muss), ist Sache des Rechners. Das ist ein bischen Rechnerei um aus der vom Benutzer vorgegebenen Angabe die Werte für die jetzt gerade aktuellen 0.1 Sekunden auszurechnen. Und wenn Computer eines können, dann ist das ja wohl rechnen.
Also vielen Dank das du die so viel Zeit nimmst :) So gut, das mit der Soft - PWM klappt also so wie ich mir das vorstelle - ein Modul für sich was jetzt erstmal abgeschlossen ist und dann die eigentliche Arbeit macht. Einen zweiten Timer habe ich auch schon, der läuft unabhängig von der Soft - PWM. Gedacht hatte ich mir das auch schon so, wie du das sagtest. Den relativ langsam laufen lassen, und dann kann das Laden und kurze Vergleichen auch in der ISR pasieren. Mein Problem: Du sagtest ja selbst, der Timer gibt sozusagen die Untergrenze für das Fading vor. D.h. es muss jede Helligkeitsstufe (angenommen mal von 0 bis 255) mindestens eine Timer - Periode anbleiben, da ja in der ISR umgeschaltet wird. Wenn der Timer nun angenommen 0.1s Interrupts liefert leuchtet also jede Stufe mind. 0,1s, d.h. bei angenommenen 255 Stufen dauer ein Fading (von 0% auf 100%) MINDESTENS 0,1*255 = 25,5s. Das ist mir allerdings zu langsam um eine große Vielzahl von Lichtprogrammen einsetzen zu können. Gut jetzt kommt sicherlich der Einwand du hast keine 255 Stufen, aber selbst bei 32 Stufen dauert es noch 3,2s. Und die 32 Stufen sind mir für Dimmen über einer Sekunde eigentlich zu wenig. Ok, ich habe mal gerechnet bei 10ms Timerperiode sieht es schon etwas anders aus. Also nochmal zum Grundsatz: Ich gehe vom Prinzipdenken in die richtige Richtung, wenn ich das komplette Einstellen der 4 Kanäle (RGBW), d.h. überprüfen ob Wartezeit erreicht ist, laden einer neuen Stufe und an PWM schicken, sowie laden der neuen Wartezeit für die Stufe alles in die ISR packe?
Martin K. schrieb: > Wenn der Timer nun angenommen 0.1s Interrupts liefert leuchtet also jede > Stufe mind. 0,1s, soweit richtig. > d.h. bei angenommenen 255 Stufen dauer ein Fading (von > 0% auf 100%) MINDESTENS 0,1*255 = 25,5s. Du musst ja nicht jede Zwischenstufe einstellen! 0 10 20 30 40 50 in 0.5 Sekunden von 0 auf 50 gefadet. (Genau darum gings ja bei den ganzen Andeutung: Das Ausrechnen, welche Lichtstufe zu einem bestimmten Zeitpunkt an sein soll, damit es sich in Summe ausgeht, von 0 auf 255 in 3.8 Sekunden zu faden). Kein Mensch schreibt dir vor, dass du jede Zwischenstufe mitnehmen musst!
An deiner Stelle würde ich mich allerdings am Anfang noch gar nicht auf das Faden konzentrieren, sondern erst mal einfach nur eine zeitliche Ablaufsteuerung mit fixen Helligkeitswerten realisieren. Also so was Kanal 1 Schritt Dauer[s] Helligkeit 0 10 5 1 50 58 2 368 250 3 12 80 Kanal 2 Schritt Dauer[s] Helligkeit 0 80 40 1 12 213 2 2 5 3 10 0 4 7 5 Kanal 3 Schritt Dauer[s] Helligkeit 0 123 0 1 2 255 2 1 8 ... Also einfach nur Tabellen, in denen verzeichnet ist, welche Lichtstufe wie lange zu halten ist. Und dann mal mit einer Timer-ISR diese Tabellen abarbeiten. Auch da gibt es schon so manche Software-Design Entscheidung zu treffen und Erfahrung zu sammeln. Und dann willst du ja auch noch einen Satz derartiger Tabellen (oder ist es nur 1 Tabelle? Du entscheidest) unter einem 'Programm' zur Verfügung haben. etc. etc. Da gibt es schon noch einige Dinge, die bedacht sein wollen.
Ich denke wir reden jetzt vom gleichen und due meinst genau das wie ich es mir vorstelle. Der Tip mit den festen Leuchtschritten ist erstmal gut, da kann ich die ganze Sache mal ausprobieren. Wie gesagt, die Timer ISR muss ja möglichst universell sein, um jedes Lichtprogramm später mal abarbeiten zu können. Da werde ich mich mal an die ISR setzen, aber nochmal zur Absicherung: Ich bin auf dem richtigen Weg, wen ich die ganze Sache mit Stufe laden, Zeit für Stufe laden und überprüfen in die ISR stecke? Nicht das ich mich dann übernehme und die ISR ständig aufgerufen wird oder sich vielleicht gegenseitig sogar verschluckt. Ins Menü muss dann ja auch noch ab und zu geschaut werden, ob vllt. ein anderes Programm inzwischen eingestellt ist. Aber ich denke das kommt hin. Aber naja im Hintergrund bahnt sich mir dann ein neues Problem an ... die Tabellen für die Lichtprogramme ... ich glaube damit ist schnell der Flash vollgestpoft bis oben hin, aber naja das ist erstmal ein Problem was dann hinten ansteht. Vielen Dank erstmal, mal schauen wie schnell es mit der ISR klappt!
Martin K. schrieb: > Ich bin auf dem richtigen Weg, wen ich die ganze Sache mit Stufe laden, > Zeit für Stufe laden und überprüfen in die ISR stecke? Ich hab nochmal drüber nachgedacht und bin eigentlich zum Schluss gekommen, dass ich das nicht tun würde. Ich würde mir in der ISR ein Jobflag setzen und dass dann in der Hauptschleife auswerten. Der Grund: Spätestens beim übergang von einer Fading Fahrt zur nächsten sind ein paar Berechnungen notwendig. Ist nicht so wild, aber doch. Und die will ich dort nicht haben. Warum? Weil in der Zeit, in der eine ISR läuft keine andere ISR laufen kann. Du hast aber im System eine andere ISR, die eminent wichtig ist: die ISR, die die PWM realisiert. Und #die# darf auf keinen Fall ins Stocken kommen, denn das würde bedeuten, dass die Lampen in der Helligkeit flackern. Wird wahrscheinlich nicht viel sein, aber mit etwas Pech würde man es bemerken. Und das darf auf keinen Fall sein. Da nehm ich lieber in Kauf, dass eine neue Lichtstufe ein paar µs zu spät gesetzt wird, denn das merkt kein Mensch. > Aber naja im Hintergrund bahnt sich mir dann ein neues Problem an ... > die Tabellen für die Lichtprogramme ... ich glaube damit ist schnell der > Flash vollgestpoft bis oben hin, das kann leicht sein. Daher ja auch: eine kompakte Beschreibung. Es ist sinnlos, wenn du das Fading in den Tabellen bis auf den Einzelschritt auflöst, das müllt dir nur den Speicher zu. In den Tabellen brauchst du alle Daten, die dir erlauben die relevanten Werte auszurechnen, zu dem Zeitpunkt an dem dieser Fading Schritt gemacht wird. Du brauchst die Werte vorher nicht und du brauchst sie nachher nicht. Damit müssen die auch nicht in den Tabellen dauerhaft abgelegt sein.
Karl Heinz Buchegger schrieb: > Ich hab nochmal drüber nachgedacht und bin eigentlich zum Schluss > gekommen, dass ich das nicht tun würde. Ich würde mir in der ISR ein > Jobflag setzen und dass dann in der Hauptschleife auswerten. Das kann ich von der Praxis her absolut bestätigen. Ich hatte bei einer ähnlichen Entwicklung Beitrag "Equinox-Uhr mit 60 ATtinys" das Fading zunächst auch in der ISR. Teilweise dauerte die Berechnung der Schrittweiten (bei variabler Fadingzeit) zu lange. Durch Setzen des Flags und die Verlagerung des eigentlichen Fadings in die Hauptschleife hatte sich das Problem dann erledigt.
Ok, also nochmal eine Frage, zur ISR: Die Berechnungen für die PWM-Stufe und das Setzen der Stufen in der PWM nehme ich ins Hauptprogramm und in der ISR schaue ich quasi nur, ob die Zeit für die jeweiligen Kanäle und Helligkeitsstufen erreicht wurden, wenn es der Fall ist, dann Flag setzen. Im HP schaue ich dann ob Flag gesetzt und abhängig davon wird dann die neue Stufe eingestellt und an die PWM übermittelt. So müsste es dann klappen, oder?
Martin K. schrieb: > Ok, also nochmal eine Frage, zur ISR: > > Die Berechnungen für die PWM-Stufe und das Setzen der Stufen in der PWM > nehme ich ins Hauptprogramm und in der ISR schaue ich quasi nur, ob die > Zeit für die jeweiligen Kanäle und Helligkeitsstufen erreicht wurden, noch nicht mal das. In der ISR setzt du einfach nur ein Flag: Es ist wieder mal soweit, 0.1 Sekunden sind vergangen. Und in der Hauptschleife tust du, was immer es alle 0.1 Sekunden zu tun gibt. Zb testen ob eine Lampe eine andere Einstellung in der PWM braucht. Diese ISR fungiert rein nur als Zeitgeber, der in ...
1 | ISR( ... ) |
2 | {
|
3 | doWork = TRUE; |
4 | }
|
5 | |
6 | int main() |
7 | {
|
8 | ...
|
9 | |
10 | while( 1 ) { |
11 | |
12 | if( doWork ) { |
13 | doWork = FALSE; |
14 | |
15 | ....
|
16 | }
|
17 | |
18 | }
|
19 | }
|
... die regelmässige Verzweigung in den Arbeitsteil anstösst.
Karl Heinz Buchegger schrieb: > Martin K. schrieb: >> Ok, also nochmal eine Frage, zur ISR: >> >> Die Berechnungen für die PWM-Stufe und das Setzen der Stufen in der PWM >> nehme ich ins Hauptprogramm und in der ISR schaue ich quasi nur, ob die >> Zeit für die jeweiligen Kanäle und Helligkeitsstufen erreicht wurden, > > noch nicht mal das. > > In der ISR setzt du einfach nur ein Flag: Es ist wieder mal soweit, 0.1 > Sekunden sind vergangen. > > Und in der Hauptschleife tust du, was immer es alle 0.1 Sekunden zu tun > gibt. Zb testen ob eine Lampe eine andere Einstellung in der PWM > braucht. > > Diese ISR fungiert rein nur als Zeitgeber, der in ... > >
1 | > ISR( ... ) |
2 | > { |
3 | > doWork = TRUE; |
4 | > } |
5 | >
|
6 | > int main() |
7 | > { |
8 | > ... |
9 | >
|
10 | > while( 1 ) { |
11 | >
|
12 | > if( doWork ) { |
13 | > doWork = FALSE; |
14 | >
|
15 | > .... |
16 | > } |
17 | >
|
18 | > } |
19 | > } |
20 | >
|
> > ... die regelmässige Verzweigung in den Arbeitsteil anstösst. Also ehrlich gesagt, das war ganz am Anfang meine Idee. Die hatte ich aber aus einem Grund verworfen: Denn ich war dann wieder dabei gelangt, das er gewissermaßen in einer Endlosschleife hängt, halt nur nicht zählt sondern wartet, das sich der Timer ausgezählt hat. Aber das kann ich ja eigentlich ganz intelligent überspringen, wie ich gerade sehe. Und dann gehts nach dem if einfach weiter mit Menu - Abfrage und so weiter - stimmt eigentlich ganz logisch. Ich glaube jetzt ist die Blockade von gestern endlich gelöst! Mal sehen ob ich dann über dem Proggen nochmal drauf stoße, oder ob ich jetzt so hinkomme. Vielen Dank erstmal!!!
Martin K. schrieb: > Also ehrlich gesagt, das war ganz am Anfang meine Idee. Die hatte ich > aber aus einem Grund verworfen: > > Denn ich war dann wieder dabei gelangt, das er gewissermaßen in einer > Endlosschleife hängt, das tut ein µC sowieso immer. (ausser er ist im Sleep) > halt nur nicht zählt sondern wartet, das sich der > Timer ausgezählt hat. Aber das kann ich ja eigentlich ganz intelligent > überspringen, wie ich gerade sehe. Und dann gehts nach dem if einfach > weiter mit Menu - Abfrage und so weiter - stimmt eigentlich ganz > logisch. Genau., Der springende Punkt ist die Denkweise. Betrachte das Flag als Benachrichtigung: Es ist ein Ereignis eingetreten. Der µC testet in seiner Hauptschleife ständig alle möglichen Ereignisuaslöser durch und bearbeitet das Ereignis. So ein Ereignis kann sein Timer hat ausgelöst (weil eine Zeitdauer vergangen ist) Taste wurde gedrückt Lichtschranke hat ausgelöst Endschalter ist betätigt ... die Hauptschleife testet einfach nur der Reihe nach die möglichen Ereignisse, ob sie eingetreten sind und reagiert darauf. Es ist immer das gleiche Prinzip. Du kannst dir auch selbst ein 'künstliches Ereignis' definieren, um eine längere Berechnung in mehrere Teile zu zerteilen, die dann in mehreren Durchgängen durch die Hauptschleife abgearbeitet werden. Das macht man zb dann, wenn man sicherstellen möchte, dass während dieses längeren Teils auch die anderen Ereignisse eine Chance haben kurz dazwischen zu funken.
Martin K. schrieb: > Ich glaube jetzt ist die Blockade von gestern endlich gelöst! Mal sehen > ob ich dann über dem Proggen nochmal drauf stoße, oder ob ich jetzt so > hinkomme. Denke daran, doWork als volatile zu definieren. Sonst wunderst Du Dich, warum nichts passieren wird ;-)
Hey, ich glaube jetzt bin ich wirklich wieder über die Klippe gesprungen. JEtzt ist mir das irgendwie alles wieder klarer und eigentlich auch selbstverständlich. Das kommt halt davon, wenn man über ein Jahr nur noch normalen PC programmieren musste und wieder auf µc umsteigt. Aber ich denke es ist wieder da, die Fading - Funktion aus dem Artikel habe ich nun so auf den Timer umgebaut, ohne Warteschleifen. So nun muss ich das nur noch universeller gestalten und dann kann es ja schon bald mit Lichtprogrammen losgehen. Ich habe sogar gesehen, das es so auch problemlos möglich ist, einfach die Lichtprogramme direkt in C zu proggen, mal sehen ob das Sparsamer ist als Tabellen, da kann der µc ja selber sich was ausrechnen. Aber wie gesagt, da muss ich erstmal schauen ...
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.