Ansteuerung für RGB-LED-Matrix

[sector]

Hi,
ich habe mit meinem Bruder ein "kleines" Projekt gestartet. Wir wollen, wie der Titel schon sagt, eine Matrix aus RGB-LEDS ansteuern. Wir wollten jetzt mal mit 50 LEDs anfangen, aber das ganze später noch hoch skalieren.
Jeder der sich schon mal damit auseinander gesetzt hat, wird unser Problem sofort sehen. 50 RGB-LEDs bedeutet, 150 Spannungswerte um die Farben jedes einzelnen Punkts einzustellen. Das ganze soll dann entweder über die Parallel/Seriell-Schnittstelle oder über einen Mikrocontroller angesteuert werden, je nachdem was einfacher ist :roll:
Bisher sind mir 2 Möglichkeiten eingefallen wie ich das lösen könnte:

1. PWM-Baustein. Entweder einen mit möglichst vielen PWM-Ausgängen, oder pro LED einen mit 3 Ausgängen. Das ganze müsste dann halt auch noch adressiert werden...

2. µC mit möglichst vielen PWM Ausgängen, die dann eigentlich auch nur als PWM-Baustein dienen.

Wie ihr euch denken könnt darf es nicht zu teuer werden, sprich so ca 50 Cent pro LED (3 PWMs) sind absolutes Maximum. Die Außenbeschaltung darf auch nicht so groß ausfallen. Die Bausteine sollten also die 20mA pro PWM-Kanal verkraften. Refreshrate des Displays wollen wir ca. 20Hz rausholen, damit auch flüssige Bewegungen bzw Farbänderungen möglich sind.

Weiß jemand Rat? Entweder eine andere Lösung oder einen Vorschlag, welches Bauteil ich verwenden könnte?

[Surveyor]

Wenn es schon eine Matrix werden soll, ist evlt. folgende Lösung sinnvoller:

Du nimmst z.B. für die erste Zeile einen Pin0 vom uC und für jede LED einen weiteren (in diesem Fall nehme ich die RGB LEDS mal als einzelne an). Somit kannst Du über den Pin0 alle LEDs mit Spannung versorgen. Die anderen Pins schaltest Du jetzt abwechselnd auf GND und somit leuchten die LEDs.

Wenn Du einen ATMEGA32 (wenn ich mich richtig erinnere hat der 32 I/Os) nimmst dann kannst Du Du 8 Zeilen und jeweils 24 Spalten ( RGB * 8 ) addressieren.

Prüfen müsstest Du noch ob die I/O-Pins des uC den notwendigen Strom abgeben und aufnehmen können.

[1hdsquad]

Is schon ein bisschen knifflig. Hochskalieren heißt was genau? 100? 500? 1000?
Du weißt auch, das 50 RGB-LEDs verdammt viel Strom brauchen? Ich weiß nicht, ob jeder Chip der RGB-LED 20 mA braucht, aber bei 50 normalen LEDs wärst du bei rund einem Ampere (20mA*50)!
Schau doch mal hier:
https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=232227
MFG

[sector]

@Surveyor: Ich will die RGB-LEDs ja stufenlos regeln. Mit deiner Lösung würde ja nur an/aus gehen, oder ist es möglich 32 Software-PWMs gleichzeitig laufen zu lassen?

@1hdsquad: Jo, hab ich gelesen. Aber da gehts doch auch nur um an/aus der LEDs, oder? Also mit hoch skalieren meinte ich ca 300 LEDs. Von der Adressierung her, würden dann 10Bit passen. Damit könnte ich 1024 Farbwerte zuordnen. Das mit dem Strom ist mir schon klar, kommt halt drauf an wieviel LEDs pro Baustein angeschlossen werden können. Wieviel Strom letztendlich aus dem Netzteil gezogen werden ist ja egal..

Ich war bisher auf der Hardware-PWM Schiene, aber viell wäre es auch möglich, die PWM in Software zu realisieren. Eine Auflösung von 3 oder 4 Bit pro Farbe würde reichen. Zeitlich, wie gesagt, ein Refresh von ca 20Hz.

