RGB Rainbow Farbwechsler mit ATMEGA168/88/48 und BASCOM-AVR

[synvox]

Hallöchen,

ich habe mal eine kleine Demo gemacht, wie man die Hardware-PWM-Funktionen der drei Timer/Counter eines ATMEGA168/88/48 (hier ist ein 168 verwendet worden, der Code geht aber auch mit einem 88 oder 48 ). Diese drei Microcontroller haben alle drei Timer/Counter, welche je zwei unabhängige PWM-Kanäle steuern können, d.h. bis zu sechs PWM-Kanäle pro Microcontroller.

Der Chip läuft bei mir auf internen 8MHz und die PWM-Frequenz beträgt je Kanal ca. 245Hz, wobei jeweils immer zwei Kanäle auf der gleichen PWM-Frequenz laufen müssen, da sie sich einen Timer/Counter teilen, das Tastverhältnis ist aber unabhängig.

Für diese Demo habe ich eine Superflux-RGB-LED direkt an den Chip angeschlossen, d.h. jede Farbkathode über einen entsprechenden Widerstand direkt an den entsprechenden (von mir so gewählten) Output Compare Register (OCR) Pin des Microcontrollers, die gemeinsame Anode der LED direkt an +5V.

Ich habe hier einen spezielle Farbkodierung (Hue; Position im Farbkreis) für das Durchlaufen der Farben gewählt, da ich damit die Regenbogen-Farbinformation in nur einem Byte speichern kann (benötige ich für ein spezielles, späteres Projekt), aber man könnte natürlich auch direkt mit den RGB-Werten spielen (der Hue wird bei mir sowieso in RGB umgewandelt, bevor er in die Compare Register geschrieben wird).

Ein Video vom Ferbverlauf befindet sich hier, live sieht's aber viel besser aus, ad der Helligkeitsabgleich meines Handys stört. Man sieht jedoch auch so, dass der Verlauf recht sanft vonstatten geht (dank Hardware-PWM), obwohl nur 42 diskrete Werte pro Farbkanal enthalten sind (Hue/Farbkreis aufgeteilt in 252 Werte).

Der Code der ganzen Spielerei in BASCOM-AVR Basic:

Code: Alles auswählen

' pwm_led_cc1.bas by Neni
' Shows usage of Hardware-PWM for LED Color Change Applications
' Works on ATMEGA168, ATMEGA88, ATMEGA48
' Frequency: 8MHz internal RC (remember to disable CKDIV8 fuse bit)
' OCR PWM Generation is set to the Inverted Mode because the LED Cathodes
' are directly connected to the OCR Pins
' Copyright: Neni (neni@synvox.ch)

$regfile = "m168def.dat"
$crystal = 8000000
$hwstack = 64
$swstack = 64
$framesize = 64

Red_pwm1 Alias Ocr0a
Red_pwm2 Alias Ocr0b
Green_pwm1 Alias Ocr1al
Green_pwm2 Alias Ocr1bl
Blue_pwm1 Alias Ocr2a
Blue_pwm2 Alias Ocr2b

Dim I As Byte

Declare Sub Color_set1(byval Hue As Byte)

' Input/Output Ports initialization
' Port B initialization
' Func7=In Func6=In Func5=In Func4=In Func3=Out Func2=Out Func1=Out Func0=In
' State7=P State6=P State5=P State4=P State3=1 State2=1 State1=1 State0=P
Portb = &HFF
Ddrb = &H0E

' Port C initialization
' Func6=In Func5=In Func4=In Func3=In Func2=In Func1=In Func0=In
' State6=P State5=P State4=P State3=P State2=P State1=P State0=P
Portc = &HFF
Ddrc = &H00

' Port D initialization
' Func7=In Func6=Out Func5=Out Func4=In Func3=Out Func2=In Func1=In Func0=In
' State7=P State6=1 State5=1 State4=P State3=1 State2=P State1=P State0=P
Portd = &HFF
Ddrd = &H68

