LED Matrix mit FETs ansteuern

10A?
Bei mir gibt 64*0,02A immer noch 1,28A.
Wenn du freilich 200mA Pulsstrom durch die LEDs jagst, dann sind das 
natürlich 12,8A. Statt der PNP-Transistoren würde ich eher zu UDN29581 
Treiber raten. Die sind allerdings nicht wirklich billig.
Andernfalls würde ich einen BC547 oder BC587 nehmen und mit dem den 
BC557 steuern. Ist halt etwas frickelig und ab so 100kHz merkt man dann 
auch noch was von der Raumladungszone im Transistor - sprich da leuchtet 
was, was nicht leuchten soll - Pullups an den Basisleitungen sollten das 
aber verhindern. Vorteil ist aber, dass die Betriebsspannung nicht mehr 
direkt aus der Schiene für den Controller kommen muss. Außerdem hat man 
sonst den Spass dass die PNPs auch dann leiten, wenn sie's nicht sollen, 
da die Spannungen dank der Last etwas auseinanderlaufen. Von daher eher 
billige NPN-Treiberarrays (ULN28003) in die Spalten und mit 16 
P-Kanalgfets nebst Treibern die Zeilen abmuxen.
Die Framerate sollte so bei 50Hz liegen. Folglich ist bei 8 "Graustufen" 
eine Bildfrequenz von 400Hz angemessen, Bei 16 Graustufen dann 
entsprechend 800Hz. Bedenken sollte man aber auch, dass das Auge die 
Helligkeitsabstufungen nicht linear wahrnimmt. Für 16 "echte" Graustufen 
wären somit wahrscheinlich 64 Abstufungen angebracht um das Ganze etwas 
zu linearisieren.
Bei einer von mir mal gebauten LED-Matrix arbeite ich mit 325Hz Bildrate 
und  4 Helligkeitsstufen, was eine Abtastrate von 7,8kHz bzw. eine 
Scanrate von 1300 Scans/Sekunde mit sich bringt. Die Hälfte wäre wohl 
noch drin, ohne dass es zu sehr flimmert, aber drunter würde ich 
ehrlichgesagt nicht gehen wollen, da sonst die niedrigste 
Helligkeitsstufe sehr stark flimmern würde (bei

 ergibt sich nämlich auch eine Bildrate von nur 325Hz, während es bei 
voller Helligkeit 1,3kHz sind).
Bei meinem Matrix-Projekt kümmert sich je ein Tiny2313 um 6x7 LEDs. Ist 
zwar etwas mehr Aufwand, aber dafür flimmert nix und man kann nach 
Belieben bis zu zig Metern Länge erweitern, wenn man nix besseres zu tun 
hat. Wenn ich sowas allerdings nochmal bauen würde, würde ich wohl mit 
Schieberegistern und Zeilenweisem Scan arbeiten und den Bildaufbau ggf. 
mit einem CPLD/FPGA erledigen oder größere Einzelmodule (z.B. 30x7 oder 
16x16) vorsehen.
Im Anhang mal ein Bild von der MassiveTinyAVR-Matrix mit 8 Modulen.

Hier mal eine funktionierende Schaltung. Für größere Blöcke/Ströme 
entsprechend erweiterbar.

korrektur oben in meinem ersten Post solls nicht 100kHz sondern 1kHz 
heißen.
Da leuchtet dann übrigens wirklich was, allerdings noch recht schwach. 
Wenn man auf 8kHz Framerate hochgeht wirds dann schon deutlicher. Mit 
FETs wäre das - passende Treiber vorausgesetzt - weniger problematisch, 
da sich hier keine Raumladungszone herausbildet, dafür hat man halt die 
Gatekapazität.
Wenn man FETs direkt mit dem AVR steuern will, tun so rund 10-100 Ohm 
vorm Gate ganz gut (je nach Frequenz). Mit 100 Ohm überlebt ein AVR 
sogar tote FETs mit durchgeschlagenem Gateoxid bei 12V.

@ Andreas Lang

>*korrektur* oben in meinem ersten Post solls nicht 100kHz sondern 1kHz
>heißen.
>Da leuchtet dann übrigens wirklich was, allerdings noch recht schwach.
>Wenn man auf 8kHz Framerate hochgeht wirds dann schon deutlicher. Mit
>FETs wäre das - passende Treiber vorausgesetzt - weniger problematisch,
>da sich hier keine Raumladungszone herausbildet, dafür hat man halt die
>Gatekapazität.

Man kann auch einfach die Treiberschalung per NPN/PNP ordentlich 
dimensioniern und ansteuern, dann klappts auch mit dem 
Nicht-Nachleuchten.