Wo sind die µC Checker? :Ostern

[vajk]

.. also ich würde einen AVR nehmen, der möglichst viele PWR-Ausgänge hat ... guck Dir mal den "Propeller" an .. der hat 24 I/Os und glaub 8 parallele Proz. intern ... der müßte sowas leisten können ...
... ich hab hier einen ATmega32 mit 8 RGB-LEDs verschaltet uind das ganze noch als Drehwurm,sprich als Rotationskörper .. der mega ist nicht in der Lage das zu leisten, 7 Farben, das wars.

Die nächste Variante werde ich eben mit dem Propeller-IC probieren oder aber in meinem Fall 4 AVRs, 3 für die PWMs für jeweils 8 LEDs und einen für die Spaltenbreite ... fehlt nur noch der entsp. große Speicher ...

[kalledom]

Mit 50 Cent pro LED möchtest Du das realisieren ?
Dann frage ich mich allerdings, warum kosten große Farb-Bildtafeln viele Tausend Euro ? Waren die Entwickler etwa nicht in der Lage, das preiswerter hinzubekommen ?
Du kannst einen µC mit z.B. 24 Ausgangs-Pins verwenden und damit 8 RGB-LEDs ansteuern. Macht dann in der erweiterten Version mit 300 LEDs etwa 38 Controller.
Das Ganze muß dann noch koordiniert werden, zu deutsch, die müssen alle von einer 'Zentrale' aus angesteuert werden, seriell.
Viel Spaß.

[vajk]

oh ja: "50 Cent pro LED (3 PWMs)"
meinst Du hier die Außenbeschaltung mit oder ohne LED ?
Deine Preisvorstellung ist wahrscheinlich etwas Blauäugig ....

.. nun ich habe das mit 3 schaltbaren Konstantstromquellen gelöst (CentBauteile) ... die hellste RGB-Led, wenn Du genug Stück abnimmst liegt pro Stück bei 0.9 Euro ... wenn Du genug Platinen machen läßt, Stückpreis (eine Platine mit atmega32 plus 8 Flux LEDs) um die 8 Euro ... allerdings hab ich die Platine schon Platzoptimiert .. war nur noch Handlötbar mit SMD 0603-Hühnerfutter ...

@kalledom wie willst Du mit einem mega32 (als Beispiel) 24 PWM-Signale generieren .. das habe ich bisher nicht hinbekommen ...

[kalledom]

@vajk
Ich habe für einen PIC16F877 mit 4,9152MHz Quarz ein Programm als Flackerlicht für ein Kaminfeuer in Assembler geschrieben, welches an 8 Ausgängen ein PWM-Signal ausgibt. Die PWM-Frequenz beträgt 100Hz, Duty-Cycle liegt zwischen 0 und 100%, also 100 Stufen.
Siehe: http://www.domnick-elektronik.de/picpwm.htm
Dann können bei 20Hz PWM-Frequenz (= 1/5) und 20MHz Quarz (= 4-fach) ohne weiteres 20 mal so viele PWM-Ausgänge genutzt werden.
Ich würde allerdings bei 100Hz PWM-Frequenz bleiben; durch die 4-fache Quarz-Frequenz ergeben sich 4 mal so viele Ausgänge, also 32 !
Das Problem wird allerdings bei sehr vielen LED's sein, wie bekomme ich mehrere µC seriell und schnell koordiniert ? Es müssen ja immerhin für jede RGB-LED 3 Bytes für die Helligkeiten / PWM-Duty-Cycles übertragen werden.

[izaseba]

Zwei Fragen meinerseits:
1. Wie alt bist Du
2. Was hast Du bis jetzt in Sachen Elektronik, programmieren gemacht ?

[squelver]

Ich habe zwar noch nichts in der Richtung programmiert, aber ich sehe Licht in dieser Sache, abgesehen von den Kosten. Ich suche täglich intensiv durchs Internet und finde Unmengen an Seiten, wo Beispiele zu diesem Thema zu finden sind ;)

[wkrug]

