Servus! Um mehre LEDs als Matrix anzusteuern, habe ich mich für folgende Beschaltung entschieden. In jeder Spalte sitzt zwischen der Versorgungsspannung (5V) und der Anode der LEDs ein pnp Transistor (BC559C). Bei den Zeilen denke ich an ein N-Kanal FET (IRLZ34N) zwischen den Kathoden der LEDs und GND, da hier Ströme bis zu 10A geschalten werden müssen. Es handelt sich bei der Matrix um eine Anordnung von 16x64 ultrahellen LEDs (typ. 20 mA). Da auch "Graustufen" mittels PWM realisiert werden sollen nun ein paar Fragen an euch. 1) Ist meine Beschaltung grundsätzlich geeignet, die Matrix anzusteuern? 2) Benötige ich einen zusätzlichen Widerstand bei dem FET zwischen dem Port des µC und dem Gate-Eingang (Hier im Forum wurde in einem anderen Thread geraten bei hohen Frequenzen eine Kapazität einzubauen)? 3) Welche Frequenz ist bei PWM sinvoll um 8 bzw. 16 Graustufen zu erzeugen? (Laut Datenblatt unterstützen die Bauteile ja bis zu 100MHz) Vielen Dank für Eure Antworten! Matthias So siehts aufm Papier für eine LED aus: (VCC: 5V) | (Emitter ) (Port µC) -----(Basis ) pnp Transistor (BC559C) (Collector) | | (LEDs) | | (Drain ) (Port µC) -----(Gate ) N-Kanal FET (IRLZ34N) (Source) | | (GND)
Angehängte Dateien:
-
matrix.jpg
120 KB
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.
Angehängte Dateien:
-
matrix2.png
34 KB
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.
@Andreas Lang >Naja, kommt immer sehr auf die Schaltung und die Frequenz an. Wenn du's Sicher, aber . . . >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. WIEVIEL? Nenn doch mal Zahlen! Solche Hausfrauenmengenangaben sind hier vollkommen untauglich! Slebst wenn es 500ns Verzögerung wären (was schon verdammt viel wäre) sind das gerade mal 2 Takte bei 4 MHz. >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. Wieviel? >2. Der PNP-Transistor auch. Wieviel? >3. Die Verzögerungen addieren sich. Ach was? >4. Die Raumladungszone im PNP wird nicht aktiv "ausgeräumt" - also kein >Push-Pull. Sicher, aber wir müssen auch nicht in 50ns schalten. Ausserdem fehlt beim PNP der Basisvorwiederstand. Würde er einfach nen NPN nehmen (Kollektorschaltung) wäre die einfacher und schneller. Siehe mein Link. >5. Die Multiplexfrequenz ist recht hoch WIE HOCH? >6. Blaue LEDs leuchten auch bei sehr geringen Strömen schon sichtbar. Mag sein, aber bei 0,0mA sicher nicht. >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. Und ich bleibe dabei, es ist entweder ein Programmierfehler oder ein Schaltungsfeler mit TIERISCH falscher Dimensionierung, und damit ggf. sehr langen Schaltzeiten. Im Hobbybereich nicht selten anzutreffen. Zeig mal deinen Schaltplan. >Das Programm ist übrigens in der Hinsicht sauber, also kein >Programmierfehler. Sagt wer? Mal das Oszi drangehalten? Ausserdem, so wie ich deinen Codeschnipsel interpretiere macht er gerade NICHT das, was ich schrieb? Ich nehme mal an, an PORTD hängen die Spalten(Digits) und PORTB die Segmente? Warum schaltest du nicht gleich am Anfang einfach ALLE DIGITS aus? Statt dessen fummelst du noch mit sowas rum PORTD&=~(1<<2); //Backplane 0 aus MfG Falk
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.
Servus! Vielen Dank für die zahlreichen Antworten. Ich denke, in diesem Forum wende ich mich genau an die richtigen Jungs ;-) Ich fasse mal kurz zusammen: 1) Als Emitterfolger BC846 verwenden aufgrund höherer Schaltgeschwindigkeit! OK, aber nennt mir bitte eine alternative Variante NICHT in SMD! Die Schaltung wird diskret auf Lochraster aufgebaut (zumindest der Prototyp). 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 kümmert sich jeweils um 8 Spalten. Die 16 Zeilen sollen ALLGEMEIN von einem weiteren AVR gesteuert werden! 3) Widerstand vor dem Gate! 10 Ohm? 100 Ohm? 4) exterer Pull-Down am Gate! Wieviel OHM? Ist er nötig, obwohl ich den AT89C2051 nicht inSystem programmiere? Nun kurz zur Software: Alle Spalten-uC laden die Daten aus ihrem Ram und legen jeweils die 8 bit an den Port, an dem die PNP-Transistoren hängen, an. Nun gibt einer dieser uC ein Signal an den Zeilen-uC und der FET der ersten Zeile wird für eine gewisse Zeit (wenige mS) durchgeschalten. Dann FET wieder gesperrt. Daten für Zeile 2 geladen usw.... Hierdurch sollten alle uC immer "gleich weit" im Programmablauf sein und der Ladevorgang des neuen Frames auf der Anzeige nicht sichtbar sein... Hoffe, das ist einigermaßen verständlich ausgedrückt. 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) 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 ;-) So weit, so gut! Bin jetzt für 3 Tage unterwegs, was meiner Motivation das Ding zum Laufen zu bekommen keinen Abbruch tut, aber ich kann evtl. nicht sofort hier antworten! Als Belohnung mach ich euch am Sonntag paar Bilder von dem Board ^^ Lasst eurer Kreativität freien Lauf...
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
Angehängte Dateien:
-
matrix2.png
34 KB
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.
> 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ö.
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.