>Wenn man FETs direkt mit dem AVR steuern will, tun so rund 10-100 Ohm
>vorm Gate ganz gut (je nach Frequenz). Mit 100 Ohm überlebt ein AVR

Quark. Der AVR bringt von Haus aus schon eher wenig Strom, den kann man 
ohne Bedenken direkt an das Gate anschliessen. Die Strombegrenzung ist 
nur bei RICHTIG fetten Gatetreibern und dicken FES nötig, dort fliessen 
dann Pulsströme von 1..X Ampere.

Viel wichtiger ist ein exterer Pull-Down am Gate, damit die FETs sicher 
sperren wenn der AVR programmiert wird. Sonst werden ggf. die LEDs 
gegrillt.

Noch was. Wenn das Ganze sowieso mit 5V läuft, kann man normale BC846 
oder ähnlich als Emitterfolger verwenden, die sind SCHNELL. Da leuchtet 
nix nach, richtiges Timing bei der Ansteuerung vorausgesetzt.

Beitrag "LED Matrix Beschaltung"

MFG
Falk

> Man kann auch einfach die Treiberschalung per NPN/PNP ordentlich
> dimensioniern und ansteuern, dann klappts auch mit dem
> Nicht-Nachleuchten.

Wenn man Push-Pull Treibt, dann ist das auch bei höheren Frequenzen 
freilich kein Problem. Oder man sorgt dafür, dass der Transistor NICHT 
in die Sättigung gehen kann. Ansonsten sagt die Physik: "und es leuchtet 
doch"

> Quark. Der AVR bringt von Haus aus schon eher wenig Strom, den kann man
> ohne Bedenken direkt an das Gate anschliessen. Die Strombegrenzung ist
> nur bei RICHTIG fetten Gatetreibern und dicken FES nötig, dort fliessen
> dann Pulsströme von 1..X Ampere.

Und trotzdem kann ein (nicht zu großer) Widerstand nicht schaden. Die 
Gates bei den oben genannten IRLZ34N ist nämlich nicht gerade soo klein. 
Jedenfalls werden es dir deine Ports am AVR danken. Die Ports am AVR 
können nämlich durchaus ganz schön Strom liefern, u.U. auch mehr als 
unbedingt gut für sie ist. Außerdem muss der Saft zum Umladen irgendwo 
herkommen, die Abblockkondensatoren werden sich jedenfalls freuen. Und 
sowieso: im ursprünglichen Post war nirgends von einem AVR die Rede. Ein 
Widerstand vor dem Gate ist übrigens auch aus EMV-Überlegungen sinnvoll.

@ Andreas Lang

>freilich kein Problem. Oder man sorgt dafür, dass der Transistor NICHT
>in die Sättigung gehen kann.

Auch gesättigte Transistoren schalten noch schnell genug, um ne popelige 
LED-Anzeige zu muxen.

> Ansonsten sagt die Physik: "und es leuchtet doch"

Die Physik weniger, meist eher Programmierfehler. Been there, done this 
;-)

Man muss dafür sorgen, dass sich die  Muster der Segmente zeitlich nicht 
überlappen. Dann gibts auch kein Nachleuchten. Praktisch heisst das, 
dass man in etwa so in seiner periodischen MUX-Funktion vorgehen sollte.

Alle Digits aus
Daten für neues Segment berechnen/aus Tabelle holen, das dauert ein paar 
us
Daten für neues Segment aktivieren
Neues Digit aktivieren

MfG
Falk

Naja, kommt immer sehr auf die Schaltung und die Frequenz an. Wenn du's 
nicht glaubst, dann nimm doch einfach mal nen BC547 und schließe den in 
Emitterschaltung an. Kollektor mit nem R (220 Ohm) nach +5V, Basis über 
einen R (1k) auf den Ausgang von einem Rechteckgenerator. Dann Gehst du 
mal mit der Frequenz so auf 10-20kHz und mes mal mit dem Oszilloskop 
gleichzeitig am Ausgang vom Funktionsgenerator und am Kollektor des 
Transis. Beim Einschalten hat der nen bisschen Verzögerung (ziemlich 
gering), beim Ausschalten aber deutlich (>2x) mehr.
Wenn man jetzt mal von der oben geposteten Schaltung ausgeht, dann 
werden die PNPs über ein NPN-Array gefahren. Es werden blaue LEDs 
verwendet. In dieser speziellen konstellation kommen mehrere Faktoren 
zusammen:

