Hallo, ich suche für eine LED-Matrix 1-aus-10-Decoder-IC's. Hab den 74HCT42 gefunden, aber dort sind die Ausgänge invertiert, ich bräuchte sie nicht invertiert. Kennt jemand da einen vergleichbaren Baustein? MfG Mathias
Danke den kann ich auch nehmen, muss nicht unbedingt nen HC oder HCT sein. Der tuts ja auch.
Ich glaube ich mach es besser mit Schieberegistern. Kennt jemand 10-Bit-Schieberegister?
kurze Verständnisfrage: Ein 1-aus-10 Decoder ist doch auch gleichzeitig ein 4-zu-10-Demultiplexer oder?
> Ein 1-aus-10 Decoder ist doch auch gleichzeitig ein > 4-zu-10-Demultiplexer oder? Nö... 3-zu-8 mag ja noch gehen. Zum Demultiplexen gehört ja auch ein Dateneingang. Wo soll der herkommen...
Ich dachte nur deswegen, bei dem folgenden Datenblatt, schreiben die decoder/demultiplexer. also ist das doch eigentlich daas gleiche. http://www.datasheetcatalog.org/datasheet/philips/74HC_HCT238_CNV_2.pdf
Ein Demultiplexer läßt sich immer auch als Decoder einsetzen, ein reiner Decoder mangels Dateneingang aber nicht als Demultiplexer. Ich weiß aber nicht, ob es überhaupt reine Decoder ohne Enable- bzw. Dateneingang als fertige Bausteine gibt. Übrigens kannst Du auch einen 4-zu-16-Decoder verwenden (z.B. 74154) und die überzähligen Ausgänge einfach ignorieren. Es geht auch mit zwei 3-zu-8-Decodern vom Typ 74138, die man dank invertierender und nichtinvertierender Enable-Eingänge ohne weitere Logik zu einem 4-zu-16 zusammenschalten kann.
Mir ist noch was eingefallen. Einen 74595 und dahinter zwei 4028. Aber dann hab ich gesehen, wenn bei den 4028 auf den 4 Eingängen ein Low-Signal ist, ist der erste Ausgang aktiv. So darf es in meiner Anwendung nicht sein. Da denk ich mal nimm ich am besten den 74154, da hab ich ja den Enable-Eingang. Aber ich bräuchte die natürlich auch nicht invertiert. Kennt da jemand einen?
Was auch noch ne Möglichkeit wär, den 154 als normaler 4-zu-16-Decoder also ohne Enable und mit nicht invertierten Ausgängen. Dann pack ich nen 595 vor den 2 Decodern.
Mathias O. schrieb: > Mir ist noch was eingefallen. Einen 74595 und dahinter zwei 4028. Das macht zusammen drei Bausteine. Da würde ich lieber drei 74595 hintereinander setzen, die 1-aus-10-Decodierung in Software machen, und das Muster für die Ausgangsbits direkt hineinschieben. Damit bist Du nicht mehr davon abhängig, ob das Verhalten irgendwelcher Decoder zu den Anforderungen Deiner Schaltung paßt. Außerdem kannst Du die übrigen vier Bits (wenn Du wie angedeutet zweimal 1-aus-10 brauchst) noch für die Spaltenleitungen verwenden. > Aber dann hab ich gesehen, wenn bei den 4028 auf den 4 Eingängen ein > Low-Signal ist, ist der erste Ausgang aktiv. So darf es in meiner > Anwendung nicht sein. So ist halt die Logik von 1-aus-10-Decodern. Wie bräuchtest Du es denn?
Ich will nur eine Matrix machen, keinen Cube. Dann las ich die restlichen 4 Pins unbeschalten. Ich will eine 10x10 RGB-LED-Matrix. Und bei einem Low-Signal bzw. mehrere, soll halt auch keine Led an sein, was bei den 1-aus-10-Decodern halt anders ist, wenn alle 4 Eingänge low sind, ist halt der erste Pin high, und das soll bei mir nicht sein. Also das einfachste wär drei 595 hintereinander.
Mathias O. schrieb: > Ich will nur eine Matrix machen, keinen Cube. Dann las ich die > restlichen 4 Pins unbeschalten. Ich will eine 10x10 RGB-LED-Matrix. Ah - OK, ich hatte es so verstanden, daß Du die 2x10 Ausgänge für eine Richtung brauchst und dann noch die zweite Richtung dazukommt. > Und bei einem Low-Signal bzw. mehrere, soll halt auch keine Led > an sein, was bei den 1-aus-10-Decodern halt anders ist, wenn > alle 4 Eingänge low sind, ist halt der erste Pin high, und das > soll bei mir nicht sein. Üblicherweise nimmt man so einen Decoder nur für eine Richtung und legt die Singale für die andere Richtung parallel an, also z.B. einen Decoder, um die Spalte auszuwählen und 10 Leitungen auf die man parallel die Zustände der einzelnen LEDs in dieser Spalte gibt. Sind in einer Spalte keine LEDs an, bleiben die Zeilenleitungen eben alle aus, die Spaltenleitung wird aber trotzdem bei jedem Durchlauf aktiviert. > Also das einfachste wär drei 595 hintereinander. Ja, aber auch da ist es besser, beim Multiplexen nicht jede LED einzeln anzusteuern, sondern entweder zeilenweise oder spaltenweise vorzugehen, sonst ist jede LED statt 1/10 der Zeit nur 1/100 der Zeit an.
Es darf aber jeweils nur eine Led an sein, da ich die RGB-Leitungen aller Leds jeweils verbinde.
Mathias O. schrieb: > Es darf aber jeweils nur eine Led an sein, da ich die RGB-Leitungen > aller Leds jeweils verbinde. Ah, daß es sich um RGB-LEDs handelt, hatte ich überlesen. Es ist also im Grunde doch ein Cube mit 10x10x3 LEDs. ;) Da würde ich einfach nochmal zwei 74595 dazunehmen und die Matrix als 10x30 oder 30x10 aufbauen, also jede RGB-LED so ansteuern, als ob es drei einzelne wären. Mach doch mal eine Skizze, wie Du Dir die Schaltung pro LED vorstellst, damit wir nicht länger aneinander vorbei reden...
Angehängte Dateien:
-
1._layout.png
19 KB
Ich hab jetzt mal ein Groblayout gemacht, wie ich mir das in etwa vorstelle. Zur Info, es ist immer nur eine Led an. Also immer eine Zeile und eine Spalte. Die Werte für die Widerstände muss ich noch errechnen und beio den Transistoren hab ich nur den BC337 erstmal genommen. Den genaueren Typ muss ich noch aussuchen.
Soll wirklich immer nur eine LED für den Betrachter sichtbar leuchten oder willst Du das so schnell multiplexen, daß am Ende ein Bild aus mehreren LEDs entsteht? Im letzteren Fall dürftest Du mit der Einzelansteuerung Probleme bekommen.
Ich wollte es multiplexen. Denkst du das Bild flackert? Was nimmt man denn bei den RGB-Leds für eine PWM, also welche Frequenz und Bittiefe, am besten?
Ich habe jetzt nicht durchgerechnet, wie schnell Du sein müßtest, damit es nicht flackert und ob das zu schaffen ist, das größere Problem dürfte nämlich sein, daß die Anzeige zu dunkel wird, weil ja jede LED nur maximal 4% der Zeit an ist (1/25). Daran kannst Du auch durch eine höhere Frequenz nichts ändern. Du kannst zwar den 25fachen Strom durchjagen, falls die LEDs 0,5A Impulsbelastung mitmachen, solltest dann aber sehr genau darauf achten, daß das Multiplexing auf keinen Fall mal aus versehen bei eingeschalteter LED stehen bleibt, sonst brauchst Du an der Stelle eine neue LED. Außerdem müßtest Du die RGB-Leitungen dann noch verstärken, denn die Portpins des Multiplexers liefern sicher kein halbes Ampere. Übrigens ist es bei Deiner derzeitigen Schaltung eher nachteilig, daß Du die RGB-Leitungen ebenfalls aus dem Schieberegister nimmst, denn Du mußt bei jeder Änderung an einer dieser Leitungen zwecks PWM auch wieder die kompletten Zeilen- und Spaltendaten in die Schieberegister takten. Wenn Du also bei der Einzelansteuerung bleiben willst, solltest Du zumindest die RGB-Leitungen direkt an den Controller legen, falls noch so viele Pins frei sind. Wenn Du, wie ich weiter oben schonmal vorgeschlagen hatte, die Ansteuerung spaltenweise machst und die drei Farben innerhalb eines Gehäuses dabei als einzelne LEDs behandelst (also so tust, als ob Du nicht 5, sondern 15 Zeilen hättest), bekommst Du den Duty-Cycle immerhin schonmal hoch auf 1/5. Damit sollte es sich eher arbeiten lassen. Dazu brauchst Du ein Schieberegister mehr, sparst Dir dafür aber die 15 Transistoren, mit denen Du im Moment die Zeilen- und RGB-Leitungen verknüpfst. Für die PWM gibt es dann zwei Möglichkeiten: 1. Du schaltest die Spalten so schnell weiter, daß es eben nicht mehr flimmert und machst auf den Zeilenleitungen PWM, solange die Spalte konstant bleibt. In dem Fall bietet es sich an, dem Spalten-Register einen eigenen Load-Pin zu spendieren, damit Du während des PWM jeweils nur zwei Bytes hinaustakten mußt. 2. Du schaltest die Spalten so schnell wie möglich weiter und entscheidest bei jedem Durchlauf, welche LED gemäß Deinem PWM gerade an oder aus sein soll.
Angehängte Dateien:
-
2._layout.png
14 KB
So hab jetzt nen neue Version. Diesmal ist nicht jede Led an, sondern jede Zeile. Also es werden immer alle Spalten gleichzeitig angesprochen. Somit ist es nicht so wie vorher 1/25, sondern 1/5. Es werden 15 PWM's generiert. Somit brauch ich für die Ansteuerung ein Word(16 Bit) und ein Byte (8 Bit). Noch irgendwelche Verbesserungen?
Das Schieben der Daten durch die Schieberegister solle mit hilfe von Hardware SPI relativ schnell gehen. Das sollte also nicht wesentlich stören, denn Software PWM sollte nicht schneller sein. Die Helligkeitsregelung (WPM) sollte man mit der Matrixumschaltung Syncronisieren. Am besten so, das die LEDs jeweils einen Puls variabler Länge erhalten. Ein extra Bit kann man dabei gewinnen wenn man mit einem Halblangen Zeitschritt anfängt. So kommt man mit der geringsten Zahl an Umschaltungen aus. Dadurch wird das Programm weniger zeitkritisch und man hat weniger Funkstörungen. Statt der Transistoren wäre eventuell ein ULN2003 einfacher, wenn der Strom ausreicht. Mit den LEDs direkt an den HC595 sollte der Strom gerade noch reichen (30 mal ca. 15 mA = 450 mA. Ist aber dann schon knapp, auch mit der Spannung für die blauen LEDs. Es ist etwas die Frage ob die Helligkeit reicht, wenn man nur 15 mA mit 1/10 Tastverhältnis hat.
Ulrich schrieb: > Die Helligkeitsregelung (WPM) sollte man mit der Matrixumschaltung > Syncronisieren. Am besten so, das die LEDs jeweils einen Puls variabler > Länge erhalten. Ein extra Bit kann man dabei gewinnen wenn man mit einem > Halblangen Zeitschritt anfängt. So kommt man mit der geringsten Zahl an > Umschaltungen aus. Dadurch wird das Programm weniger zeitkritisch und > man hat weniger Funkstörungen. Könntest du das genauer beschreiben. > Statt der Transistoren wäre eventuell ein ULN2003 einfacher, wenn der > Strom ausreicht. Mit den LEDs direkt an den HC595 sollte der Strom > gerade noch reichen (30 mal ca. 15 mA = 450 mA. Ist aber dann schon > knapp, auch mit der Spannung für die blauen LEDs. Es ist etwas die > Frage ob die Helligkeit reicht, wenn man nur 15 mA mit 1/10 > Tastverhältnis hat. Wie kommst du auf 30mal, ich würde eher sagen 15mal, es sind schließlich immer 15 Leds (eigentlich 5) an.
Kann denn jemand sagen ob das jetzt so in Ordnung aussieht. Und etwas bezürlich meiner Antwort auf Ulrich sagen, ob ich Recht habe mit den 15mal und vielleicht weiß einer was Ulrich mit dem ersten genau meinte.
Ich hab mir grad überlegt, ob ich anstatt den 74HCT595, vielleicht PCF8574 benutze und dann mit I2C ansteure. Ist das vielleicht besser dafür?
"Besser" ist relativ. Ich zähle mal die Vor- und Nachteile der PCF8574-Lösung auf: Vorteile: - Braucht noch weniger I/O-Pins - Die Bausteine sind einzeln addressierbar Nachteile: - Kostet (bei Reichelt) mehr als fünfmal soviel wie ein 74HC595 - Es muß außer den Daten auch jedes Mal die Adresse übertragen werden, bei gleichem Ausgabetakt erreichst Du damit also nur die halbe Geschwindigkeit. Warum nimmst Du eigentlich nicht einfach einen Mikrocontroller, der genügend I/O-Pins hat, die Du direkt ansteuern kannst? Für den Preis von 1-2 PCF8574 bekommst Du z.B. schon einen ATmega48 oder ATmega88, den Du ebenfalls per I2C anbinden und so programmieren kannst, daß er das Multiplexing selbständig macht und vom Haupt-Controller nur dann neue Daten bekommt, wenn sich der Display-Inhalt ändert.
Du meinst ich soll fürs Multiplexing einen eigenen Controller nehmen und den per I2C die Daten von einem anderen Controller geben?
Nein. Bau dein ganzes Projekt mit einem größeren AVR auf und leg den jetzigen unter dein Kopfkissen.
Du meinst ohne Schieberegister? Dann bräuchte ich einen mit min. 20 IO-Pins. Ich wollte den Controller aber so klein wie möglich halten. Der Controller gehört zu einer größerenen Gruppe von anderen seiner Art und diese sollten alle von einem Hauptcontroller die Daten kriegen.
@ Mathias O. (m-obi) >Du meinst ohne Schieberegister? Dann bräuchte ich einen mit min. 20 >IO-Pins. Ja und? Mega8 im DIL28 Gehäuse tuts. > Ich wollte den Controller aber so klein wie möglich halten. Warum? Ist 1,50 zu teuer? Und mehr Platz und Verdrahtung braucht die Schieberegisterlösung zusätzlich. >Controller gehört zu einer größerenen Gruppe von anderen seiner Art und >diese sollten alle von einem Hauptcontroller die Daten kriegen. Wo ist das Problem? RS232, RS485, I2C und wasweissichnoch macht der spielend nebenbei. MFG Falk
Mathias O. schrieb: > Du meinst ich soll fürs Multiplexing einen eigenen Controller nehmen und > den per I2C die Daten von einem anderen Controller geben? Entweder das oder wie Magnus es vorgeschlagen hat, einen Controller der groß genug für alles ist. Wenn Du noch ein bißchen mehr darüber verrätst, was das Ganze am Ende werden soll, ist es auch einfacher, Dir einen konkreteren Rat zu geben. > Du meinst ohne Schieberegister? Ja. > Dann bräuchte ich einen mit min. 20 IO-Pins. Die, die ich vorgeschlagen habe, haben dafür genug Pins. > Ich wollte den Controller aber so klein wie möglich halten. Warum? Du sparst dadurch weder Zeit noch Geld noch Platinenfläche noch Strom.
Also wie ihr oben vielleicht schon gesehen habt, soll das eine RGB-Led-Matrix werden. Zu Ansteuerung bruach ich da insgesamt 20 Pins. Dazu soll der Controller über I2C seine Daten bekommen, also noch SDA und SCL. Den Mega8 kann ich nicht nehmen, weil ich möchte gerne einen XTAL und den Reset auch dranmachen, weil dort gehören sie zu den IO-Pins. Besser wäre da der Mega16. Oder?
@ Mathias O. (m-obi) >und SCL. Den Mega8 kann ich nicht nehmen, weil ich möchte gerne einen >XTAL und den Reset auch dranmachen, weil dort gehören sie zu den >IO-Pins. Quark^3. Der mega8 ist problemlos nutzbar, auch mit XTAL. Und für I2C brauchst du aber keinen Quarz, nur für RS232. > Besser wäre da der Mega16. Oder? Nöö. MFG Falk
Hi
>Aber ich brauche für die PWMs den XTAL.
Nö. Bei der PWM ist das ON/OFF-Verhältnis entscheidend, nicht die genaue
Frequenz.
MfG Spess
Mathias O. schrieb: > Den Mega8 kann ich nicht nehmen, weil ich möchte gerne einen > XTAL und den Reset auch dranmachen, weil dort gehören sie zu den > IO-Pins. Besser wäre da der Mega16. Oder? Wenn der interne Oszillator schnell genug ist brauchst Du keinen XTAL, denn wie spess53 schon gesagt hat, kommt es auf die Genauigkeit nicht so an. Falls Du aber noch nicht weißt, ob Du den Controller nicht schneller takten mußt, bist Du für einen ersten Prototypen mit dem Mega16 erstmal auf der sicheren Seite. Sollte sich nachher herausstellen, daß der interne Oszillator doch reicht, kannst Du für die Massenproduktion ja immer noch einen kleineren Typen nehmen.
Eben deswegen. Ich weiß noch nicht ob der interne reicht. Deswegen würd ich dann auch zum Mega16 tendieren.
@ Mathias O. (m-obi) >Eben deswegen. Ich weiß noch nicht ob der interne reicht. Der interne RC-Oszillator macht 8 MHz. Da langweilt sich der AVR mit dem bissel Muxen zu Tode. MfG Falk
ist ja nicht nur das Muxen, sondern auch die PWMs für die Farben und dazu das Dimmen. Reicht der dann trotzdem? Wenn ich den Mega16 nehmen würde, müsst ich den TQFP nehmen, der DIL ist zu groß.
@ Mathias O. (m-obi) >ist ja nicht nur das Muxen, sondern auch die PWMs für die Farben und >dazu das Dimmen. Reicht der dann trotzdem? Ja. > Wenn ich den Mega16 nehmen würde, müsst ich den TQFP nehmen, > der DIL ist zu groß. Dann nimm ihn. MfG Falk
Falk Brunner schrieb:
> Dann nimm ihn.
Das klingt so nach dem Motto. Dann nimm den doch und las mich in Ruhe.
Nachdem das mit dem Controller wohl langsam geklärt ist, sollte man noch mal über das Multiplexing nachdenken. 15 20mA LEDs in 5 Reihen macht 1.5A Reihenstrom für den armen BC337 und 100mA Spaltenstrom aus 5V mit einem UDN2981 an unter anderem blauen LEDs (also 3.6V bis 4V alleine für die LED). Daß das so nicht klappt, ist offensichtlich, schon die 150mA Basisstrom für einen gesättigten BC337 kann man nirgendwo herzaubern, 4V für die LED, 2V für den UDN2981, 1V für den Reihentransistor wenn es denn kein ULN2803 Darlington wird, und mindestens 1V für den 15R Vorwiderstand damit er trotz Schwankungen des Spannungsverlusts der anderen noch halbwegs den Strom definieren kann, macht schon mal 8V als Betriebsspannung. Etwas Grundlagen zu Multiplex in http://dse-faq.elektronik-kompendium.de/dse-faq.htm#F.8.1
Ich hatte den Transistor gewählt, weil ich am Anfang immer nur eine Led anhaben wollte. Jetzt ist es so es sind immer 5 Leds gleichzeitig in einer zeile an. Und wieso hast du denn den Strom für alle Zeilen berechnet, du musst es doch nur für eine Zeile berechnen, also 300mA. Oder sehe ich das falsch?
@ Mathias O. (m-obi) >berechnet, du musst es doch nur für eine Zeile berechnen, also 300mA. >Oder sehe ich das falsch? Ja, das tust du. Beim Multiplexing muss der Pulsstrom um den Faktor N (=Anzahl Zeilen) höher sein, um die gleiche Helligkeit zu erreichen. Siehe LED-Matrix MFG Falk
Achja das hatte ich vergessen. Deswegen muss ich den mit 5 multiplizieren, also 1,5 A pro Zeile. ui das ist viel. Ob ich den ULN noch dahin packe, statt den Transistoren, bin ich noch am überlegen.
Dazu kommt noch, dass von diesen Modul, was es später dann wird, noch 9 Stück dazu kommen. Also die werden alle per TWI angesprochen und der Versorgung und Rest wird durchgeschliffen. D.h. ich komme dann auf 15A für die Versorgungsleitungen. Dies Wollte ich im Prinzip mit Wannestecker und Flachbandkabel lösen. Aber ich habe da noch keine gefunden für die hohe Amperezahl. Also muss ich wohl oder übel Steckverbinder nehmen, die dann viel Platz wegnehmen oder weiß jemand eine andere Lösung?
@ Mathias O. (m-obi) >Wannestecker und Flachbandkabel lösen. Aber ich habe da noch keine >gefunden für die hohe Amperezahl. Also muss ich wohl oder übel >Steckverbinder nehmen, die dann viel Platz wegnehmen Für VCC/GND kann man Klemmleisten nehmen. MFG Falk
Du meinst ich soll Printklemmen verwenden? Das ganze durchschleifen ist doch viel einfacher.
Erst mal: Willst du wirklich nur ENTWEDER die rote, die grüne ODER die blaue LED leuchten lassen, oder nicht doch manchmal alle 3 anmachen für weisses Licht ? Sind nie alle 3 an, sondern stets nur 1, reicht natuer 1/3 des Stromes. > Wannenstecker Mehrere Pins parallel ? Sternverdrahtung vom Netzteil aus ? (eh sinnvoll). Statt Stecker ein Modul mit dem Nachbarmodul über drübergelegte blanke Drähte verlöten? Bei 15A impulsförmig geschaltetem Strom wird das Ding bereits zur deutlichen Störquelle. Wie schrieb die FAQ: Multiplexanzeigen aufzubauen ist einfach, die Kunst liegt darin, sie EMV verträglich zu machen (und bei Videowänden die gleichmässige Helligkeit der Lichtpunkte zueinander aus jedem Betrachtungswinkel sicherzustellen).
Also ich möchte natürlich alle Leds der RGB-Led ansteuern, da ich alle möglichen Farben haben möchte. D.h. pro Modul 1,5A Spitze. Also wenn ich dann 10 Module haben kommen da 15A zusammen da ja alles an einem Bus hängt, welches ein gemeinsames Netzteil haben. Zum Thema EMV: Da ich ja praktisch eine Platine habe mit den Leds, dann da unter eine mit den Controller und den Treiberbausteinen. Dann würde ich noch da unter eine machen wo dann der Bus lang geht, also SDA, SCL, Reset, GND, Versorgung Controller und Versorgung UDN/ULN. Oder ich nehme als Busleitung eine geschirmte. Kann man irgendwie pi mal Daumen sagen, wie stark die EMV-Strahlung sein könnte, was von den beiden Möglichkeiten ausreichen? Achja die Busplatinen von der ersten Möglichkeit würde ich mit diesen Direktsteckverbinder miteinander verbinden: https://eshop.phoenixcontact.de/phoenix/treeViewClick.do?UID=1915699&parentUID=&reloadFrame=true
Ich hab mich nun entschieden es kommen max. 5 Module in eine Reihe. Also insgesamt 7,5A.
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.