RGB-Controller mit ATmega8 und BASCOM

  • Ich habe in den letzten Tagen/Wochen einen eigenen RGB-Controller erstellt,es war eigentlich nur eine Testschaltung um verschiedenes auszuprobieren,aber dann hab ich es doch etwas "ausgeweitet".
    Ich will mal einige Meinungen dazu hören,konstruktive Kritik ist auch wünschenswert. :D
    Er hat 2 Taster mit denen man das Programm und den Modus ändern kann,ausserdem noch ein Poti,das verschiedene Aufgaben übernimmt.
    Man kann noch 8 LEDs als Anzeige anschließen,diese zeigen den Stand des Potis an.Also z.B. wenn das Poti auf der Mitte steht,leuchten 4 LEDs.
    Funktionen:
    Regenbogenfader (4 Modi,weiche Übergänge):

    -Durchgehender Regenbogenfader
    -Wechsel zwischen Rot-Grün
    -Wechsel zwischen Rot-Blau
    -Wechsel zwischen Blau-Grün
    Zufällige Farben (4 Modi,weiche Übergänge):
    -Zufällige Farbe aus allen mischbaren Farben
    -Zufällige Farbe aus dem Bereich Rot-Grün
    -Zufällige Farbe aus dem Bereich Rot-Blau
    -Zufällige Farbe aus dem Bereich Blau-Grün
    Feste Farbeinstellung:
    -Per Poti wird ein Farbwert für eine Farbe gesetzt und per Tastendruck kann man den Farbwert für die nächste Farbe einstellen.
    Feste Farbeinstellung:
    -Per Poti wird eine Farbe eingestellt.Diesmal wird kein Taster benötigt,sondern man geht mittels Drehen des Poti durch die Farben.


    Bei den ersten beiden Programmen kann man mit dem Poti die Geschwindigkeit ändern,mit der die Farben wechseln.
    Mit den folgenden Fuses stellt man als Taktgeber den externen Quarz ein,wer keinen Quarz benutzt sollte die Fuses lieber lassen und im Programm den Takt auf 8.000.000Hz umstellen.
    Fuses:
    Low:0xFF
    High:0xD9
    Für die Ausgänge habe ich BC337-Transistoren benutzt,wer größere Ströme schalten möchte,sollte da was anderes einsetzen.Ich hab diese benutzt,da ich sowieso nur ca 230mA pro Kanal schalten muss und ich viele davon hier rumliegen hab.


    Der Bascom-Code ist fast 4kb groß,also kann man das grade noch so mit der Demo-Version von Bascom kompilieren lassen.Ich bin beim schreiben einige Male über die 4kb drüber gekommen,aber konnte dann doch recht gut den Code kürzen/komprimieren. :)


    Software(+Quellcode):
    rgb-controller v2.0.zip
    rgb-controller v2.0 turi.zip

  • Schöne Sache! - Auch ein gutes Bedienkonzept - ich finde das generell immer besser, wenn man zum Werte (Helligkeit, Geschwindigkeit, ...) einstellen was zum drehen hat, statt so Up/Down-Taster...

    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!

  • Schön,dass es euch gefällt.An einen Bausatz hab ich noch garnicht gedacht,weil es eigentlich nur ein privates Projekt ist und ich vom Layouten keine Ahnung habe. :rolleyes:
    Ich schau mal,sobald ich den Code noch etwas komprimiert habe,kommen noch Funktionen,wie z.B. Helligkeit einstellen dazu.

  • Na da hätte ich doch eine Idee: ich hatte ja schon mal einen Mega8-Controller entwickelt: [Sammelthread] RGB-Controller Layouts/Schaltpläne. Vielleicht kannst Du die Ports einigermaßen anpassen und dann Deine Software dafür adaptieren. Dann ist das Problem mit der Platine und dem Layout geklärt. Wenn ich Dir mal eine schicken soll, schick mir eine PN.

  • Also Turi's Idee ist eigentlich nicht schlecht,wenn ich Zeit hab,passe ich die Software an,dass sie auch auf seiner Platine läuft.
    Gestern und heute hatte ich keine Zeit,ich hoffe im Laufe der Woche kann ich mich mal dran setzen.Mal sehen,ob ich mich doch ins Layouten einarbeite,brauchen werde ich es wohl so oder so,immer nur Lochraster ist auch nicht das Wahre. :D

  • Habe soweit alles angepasst:
    -LED-Anzeige wird an PD0-2 ,PD4-7 und an PB0 angeschlossen (Pin 2,3,5,6,11,12,13,14)
    -Taster an PC4 und PC5 (Pin 27,28 ) mit Pullup-Widerstand
    -Poti an den ADC0 (Pin 23)
    War nicht viel,hoffentlich hab ich nichts vergessen.
    Edit:
    Habe doch was vergessen und zwar auf 8MHz zu stellen.In der jetzigen Version stimmts so.

  • Schick schick. Aber wäre nicht ein Impulsdrehgeber einfache als ein Poti zu bedienen?


    Aber gute Idee werd mir davon evtl. mal was für meine Lichtsteuerbox "klauen" wenn ich das dann auch noch hinkriegen würde, dass das ganze mit einem Drehimpulsgeber läuft.


    Edit: Mit Drehimpulsgeber meine ich z.B. die Lautstärkeregelung am Radio, welche sich endlos drehen lässt. Evtl. heißt das ja dann anders.

  • Ich finde die Bedienung mit einem Drehimpulsgeber auch sehr schön, aber die programmierung finde ich schwieriger. Bei Potis brauch man einfach nur den ADC auslesen und das macht das ganze sehr einfach. Wenn man genug Interrupt eingänge am µC hat dann ist das mit Drehimpulsgeber auch einfach, das hat der Mega8 aber nicht ;)


    Grüße Jakob

  • Ach,Drehimpulsgeber heißt das.Hab bei meinem AV-Receiver so eines für die Lautstärkeregelung und wollte wissen,wie das genau funktioniert.Hier schon mal ein danke. :thumbup:
    Da ich jetzt ja den Namen weiß,kann ich mich damit weiter beschäftigen,wenn meine Zeit das zulässt kommt da dann wohl auch eine Implementierung.Bin jetzt im Abi-Jahr,da kannst ab und an etwas dauern. ;)

  • Wenn man genug Interrupt eingänge am µC hat dann ist das mit Drehimpulsgeber auch einfach, das hat der Mega8 aber nicht ;)

    Braucht es auch nicht, ganz im Gegenteil!


    Diese ganzen Ansätze, das irgendwie mit Interrupt zu machen, sind Käse, erzeugen zu viel Prozessorlast, funktionieren nicht richtig...


    Das einzig wirklich sinnvolle ist, den Encoder regelmäßig abzufragen (z.B. in nem Timer, der eh' für die PWM läuft) und den aktuellen Stand mit dem letzten zu vergleichen - so ein Encoder hat ja letztlich nur 4 Positionen, die sich dauernd wiederholen... z.B. Stand vorher war 1, jetzt 2 -> Encoder eins nach rechts gedreht... Stand vorher 0, jetzt 3 -> Encoder eins nach links gedreht...


    Der gibt ja Gray-Code aus, wäre etwas umständlich, den in ne Zahl umzurechnen, und dann die zwei Zahlen zu vergleichen, den Fall berücksichtigen, dass der Encoder von 0 nach 3 gedreht wurde etc. - also macht man das am einfachsten mit ner Tabelle - hier wäre ein Beispiel, ab Zeile 214...


    Man hat ja nur 4 Positionen, die der Encoder bei der letzten Abfrage gehabt haben kann, und 4 bei der aktuellen - also 16 Kombinationen - also werden einfach die 2 Bit von der letzten Abfrage genommen (dabei ist es egal, dass das Gray-Code ist) und die zwei von der aktuellen dazu, ergibt eine 4-Bit-Zahl - damit wird einfach in ner Tabelle aller 16 Kombinationen nachgesehen, 4 Kombinationen bedeuten "Encoder nicht gedreht", 4 nach links, 4 nach rechts, und 4 sind "ungültig" (also ein Schritt von 1 nach 3 z.B.)...


    Sind gerade mal 21 Zeilen Code inkl. der Tabelle - also 33 Byte im Flash, da braucht Bascom wohl mehr, um den ADC abzufragen... ;)


    Das Entprellen ist bei dieser Methode auch "automatisch" mit dabei... also nicht mal nötig, da noch Maßnahmen zu ergreifen... ein ost weiter oben ist ein komplettes Beispiel für nen kleinen RGB-Controller, einfach rot rauf und runter drehen, klick, grün rauf und runter, klick, blau rauf und runter, klick, wieder von vorne...


    sollte auch mal irgendwann HSV werden und feste Farben und Programme etc. (Umschalten über langen Klick), aber natürlich auch immer noch Baustelle... :D

    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!

  • Ich habe ein (kleines) Problem beim Programm festgestellt.Der AVR startet nach einiger Zeit einfach neu.Das kommt besonders bei den neueren Versionen auf.Mein erster Gedanke war,dass ich den Reset-Pin über einen Pull-up stabilisiere,aber daran lag es nicht,der Fehler tritt weiterhin auf.
    Dann fiel mir auf,dass der Fehler auftritt,wenn man oft den Modus wechselt,oder auch einfach nur den zufälligen Farbwechsel lange genug laufen lässt.Mein Gedanke hier war,dass der Speicher für die Unterprogramme überläuft,da ich ja doch einige ineinander geschachtelt hab.Deswegen hab ich HW-/SW-Stack/Framesize manuell eingestellt(nicht speziell berechnet,nur nach Gefühl groß genug eingestellt),aber es hat wieder nichts gebracht.
    Heute hatte ich wieder etwas Zeit und hab das Programm überarbeitet und ein wenig an der Programmstruktur gearbeitet,d.h. weniger ineinander geschachtelte Programme,Wait-Befehle geschickter platziert,usw...
    Leider tritt der Fehler auch mit der neuen Version auf und mir gehen die Ideen aus,woran das liegen könnte.Ich lade das Programm später hoch,wie immer beide Versionen.
    Zum Drehimpulsgeber bin ich noch nicht gekommen,Ferien haben ja erst angefangen.

  • Ich habe mit den Einstellungen für Watchdog ein wenig herumgespielt.Habe ihn eingeschaltet und regelmäßig resettet,per Fuses und in Bascom per Stop Watchdog versucht auszuschalten.Trotzdem hat es nichts genützt.
    Der AVR resettet sehr schnell,wenn ich im Programm 3 bin,alle Farben voll aufdrehe und den Taster drücke um zwischen den Farben zu wechseln.
    Was seltsam ist,egal ob ich Watchdog in den Fuses einschalte oder aus,der AVR hängt sich kurz auf und startet wieder neu.
    Edit:Also es scheint ein Problem mit meinem Aufbau zu geben,denn auf Turi's Platine konnte ich das einwandfrei testen!
    Hier nochmal ein Danke an Turi für das bereit stellen eines Musters.
    Ich weiß,ich wollte die neue Software heute online stellen,aber musste das Verschieben,wegen der Suche des Problems.Morgen kommt sie dann ganz sicher. ;)


    Edit2:
    Habe kleinere Änderungen an der Pinbelegung gemacht,naja eigentlich nur eine.Die Taster kommen statt an PC4 und PC5 an PC2 und PC3.
    PC2 ist für die Programmauswahl zuständig und PC3 für die Modi.
    Das Programm an sich hab ich einfacher strukturiert.Es gibt statt einzelnen Unterprogrammen für Taster,Anzeige und Zeit nur noch ein einziges in dem alles zusammen erledigt wird.

  • hey :)


    kann das sein, dass du die gleiche version wie oben hochgeladen hast?
    wollte das ganze mal nachbauen, aber irgendwie klappts nicht. im code stehen auch noch portc.4 und portc.5 als input. nicht 2 und 3.


    dein beitrag ist zwar schon etwas älter, aber ich hoffe du liest es trotzdem :)


    und diese turi version, ist das das turi board im sammelthread 1zu1?


    danke schonmal!