mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik LEDs dimmen ohne PWM


Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: KoF (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmm dimmen ohne pwm...

umständlich über z.b. dac`s aber bevor ich mir das aufbaue, würde ich
mir lieber pwm ansehen!!!

Autor: ka-long (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ka-long

Ich möchte damit Bilder anzeigen.
PWM würde eine gepunktete Linie ergeben.

Autor: KoF (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
??? 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 ;-)

Autor: ape (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ka-long (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: KoF (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen
Das klingt sehr interessant, aber 32MHz Pixeltakt ? Woher kommen die
Daten dafür, aus einem AVR wohl nicht...

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ich Bin (ichbin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt's hier schon was zu sehen? Klingt lustig!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.