Programm "ausdünnen"

[Besserwessi]

Die Routinen für das Fading könnte man ggf, noch zusammenfassen. Es braucht dann aber den Indirekten Zugriff auf des Register. Wie das in BASIC geht weiß ich nicht.
Ein Versuch wäre ggf. eine Parameter mit Call by Reference.

[HeXPloreR]

Hallo stardust19322,

schau dir mal den Befehl "select case" an. Damit wäre es denke ich möglich schon sehr viel zusammen zu fassen.
Dazu die Interrupts für die zwei Taster nutzen um einmalig je eine Variable zu setzen die die Schleife abbricht oder auswählbar macht ob fading oder nicht fading.
V und V2 sind zwar sehr kurze Variablen, sie "sprechen" aber auch nicht - wenn du sie zb umbennenst in RGB_taster und Fading_taster dann sprechen sie schon etwas. Wenn du den Codeaufbau auf eine Select_Case inklusive dem Fading aufbaust dann könntest du damit sehr viel Code ein sparen. Die Farbenwahl würde ich direkt im case auswählen - also case 1 (soll rot sein), "rot = 1023, grün = 0, blau = 0". So bei jeder Farbwahl verfahren, dann braucht man kiene Rücksicht darauf beim programmieren nehmen, welche Farbe man in der if-Abfrage davor gewählt hatte. Das wäre dann das Hauptprogramm.
Da sich im Code die Anzahl der waits dadurch reduzieren müssten, wäre es möglich auch hier für die Wartezeiten Variablen zu vergeben. Ich habe zwei Zeiten gesehen - "wait 1" wird zu "wait waitms1000" oder "1sec" und waitms 10 wird zu "wait waitms10" oder "10msec" - damit hast du dann praktisch auch direkten Zugriff auf die Fadingzeiten und könntest diese dann auch mit manipulieren.

Das Fading würde ich versuchen so halten das die Bedingungen für den Durchlauf und auch der Step (2 oder -2) einfach ausgetauscht werden können. Ob das mit einem For-Next Konstrukt möglich ist sagt die Hilfe oder ein Versuch. Ich müsste es jetzt selbst nachlesen und/oder ausprobieren. Wenn es damit nicht möglich sein sollte zu tauschen, dann das Konstrukt auf etwas passendes ändern.
Diese Massnahme allein würden den Code innerhalb der beiden verschiedenen Fadings geschätzt schon auf über die Hälfte reduzieren.

Ich hoffe es wird dir helfen.

Viele Grüße
Jörg

[stardust19322]

Hallöle Hex ^^.

Danke sehr für deine ausführliche und hilfreiche Antwort.
An Select-Case habe ich schon gar nicht mehr gedacht. Als ich das Programm im Software-PWM-Modus aufbaute, musste ich diese Anweisung nutzen.
Fraglich ist nur, wie ich das zutreffende Ereignis (beispielsweise Case 3 = true) dann mit dem Fading-Unterprogramm verbinde. Aber das bekomme ich schon irgendwie hin.

Gestern wurde es bei mir ja sehr spät - konnte erst gegen halb 2 morgens in Bett, weil mich Fortschritte im Programmablauf extrem weit voran brachten. Da ich immer Probleme hatte, Variablen in die DO...LOOP zu übergeben, habe ich nun eine Möglichkeit gefunden, diese gänzlich zu entfernen, sodass nur noch eine Hauptschleife und entsprechende Subroutinen verblieben sind. Habe mir dazu ein Testprogramm geschaffen, in welchem nur 4 Möglichkeiten des Farb-Fadings auswählbar sind, um zu schauen, ob die Variablen auch sauber funktionieren. Die Farben blieben trotzdem noch alle erhalten.

Dazu konnte ich in einem ersten versuch erfolgreich eine 5-stufige Dimmfunktion einbauen. Allerdings muss ich noch (wie du bereits geschrieben hast, Hex) die Fading-Zeiten ändern, denn mit heruntersetzen der Helligkeit (Wurzel 1,5) beschleunigt sich das Pulsor-Verhalten, und das soll es nicht. Also muss ich die Zeiten mit 1,5 je Stufe zum Quadrat nehmen.

Ich denke, dass es machbar ist, die Step's komplett auf 1 zu setzen, im Gegenzug die Wartezeit je Takt verringern. Derzeit läuft der Takt mit einem 10ms-Delay, dafür werden aber nur alle 2 Takte gezählt, das Delay steht real also bei nur 5ms. Ich probiere noch ein wenig - dann geb ich dir/euch Bescheid.