' Timer/Counter 0 initialization
' Clock source: System Clock
' Clock value: 125.000 kHz -> PWM-Freq ca. 245Hz
' Mode: Phase correct PWM top=FFh
' OC0A output: Inverted PWM
' OC0B output: Inverted PWM
Tccr0a = &HF1
Tccr0b = &H03
Tcnt0 = &H00
Ocr0a = &H00
Ocr0b = &H00

' Timer/Counter 1 initialization
' Clock source: System Clock
' Clock value: 125.000 kHz -> PWM-Freq ca. 245Hz
' Mode: Ph. correct PWM top=00FFh
' OC1A output: Inverted
' OC1B output: Inverted
' Noise Canceler: Off
' Input Capture on Falling Edge
' Timer 1 Overflow Interrupt: Off
' Input Capture Interrupt: Off
' Compare A Match Interrupt: Off
' Compare B Match Interrupt: Off
Tccr1a = &HF1
Tccr1b = &H03
Tcnt1h = &H00
Tcnt1l = &H00
Icr1h = &H00
Icr1l = &H00
Ocr1ah = &H00
Ocr1al = &H00
Ocr1bh = &H00
Ocr1bl = &H00

' Timer/Counter 2 initialization
' Clock source: System Clock
' Clock value: 125.000 kHz -> PWM-Freq ca. 245Hz
' Mode: Phase correct PWM top=FFh
' OC2A output: Inverted PWM
' OC2B output: Inverted PWM
Assr = &H00
Tccr2a = &HF1
Tccr2b = &H04
Tcnt2 = &H00
Ocr2a = &H00
Ocr2b = &H00


Do

   For I = 0 To 251
      Call Color_set1(i)
      Waitms 100
   Next I

Loop

Sub Color_set1(byval Hue As Byte)
   If Hue < 42 Then
      Red_pwm1 = 251
      Green_pwm1 = Hue * 6
      Blue_pwm1 = 0
   Elseif Hue < 84 Then
      Hue = 84 - Hue
      Red_pwm1 = Hue * 6
      Green_pwm1 = 251
      Blue_pwm1 = 0
   Elseif Hue < 126 Then
      Hue = Hue - 84
      Red_pwm1 = 0
      Green_pwm1 = 251
      Blue_pwm1 = Hue * 6
   Elseif Hue < 168 Then
      Hue = 168 - Hue
      Red_pwm1 = 0
      Green_pwm1 = Hue * 6
      Blue_pwm1 = 251
   Elseif Hue < 210 Then
      Hue = Hue - 168
      Red_pwm1 = Hue * 6
      Green_pwm1 = 0
      Blue_pwm1 = 251
   Else
      Hue = 252 - Hue
      Red_pwm1 = 251
      Green_pwm1 = 0
      Blue_pwm1 = Hue * 6
   End If
End Sub

Vielleich kann's ja auch noch jemand anders von Nutzen sein .

Grüsse aus der Schweiz
Neni

[tho_weiss]

schöne sache das...

aber wie kommt man denn nur mit nur dem hue-wert auf weiss??

Wenn ich die vollen 360° einsetze müsste die farbauflösung doch noch höher werden - oder??

gruß,
thorsten.

[root]

Was ich nicht so ganz verstehe wieso du umbedingt die Hardware PWM verwendest, mit einer Software PWM schafft man das gleiche und braucht nur noch einen Timer.

Der Ablauf dabei wäre dann folgender:

Jedes mal wenn der Timer überläuft wird eine Variabel (nennen wir sie mal pwm_global) um 1 erhöht, jetzt hast du für jeden Kanal auf dem du ein PWM Signal ausgeben willst wieder eine Variabel in der der entsprechende/gewünschte PWM Wert gespeichert ist, z.B. Output 1 soll auf 50% laufen, bei einer Auslösung von 8Bit würde dies dem Wert 127 entsprechenen. Jetzt wird immer der Wert von pwm_global mit dem in Output verglichen, ist pwm_global >= Output1, dann wird der entsprechende Pin auf High gezogen und eben solange gehalten bis diese Bedinung nicht mehr erflüllt ist, sprich, wenn pwm_global den Wert 255 erreicht und dann wieder von vorne mit dem zählen anfängt.

Aber sicherlich so wie du es gemacht hast geht es auch. Sollte nur ein kleiner Tipp auch evtl. an andere sein, die evtl. nicht so viele Hardware PWM bzw. Timer haben.

[tho_weiss]

Der Vorteil von HW-Pwm ist ja das die PWM völlig unabhängig vom restlichen programm-gedöns läuft.

Wenn bei SW-PWM noch eine menge anderer Funktionen eingebaut werden wie z.B. RS485-Bus, IR-Fernbedienung, Sound-to-light, aufwendige Programme, dann muss mann mit SW-PWM ganz schön trixen damit es keine aussetzer gibt.

Von Daher...

Ich werde mal wieder mehr mit AVR's machen - bin gerade auf den geschmack gekommen.


Mir schwebt da ein Busfähiger 4-Kanal PWM RGBW Kontroller vor, sowas Ähnliches wie der Chromoflex, allerdings mit 4-Kanälen RGB + Weiss.