Also das mit 32 Ports per Software PWM ansteuern sollte sich hinkriegen lassen.
Mit 8MHz und 3LED's mit 256 Stufen hab ich sowas kürzlich geproggt.
Das Programm müsste halt nur auf 30LED's aufgemotzt werden.
Die PWM Frequenz liegt bei mir bei 125Hz, also hoch genug um nicht zu flackern. Mit 16MHz sollten somit auch 250Hz möglich sein
Die einzelnen Farben müssten dann halt nacheinander abgearbeitet werden. Man käme dann also auf eine Flackerrate von ca. 83Hz pro Farbe.
In 2 oder mehr Zeilen Multiplexen würd ich die Geschichte aber dann nicht mehr, sonst kommst Du unter 60Hz- also in den Flacker Bereich.
Ich bin auch der Meinung das das eigentliche Problem die Datenmenge für mehrere solcher Einheiten sein wird.
Bei der Portvergabe solltest Du auch an freie Pins für eine Adressierung und die Datenschnittstelle bedenken.
Ein Controller mit noch mehr Ports (ATMEGA128) wär vermutlich noch besser, aber auch wesentlich teuerer.
Wie möchtest Du den Datenaustausch machen SPI, I²C oder seriell ?
Wie willst Du den Datentransfer managen? Adressierung, alle kriegen alles oder was komprimiertes?

[sector]

Danke für die vielen Antworten, so hab ich mir das vorgestellt :cheesy:
Also kurz mal zu mir, ich bin 26 und studiere E-Technik. Bisher habe ich mit 8051 etc, PIC und C167 gearbeitet. Den 8051 in Assembler programmiert, den Rest in C.

Zur Kostenfrage: Die 50 Cent waren nur für die PWM+Treiber gedacht. Platinen kann ich in der FH machen und die restlichen Kleinkram lass ich jetzt mal außen vor. Wenn ich also mit einem µC mit 32 I/O-Pins arbeite, heißt das ca 5€ pro Controller. Ihr habt Recht, wird wahrscheinlich teurer...

Die Übertragung könnte wirklich ein Problem geben. Wenn ich von einer zeilenweisen Ansteuerung ausgehe wirds vielleicht einfacher. Ein Controller für 10 LEDs und 2 Pins für Datenübertragung. Also müssen pro Refresh max 30 Zeilen a 30bit Farbwerte geschrieben werden:

30 Zeilen * 30bit * 100Hz = 90kBit/s + Overhead des Protokolls

Das müsste mit I2C ja möglich sein, was meint ihr?

edit:
Gibts einen µC mit 32 (oder mehr) I/O-Pins der I2C oder CAN-Bus an Bord hat und ~5€ kostet? O:)

[kalledom]

Ein PIC16F877 hat 33 I/O-Pins minus 2 für I2C: http://www.domnick-elektronik.de/aktuell.htm
Der 80C166 hat 4 x 16 = 64 I/O-Pins + 10 Input TTL / analog
oder mit I/O-Karten dazu noch viiiiiel mehr: http://www.domnick-elektronik.de/projekte.htm

[BASTIUniversal]

Hi!
Ich denke ein Mega16 (2,55€) mit 16MHz könnte diese Aufgabe schon schaffen wenn man ordentlich optimiert beim Programmieren.
Der hat 32 I/O's könnte somit 10 LED's zum laufen bringen. An seriellen Schnittstellen mangelts dem auch nicht...I²C, SPI und USART in Hardware.

Dazu kommen dann noch 30 Kleinsignaltransistoren (BC547 3ct/St), 30 Vorwiderstände für die Basis (Kohleschicht 3,2ct/10 St) und 30 Vorwiderstände für die LED's (Kohleschicht 3,2ct/10St).
Mach gesamt:
Mega16..........2,55€
Transistoren...0,90€
Widerstände...1,92€
................................
Gesamt:.........0,537€/LED

Dann kommen noch einige Kleinteile dazu...je nach Fertigungskosten für die Leiterplatten halte ich 0,75€ bis 1€ / LED für realistisch.

MfG

[wkrug]