Mit den Variablen-Namen halte ich mich auch recht kurz. Zeit ist zwar nicht Geld, jedoch tippt man sich auch schnell mal die Finger wund, wenn man 20mal die gleiche Variable vertippeln muss ^^


LG - Maik

[HeXPloreR]

Hallo Maik,

eigentlich ganz einfach wenn es in ein Unterprogramm laufen soll: case 3 = Gosub Unterprogramm (für Fall 3). Du kannst den case auch in innerhalb der angesprungenen Sub erneut auswerten sofern er sich noch nicht geändert hat. Und das kann man ja gut steuern
Nur wenn man die Bedingungen der For-Nextschleife tauschen möchte - das gilt es ja mal zu prüfen ob es überhaupt geht, das zu Laufzeit zu ändern(?) - also hoch und runter zählen möchte, dann benötigt man irgendwie einen wechsel mit dem Stepper als Variable damit der Step negativ wird. Da gibt es z.b. die Lösung des
"stepwert = 1 (stepwert) *-1 " wird negativ oder eine Abzweigung den wert zu setzen.

Ich denke auch das es eine bessere Methode ist nicht mit einem Mischzustand im Zähler-/Timingbereich indirekt zu arbeiten - was jetzt also so 2er Steps z.b. betrifft. Damit holt man sich einfach zu viele unnötige Stolpersteine rein. Lieber den Zähler normal Zählen lassen - übrigens benötigt man den nicht beim hochzählen, weil er im Hintergrund auf 1 voreingestellt ist und dann ohne weiteres zu tun genutzt wird. Beim runterzählen benötigt man aber zwingend das Minus (-) vor der geschriebenen 1.

Ich finde die Idee mit dem zweiten Taster zu toggeln garnicht so schlecht. Wenn du darauf einen Interrupt legst, und innerhalb dessen toggelst, dann kannst du in dem ersten case für z.b. "rot" PWM mit if (Taster2 = 1) then...das Fading einleiten indem du hier gleich die 3 PWM-Wert auf Variablen setzt und dann dort heraus eine FadingSUB anspringst. Dieser eine Sub wird jetzt mit den drei PWM-Werten betrieben - und ob die jetzt hoch und anschliessend wieder runter zählt oder ob man da noch einige Codetricks anwenden kann spielt kaum noch eine Rolle. Der Übersicht halber die einfachst Art benutzen.

Warum wird der Zähler bei blau durch 4 geteilt?

Na, ich hoffe es hilft dir.

Viele Grüße
Jörg

[stardust19322]

Hallo Jörg.

Der Zähler für "Blau" wird aus dem Grund durch 4 geteilt, da dieser Zähler seltsamerweise 4mal schneller läuft als die Anderen. Bei der Farbanwahl fiel mir das erst gar nicht auf. Erst, als ich die Farben das erste Mal gemischt (Violet = rot und blau) faden ließ, überlief der blaue Zähler 3mal in beide Richtungen, also sowohl beim Aufdimmen als auch beim Abdimmen. Demzufolge Werte durch 4 geteilt und das funzt 1a. ^^


Hm, ich verstehe nicht ganz, was genau du mit deinem Vorschlag "Wait Waitms 10" meinst. Ich kann dies ja nicht hintereinander schreiben, denn dann meckert Bascom und erwartet noch weitere Variablen.

Die Hauptschleife mit den Fallbedingungen "Select_Case" funktioniert bereits einwandfrei. Habe hinter jeder Leuchtfarbe eines Falls noch eine Variable gesetzt, welche mit dem Fall mitgesetzt wird. Somit leuchtet die entsprechende Farbe und ein zusätzlicher Merker bleibt im Hintegrund aktiv, von welchem dann auch das richtige Fading angesprungen werden kann.
Leider war es mir bislang nicht möglich, die Takt-Pausenzeiten in-program zu verlängern oder zu verkürzen, wodurch sich die Fading-Zeit ebenfalls verlängern oder verkürzen würde.
Ebenfalls keine Chance beim Ändern der Farbe innerhalb der Routine, egal wo ich ansetze:

      For Zaehler = X To Y Step -2
         If Taster1 = 0 Then Exit For 
         Waitms Schrittpause
         Rot = Zaehler
      Next Zaehler

Ich konnte zwar die Zeit für den Durchlauf eines Zyklus anpassen, jedoch nach Ablauf dieses Zyklus (einmal von X nach Y gezählt) stellten sich die Werte wieder auf den Basiswert zurück. Außerhalb der Sub kann ich jedoch auch keine Zeiten per Variable übergeben.



