Mini-RGB-Fader Bausatz - Hardware - Bausätze vorrätig!

  • Die Werte werden eine Modus werden immer dann gespeichert wenn man in den anderen Modus wechselt. Das heißt wenn man im Manuell-Mode eine Farbe eingestellt hat, dann muss man kurz in den anderen Mode wechseln und wieder zurück um die eingestellten Farbwerte zu speichern.

    Da lässt sich aber sicher noch was dran ändern ;) Dachte da so an einen Live-Save, also alles was man tut wird direkt in den Flash gespiegelt :) Aber mach dir da mal erst keine Gedanken drum, kann ich evtl mal umbasteln, wenn ich was Zeit habe.

  • Da lässt sich aber sicher noch was dran ändern ;) Dachte da so an einen Live-Save, also alles was man tut wird direkt in den Flash gespiegelt :) Aber mach dir da mal erst keine Gedanken drum, kann ich evtl mal umbasteln, wenn ich was Zeit habe.

    Im Flash sind die ja auch "live", nur im eeprom nicht. Ins eeprom will ich die auch nicht jedesmal nach jedem Tastendruck speichern, weißt ja, für eeprom gelten ca. 100.000 Schreibzyklen! Das darfst nicht vergessen!



    Gruß, Benny.

  • Wie das genau in Bascom geht weiß ich nicht, in C geht es auf jeden Fall. Du adressiest halt immer die Speicherpages. Wie groß die sind kannst du einstellen, standardmäßig sinds bei den meisten 256 Byte. Da würde fast schon eine Seite für alle Daten ausreichen. Du kannst zwar nicht jedes einzelne Byte dadrin verändern, aber die neu-generierung der Speicherseite aus den aktuellen Variablen + schreiben in den Speicher sollte so fix gehen, dass der User davon nix mitbekommt.
    In C wäre das bootpage_fill(..) zum füllen der bootpage, bootpage_write(...) zum schreiben in den flash, boot_spm_busy_wait(...) zum warten auf Ende des Schreibvorgangs und bootpage_erase(...) zum löschen der Speicherseite.

  • Korrekt ;) Ich würde nur schauen, dass man das ganze so weit wie möglich voneinander trennt, damit man nicht versehentlich was vom Programm überschreibt. Sollte halt die Bootsektor-größe so klein wie möglich machen und dann die davor liegenden Speicherseiten benutzen. Viel mehr als 6 Byte oder so würden es eh nicht, da wären die Helligkeiten der drei Farben, die Geschwindigkeit, die Gesamthelligkeit und der Modus, mehr fällt mir da schon nicht ein. Jedes sollte eigentlich mit einem Byte auskommen, wenn mans spendabel sein will kann man der Geschwindigkeit noch nen Integer geben, da wären wir dann bei 7 Byte :D

  • Hallo Leute,


    vergesst den Flashspeicher bitte schnell wieder!


    Ich habe oben geschrieben warum ich die Werte nur bei einem Moduswechsel in den EEPROM speicher. Weil der EEPROM halt mit 100.000 Schreibzyklen eine Begrenzung hat und ich daher nicht nach jedem Tastendruck einen Schreibzyklus verschwenden möchte.


    Das wäre auch unlogisch. Wenn ich die Fadinggeschwindigkeit eines Schrittes von 20ms auf 10ms senken möchte. Dann muss ich 10x den Taster betätigen. Würde ich nun nach jeder Tasterbetätigung in den EEPROM schreiben, hätte ich 9x von den 10x umsonst in den EEPROM geschrieben. Daher muss man dann halt, nachdem man seine gewünschte Einstellung vorgenommen hat, einmal den Modus wechseln.


    Und zum Flash-Speicher: der Flash-Speicher hat nur 10.000 Schreibzyklen! Dann doch lieber den EEPROM stressen, der hat 100.000 Schreibzyklen.



    Gruß, Benny.

  • Hi folks,



    die Diskussion um das automatische Speichern der Werte verstehe ich nicht ganz.


    Folgende Strategien wären doch möglich:


    1. Wenn der gewünschte Modus oder das Farbspiel erreicht ist, könnte doch gezielt durch eine Taste eine Speicherung der Einstellung vorgenommen werden. Die Speicherung des aktuellen Wertes (beim Abschalten der Versorgungsspannung), wenn die LED im Faiding-Modus sich befindet, finde ich persönlich uninteressant, denn ich wäre nur nach dem erneuten Einschalten wieder am aktuellen Modus und nicht an der Fortsetzung der letzten Werte interessiert.


    Alternative:


    2. Automatisches Speichern, nach dem letzten Tastendruck (d.h. Speichern der Einstellung, wenn lastkeypress + Wartezeit (Bsp. 10sec) erreicht wurde).


    Damit würden die garantierten Speicherzyklen wahrscheinlich nie ausgereizt werden.


    Oder sehe ich das falsch?



    Gruß Franzy

  • Hi Franzy,


    das mit dem Speichern bei Tasterdruck ist ok. Nur bisher habe ich mein Programm so geschrieben das ich keine Taster frei habe. Aber ich muss das alles eh umschreiben.


    Folgendes Problem, es betrifft nur den Manuell-Mode:


    Wir haben ja im Manuell Mode zunächst 6 Taster frei, die 2 restlichen sind dauerbelegt durch Reset und Mode-Wechsel.
    Wir wollen mit den 6 Tastern 3 LEDs dunkler oder heller schalten. Ist eigentlich leicht, je ein Tasterpaar schaltet eine LED Stufenweise heller oder dunkler. Problem dabei ist nur das es von "Led-aus" bis "Led-an" 254 Zwischenwerte gibt.
    Bei dem ein oder anderen klingelt es jetzt schon. Man müsste also einen Taster ca. 127 mal drücken um die Led "halb" hell zu bekommen.



    Dazu habe ich mir folgendes überlegt:


    4 Taster werden dazu verwendet um die LEDs Stufenweise zu verändern. Dabei hat jeder von den 4 Tastern eine andere wertigkeit. 1. Taster zählt um 1 weiter oder zurück. 2. Taster zählt um 4 weiter oder zurück. 3. Taster zählt um 10 weiter oder zurück. 4. Taster zählt um 40 weiter oder zurück.
    Die 2 restlichen Taster werden dazu verwendet die LED auszuwählen bzw. festzulegen ob hoch oder runter gezählt wird.


    Das Problem hierbei:


    - kein Taster mehr frei um ins EEPROM zu speichern.
    - passt nicht in den Chip - Programm toooooo big.



    Also muss ich mir was anderes überlegen. An der Idee mit einem extra Speichern-ins-EEPROM Taster will ich festhalten. Aber dann haben wir im Manuell-Mode nur noch 5 Taster zur Einstellung frei....


    Also wer Ideen hat, her damit.



    Gruß, Benny.

  • Hallo Benny,


    das mit der Codegröße kann ich natürlich nicht beurteilen ist aber in der Tat ein "Killerargument" für SW-Lösungen und ich hab' hierfür keinen Code parat, sondern habe mich an Realisierungen aus dem Alltag orientiert( Bsp. gleichzeitiges Drücken zweier Tasten (up+down) oder einfach ein Timeout nach dem letzten Tastendruck (mein Sony-Autoradio)).


    Ich habe eine mögliche Tastenbelegung mal aufgeschrieben:


    Taster 1 Reset, Taster 2 Mode, Taster 3 LEDselect, Taster 4 up, Taster 5 down, Taster 6 inc/dec 1, Taster 7 inc/dec10, Taster 8 free?
    Wenn man den letzten von Dir beschriebenen Zählschrit (+/- 40) wegläßt, dann wäre eine Taste fürs Speichern frei.


    Ich denke 25 mal einen Taster zu drücken ist doch akzeptabel, aber die anderen sollten auch ihre Meinung dazu sagen.


    Gruß



    Franzy

  • Hallo,


    Ich finde die Tasterbelegung für den Manuellbetrieb so, wie sie JayDragon vorgeschlagen hat akzeptabel, wobei ich für die Taster, die er mit 10-er Schritten vorgeschlagen hat, mit 16-er Schritten belegen würde. Dann hat man von 0 bis 255 genau 16 Tastendrücke, und für Zwischenhelligkeiten max. 8 weitere Einzelschritte. - Das halte ich für vertretbar.


    Einen Extrataster zum Speichern halte ich somit auch für sinnvoll.


    Und dann habe ich zu dem System noch eine Frage: Was passiert, wenn der Zähler für die Helligkeit einer Farbe überläuft?


    Viele Grüße,


    c-kolb

  • Hier ne Anregung für das rauf-/runterfaden anhand gekaufter Geräte:


    1. Man drückt eine Taste (z.B. rauf) kurz -> Wert wird um 1 erhöht - bleibt man länger drauf, "läuft" die Erhöhung, also solange man auf dem Taster bleibt, wird immer schneller hochgezählt.... so ist das z.B. bei der Uhr in meinem Auto....


    2. Man drückt und hält z.B. den "rauf"-Taster - der zählt dann langsam hoch (Dadurch zählt er auch automatisch nur einen Schritt, wenn man nur 1x kurz drückt). Wenn man nun (während der "rauf"-Taster gedrückt ist), den "runter"-Taster drückt, erhöht sich diese Hochzählgeschwindigkeit, meinetwegen auf das 3-fache.... so ist das bei nem Dimmer-Bar, das ich habe, finde ich sehr praktisch...*


    Ich persönlich würde es schon besser finden, wenn man pro Farbe (R, G, B) ein heller/dunkler-Päärchen hätte, das mit dem erst LED anwählen, und dann auch noch die Schrittweite finde ich etwas arg umständlich.


    V.a. wenn man nur einen Taster hat, um die LED auszuwählen - da muss man erst mal rumprobieren, welche LED grad dran ist (OK, man könnte es auch so machen, dass der Kanal kurz aufblitzt, damit man sieht welcher ausgewählt ist....), und dann hat man damit auch schon wieder die Einstellung in dem Kanal geändert... und ein Taster pro Kanal (wären dann 3), einer für Schrittweite und 2 für rauf/runter macht dann ja auch schon wieder 6 Taster - mit umständlicherer Bedienung...


    Und die Idee vom ersten Beitrag, dass man in einem Modus die Schrittweite für den anderen ändert, finde ich gar nicht gut: das wird ja ein ewiges rumgeklicke: im Fader-Modus die Geschwindigkeit hoch stellen, dann in den Stop-Modus wechseln, dann LED grob heller, wieder in den Fader-Modus, dort Schrittweite verringern, wieder in den Stop-Modus, genauer rantasten usw.


    Wofür war der Reset nochmal...? da habe ich jetzt auf die Schnelle nix gefunden... hängt der direkt am Reset-Pin des AVR....? - hätte man sich dann eigentlich auch sparen können... eine beliebte Methode zur Doppelbelegung ist ja auch lang/kurz, also hier z.B. die Mode-Taste doppelt belegen als Mode/Store: bei kurzem Druck wird der Modus gewechselt, bei langem wird gespeichert (hier ist es auch beliebt, dass z.B. die LEDs kurz aufblitzen, als Rückmeldung, dass die Speicherung erfolgt ist).


    Und falls der Reset nicht wirklich gebraucht wird (also d.h., der nicht am Reset-Pin des AVR hängt) geht's doch sowieso aus: 1 Taster Modus wechseln, 1 Taster speichern, je 2 Taster pro Farbe rauf/runter bzw. im Fader-Modus für die Geschwindigkeiten...


    Was da zwischendurch mal erwähnt wurde, dass der AVR beim ausschalten den momentanen Stand speichert, wird nicht funktionieren: da müsste er ja kurz vorher wissen, dass er jetzt gleich ausgeschaltet wird - und wenn er aus ist, kann er ja nicht mehr speichern... ;)


    *da ist es übrigens auch so, dass das Teil die Einstellungen "automatisch" speichert - keine Ahnung, ob die auf die Lebensdauer des EEprom sch***, oder das so gemacht ist (gute Idee, Franzy!), dass der einfach immer dann speichert, wenn eine Zeit lang die Pfoten wieder weg sind von den Tasten... das ist natürlich super, weil man das dann gar nicht vergessen kann, die Einstellungen erst zu speichern...


    p.S.: ich schätze mal, das ist so gemacht, dass die Helligkeit gar nicht "überlaufen" kann, also wenn's schon 100% ist und Du drückst nach oben, passiert halt nix...?

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Ok alles zurück, ich hatte nicht bedacht, dass der Flash auch nur eine bestimmte Anzahl von malen beschrieben werden kann. In dem Fall würde ich dann auch wirklich den EEPROM nehmen, hast recht. Die Frage ist jetzt ob es wirklich eine Taste für Speichern sein muss oder ob man das nicht eventuell direkt über das gleichzeitige und länger andauernde Drücken von zwei Tasten machen könnte, also bspw. LEDselect und Mode oder sowas in der Art halt. Naja letztendlich muss benkly entscheiden wie er es macht. Wers anders will kann sich die Firmware ja immernoch umschreiben (lassen)

  • Hier ne Anregung für das rauf-/runterfaden anhand gekaufter Geräte:


    1. Man drückt eine Taste (z.B. rauf) kurz -> Wert wird um 1 erhöht - bleibt man länger drauf, "läuft" die Erhöhung, also solange man auf dem Taster bleibt, wird immer schneller hochgezählt.... so ist das z.B. bei der Uhr in meinem Auto....


    2. Man drückt und hält z.B. den "rauf"-Taster - der zählt dann langsam hoch (Dadurch zählt er auch automatisch nur einen Schritt, wenn man nur 1x kurz drückt). Wenn man nun (während der "rauf"-Taster gedrückt ist), den "runter"-Taster drückt, erhöht sich diese Hochzählgeschwindigkeit, meinetwegen auf das 3-fache.... so ist das bei nem Dimmer-Bar, das ich habe, finde ich sehr praktisch...*


    Diese Lösung finde ich auch am besten. Ich habe unter anderem auch den MultiLine RGB Controller V2.0 hier aus dem Shop. Da ist das
    mit der Helligkeit so geregelt. Das häufige "pumpen" um die Helligkeit zu erhöhen oder zu senken ist schon nervig.

  • Sorry, dass ich "dazwischenpfusche", aber ich habe mir das mal aus lauter Neugier so überlegt:


    Im "Stop"-Modus machst Du ja nix anderes, als ständig in ner Schleife abzufragen, ob ne Taste gedrückt wird, oder? Also würde ich das so machen, wenn jetzt z.B. "Rot erhöhen" gedrückt wird, springst Du in ne entsprechende Subroutine, in der wird erst mal kurz gewartet (entprellen), dann (sofern's nicht eh' schon 255 ist), rot eins raufgezählt. Gleichzeitig eine Variable "Store" (oder so) auf z.B. 255 gesetzt.


    Dann wird wieder "kurz" (2 Sek.) gewartet, und danach abgefragt, ob die Taste immer noch gedrückt ist. Falls nein: zurück, das war dann nur ein kurzer Druck, für ne Erhöhung um 1. (Damit man nun nicht zwischen 2 Einzeldrückern 2 Sekunden warten muss, wird die 2-Sek.-Schleife natürlich sofort abgebrochen, wenn in der Zeit die Taste losgelassen wird...)


    Falls ja, dann läuft die "Raufzähl-Schleife" los: Rot um eins erhöhen (sofern noch nicht 255), und kurz warten, sonst ist das ja in einem Rutsch durch! - Die Wartezeit hier so anpassen, dass vielleicht 3x in der Sekunde erhöht wird (ausprobieren).


    Diese Wartezeit (festgelegt durch die Anzahl der Wiederholungen der Warteschleife) ist aber auch nicht fest, sondern es wird am Anfang der Warteschleife abgefragt, ob die "runter"-Taste auch gedrückt ist - und je nachdem ob gedrückt oder nicht, wird die Warteschleife halt z.B. 100 mal wiederholt oder nur 33 mal - was dann ein 3x höheres Tempo ergibt...


    Muss man halt ausrechnen, so hintrimmen, dass bei normalem "Dauerdruck" vielleicht die 255 Werte in 5 Sekunden durchlaufen werden, bei zusätzlich gedrückter "Runter-Taste" dann in 1,6 Sek. (so ist das ca. bei meinen Dimmerbars, finde ich sehr angenehm...).


    Und nach der Wartezeit wieder von vorne: schauen, ob die "Rauf-Taste" immer noch gedrückt ist, falls ja, das Spiel von vorne, falls nein, Routine beendet....


    Und nach dem Prinzip das selbe für alle Farben und rauf/runter.


    Wegen der Store-Variable: Die wird dann in der Hauptroutine (also da, wo nur geschaut wird ob ne Taste gedrückt wird) runtergezählt (natürlich nur, wenn sie >0 ist). Wenn sie 1 erreicht hat, wird die aktuelle Einstellung gespeichert (Subroutine).


    Da muss man in der Hauptroutine dann auch ne Verzögerung einbauen: macht man das so, dass die in 5 Sek. 255 mal durchläuft, dann heisst das, dass ca. 5 Sek. nach dem letzten Tastendruck (wenn keiner dazwischen war, ansonsten wird "Store" ja wieder auf 255 gesetzt) automatisch gespeichert wird - Tasten werden dann ca. 50 mal in der Sekunde abgefragt, das sollte ja reichen, dass man da keine Verzögerung merkt...


    Natürlich könnte jetzt der "Mode"-Umschalter (*falls* er per Interrupt gemacht wird) "dazwischenpfuschen", aber das würde ich dann auch so lassen, dass bei jedem Moduswechsel alles gespeichert wird, dann ist's ja egal, welchen Wert die "Store"-Variable in dem Moment hat.


    Dann hättest Du ne automatische Speicherung, die nicht *nach jedem einzelnen Tastendruck* speichert, sondern nur nach Änderung einer Einstellung - und ich glaube nicht, dass während der "Lebensdauer" des Geräts so oft Einstellungen/Farben/Modus geändert werden, dass der EEProm kaputt geht...


    Im Fader-Modus das Ganze analog für die Zeiten - hier laufen im Hauptprogramm ja auch irgendwelche Schleifen, in denen man die "Store-Variable" runterzählen kann...?


    Äääääh, btw.: würde das nicht in den dazugehörigen SW-Thread gehören? - aber den gibt's ja noch nicht....


    Und mal total off-topic: was macht der Jackpot denn da....? sollte das nicht mal so geregelt werden, dass der bei 500 "ausgeleert" wird....?!?!

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Ja, so finde ich es auch am besten. 2 Taster für einen Schritt auf bzw. ab. 2 Taster für 16 Schritte auf bzw. ab. Einen zum LED auswählen und einen zum Speichern.

    zu 1. und 2.:
    Das könnte man alles schon irgendwie machen, aber das sprengt den Speicherplatz den Chips. Ich habe jetzt schon nur noch ein paar % frei.


    zu 3.:
    Beim Chromoflex ist es auch so das man zuerst die Farbe auswählt die man will. Und ich muss das nun aus Tastermangel auch machen. Welche LED ausgewählt ist, wird einem dann durch ein aufblitzen der gewählten LED angezeigt.


    zu 4.:
    Das ist eigentlich schon lange verworfen. Muss ich im ertsen Beitrag noch ändern.


    zu 5.:
    Ja, der hängt direkt am Reset-Pin des µC. Wenn ich den per Fusebits als IO setze, dann ist der µC ohne weiteres für nichts anderes mehr zu gebrauchen als für das Programm das dann als letztes drauf gespielt wurde. Schon zum testen will ich mir das nicht anzun.


    zu 6.:
    GOIL, das wärs! 8o Ein µC mit Hellsehfunktion. :thumbup:


    zu 7.:
    Also Pesi, jetzt bin ich echt enttäuscht von Dir! Wenn Dein Zählerwert auf 255 steht und Du machst dann "INCR" was passiert dann? Er springt auf 0. Das gleiche passiert auch umgekehrt, also wenn der auf 0 steht und man macht "DECR" dann springt der auf 255.

    Die Frage ist jetzt ob es wirklich eine Taste für Speichern sein muss oder ob man das nicht eventuell direkt über das gleichzeitige und länger andauernde Drücken von zwei Tasten machen könnte, also bspw. LEDselect und Mode oder sowas in der Art halt.

    Zuviel Code, kein Platz mehr.



    Diese Lösung finde ich auch am besten. Ich habe unter anderem auch den MultiLine RGB Controller V2.0 hier aus dem Shop. Da ist das
    mit der Helligkeit so geregelt. Das häufige "pumpen" um die Helligkeit zu erhöhen oder zu senken ist schon nervig.

    Wie schon gesagt, wir haben kein Platz mehr für sowas.
    Dieser MultiLine hat auch nen etwas größeren µC drauf. Da kost allein der µC bald soviel wie unser ganzer Bausatz.



    @all


    Ich werde es nun folgendemaßen lösen:


    Es wird 2 Tasterpaare geben. Das eine um in 1er Schritten heller bzw. dunkler zu schalten. Das andere für das gleiche in 16er Schritten. Einen Taster um die LED auszuwählen, einen um die eingestellte Farbe zu speichern.
    Ich werde dann noch die eine übrige Taste im Fading-Mode dafür missbrauchen um im Manuell-Mode alle Werte auf 0 setzen zu können. Falls mal einer mit Farben mischen neu anfangen will.
    Ich denke dann ist das Programm fertig.


    So und jetzt mache ich mich ans proggen.......mal schauen wie lange die Nacht wird.....



    Gruß, Benny.

  • 6. Was da zwischendurch mal erwähnt wurde, dass der AVR beim ausschalten den momentanen Stand speichert, wird nicht funktionieren: da müsste er ja kurz vorher wissen, dass er jetzt gleich ausgeschaltet wird - und wenn er aus ist, kann er ja nicht mehr speichern... ;)

    zu 6.:
    GOIL, das wärs! 8o Ein µC mit Hellsehfunktion. :thumbup:

    Naja, Hellsehen muss ein µC dazu nicht, er braucht nur einen Helfer dabei :D (OK, Hellseher meistens auch...)
    Ein IC überwacht die Betriebsspannung und meldet, wenn diese zusammenbricht - der µC wir Elko-gepuffert und bekommt einen Interrupt ausgelöst, der die Speicherung erledigt - fertig ist die Hellseherei. So in der Art funktioniert das zumindest in Hausgeräten. Für dieses Projekt wäre es aber etwas overdressed. :P

  • zu 1. und 2.:
    Das könnte man alles schon irgendwie machen, aber das sprengt den Speicherplatz den Chips. Ich habe jetzt schon nur noch ein paar % frei.

    Nicht "irgendwie", sondern so wie ich es im letzten Beitrag (gelesen..?) vorgeschlagen habe... aber k.A., ist Bascom echt so ein dermaßen übler Speicherverschwender..?!? - naja, ich weiß schon, warum ich in .asm programmiere... :D - wobei ich nach wie vor der Meinung bin, das kann nicht mehr den *Riesenunterschied* (bzw. wohl kaum einen, bei der anderen Variante brauchst Du ja wieder etliche Zeilen Code für die LED-Auswahl und die Auswahl der Schrittweite...) machen, die Abfrage, ob die Taste nun kurz oder lang gedrückt ist - viel bequemer wär's halt dadurch... und da spielt's ja auch keine Rolle, wie das beim Chromoflex geregelt ist, man kann's ja auch besser machen...? ;)


    Ja, der hängt direkt am Reset-Pin des µC.

    Hm, aber wozu denn?!? - vertraust Du Deiner SW so wenig, dass Du da extra nen Taster für Reset verschwenden musst...? 8o - wenn sich das Teil wirklich mal gelegentlich aufhängt, dann kann man's ja einfach aus- und wieder einschalten.... ;) - aber jetzt eh' schon zu spät, Platinen sind ja schon in Produktion....


    Also Pesi, jetzt bin ich echt enttäuscht von Dir! Wenn Dein Zählerwert auf 255 steht und Du machst dann "INCR" was passiert dann? Er springt auf 0. Das gleiche passiert auch umgekehrt, also wenn der auf 0 steht und man macht "DECR" dann springt der auf 255.

    Das mach' ich aber nicht so - ich frage vorher ab "ist der Wert schon 255?" und falls ja, dann gibt's ganz einfach kein INCR - genauso andersum, wenn der Wert schon 0 ist - weil ich finde es bei sowas schon besser (und das ist auch bei allen meinen gekauften Geräten so), nen "Anschlag" zu haben, als dass es plötzlich wieder finster wird, wenn ich "nach oben" drücke.. 8o :D


    Soll alles keine "Kritik" sein, nur Anregungen - ist ja sowieso schon bewundernswert, dass Du Dir hier die ganze Mühe machst! :thumbup:

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Hi,


    Code ist fertig und im Anfangsbeitrag die Beschreibung aktualisiert. Hat ja jetzt doch nicht so lange gedauert und geschrieben habe ich nebenher auch noch einiges.



    @ Pesi


    Bascom ist eigentlich kein großer Platzverschwender. Manche Befehle werden ganz gut angepasst. Aber die Auswahl welche LED jetzt gewählt ist brauche ich exakt nur 5 mal und der Speicherverbrauch ist dabei nicht mal groß.
    Man wählt jetzt die LED per Taster aus und bekommt durch ein aufblinken gezeigt welche LED ausgewählt ist. Das müsste doch so ok sein.


    Das mit dem Reset-Taster stimmt schon. Den hätte man eventuell weg lassen können. Also wer den nicht braucht, der braucht den ja nicht zu bestücken.
    Aber irgendwie bin ich das so gewohnt an einen µC einen Reset-Taster einzuplanen. Zumindest dann wenn man am Programm über ISP rumfummeln kann. Aber ist ja jetzt egal.


    Das mit dem überlaufen des Wertes für die PWM hat bei dieser Schaltung einen tollen Vorteil! So kommt man schneller an die höheren Werte ran indem man ein ab 0 nach unten zählt. Dann muss ich nämlich um den Wert 255 zu erhalten nur einmal die Taste für DECR 1 drücken und fertig. Bei Dir müsste ich dann erst 15 mal die Taste für INCR 16 und anschliessend 15 mal die Taste für INCR 1 drücken.
    Aber das kommt wohl immer auf den Anwendungsfall an ob man einen Anschlag programmiert oder nicht.



    Gruß, Benny.