30 Kleinsignaltransistoren (BC547 3ct/St), 30 Vorwiderstände für die Basis (Kohleschicht 3,2ct/10 St) und 30 Vorwiderstände für die LED's
Wenn Du dann noch 30 Z Dioden dazunimmst hast Du pro LED auch gleich eine Konstantstromquelle und kannst dadurch am Netzteil etwas sparen.
Wenn Du die LED's trotzdem Multiplexen willst (könnte mit 3*9 LED's noch gehen) brauchst Du noch 3 PNP Transistoren mehr, kannst aber dann 27LED's
mit allen Farben ansteuern.

[sector]

@Basti: Das hört sich doch sehr gut an :D

Ich hab zwar leider kein Zugriff auf einen ATMega16-Board, aber auf ein C167-Board @ 20MHz. Da werde ich "einfach" testweise mal 32 Software-PWMs programmieren. Optimierter Code heißt bei dir wahrscheinlich Assembler, oder? Ich bin leider nicht mehr so fit in Assembler (ist schon 6-7 Jahre her, daß ich das letzte Mal Assembler programmiert hab) deswegen hätte ich mein Glück mit C versucht, oder hat das keinen Sinn?

Gruss

[wkrug]

Also ich hab meine 3 LED Routine so gebaut:




volatile unsigned char uc_tim0ovf;
volatile unsigned char uc_red ; //Helligkeitswert Rot 0...255
volatile unsigned char uc_green ; //Helligkeitswert Grün 0...255
volatile unsigned char uc_blue ; //Helligkeitswert Blau 0...255

// Timer 0 overflow interrupt service routine
interrupt [TIM0_OVF] void timer0_ovf_isr(void)
{
uc_tim0ovf++ ;

if (uc_tim0ovf==0) {
uc_tim0ovf++;
}
if (uc_red>=uc_tim0ovf) {
# asm ("SBI PORTC,0"); //Die Rote LED Port C,0
}
else
# asm ("CBI PORTC,0");

if (uc_green>=uc_tim0ovf) {
#asm ("SBI PORTC,1"); //Die Grüne LED Port C,1
}
else
#asm ("CBI PORTC,1");

if (uc_blue>=uc_tim0ovf) {
#asm ("SBI PORTC,2"); //Die Blaue LED Port C,2
}
else
#asm ("CBI PORTC,2");

}


.....
void main(void)
{
// Declare your local variables here

// Input/Output Ports initialization
// Port B initialization
// Func7=In Func6=In Func5=In Func4=In Func3=In Func2=In Func1=In Func0=In
// State7=T State6=T State5=T State4=T State3=T State2=T State1=T State0=T
PORTB=0x00;
DDRB=0x00;

// Port C initialization
// Func6=In Func5=In Func4=In Func3=In Func2=OUT Func1=OUT Func0=OUT
// State6=T State5=T State4=T State3=T State2=T State1=T State0=T
PORTC=0x00;
DDRC=0x07;

// Port D initialization
// Func7=In Func6=In Func5=In Func4=In Func3=In Func2=In Func1=In Func0=In
// State7=T State6=T State5=T State4=T State3=T State2=T State1=T State0=T
PORTD=0x00;
DDRD=0x00;

// Timer/Counter 0 initialization
// Clock source: System Clock
// Clock value: 8000 kHz
TCCR0=0x01;
TCNT0=0x00;
.....




Das Ganze auf 30 Werte erweitern und bei Wunsch noch eine Multiplexroutine einbauen und fertig ist der Hanomag (die PWM).
Was noch fehlt ist die Datenschnittstelle zum Datenempfang, sowie eine eventuell nötige Adressierung.
Wie das Timingmässig hinhaut kannst Du ja nochmal mit AVR Studio 4 Austesten.
Ein paar Zuweisungen fehlen in dem Code noch - ich hab CODEVISION AVR benutzt.

[BASTIUniversal]

@sector:
Wie heißt es immer so schön: Probieren geht über studieren. Die Hardware muss für einen ersten Software-Versuch ja auch noch nicht stehen...also wenn's nicht funktioniert hat man noch kein Geld ausgegeben!

Wenn du in C fit bist, dann probiers doch mal in C...wenn's nicht tut kannst du dich immernoch in Asm reindenken.

MfG