Farbsteuerung im HSV modell

[Jörn Arne]

Hallo zusammen!

Zurzeit arbeite ich an Dekoleuchten, die rote und gelbe LEDs im Inneren haben, die unabhängig von einem Attiny26 angesteuert werden sollen. Die Leuchten sollen dann ein Spektrum von gelb über orangetöne nach rot wiedergeben.
Das prinzip funkltioniert soweit, ein paar Leuchten sind fertig und die Microcontrollersteuerung befinden sich in der Entwicklung (Die reine ansteuerung der PWM Kanälen arbeitet)

Mein Problem ist jetzt folgendes:
Über 4 tasten sollen die 2 Kanäle getrennt gesteuert werden (2 zum hoch tasten und 2 zum runter tasten, jeweils für rot und gelb) - soweit auch keine Schweirigkeit; einfach den DutyCircle verändern.

Jetzt sollen aber über 2 weitere Tasten die Gesamthelligkeit geregelt werden.
Überlegt habe ich mir, wie ich das wohl am sinnvollsten realisieren könnte.
Und zwar die RBG Werte (wobei blau stets 0) in HSV Werte zu konvertieren und dann die Helligkeit verändern und zurück in den RGB konvertieren und die RGB Werte auf die PWM Kanäle leiten (wobei blau ignoriert wird)
Als Zwischenfrage - was haltet ihr grundsätzlich von dieser Idee? (Den Controller mal ausser acht lassen)
Jetzt wirds problematisch: Die Umrechnung von RGB in HSV und umgekehrt verlangt nach Multiplikation und Division. Also Operationen die mit einem Controller nicht so ohne Subroutinen durchgeführt werden können.
Was haltet ihr davon? Lohnt sich die Mühe diese Umrechnungsroutinen zu schreiben oder gibt es andere schnellere Wege zum Ziel zu gelangen?
es kommt weniger auf exakte Farbwiedergabe an, da es sich nur um Deko handelt.

Ich verwende für die Programmierung das AVR Studio und arbeite in Assembler

Ich hoffe von euch ein paar anregungen und Tips zu bekommen, um zum Ziel zu kommen

Vielen Dank

Gruß
Jörn

[robocat]

ich denke du kommst schneller zum ziel, wenn du die PWM werte für beide farben in gleichem verhältnis absenkst, um abzudunkeln.

zum bleistift orange (250,200,0) -> (125,100,0) -> (62,50,0)....

hier ist eine hsl->rgb funktion, aber man sieht schon, dass das ein haufen rechnerei ist: http://codefactory.dead-men.de/index.php?content=51

gruesse

edit: gut möglich, dass die leds keinen linearen helligkeitsverlauf haben, dann müsste man etwas experimentieren.

[Jörn Arne]

Danke für deine Antwort!

Du meinst also durch teilen oder multiplizieren eines konstanten Faktors?

Sprich pro tatsen druck das Doppelte oder die Hälfte (Wobei man dann immer noch eine * / Subroutine erstellen müsste)

Durch addieren oder subtrahieren von Konstanten würde man schnell zu einer Farbverschiebung kommen, das möchte ich vermeiden

Ich versteh zwar was du meinst, kann aber den Gedankengang nicht ganz zu ende führen. Den Faktor 2 zu verwenden (also immer die hälfte des aktuellen Wertes )würde ja zu einer logarithmischen Steuerung führen
So wie ich das verstehe...


Der Rechenaufwand von HSV - RGB ist mir bekannt. Mit einem PC kein Problem, aber mittels µC ~~~


Gruß
Jörn

[robocat]

sry, das mit faktor 2 war etwas missverständlich. wenn du (obiges beispiel) rot pro knopfdruck um 5 absenkst, würdest du grün um 4 absenken, also (250,200,0)->(245,196,0), so dass insgesamt das verhältnis 250/200 (5/4) erhalten bleibt.

gruesse

edit: das geht mit den hier gewählten werten schön auf, normalerweise wird mit rundungsfehlern zu rechnen sein.

[Jörn Arne]

In der kommenden Woche werde ich noch mal genauer mit deiner Idee beschäftigen, und mich dann melden, sowie ich wieder zugang zum Internet habe.

Gruß
Jörn

[Besserwessi]

In Assembler ist das Umrechnen tatsächlich etwas lästig zu programmieren. Unterprogramme für die Multiplikation und Division gibt es z.B. in den Atmel Appl. Notes. Die Rechenzeit ist allerdings wohl kein Problem.
Eventuell wäre es besser für dieses Projekt Basic oder C zu verwenden, da ist die Umrechnung schnell geschrieben.