1. Der NPN Transistor hat ein bisschen Turn-Off-Delay.
2. Der PNP-Transistor auch.
3. Die Verzögerungen addieren sich.
4. Die Raumladungszone im PNP wird nicht aktiv "ausgeräumt" - also kein 
Push-Pull.
5. Die Multiplexfrequenz ist recht hoch
6. Blaue LEDs leuchten auch bei sehr geringen Strömen schon sichtbar.

Der Effekt kommt damit in erster Linie bei geringster Helligkeitsstufe 
zu Geltung, da hier die schwach leuchtenden LEDs stärker auffallen. 
Diese Stufe wird idR nur bei Dunkelheit verwendet. Man sieht's also noch 
besser.

Das Programm ist übrigens in der Hinsicht sauber, also kein 
Programmierfehler.

---snip---

1

PORTB=0x00; //LEDs aus, Backplane 5 aus

2

        if (display==0)

3

    return;

4

  if (bright>=dimm)

5

    { //Main matrix

6

    switch(spalte)

7

      {

8

      case 0:

9

        //Backplane 5 ist schon aus!

10

        update(); //Hier ist ein Update ohne flackern möglich

11

        PORTD|=(1<<2); //Backplane 0 auswählen

12

        spalte=1;

13

        PORTB|=(matrix[0]<<1); //Spalte laden

14

        break;

15

      case 1:

16

        PORTD&=~(1<<2); //Backplane 0 aus

17

        PORTD|=(1<<3); //Backplane 1 auswählen

18

        spalte=2;

19

        PORTB|=(matrix[1]<<1); //Spalte laden

20

        break;

---snap---

Die LEDs werden erst ausgeschaltet, dann wird das alte Backplane 
abgeschaltet, das neue Backplane eingeschaltet und dann die LEDs wieder 
entsprechend besaftet.

Der Schaltplan ist oben angehängt.

Bei einem 2N2219 (NPN) mit 2,2k Basisvorwiderstand und zusätzlich 2k2 
von Basis auf Masse und 2,2k Kollektorwiderstand kommt so was um die 
0,5µs Speicherzeit und 860µs t_fall raus. Das ist dann zusammen so rund 
1,2µs bis der Kollektorstrom auf 10% Imax unten ist. Wenn die MCU nun 
mit 16MHz läuft ist bis dahin ggf. schon längst die nächste Zeile/Spalte 
eingeschaltet. In der oben geposteten Schaltung ist übrigens die 
LED-Betriebsspannung nicht gleich der Betriebsspanung der CPU.
Die Speicherzeiten muss man logischerweise addieren, wenn man 
Transistoren komplementär hintereinanderschaltet. Der PNP kann ja 
schließlich erst sperren, wenn der NPN ihm keinen Basisstrom mehr gibt.

Die t_storage+t_fall hatten wir damals auch unterschätzt.

> Warum schaltest du nicht gleich
> am Anfang einfach ALLE DIGITS aus? Statt dessen fummelst du noch mit
> sowas rum...

Die LEDs werden am Anfang alle ausgeschaltet. (PORTB=0;)
Auf PortD ist noch der UART drauf der hier mit aktiviertem Pullup im RxD 
läuft. Wäre also nicht optimal einfach mal so PORTD=0; zu machen - daher 
das rumgekröse mit PORTD&=... . Alles weitere siehe Schaltplan.

Die Scangeschwindigkeit ist bei 7,8kHz.

Der AT89C2051 ist doch ein 80C51 und kein AVR?

Ist es nicht einfacher mit einem µC die Daten für je eine Zeile per SPI 
in ein Schieberegister zu blasen, statt da ettliche µCs irgendwie 
aufeinander zu synchronisieren?

@ Andreas Lang

>Der Schaltplan ist oben angehängt.

Nö, der fehlt.

>Die LEDs werden am Anfang alle ausgeschaltet. (PORTB=0;)
>Auf PortD ist noch der UART drauf der hier mit aktiviertem Pullup im RxD
>läuft. Wäre also nicht optimal einfach mal so PORTD=0; zu machen - daher
>das rumgekröse mit PORTD&=... . Alles weitere siehe Schaltplan.

>Die Scangeschwindigkeit ist bei 7,8kHz.

??? Warum zum Henker braucht man 7,8 KILOHERTZ MUX-Freqeunz? Soll das 
Ding in nem Düsenjäger verbaut werden und bei MACH 2 noch flimmerfrei 
sein?
Für 99,99% der Weltbevölkerung sind 100 Hz Bildwiderholfrequenz 
flimmerfrei, Macht bei ner 1:8 MUX 800 Hz. Du bist um den Faktor 10 
drüber. Und das mit den 16 MHz kann man auch berücksichtigen.

@ Matthias

>1) Als Emitterfolger BC846 verwenden aufgrund höherer
>Schaltgeschwindigkeit!

Unter anderem. Aber vor allem ist es einfacher von der Bauteillogistik, 
man braucht nur NPNs.

> OK, aber nennt mir bitte eine alternative
>Variante NICHT in SMD! Die Schaltung wird diskret auf Lochraster

BC337, der Standardtyp.

>2) Wie von Falk vermutet handelt es sich bei dem uC um einen AVR und
>zwar um den AT89C2051, da ich mich damit ganz gut auskenne... Dieser