Na mal schauen, erstmal muss ich meinen Springbrunnen illuminieren, dann evtl die Gartenhütte (sieht bestimmt gut aus in RGBW

[synvox]

Richtig, wenn man mehrere PWM-Kanäle jitter-frei steuern möchte, gleichzeitig zum Beispiel per I2C auf Programmwechsel, Programm-Übertragungen, Speichern ins EEPROM etc. reagieren/realisieren muss, alles noch Interrupt-gesteuert wohlgemerkt (wegen der für den Benutzer wünschenswerten 'Echtzeitigkeit'), kommt NUR eine Hardware-PWM-Lösung in Frage, ansonsten hat man eben unschönes Blinkern, Farbsprünge etc.

Zugegeben, die einfache Rainbow-Effekt-Steuerung für sich allein könnte man auch ohne HW-PWM realisieren, aber ich hab dieses kleine Programm ja hier gerade zu Demozwecken reingestellt, wenn man eben mal was Grösseres realisieren will (z.Bsp. nächstes Projekt ).

Weiss bekommt man übrigens nur, wenn man in der Umrechnung noch ein Byte für den Sättigungswert mit einbezieht, dann gäbe es wenn man will auch noch ein Byte für die Helligkeit, und dann hätte man die volle HSV nach RGB Umrechnung, würde aber nichts mehr einsparen gegnüber RGB.
Man kann den Farbkreis (Hue) natürlich auch fast beliebig fein abstufen, also auch in 360, 3600, oder gar 36000 Schritte (der Farbkreis selbst ist ja nicht diskret, man kann auch auf Bruchteile von Grad fein gehen), für mein künftiges Projekt ist es aber wegen EEPROM-Platz etc. wichtig, für die gespeicherten Farbpunkte von Ablaufprogrammen 'nur' jeweils ein Byte zu verwenden, deshalb der Wert 252 (der höchste noch durch 6 teilbare Wert im Werteraum 0 bis 255). Ausserdem habe ich die Feststellung gemacht, dass das Auge besonders bei den LED-Farben/-Helligkeiten nur begrenzt die Abstufungen wahrnehmen kann. 42 Stufen pro Farbe sind meiner Erfahrung nach ein durchaus guter Kompromiss zwischen Speicherschonung und Stufenwahrnehmung.

Gruss
Neni

[dedicated]

Hi

super Arbeit die HardwarePWM.


Habe einige Anfängerfragen:

1. Du deklarierst 6PWM-Kanäle (Ocr0a Ocr0b Ocr1al Ocr1bl Ocr2a Ocr2b ) mit Variablen.

Aber du benutzt in deinem Programm nur die Ocr0a Ocr1al Ocr2a bzw. die Variablen Red_pwm1 Green_pwm1
Blue_pwm1, der Rest bleibt ungenutzt oder übersehe ich das was.

2. Dein At168 hat 2 8Bit-Timer und 1 16Bit-Timer, was muss man bei dem 16Bit-Timer beachten?


Mfg Martin

[synvox]

Hallo Martin,

zu Frage 1:
Nein, du übersiehst nichts. Ich möchte grundsätzlich ZWEI RGB-LEDs (oder ganze RGB-LED-Gruppen) pro chip unabhängig voneinander steuern, für diese Demo habe ich aber bloss eine angeschlossen, also nur 3 PWM-Kanäle benutzt. Wenn man nur eine RGB steuern möchte, könnte man auch z.Bsp. nur Ocr1a und b und Ocr2a verwenden, und könnte so noch Timer0 für andere Zwecke verwenden, kommt immer auf die geplante Anwendung an.

zu Frage 2:
bei Timer1 (16 Bit) ist es wichtig, die PWM-Konfiguration so zu wählen, dass der Top-Wert des Timers bei &HFF liegt. Der Timer1 bietet noch die Möglichkeit, diesen Wert auf &H1FF oder &H3FF zu setzten, was dann einen 9-Bit bzw. 10-Bit PWM ermöglichen würde. Wenn man die Werte aus meinem Program nimmt, läuft der Timer1 als 8-Bit-PWM. Wichtig ist dabei auch, dass das LSB-Register (also Ocr1aL bzw. Ocr1bL) den PWM-Wert enthält und dass die MSB-Register (also Ocr1aH bzw. Ocr1bH) am Anfang auf 0 initialisiert werden, sonst gibts u.U. gar kein Compare Match Ereignis.

Wichtig ist allgemein auch noch, dass man einen Vorteiler wählt, der bei allen beteiligten Timern vorkommt (Die drei Timer haben teilweise unterschiedlich umfangreiche Vorteiler), weil dieser die PWM-Frequenz mitbestimmt, und normalerweise möchte man die Frequenz bei den versch. PWM-Kanälen ja gleich haben.

Gruss
Neni

[Ilker21]

hii,

synvox kannst du vll noch einen schaltplan reinstellen wo ich was anschliesen muss ?

mfg ilker

[dedicated]

Hi

hab zwar nur die Pinbelegung eines ATmega32, du mußt die Timerausgänge wie OC0,OC1A,OC1B oder OC2 benutzten.

mfg martin

[synvox]

Hi Ilker,

es ist so wie Martin es gesagt hat; du musst die entsprechenden Output Compare Ausgänge (OCRXx) des Chips an die Kathoden der LEDs anschliessen. Ich habe hier mal einen Schaltplan genau der Testschaltung gemacht, die ich verwendet habe für das Programm und das Testvideo. Die Widerstandswerte Rr, Rg und Rb müssen so gewählt werden, dass entsprechend den Forwärtsspannungen der verwendeten LED(s) je maximal 20mA pro OCR-Pin (also auch pro LED-Farbe) fliessen.

Gruss
Neni

[Ilker21]

danke

[Fightclub]

hi synvox, mit was hast du die At168 bespielt? habe hier ein ATMEL Evaluations-Board V2 von Pollin, funktioniert das damit auch?

In der Beschreibung ist folgendes angegben:

Diese Platine zum Anschluss an den PC ermöglicht die direkte Programmierung der ATmega8535, ATmega16, ATmega32, ATmega8, ATtiny2313, ATtiny12 und ATtiny15.

ist der ATMEGA168 kompatibel mit einem der oben genannten (ATMEGA16???) sodass ich den ATMEGA168 auch mit meinem Board beschreiben könnte?

[KB]

der MEGA168 ist im 28pin Gehäuse und sollte Pin Kompatiebel mit dem Mega8 sein. Zumindest die PINs fürs ISP sind gleich sowie Reset und die Versorgung. Der Mega168 hat allerdings mehr Funktionen. Das Programm würde sich warscheinlich auch an einen Mega8 Anpassen lassen allerdings sind dann nur 3 Hardware PWM Ausgänge möglich.

[Fightclub]

mir ging es eher weniger darum, dass ich das ganze auf nen MEGA8 spielen kann, als dass ich mit meinem Board nen MEGA168 bespielen kann =/

wobei ja für das Testprogramm von synvox eh nur 3 hardwarepwm kanäle benutzt wurden.... hmmm was müsste ich denn ändern ums an nen MEGA8 anzupassen? Nur die Pinbezeichnung? Bin leider noch relativ neu in der Materie

[KB]

Also den MEGA168 zu programmieren sollte kein problem sein. da er Pinkompatiebel mit dem mega8sein sollte.

Um das Programm zu an einen Mega8 anzupassen wäre etwas aufwand nötig, um die Timer entsprechen anderst zu Initialisieren. aber wie gesagt wenn du dir einen Mega168/88/48 besorgst sollte das kein Problem sein das programm mit dem Programmierboard da drauf zu spielen.

[Fightclub]

ok herzlichen dank, dann vertraue ich dir mal und lasse mir die 168er besorgen. Melde mich dann vllt nochmal wenn ich sie hab

[synvox]

Also der mega168 (16k Flash), mega88 (8k Flash) und mega48 (4k Flash) sind pinkompatible aber funktionsmässig aufgemotzte Versionen des mega8 (sozusagen der Volks-AVR ). Es kommt aber nicht nur auf die hardwaremässige Unterstützung der ISP-Schnittstelle an, sondern auch auf die dazugehörige Software des Programmers. Diese muss den Chip-Typ 'kennen', d.h. dessen Besonderheiten, wie die versch. Fuse-Bits, da diese ja von mega8 zu mega168/88/48 unterschiedlich sind.
Ich kenne das Pollin-Programmierboard nicht (ich selbst habe einen ISP- und Parallelprogrammer), weiss also auch nicht welche Software da zum Proggen genutzt wird und ob diese die mega168/88/48-Chips unterstützt. Theoretisch, wenn die ISP-Schnittstelle beim Pollinboard die Standardbelegung des Parralel- oder Seriell-Ports am PC verwendet, könnte man ein Gratis-Brennprogramm einsetzen, wie z.Bsp. PonyProg, welches die 168/88/48 Chips ganz sicher unterstützt.

Gruss
Neni

[Fightclub]

spezielle Software war beim Pollinboard nicht dabei, zum Proggen verwende ich die Bascom Demo und zum brennen Ponyprog

klingt als würde es funktionieren....

[synvox]

Uups, da hab ich mich wohl etwas zu weit vorgewagt, ein Schnellschuss sozusagen, sorry. Habe mir gerade zur Sicherheit die neueste Version von Ponyprog angesehen (2.06f Beta, März 2005), und da ist leider keiner der mega168/88/48 chips dabei . Das Programm wird anscheinend seit 2005 auch nicht mehr upgedatet.
Da du ja aber die BASCOM Demo verwendest, schau dir mal den in BASCOM integrierten Programmer an, der unterstützt die chips ganz sicher (diesmal wirklich ), und er sollte auch die ISP-Schnittstelle über den Seriell-Port (bei den Device-Einstellungen) unterstützen, ansonsten müsstest du dir einen Programmierdongel (sehr einfach) nach Schema und Anleitung in BASCOM basteln.
Ansonsten ist auch ein Umschreiben des Programms auf mega8 möglich, sofern du wirklich nur 3 PWM-Kanäle (1 RGB-LED) benötigst, wie mein Testprogramm. Zu beachten wäre dann allerdings, dass du nur OC1a, OC1b und OC2 für die Steuerung der Kanäle verwendest und die Timer entsprechend initialisierst. Du kannst dies aber auch per BASCOM-Funktion "CONFIG Timer1 ..." bzw. "CONFIG Timer2 ..." machen (ich persönlich schreibe lieber die Register direkt, da ich die Hardware der AVR-Chips relativ gut kenne und so nicht über eventuelle Fehlimplementationen in BASCOM stolpere). Wichtig ist auch beim mega8, die CKSEL-Fuse-Bits anders zu setzen, da der RC-Oszi vom mega8 defaultmässig auf 1MHz läuft. Er kann auch 8MHz, aber man muss eben die Clock-Selection richtig einstellen (Datenblatt benutzen).

Gruss
Neni

[Fightclub]

also ich fasse zusammen:
brennen mit ponyprog nicht möglich...(benutze 2.06f beta)
brennen per Bascom möglich, nur bissel einstellen....

kann ich die fuse-bits auch bei bascom einstellen?

im notfall muss ichs halt umschreiben, auch wenns mir nich so recht wär, weil ich wie gesagt noch nich so im element bin....

ps: kann man dich iwie so zwischendurch mal in icq,yim,aim,msn,irc oder teamspeak antreffen? wenn ja schreib mir ma ne pm

[synvox]

ja, mit BASCOM kannst du auch die Fuse bits, lock bits etc. brennen.

Da ich in meinem Job als Webapplikationsentwickler/programmierer relativ ausgelastet bin, bin ich kaum in solchen Synchron-Kommunikations-Systemen (icq, irc, messenger etc.) anzutreffen. Die beste Option für mich sind und bleiben die asynchronen Comm-Tools (E-Mail, PM, Forum etc.). Ich antworte dann jeweils, wenn es sich zeitlich gerade gut ergibt.

@ALLE:
Wie gesagt, ist das kleine Program nur als Test bzw. Ideenlieferant gedacht gewesen. Für die, die lieber etwas Fertiges direkt übernehmen wollen: Wenn ihr noch ca. 1 Woche warten könnt, dann poste ich hier noch eine fertige Applikation auf der Basis von HW-PWM für zwei unabhängige RGB-Ziele (6 PWM-Kanäle) mit Dipschalter/Jumper-Erfassung als Vorwahlmöglichkeit und Tastenverarbeitung zur Steuerung von Programmwahl, Geschwindigkeit, Helligkeit und Start/Stop der Lichtprogramme jeweils für beide RGB-Ziele unabhängig.

Grüsse
Neni

[Fightclub]

hm ok, wenn ich fragen hab meld ich mich dann mal asynchron freut mich, dass es in der Branche noch genug zu tun gibt

[Fightclub]

Übrigens noch 100 Credits nachträglich dafür

[Mr M3xX!]

huch ^^ endnlcih ist der Schaltplan auch da =)
Da ich eh in die Mikrocontroller welt einsteigen möchte, werde ich diese How to direkt mal befolgen

Mal sehen ob ichs hinbekomme
Wenn ja bekommst du direkt paar credits ab

[synvox]

@Fightclub
Vielen Dank für die Credits .
Naja, wenn man im IT-Bereich der grössten Schweizer Universität arbeitet, dann ist man von irgendwelchen Marktfluktuationen der Branche ziemlich wenig betroffen .

@Alle
Leider hat mich die letzte Woche irgend so ne blöde Frühlingsgrippe erwischt gehabt, so dass ich gut 5 Tage flach gelegen bin. Deshalb bin ich mit der Final-Version nicht so weit gekommen, wie ich gerne wollte. Deshalb verzögert es sich noch etwas. Ich bin aber guter Dinge, dass ich bis Mitte nächster Woche das Programm kompilier- und brennfertig hier posten kann.

Gruss
Neni