Ich suche eine (relativ) einfache Möglichkeit, um 16 RGB LEDs (=48LEDs) mit mehreren Farben (mindestens 16, je mehr desto besser) mit einem AVR anzusteuern. Das ganze soll in der Art einer Propeller Clock aufgebaut werden, und so Bilder mit etwa 64*16 Pixel darstellen. Da das ganze schnell sein muss, kann ich kein PWM verwenden. Bei 16 Farben würde ich für jede LED einfach eine Stromquelle verwenden, die in 2 Stufen schaltbar ist, das wäre bei 48 LEDs gerade noch akzeptabel (8x 8bit Schieberegister = 1x CPLD, 48 Transistoren, 192 Widerstände) aber es gibt doch bestimmt eine einfachere Lösung, oder ?
hmm dimmen ohne pwm... umständlich über z.b. dac`s aber bevor ich mir das aufbaue, würde ich mir lieber pwm ansehen!!!
Hi, warum kein PWM ? Die LEDs hängen doch vermutlich eh alle an GND oder VCC. Da nen Trasistor rein und feddisch. Oder willst Du jede einzelne LED dimmen können ? Gruß ka-long
@ka-long Ich möchte damit Bilder anzeigen. PWM würde eine gepunktete Linie ergeben.
??? gepunktete linie ??? ja, du kannst viele kleine led`s vermutlich nicht so dicht packen, das du diese nicht als "große" punkte warnimmst. oder meinst du damit pwm? meinst du, sie würden blinken? das tun sie nur, wenn du eine ungeignete frequenz wählst!! so ab ~30 hz schätze ich, sießt du kein flackern mehr. kannst ja auch einige kHz nehmen ;-)
Wenn ich das richtig gelesen hab will Benedikt eine Art Propeller-Clock bauen, soll heißen die LEDs bewegen sich sehr schnell, bei PWM würde man die einzelnen An-Phasen dann als Punkte sehen... Jedenfalls wenn sie zu langsam ist. Aber mit nem Atmel bekommt man bei 16MHz ne 8 Bit PWM mit 62,5kHz hin, reicht das nich? Wie schnell soll sich das Ding drehen? Ansonsten könntest du vielleicht die Seite der LEDs die auf festem Potential hängen (also z.B. GND, wenn sie gegen GND geschaltet sind) mit PWM regeln und mit Kondensator und Spule glätten.
Hi, Wie schnell dreht sich denn die Clock ? Wenn das Ding 60mal pro Sekunden einen Punkt passiert, bei 360 Grad, reicht das doch völlig. Wenn Du jetzt alle 20 Grad die Helligkeit ändern willst, hast Du ca. 9ms pro 20 Grad Zeit. Das entspricht ca. 100HZ. Wenn Dein PWM dann um 200-300Hz hat, müßte das doch klappen. Gruß ka-long
analog zum normalen Fernseher würden 50Hz pro LED reichen um ein stabiles "Leuchten" zu erreichen. Angenommen du kommst auf 200Hz Wiederholrate dann kannst du die Helligkeit der LED's bildweise erzeugen. Zb. 4 nachfolgende Bilder ergeben pro LED dann 5 unterschiedliche Helligkeiten. Je nach Helligkeit werden die LED's also jeweils auf 4 nachfolgende Bilder ein/aus geschaltet. So kommst du wieder effektiv auf 50Hz Bildrate. Für meine Clock habe ich einen leicht anderen Weg beschritten, der ähnlich einer PWM funktioniert. Ich habe 512 Pixelspalten pro Umdrehung mit 50Hz. Jede Pixelspalte wird gemultiplext in 3 Farben zerlegt, RGB. Jede dieser Farbspalten wird 312 Takte a 31.25ns angesteuert. Da ich pro Farbe in einem Pixel 2 Bit an Information habe wandle ich diesen 2 Bit Wert in eine 3 Bit breite Pulssequenz um. Farbe = Pulse 00 = 000 01 = 010 10 = 101 11 = 111 Das könnte man als PWM bezeichnen wenn man es zb. so kodieren würde: Farbe = PWM 00 = 000 01 = 100 10 = 110 11 = 111 Um aber ein Flackern zu vermeiden benutze ich eben die erstere Konvertierung und pulse die LED's je nach Helligkeit. Bei 32Mhz Pixelspaltentakt und 312 verfügbaren Takten pro Farbspalte macht das 312/3 = 104 Takte pro LED Impulse/Zeitscheibe = 104 * 32.25ns = 3.354µs die eine LED Leuchtphase dauert. Das liegt noch absolut im Bereich der möglichen Pulsfrequenz heutiger LED's. Normale LED's können ohne Probleme mit bis zu 1 Mhz gepulst werden. Allerdings sollte man die Kapazität der LED's nicht unberücksichtigt lassen ! Ergo: ich würde dir anraten die LED's per PWM, bzw. genauer gesagt gepulst, zu betreiben und dann durch das Verhältnis der On/off-Zeiten die Helligkeit zu regeln. Elektrisch benutze ich eine Matrix mit 16*12 Zeilen/Spalten, macht 64 RGB LED's. Die 16 Zeilen steuern die RGB LED's mit gemeinsammer Kathode über eine PNP Konstantstromquelle an. Die 12 Spalten werden durch N-Channel MOSFETs durchgeschaltet. Diese 12 Spalten sind gruppiert in 4 * 3 Farben. Die 512 Pixelspalten werden also pro Sekunde zerlegt in 50 512 4 * 3 * 104 ~ 32.000.000 Einzelschritte -> ergo Pixeltakt ist 32Mhz. Die einzelnen 12 Spalten werden nun nach jeder Umdrehung der Clock um einen Schritt versetzt zeitlich verschoben angesteuert. Das bedeutet das bei der 1. Umdrehung 3*Rot 3*Grün 3*Blau 3*Dunkel angesteuert wird. Bei der 2. Umdrehung aber 2*Rot 3*Grün 3*Blau 1*Rot 3*Dunkel, bei der 3. Umdrehung 1*Rot 3*Grün 3*Blau 2*Rot 3*dunkel usw. usw. D.h. die Farbliche Ansteuerung der Pixel rotiert reihum pro Pixelspalte und somit wird nach 12 Umdrehungen des Rotors alle anfallenden Farbscheiben pro Pixel gleichmäßig verteilt. Erreicht wird dies indem im zeitlichen Takt pro Umdrehung einfach 1 virtuelle Zeitscheibe mehr als nötigt eingefügt wird. Wie oben geschrieben dauert eine Farbspalte 3*104 Takte a 32.25ns. Diese dauer von 104 Takten muß aber nicht für die R,G,B,D Phase immer gleich sein. Ich benutze 4 globale Variablen die die Anzahl der Takte pro Farbphase enthalten. Normalerweise eben 104,104,104,104 Takte. Ändert man das aber zb. in 52,52,52,260 so würden also R,G,B Phasen nur 52 Takte lang sein und die Dunkelphase aber 260 Takte, ergo die Gesamthelligkeit des Displays ist dunkler. Man kann also über diese 4 Taktanzahlen sowohl die Helligkeit als auch den Farbkontrast des Displays im Gesammten regulieren. Insgesamt komme ich so auf 6Bit Farbinformation pro Pixel = 64 Farben. Ein Pixel belegt somit 1Byte an Speicher. Die restlichen 2 Bits werden für andere Aufgaben benutzt. Angenommen der Pixel hat den Farbwert von 0b00101101 -> R = 10, G = 11, B = 01 dann sieht die Pulsesequenz so aus 101 111 010, und jeder Puls = Leuchtphase dauert ca. 104 Takte a 32.25ns. Eine Rotor-Umdrehung später würde dieses Pulsmuster um 1 Bit rotiert angezeigt, also 01 111 010 1, eine Umdrehung später dann 1 111 010 10 usw. usw. Somit wurden nach exakt 12 Umdrehungen des Rotors alle drei Farben -> rot,grün,blau örtlich pro Pixelspalte gleichmäßig verteilt angezeigt. Dein Problem mit dem gepulsten Flackern der LED's, bzw. der ungleichmäßigen Verteilung der Farbintensitäten pro Pixel wäre damit dann erledigt, da das menschliche Auge die Summe der Leuchtpulse pro Pixel von selber glättet. Gruß Hagen
@ KoF Bei neueren Autos (Audi A8, 7er BMW,...), bei denen die Rücklichter zum Teil mit LED's realisiert sind, wird PWM verwendet, um die LED's an einer konstanten Spannung zu betreiben. Dabei werden ca. 100Hz verwendet und da sieht man beim schnellen Vorbeifahren oder bei der Fahrt über eine 'Hoppelstrecke' viele 'Einzelbilder' der LED's. Ich hab mal eine LED-Matrix über einen MAX7219 angesteuert und der verwendet für das Multiplexen der Zeilen/Spalten eine Frequenz von (meines Wissens) 800Hz. Wenn man die Platine schnell in einem dunklen Raum bewegt hat, konnte man selbst bei der hohen Frequenz, bei einer einzelnen angesteuerten LED die Bahn der Bewegung als Reihe von Punkten sehen.
hmm nagut, ich bin davon ausgegangen, das das menschliche auge nur etwa 25 bilder pro sekunde wahrnimmt. wenn man die frequenz hochsätzt (so ab 1kHz) müsste man auch solche schnellen bewegungen realisieren können
@Hagen Das klingt sehr interessant, aber 32MHz Pixeltakt ? Woher kommen die Daten dafür, aus einem AVR wohl nicht...
Hi Benedikt, Jain :) Die Bilddaten liegen in einem 128Kb asynchronen SRAM der Zugriffszeiten von < 15ns ermöglicht. Der SRAM ist komplett und exklusiv an einem FPGA angeschlossen. Der FPGA steuert die 16x12 Matrix an und wird mit 32MHz getaktet. Einerseits halbiert er diesen Takt auf 16Mhz und andererseits erzeugt er einen internen Takt von 64Mhz, jeweils mithilfe zweier DLL's. Die dritte DLL wird als PLL benutzt die den exakten Pixeltakt für die 512 Pixelspalten erzeugt, mithilfe von 4 IR Lichtschranken synchron zur Rotationsgeschwindigkeit des Rotors. Am FPGA wird der AVR, ein ATMega128 mit seinem XMEM Interface angeschlossen. Der FPGA hat nun mehrere Aufgaben 1.) Memory Bank Controller damit der AVR auf die kompletten 128Kb SRAM zugreifen kann 2.) pseudo Dual Port RAM Controller, damit der AVR und der FPGA selber quasi parallel auf den Inhalt des SRAM's zugreifen können 3.) Display Controller, dieser besteht aus folgenden Untermodulen 3.1.) Display Cache RAM, teile des internen Dual Port RAMs des FPGA's werden als Cache benutzt. Dabei holt dieser Cache schon die nächsten 3 kompletten Pixelspalten an Informationen aus dem externen SRAM 3.2.) Farb-dekodierer, dieser nimmt die Daten aus dem Cache un dekodiert sie in die Pulse-Bits zur Ansteurerung der LEDs um. Dabei werden aus 64*8Bytes pro Pixelspalte jeweils 3*3*64 Bits an Pulssequenzen umkodiert und ebenfalls im internen RAM des FPGA's abgelegt 3.3.) der Multiplexer, dieser nimmt diese Daten und steuert die 16*12 Matrix zeitlich exakt an 4.) der PLL, deren Aufgabe es ist synchron zu Umdrehungsgeschwindigkeit und mit den 4 IR Lichtschranken einen Pixel-Spalten-Takt zu erzeugen, sprich dieses PLL misst also die Umdrehungsgeschwindigkeit des Rotors und erzeugt für die 512 Pixelspalten einen Basistakt. 5.) Takterzeugung aus einem 32Mhz externen Oszillator für die 16Mhz des AVR's und den internen Takt von 64Mhz für den FPGA. Soweit in Einzelmodulen fertig sind die Takterzeugung, die PLL zur Synchronisation, der Multiplexer, der Dekodierer,der Memory Bank Controller und der Pseudo Dual Port SRAM für den externen SRAM. Der Cache macht mir momentan noch die meisten Probleme. So, der AVR selber konfiguriert nur noch das Timing dieses Display Controllers. Angedacht habe ich aber die DLL's zur Takterzeugung wieder umzubauen. Der FPGA wird dann direkt mit den 16Mhz des AVR's angesteuert, d.h. der FPGA benötigt nur noch eine DLL nämlich um aus den 16Mhz Takt die internen 64 MHz zu erzeugen. Das hat dann den Vorteil das der AVR ohne den FPGA lauffähig sein wird. Der AVR ist nun in der Lage den FPGA selber zu konfigurieren und so spareich den exteren FPGA PROM. Am AVR liegt dann nur noch die SD/MMC Karte und der Dekoder zur Dekodierung der induktiven Datenübertragung. Der AVR kümmert sich also nicht im geringsten um die Darstellung, Dekodierung und Synchronisierung der eigentlichen Clock. Dafür kann ich nun im AVR komplexere Funktionen einbauen, wie Linien, Fonts, Bitmaps und Sprites. Aber fertig bin ich mit dem Projekt noch lange nicht. Einiges funktioniert schon in Hardware, anderes ca. 60% sind schon in VHDL fetig getestet und simuliert. Gruß Hagen
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.