LG - Maik

[HeXPloreR]

Moin Maik,

ich freue mich das es bei dir schon Fortschritte gibt.

Mit "wait Waitms 10" (ohne Leerzeichen: Waitms10) meine ich eine Variable die sich "Waitms10" nennt Sie ist sprechend und wird dann mit 10ms als Wartezeit inizialisiert. Du hast sie jetzt "Schrittpause" genannt, ist auch okay. Denk daran du hattest oben zwei verschiedene Pausenzeiten drin.

Ein "wait" gefolgt von einfachem "waitms" geht halt nicht, weil es beides Schlüsselwörter in Bascom sind. Deshalb kann man den Wert für wait in eine Variable packen, dann geht's

Du hast in der Config vom Zähler Blau übrigens den Prescaler doppelt gesetzt - ob's was negatives oder garnichst weiter bewirkt kann ich nicht sagen, dazu bin ich bei dem Prescaler so auf Anhieb nicht sicher genug.

Ich denke mal das sich die Werte nicht von alleine auf den Basiswert zurückstellen/verändern. Sie müssen natürlich manuell programmtechnisch getauscht werden. Und es ist ja der "Zähler" der dann den neuen Wert aufnimmt, nicht x und y - die bleiben so wie sie sind wenn daran nichts geändert wird.

Es gibt aber grundsätzlich mehrere Möglichkeiten das zu lösen, also kann es sich auch lohnen an dieser Art Schleife dran zu bleiben muss aber nicht.

Jetzt fehlt eigentlich nur noch Dein aktuelles Programm

Weiterhin viel Erfolg und Grüße aus dem Norden
Jörg

[stardust19322]

Hallo Jörg.

Ach das meintest du... ^^

Variablen zum Ersetzen der Zeitangabe hatte ich bereits versucht und es funktionierte eben nur außerhalb der For-Schleife. Allerdings war ich mit meinen Experimenten noch nicht vollständig durch. Ich möchte meinen, dass ich versuchte, die Dimmzeit On-The-Fly zu verändern, als während das entsprechende Programm lief, aber das ist ja nicht das, was ich erreichen möchte.
Denke, dass es ausreicht, wenn ich jeder Dimmphase eine eigene Zeitvariable zuweise - also fest zuweise. Diese wird dann vor dem Dimmprozess bereits aufgerufen. Allerdings kann dann nur während dem Konstant-Leuchtmodus gedimmt werden und nicht während des Pulsmodus, da im Pulsing die Zeit offensichtlich nicht verändert werden kann oder darf, sonst stoppt das Fading an der Stelle (Led bleibt halb leuchtend "stehen").

Hm - ich muss mir das Programm noch mal anschauen. Wenn der Prescaler dort doppelt gesetzt ist, dann wird einer entfernt. Schädlich sollte es wohl nur sein, wenn dieser 2te einen anderen Wert hat als der erste ^^.

Eine andere Art Schleife, um das Fading zu realisieren, hatte ich bereits einmal versucht (Ebenfalls eine Zählschleife mit Incr und Decr), jedoch konnte ich hier keine Zeiten ändern. Die zählten also so schnell, dass ich das nicht mal wirklich sehen konnte. Wäre natürlich super, wenn es eine "flexiblere" Variante zum Auf- und Abdimmen geben würde, bei der ich auch die Farben vor dem Aufruf des Unterprogramms tauschen kann, aber solange das nicht geht, bin ich an FOR-NEXT gebunden.

Werde die Tage mal alles zusammenstellen, was ich habe und brauche. Die Dimmfunktion mit den sazugehörigen Zeiten in das Testprogramm einbinden.
Später müsste ich noch alles auf den "Anwendungsfall" umschreiben, also alle Variablen ändern. Aus X = 1023 wird dann X = 0, aus Y = 0 wird Y = 1023 - und so auch mit allen Zwischenwerten, sonst leuchten die falschen Farben auf, und das Problem hatte ich beim ersten Versuch mit einer Prototypen-Platine.


LG - Maik

[Peter(TOO)]

Hallo Maik,

Habe gerade nachgesehen, Bascom kennt Funktionen, diese werden mit Call aufgerufen.
Aufruf wäre dann z.B.

Call Fading(Rot, Gruen, Blau)

Die Fading-Funktion kann dann alle Farben und wird nur einmal benötigt.
Mit den Werten für die 3 Farben wird festgelegt, welche Farben angesteuert werden müssen.

MfG Peter(TOO)