Universeller Controller mit ATmega8

  • Edit 02.02.2010: Beitrag 2 mit neuem Programmcode versehen, Vorstellung Platine Version 2 am Ende


    In den letzten Projekten hatte ich immer das Bedürfnis, einen Micro-Controller für die Dimm-Funktion einzusetzen. Ich hatte mir zwar auch einen RGB-Fader und RGB-Controller von LED-Tech zugelegt, jedoch erfüllten die Programme nicht direkt meine Anforderungen. Eine davon war, dass ich zwei Kanäle (warmweiß / kaltweiß) unabhängig voneinander regeln wollte. Die Regelung sollte einerseits mit einer Fernbedienung möglich sein, andererseits mit einem Poti.



    Hier ist das Ergebnis zu sehen. Im Versuchsaufbau sind die beiden Potis für je eine LED, zwei KSQ mit CAT4101 sowie die (teil-)bestückte Controller-Platine zu sehen.



    Der Controller wurde dabei so gestaltet, dass er noch einigermaßen flexibel angepasst werden kann. Hier mal ein paar Möglichkeiten:
    · Bis zu 3 PWM-Kanäle, Ausgang entweder direkt oder über MOSFET
    · Bis zu 4 Potis anschließbar (ADC-Eingänge)
    · Wahlweise Bestückung der Eingänge mit Tastern (kein Interrupt!)
    · Bedienung über handelsübliche RC5-Geräte möglich
    · Programmierung über Wannenstecker
    Das Ganze ist nicht so spektakulär. Wichtig war mir die Anschlussmöglichkeit der Potis. Da ich mehrere dieser Controller verbaut habe bzw. noch werde, habe ich mir Platinen fertigen lassen. Die ersten hatte ich noch von Hand belichtet und geätzt, aber da es mehr wurde … Deshalb ist das Layout auch einseitig erstellt (eine Brücke).



    Die Anschlüsse sind über Stiftleisten nach Außen geführt. Bei fester Installation kann man natürlich auch direkt anlöten.



    Entscheidend bei so einem Controller ist immer die Software. Hier habe ich inzwischen einige verschiedene Programme erstellt. Gerade für die Fernbedienung habe ich auf fertige Bibliotheken zurückgegriffen, was die Entwicklung sehr einfach gemacht hat. Allerdings bin ich von Bascom weg zu C gegangen, um bei Nutzung der Fernbedienung keine Verzögerungen zu haben (zumindest hat noch keiner das plausibel in Bascom gelöst).


    Das erste Programm arbeitet in meiner indirekten Beleuchtung hinter dem Bett. Dabei bedient der Controller nur zwei Potis, welche zur Dimmung dienen. Beide können unabhängig voneinander geregelt werden. Das letzte Poti „gewinnt“.


    In einem zweiten Schritt kam die Fernbedienbarkeit hinzu. Dieses Programm wird in einer ähnlichen Leiste wie meiner Bettbeleuchtung verwendet. Eine leicht abgewandelte Form mit zwei getrennten PWM-Kanälen kommt demnächst in der Stehlampe zum Einsatz.


    Schließlich gibt es noch ein Programm, bei dem mit 3 Potis die 3 RGB-Farben getrennt eingestellt werden können (auch per Fernbedienung).


    Orca hatte hier im Forum den Wunsch, die RGB-Farben in der Helligkeit bei Farbtreue zu dimmen. Dies habe ich experimentell schon mal aufgebaut. Allerdings stößt man da teilweise an technische Grenzen. Aber die Ergebnisse waren z.T. besser als erwartet. Wenn ich z.B. einen gelben Farbton einstelle, kann ich die Helligkeit dessen sehr gut dimmen. Es hängt eben immer von der jeweiligen Farbzusammensetzung ab und davon, wie die Dimm-Strategie im Programm arbeitet.


    Für Interessierte gibt es hier noch die Schaltung und das Board, auf Wunsch auch als Eagle-Datei. Bei Bedarf könnte ich ein paar einzelne Platinen abgeben.


    ControllerPotiFBv39.zip

  • Noch ein paar Erläuterungen zum Programmcode. Wie schon erwähnt, habe ich verschieden Komponenten verwendet. Die betrifft einerseits die Verwendung der Fernbedienung, andererseits auch die PWM-Regelung.


    Die Fernbedienungskomponenten stammen von Georg-Johann Lay und sind in den Dateien rc5.* zu finden. Sie werden im Hauptprogramm einfach angesprochen.


    Weiterhin habe ich die PWM-Regelung aus dem LED-Fading-Testprogramm von www.mikrocontroller.net verwendet. Dabei werden PWM-Tabellen aufgebaut, die dem Empfinden des menschlichen Auges näher kommen als eine lineare Regelung. Die Routinen habe ich für meine Zwecke leicht angepasst.


    Auch die ADC-Regelung stammt aus dem Tutorial von mikrocontroller.net. Mit der Funktion kann man auch einfache Weise einen analogen Wert eines Potis einlesen.


    Das Ganze zusammen gepackt ergibt die Software des Controllers. Es gibt sicher noch eine Reihe weiterer Möglichkeiten, die ich bisher (mangels Anwendung) noch nicht umgesetzt habe, z.B. ein Fading-Programm, die Verwendung von Tastern für Programmumschaltung oder auch ein Poti, um mehrere Programme umzuschalten oder die Fading-Geschwindigkeit zu regeln. Ich denke einfach, dass man für viele Anwendungen mit Potis eine bessere Eingabe-Schnittstelle hat als mit Tastern.


    Für jegliche Anregungen bin ich dankbar.


    Programm V2: ein PWM-Kanal, der über 2 Potis gesteuert wird; Fernbedienung RC5
    RC5_v2_20090611_1PWM2PotFB.zip


    Programm V4: drei PWM-Kanäle, jeder Kanal wird über ein Poti gesteuert; Fernbedienung RC5
    RC5_v4_20090622_3PWM3PotFB.zip


    Programm V22: 2 PWM-Kanäle, Steuerung über ein Poti und Fernbedienung möglich (Stehlampen-Projekt)
    RC5_v22_20090706Stehlampe.zip


    Programm v41: drei PWM-Kanäle + Helligkeit entweder per RGB oder HSB geregelt (und Fernbedienung)
    RC5_V41_RGB-HSB20090714.ZIP


    Programm v43: drei PWM-Kanäle + Helligkeit entweder per RGB oder HSB geregelt (und Fernbedienung), RGB/HSB-Fading
    RC5_v43_20090920.zip


    Programm v51: drei PWM-Kanäle + Helligkeit entweder per RGB oder HSB geregelt (und Fernbedienung), RGB/HSB-Fading, 16x2 LCD-Display
    RC5_v51_20100131.zip


    Programm v52: verbesserte Version von v51
    RC5_v52LCD_20100316.zip

  • Orca hatte hier im Forum den Wunsch, die RGB-Farben in der Helligkeit bei Farbtreue zu dimmen. Dies habe ich experimentell schon mal aufgebaut. Allerdings stößt man da teilweise an technische Grenzen. Aber die Ergebnisse waren z.T. besser als erwartet. Wenn ich z.B. einen gelben Farbton einstelle, kann ich die Helligkeit dessen sehr gut dimmen. Es hängt eben immer von der jeweiligen Farbzusammensetzung ab und davon, wie die Dimm-Strategie im Programm arbeitet.


    Hallo,


    hört sich gut an.
    Ich habe mir zur oberen Problematik auch schon zwei drei Gedanken gemacht. Ich kam nur zum Ergebniss das prozentuall zu dimmen(runterzu fahren) , hatte es noch nie programmiert. Fänd es toll wenn du vielleicht über das Thema noch paar Wörter verlieren könntest, da hab ich sehr großes interesse dran.


    MfG

  • Es gibt wie gesagt beim farbechten Dimmen technische Grenzen. Wenn z.B. die Farbe sich aus den Prozentwerten 80/60/10 zusammen setzt, kann man nur so lange einigermaßen farbgetreu dimmen, bis eine Farbe auf Null geht. Danach sind Kompromisse notwendig.


    Auch gibt es einen Unterschied im Verringern und Erhöhen der Helligkeit. Das Erhöhen stellt noch größere Anforderungen, da ja das Verhältnis der Anteile untereinander beibehalten werden muss. Das ist zwar prinzipiell beim Verringern auch so, jedoch kann man da einfachen jeden Wert um einen absoluten Betrag verringern. Komplizierter wird es noch, wenn ein Wert auf Null steht. Da muss ich dann beim Erhöhen wissen, ab wann die Farbe zugemischt werden kann.


    Hier muss ich nochmal experimentieren...

  • Es gibt wie gesagt beim farbechten Dimmen technische Grenzen. Wenn z.B. die Farbe sich aus den Prozentwerten 80/60/10 zusammen setzt, kann man nur so lange einigermaßen farbgetreu dimmen, bis eine Farbe auf Null geht.

    Ich hätte mir das so vorgestellt, dass man eine Farbe mit den 3 Kanälen(PWMs) einstellt und dann eine PWM vor die 3 Kanäle hängt und mit der dann dimmt. Allerdings habe ich keine Ahnung wie sich PWMs in Serie verhalten und ob das überhaupt möglich ist. Jedenfalls wäre es in diesem Fall auch egal, wie viele Schritte bis Null die jeweilige Farbe noch hat.
    Ich hoffe ihr könnt verstehen wie ich das meine!?


    lg
    Simon

  • Hallo Simon,


    ich befürchte, so wie Du Dir das vorstellst, geht es nicht. PWM heißt ja Pulsweitenmodulation, also über die Breite des Impulses wird die scheinbare Helligkeit der LED gesteuert. Sie ist also immer voll an, nur nicht die gesamte Zeit durchweg. Das Auge empfindet das als gedimmt. Genauso werden die Farben gemischt. Ich kann jetzt nicht wie z.B. bei einem Mischpult hingehen und nochmal PWM darüber jagen. Ich kann nur die Ein-Phasen weiter verkürzen.


    Ich habe oben die Software ergänzt. V4 stellt dabei den Ansatz und ersten Versuch, die Helligkeit möglichst farbecht zu dimmen. Da es aber nicht so wie gewünscht funktionierte, habe ich es nochmal auskommentiert. Ich habe, wenn ich es richtig verstanden habe, heute im DMX-Thread einen Lösungsansatz gesehen, der mir in ähnlicher Form vorschwebte. Man merkt sich die Einstellung der Anteile der 3 Farben und multipliziert dies mit einem Faktor (z.B. zwischen 0 und 1), der über das "Helligkeits-Poti" eingestellt ist. Damit bleibt das Verhältnis der Farben untereinander weitgehend gleich. Das werde ich noch testen. Bin aber diese Woche fast nur unterwegs, wird also Wochenende...


    Vielleicht kann Pesi mal sagen, ob das vom Prinzip her funktioniert.


    Nino

  • Ja, so funktioniert das ;)


    Die Farbe hängt ja vom *Verhältnis* der drei Grundfarben ab, dieses muss gleich bleiben - sehe ich das richtig, dass bei Dir, wenn Du z.B. diese 80/60/10 um 10 runterdimmst dass dann 70/50/0 rauskommt...? - und wenn's noch mal um 10 runtergedimmt wird, dann 60/40/0....? - dann kann das nicht funktionieren, weil Du ja das Verhältnis der Farben untereinander änderst.


    Bei mir werden die Grundfarben mit dem Dimmer-Wert multipliziert - dabei bleibt das Verhältnis gleich, da R:G:B mal Dimmer = R mal Dimmer : G mal Dimmer : B mal Dimmer - dabei gehen sowohl die Farben wie der Dimmer-Wert jeweils von 0 - 255, weil der µC direkt damit rechnen kann - für den Dimmer (was Du als "Faktor" bezeichnest) 0-1 zu nehmen, wäre eher ungeschickt/unmöglich, weil der µC ja nur mit ganzen Zahlen rechnen kann (direkt, intern, k.A. ob's in C auch Fließkomma-Rechnungen gibt, aber die werden wenn dann auch nur irgendwie emuliert und sind eher ungenau...)


    da hier (bei mir) dann Werte bis 65.025 (255 x 255) rauskommen, wird anschließend wieder durch 255 geteilt (EDIT: OK, damit kommt das unterm Strich auf's selbe raus, wie wenn ich die Kanäle mit einem Wert zwischen 0 und 1 multiplizieren würde ;)), damit ich wieder auf 0-255 pro Kanal (8-Bit-PWM) komme... (also die PWM-Werte, 255 = 100%) - wenn man 16-Bit-PWM nehmen würde, könnte man diese Werte direkt benutzen, hätte dann auch ne höhere Auflösung... bei mir wird's halt schon etwas arg abgestuft, wenn sowohl Dimmer als auch Farbwert sehr niedrig sind...


    *ganz exakt* funktioniert das auch nicht, da ich aus programmiertechnischen Gründen durch 256 teile, ausserdem gibt's ja Rundungsfehler, z.B. wenn Blau den Wert 2 hat und auf 2 gedimmt wird, dann kommt 0 dabei raus, ebenso wie wenn es 2 hat und auf 120 gedimmt ist - also z.B. die Farbe 255/255/2 (gelb mit klitzekleinem Blau-Anteil) auf 25% (64) gedimmt ergibt 63/63/0, also gelb ganz ohne Blau - nur, 2 Blau bei 255 rot und grün fällt eh' unter den Tisch...


    schwieriger ist das bei Dir, weil Du die PWM mit Helligkeitskorrektur benutzt - die ist ja *pro Kanal* und haut Dir damit die Verhältnisse auch wieder durcheinander - musst Du mal ausprobieren, wie stark sich das auswirkt - wenn der Effekt zu krass ist, dann müsste man die Korrektur nur auf den Helligkeitskanal anwenden, und anschließend die korrigierte Helligkeit mit den Farbkanälen verrechnen, diese dann ohne Korrektur ausgeben...


    aber so (multiplizieren) wird's auf jeden Fall schon mal *wesentlich* besser, als nur die einzelnen Kanäle jeweils um den selben (EDIT: Absolut-)Wert rauf- und runterzudrehen...


    Nochmal EDIT: aber schönes Gerät übrigens! :thumbup: - und da stimme ich Dir zu, für sowas (Helligkeit rauf- und runterstellen etc.) sind Potis echt schöner als Taster - ich baue (nebenbei, neben x anderen Baustellen) auch so nen kleinen RGB-Controller, da aber mit Encoder statt Poti... jedenfalls halt auch zum drehen statt drücken...

    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!

    3 Mal editiert, zuletzt von Pesi ()

  • Jo, Danke Pesi. Das hatte ich schon bemerkt, dass es nach meinem ersten Verfahren nicht richtig funktioniert. Herunterdimmen ging gerade noch, aber beim hochdimmen kamen immer alle Farben im gleichen Verhältnis mit, egal wie es vorher war. Das Ende war immer weiß ...


    Das mit der Berechnung ist ein guter Hinweis. Hab mir zwar nicht angesehen, ob es Fließkomma-Typen gibt. Aber in C wäre das halt so schön einfach. Nur muss dann wirklich der Prozessor die Arbeit machen. Das werde wie wie von Dir vorgeschlagen machen. Bin nur noch am überlegen, ob das mit der PWM-Tabelle bei der RGB-Steuerung so günstig ist. Ich kann ja noch auf mehr als 64 Stufen hoch gehen. Aber die Korrektur ist bei RGB doch wohl unsinn, oder?


    Ich hatte es bisher immer nur mit weißen LEDs zu tun, deren Helligkeit geregelt wurde. Da war das sinnvoll.


    Na dann an die Arbeit. ;)

  • nee, nee, denn kenn ich schon ;) - hier geht's (zumindest vom Ansatz her) um was anderes: eine eingestellte Farbe (hier in RGB) *nochmals* in der Helligkeit *extra* zu dimmen, und das geht nur mit einem 4. ("Dimmer")-Kanal, mit dem man diese Werte multipliziert. So wie bei meinem DMX-Receiver auch.


    Da hat das einen bestimmten Grund, dass da (bei mir) nochmal ein extra Dimmer-Kanal dabei ist (den man ja "eigentlich" nicht braucht): Es erleichtert wesentlich die Programmierung einer Lightshow - ich kann z.B. ein Bild erstellen mit 4 Leuchten nebeneinander, die erste hat 25% Blau, die 2. 50%, die 3. 75% und die 4. 100% - nun kann ich mit einem 4. Kanal (Gesamtdimmer) dieses komplette "Bild" heller und dunkler machen - oder es läuft ein Rainbow-Fader synchron auf allen 4 Leuchten, es sind aber nicht alle immer an, sondern "springen" hin und her - da mache ich einen Fader, der die Farbkanäle für alle Leuchten synchron ändert, und ein 2. Programm ändert die Dimmerkanäle so, dass die Leuchten an- und ausgehen - unabhängig voneinander... wenn alle 4 leuchten sollen, ziehe ich bei allen 4 den Dimmer-Kanal hoch, aber das Programm, das die Farben steuert, bleibt das selbe...


    mit HSV würde das nicht gehen, ausser man macht da auch einen 4. Kanal, den man dann nur mit V verrechnet... das wäre dann "das selbe in grün"


    Aber, Stefan, das war ein guter Hinweis mit dem Farbraum, weil das wäre für Dich, Turi, eigentlich besser geeignet - Du willst ja keine Lightshow programmieren, sondern eine Farbe und deren Helligkeit einstellen - und da ist HSV wesentlich intuitiver (wohl auch ein Grund, dass dieses Philipps-Teil recht beliebt ist): Du stellst einen Farbton ein (z.B. Orange) und den dann in der Sättigung (von "kräftig" über Pastell bis weiß) und in der Helligkeit - das ist viel besser, als mit RGB rumzumachen ("welche RGB-Werte hat gleich noch mal Flieder"..?) - und ausserdem brauchst Du nur 3 Potis (Farbton, Sättigung, Helligkeit) statt 4 (RGB + Dimmer)...


    Schau' Dir doch das vom Stefan mal an - das sollte sich auch in C umsetzen lassen - im wesentlichen sind das auch nur Multiplikationen und Divisionen, womit HSV letztlich wieder in RGB umgerechnet wird... Die Formeln dazu gibt's auch bei Wikipedia...


    Ansonsten: Auch in C geht das ganz einfach und macht Sinn, erst mal zu multiplizieren und dann wieder zu teilen, weil's der Prozessor intern dann auch so macht - also auch, wenn man in C mit Kommazahlen (z.B. einen Wert mit 0,7 multiplizieren) rechnen kann/könnte (weiß nicht, ob das geht...?), der Prozessor selbst kann das nicht, also wird das dann letztlich auch wieder so umgesetzt.....


    Und, richtig, die Korrektur macht bei RGB oder HSV nicht so viel Sinn, wie bei einer weißen LED rauf- und runterdimmen - wie gesagt, bei HSV könnte man diese Korrektur dann im Helligkeitskanal anwenden - Prinzip hast Du ja verstanden: Du bekommst einen Wert vom Poti, schaust dann in der Tabelle nach, da kommt dann ein Helligkeitswert raus, den Du für Deine HSV-in-RGB-Umechnung benutzt...


    EDIT: ach, übrigens, Orca, das mit dem 2 PWMs überlagern würde schon auch gehen, da muss halt nur eine davon eine wesentlich höhere Frequenz als die andere haben - also theoretisch, bei nem AVR auf drei Ausgängen die RGB-Werte mit 244 Hz SW-PWM ausgeben, und auf einem HW-PWM-Kanal die Helligkeit mit 64 kHz, das Ganze mit nem AND-Glied verknüpft, dann werden die "an"-Phasen der Farben nochmal in 256 Stufen "zerhackt" und damit nochmals gedimmt... kommt dann unterm Strich von der Auflösung her auch auf das selbe raus wie ne 16-Bit-PWM - aber ist EMV-technisch usw. nicht mehr so einfach, mit 64 kHz...

    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!

    Einmal editiert, zuletzt von Pesi ()

  • Hach, ich propagiere ja schon seit je her den HSB-Farbraum (resp. HSV-Farbraum) ;) .


    Ich habe mir mal die Mühe gemacht, einen C-Code für die Umrechnung hier zu posten, und zwar so, dass nur maximal 16-Bit-Integer (signed oder unsigned) verwendet werden, und dass keine Divisionen durchgeführt werden (Divisionen werden durch Right-Shifts ersetzt). Wenn der C-Compiler auch noch optimiert, dann ersetzt er einen 8-fachen Right-Shift im resultierenden Assembler-Code sogar noch dadurch, dass er einfach nur das High-Byte der entsprechenden Variable weiter verwendet. Ganzzahl-Multiplikationen sind bei den Mega-AVRs grundsätzlich sehr schnell in der Verarbeitung, da hier eine Hardware-Implementation vorhanden ist. Für den Hue-Wert (Farbkreis) ist jeweils mit dem angegebenen Wertebereich zu arbeiten, da sonst in der Umwandlungsfunktion zusätzliche Faktor-Berücksichtigungen nötig sind. Wenn ein Hue-Wertebereich von 0 - 255 gewünscht ist, sollte man den hue-Wert dann vor der Umwandlungsfunktion entsprechend mit 6 (Fall 1) oder mit 3 (Fall 2) multiplizieren, das ist auf jeden Fall zeitsparender.


    Fall 1: Hier ist die klassische Umwandlung.
    hue (Farbkreis) = 0 bis 1529, sat (Sättigung) = 0 bis 255, bri (Helligkeit) = 0 bis 255; alle Variablen unsigned int (word).


    Fall 2: Hier ist die Umwandlung auf möglichst gleichbleibende Lichtemissionsleistung (mW, nicht Lumen) der Farben normalisiert (Die Summe der RGB-Werte darf max. 255 betragen). Diese Umwandlung verwende ich bei meinen RGB-Wall-Modulen, vor allem um Gesamtstrom zu sparen, aber auch das allgemeine Erscheinungsbild der Animationen scheint mir dadurch homogener zu wirken. Der Preis ist aber eine verringerte Anzahl der theoretisch maximal darstellbarer Farben, und zwar ca. 85^3 + 127^2 + 256 = 630'510, und eine leicht verlängerte Berechnungsdauer. Bei Einzel-RGB-Lichtquellen (oder generell wenigen nicht flächig angeordneten Lichtquellen) ist es aber nicht unbedingt von Vorteil, dieses Verfahren zu verwenden.
    hue = 0 bis 764, sat = 0 bis 128, bri = 0 bis 255; alle Variablen signed int (signed ist hier wichtig).


    Für beide Fälle gelten die gleichen Formeln für die Berücksichtigung des bri-Wertes (Brightness; Helligkeit). Der bri-Wert könnte natürlich noch vor der Applikation in den Formeln aus einer Exponentialtabelle (zur linearisierung des Helligkeitsempfindens) herausgelesen werden, wenn man das will.

    Code
    1. red = ((bri + 1) * red_val) >> 8;
    2. green = ((bri + 1) * green_val) >> 8;
    3. blue = ((bri + 1) * blue_val) >> 8;


    Ich hoffe, das alles nützt jemandem was ;) .


    Gruss
    Neni

  • Sehr schön, Neni macht's wieder sehr ausführlich!


    die letzte Berechnung ist ja dann die selbe wie von mir oben erläutert, die RGB-Werte mit der Helligkeit verrechnet, damit man diese noch gesamt beeinflussen kann - OK, Du addierst zuerst noch 1 zur Helligkeit dazu, das könnte ich eigentlich auch mal machen, um wieder auf 0 - 255 zu kommen (bei mir ja nur 0 - 254)


    also im Endeffekt dimmst Du dann genauso wie ich die Gesamthelligkeit per Multiplikation der RGB-Werte mit dem Helligkeitswert, hier kommt halt *davor* noch die Umrechnung von HSB in RGB...

    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!

  • ... Bei meiner RGB-Wall-Plasma-Software ist Fliesskomma erforderlich, da ich trigonometrische und andere, komplexe Berechnungen benötige, ...

    Zumindest die trigonometrischen Funktionen bekommt man aber auch mit Ganzzahlen und einer Tabelle hin. Das braucht sogar weniger Speicher, weil Tabelle und Code kleiner ist, als die entsprechenden Fließkommafunktionen.

  • Ja klar, aber die Spannweite der Zahlen in den Zwischenresultaten der verwendeten Formeln sind relativ gross, so dass sich Fliesskomma geradezu aufdrängt. Ausserdem wollte ich das Rad nicht neu erfinden bzw. irgendwelche eigenen Implementationen 'ausprobieren', wenn ja sowohl in BASCOM als auch in den gängigen C-Compilern für AVR entsprechende, gut funktionierende Fliesskomma-Libraries vorhanden sind, wärend Ganzzahl-Implementationen von Trig-Funktionen und anderen zumindest standardmässig nicht vorhanden sind. Und nicht zuletzt war eben für meinen Anwendungsfall (gewünschte Frame-Rate) die Geschwindigkeit der Berechnungen pro Frame mehr als ausreichend (auch wenn ein Sinus so um die 2000 Taktzyklen benötigt), so dass sich jegliche Gedankenspiele von Spezialimplementationen erübrigten. Hätte es nicht gereicht, hätte ich andere Wege gesucht.


    Aber eigentlich ist das ja OT in diesem Thread.


    Gruss
    Neni

  • also im Endeffekt dimmst Du dann genauso wie ich die Gesamthelligkeit per Multiplikation der RGB-Werte mit dem Helligkeitswert, hier kommt halt *davor* noch die Umrechnung von HSB in RGB...


    Ja genau, bzw. wird eben vorher HS (ohne B bzw. bei B = 255) in RGB und danach noch B in RGB gewandelt. Das hat sich als code-sparender und schneller erwiesen, als B auch noch in die Formeln in der If-Kette einzubeziehen.


    Gruss
    Neni

  • So, ich habe es jetzt auch geschafft, die Steuerung der Helligkeit bei konstanter Farbe in Software zu realisieren, dank der Anregungen. Ich hätte nicht gedacht, dass das so gut funktioniert.


    Dabei finde ich die HSB-Regelung auch einfacher, als eine Farbe per RGB einzustellen. Das Programm habe ich derzeit nur in einer Rohfassung da, aber wenn es fertig ist, wird es natürlich veröffentlicht.

  • Ich muss unsere Experten nochmal bitten, über den Quellcode zu schauen. Habe nochmal einiges optimiert und dokumentiert und auch die Routinen der Fernbedienung wieder aktiviert. Wie ich schon oben mal beschrieben habe, ist die Regelung per HSB deutlich einfacher als die RGB-Variante. Wie mir noch aufgefallen ist, ist auch die Konstanz der Farbe deutlich besser als bei RGB. Das kann und wird aber noch mit meiner log. Tabelle zusammen hängen. Die werde ich hier sicher rauswerfen müssen.


    Ich habe mit der HSB-Regelung allerdings noch kleine Probleme. Ich habe die Variante 2 verwendet. Wenn ich die Farben einstelle (Hue) laufen diese von blau bis rot und dann aber wieder weiter und wie ein kleiner Sprung zu blau. Stimmt da villeicht mit den Wertebereichen bzw. meiner Umrechnung etwas nicht? Ist es vielleicht besser, alles komplett auf 8-Bit-PWM umzustellen und die Werte direkt zu verwenden? Spart ein wenig rechnerei, bis auf die Umrechnung der ADC-Werte.


    Ich habe hier 3 verschiedene Programmvarianten drin (wird über FB umgeschaltet):
    0 - Standard RGB mit Helligkeitsregelung
    6 - HSB mit Helligkeitsregelung
    9 - RGB ohne Helligkeitsregelung


    Ein Teil des Codes habe ich doch mal hier reingesetzt. Der vollständige Code ist im Anhang enthalten und wird, wenn er richtig funktioniert, auch offiziell veröffentlicht.


    RC5_v4RGB-HSB.zip