Das ist ein ATMEL, aber KEIN AVR! Ausserdem musst du prüfen, ob der 
Push-Pull oder Open Drain-Ausgänge hat. Bei Open Drain brauchst du noch 
exteren Pull-Ups (Wer sowas im Jahr 2007 noch verkauft müste gesteinigt 
werden . . .)

>kümmert sich jeweils um 8 Spalten. Die 16 Zeilen sollen ALLGEMEIN von
>einem weiteren AVR gesteuert werden!

Und warum so kompliziert? Dann musst du deine beiden uC gut 
synchronisieren. Machbar, aber IMHO unsinnig. Ein einzelner uC hat mehr 
als genug CPU-Power für eine normale LED-Matrix.

>3) Widerstand vor dem Gate! 10 Ohm? 100 Ohm?

Meinetwegen 100 Ohm. Aber auch 10k vom Gate gegen GND!

>4) exterer Pull-Down am Gate! Wieviel OHM? Ist er nötig, obwohl ich den
>AT89C2051 nicht inSystem programmiere?

Sicher ist sicher.

>Nun kurz zur Software:

>Die Frage, die mir die meisten Sorgen bereitet: Was passiert mit den
>armen LEDs, wenn ein uC "hängen" bleibt (sei es softwarebedingt oder
>warum auch immer) und dann aus den 100mA Pulsstrom 100mA (oder mehr)

Sie werden getostet.

>Dauerstrom wird? Klar, die werden nicht lange überleben, aber was kann
>man dagegen tun? Un jetzt bitte keine Tipps der Gestalt: Dann
>programmier halt gscheit ;-)

1.) Während der Testphase grosse Vorwiderstände, das macht die Anzeige 
zwar dunkel aber absturzsicher.

2.) Im Betrieb einen Watchdog bauen, z.B. mit 74HC123. Das ist ein 
flankengesteuertes Monoflop. Wenn dass eine zeitlang keinen Puls am 
Eingang sieht, schaltet der Ausgang. Damit kannst du deine 
Zeilentransostoren ausschalten.

MFG
Falk

Das ist dann nochmal der Schaltplan.
Die hohe Scangeschwindigkeit liegt daran, dass das Ding mehrere 
Helligkeitsstufen kann. Bei 800Hz und z.B. 4 Stufen wären dann nur noch 
25Hz Blinkrate übrig, wenn die LEDs auf geringster Stufe leuchten und 
das flimmert.

@ Andreas Lang

>Das ist dann nochmal der Schaltplan.

OK, hab ihn auch weiter oben gefunden.

>Die hohe Scangeschwindigkeit liegt daran, dass das Ding mehrere
>>Helligkeitsstufen kann. Bei 800Hz und z.B. 4 Stufen wären dann nur noch
>25Hz Blinkrate übrig, wenn die LEDs auf geringster Stufe leuchten und
>das flimmert.

JAIN. Wen du PWM machen willst, muss zwar der uC schneller rechen bzw. 
mit höherer MUX-Frequenz arbeiten, allerdings ändert das nichts an der 
Schalthäufigkeit der LEDs bzw. der Bildwiderholfreqeunz. Die schalten zu 
Beginn der MUX-Zeit ein, und je nach PWM-Wert irgendwo zwisch 0..100% 
der Zeit aus.

MfG
Falk

P.S. Deine Spaltenansteuerung kannst du wesentlich vereinfachen, siehe 
mein Link.

http://www.mikrocontroller.net/articles/Led_matrix

Was meint die Gemeinde?

MFG
Falk

> P.S. Deine Spaltenansteuerung kannst du wesentlich vereinfachen, siehe
> mein Link.

Werde ich ggf verwenden, falls ich nochmal so'n Ding baue. Das mit der 
o.g. Schaltung gibt's aber schon und es läuft seit ungefähr 1 Jahr 
annähernd ununterbrochen.

@ Andreas Lang

Hast du den neuen Artikel zur LED-Marix aufgemacht? Das Layout ist 
besser, da kann der alte gelöscht werden.

MFG
Falk

> Hast du den neuen Artikel zur LED-Marix aufgemacht? Das Layout ist
> besser, da kann der alte gelöscht werden.

Äh? Nö.