ich bin auch am entwickeln eines RGB Led Cubes.
Allerdings mit einem etwas anderen Ansatz als die meisten anderen.
Meine Lösung ist sehr PC basiert. Ich habe eine Serversoftware für den PC unter QT und C++ geschrieben.
Diese unterstützt folgende Funktionen:
-Pattern Editor (einzelne Pixel oder Gruppen können mit 256^3 verschiedenen Farben eingefärbt werden)
-Simulation des Würfel in OpenGL
-Bewegtbilder (einzelne Fixbilder können zu Bewegtbildern zusammengefügt werden und so eine Animation von Hand erstellt werden)
-Speichern von Bildern und Filmen
Für die Zukunft sind noch folgende Features geplant:
-Farbübergänge(wie weiß ich noch nicht so wirklich, aber da fällt mir sicher noch was ein)
-Anbindung an Winamp/iTunes etc. Visualisierung der Musik auf dem Würfel
-Verbindung zum Würfel über TCP/IP
-Kaskadierung von Würfeln. (Die Patterns werden aufgesplittet und an verschiedene IP Adressen verteilt. So können Kompakt gebaute Würfel nebeneinander gestellt werden und als ein großes 3D Display angesteuert werden)
-Komplexe Animationen, die automatisiert Ablaufen
-eventuell Ansteuerung über eine Software Midi Schnittstelle. Hier habe ich noch keine Ahnung wie ich das realisieren soll. Muss aber irgendwie gehen.
Der Würfel soll als Basisplatine das AVR Net IO von Pollin verwenden.
Darauf möchte ich eine modifizierte Arduino Version laufen lassen um die Programmierung zu vereinfachen.
Arduino unterstützt z.B. von Haus aus den ENC28J60.
Das Projekt möchte ich gerne als OpenSource veröffentlichen und hoffe bei späteren Funktionen auch auf Mithilfe.
Ich bin allerdings Informatiker und kein Elektroniker. Deshalb bräuchte ich beim Schaltplan und der Auslegung der Hardware ein wenig Hilfe.
Ich möchte Leds mit gemeinsamer Anode(-) verwenden.
Die Ansteuerung möchte ich über 16*3 Säulen realisieren.
Die führt dazu dass ich 48 Ausgangspins bräuchte. Recht einfach scheint eine Ansteuerung der 74HC595 zu sein. An diese kommt man auch sehr einfach. Ich steuere also die LED Kathoden aller LEDs in einer Säule gemeinsam an.
Um jede LED einzeln anzusteuern muss ich aber noch irgendwie durch die Ebenen Multiplexen. Dies würde z.B. über BC547 funktionieren. Um den Lötaufwand etwas geringer zu halten dachte ich an das Darlington Array ULN2803A. Hier möchte ich dedizierte Portpins pro Ebene verwenden.
Warum? weil ich sie zur Verfügung habe und es die schnellste Lösung ist.
Die ULN2803A haben soweit ich weiß interne Widerstände?
Ich denke dann benötige ich keine Vorwiderstände mehr für die LEDs.
Sehe ich das Richtig?
Wenn nein? Welche Werte benötige ich denn?
Ich nehme an zwischen den 74HC595 und den LEDs selbst?
Desweiteren Frage ich mich wie das mit den Strömen bei den LEDs aussieht. Durch das Multiplexing habe ich ja bei den normalen 20mA einen Helligkeitsverlust.
Nach meinem Verständnis müsste ich ein 1/4 Multiplexing haben, da ich ja die einzelnen Farben der einzelnen LEDs in jeder Ebene gleichzeitig Ansteuern kann.
Laut Datenblatt sind 200mA für den kompletten Controller und 40mA pro Ausgangspin ok.
Das heißt als maximalen Strom pro Led kann ich 40mA festlegen. Das bedeutet beim 1:4 Multiplexing eine Helligkeit wie bei 10mA pro Led.
Ist das noch ausreichend von der Helligkeit?
Ich komme dann auf eine Belastung des Controllers mit 40*3mA also 120mA. Das dürfte Save sein.
Sind meine Überlegungen soweit korrekt?
Nun zu meinem Problem. Die 74HC595 haben soweit ich das verstanden habe keine Slave Select Leitung. Am SPI hängt aber der ENC28J60.
Demnach muss ich die 74HC595 ja über Software SPI ansteuern.
Reicht die Geschwindigkeit hier für PWM noch aus?
Ich dachte an 4bit PWM in Software? Das sollte für einen flüssigen Farbübergang doch ausreichen?
Wichtig: Das ganze sollte problemlos nachzubauen sein (auch auf Lochraster). Deshalb bitte keine SMD Bauteile empfehlen!
Außerdem habe ich ncoh eine Frage zur Auslegung des Netzteiles. Kann ich da auf dem 7805 bleiben? Der kann ja 1A Problemlos.
Sollte ich ja eigendlich nicht überschreiten wenn ich das richtig überlegt habe, oder?
Habe ich sonst noch irgendetwas wichtigs vergessen?
Im Anhang der Schaltplan, bei dem ich mir nicht sicher bin und ein Bilder der Software.
kuck mal nach Max7221 oder Max7219.
Das sind Multiplexerchips, einfach anzusteueren und beherrschen bis zu 100 LEDs (musste noch genau nachschauen). Wie PWM da machbar ist (ist mit sicherheit machbar) müsste man noch klären.
Aber ist glaub ich einfacher als selbst zu multiplexen.
Im Schaltplan sind noch keine Widerstände zu den LEDs. Ohne wird bei RGB LEDs schwierig, schon wegen der verschiedenen Spannungen.
Für eine einigermaßene Helligkeitsregelung wird man mher als 4 Bits brauchem. Wegen des nichlinearen Helligkeitsemppfinden sind selbst 8 Bit nicht so reichlich.
Die Geschwindigkeit des µC reicht für software PWM (8 Bit) gerade so aus, wenn man sich mit dem Programm etwa Mühe gibt. Viel Rechenzeit ist dann aber vermutlich nicht mehr über, und man braucht eine Hardware SPI Verbindung. Das könnte das SPI Interface oder die USART sein. Wobei ich nicht weiss ob die USART schnell genug ist. die müßte man dann eventuell für die andere VErbindung nutzen. Entsprechend müßte man etwas andere Pins wählen.
Wie viel Rechnzeit die Ethernet verbindung braucht weiss ich nicht, dass sollte man vorher nachsehen, ob noch genug übrig ist.
Vom Strom her sollte der 7805 noch reichen, wohl aber mit Kühlkörper.
Mehr als 70 mA sollte einer HC595 nicht liefern (limit aus dem Datenblatt), also maximal 420 mA gesamt. Auch der ULN2.... kann ja nur 500 mA maximal.
Ist ein wenig die Frage ob die LEDs mit ca. 8 mA und 1:4 multiplexing hell genug sind. Das entspricht etwa 2 mA Dauerstrom pro LED.
Edit:
Wenn das Datenblatt stimmt, sollte die Helligkeit zumindest im Zimmer ausreichen.
ich hab ich mir schon angeschaut. Die werden z.B. beim Arduinome verwendet http://en.wikipedia.org/wiki/Arduinome
Diese können aber soweit ich wei kein PWM. Fallen also weg
Mittlerweile ist mir noch folgendes eingefallen:
1.Die Belastbarkeit der PIN Outs des AVR sind unerheblich, da sowieso alles entweder an den ULN oder an den 75HC595 hängt
2.Die Pins des 74HC595 sind bis 35mA belastbar. Gesamtbelastbarkeit liegt bei 500mW für den Chip.
3. Natürlich brauche ich Vorwiderstände. die ULN2803 haben diese nicht eingebaut, da es nur ein Darlignton Array ist.
4. Es wäre Vernünftiger den AVR an 5V laufen zu lassen (um die 16Mhz problemlos zu erreichen) und ein eigenes Netzteil für die LEDS auszulegen, welches sinnigerweise mit 3.3V läuft. Damit würde ich am wenigsten Leistung an den Widerständen verheizen.
Ist das überhaupt problemlos möglich? Ich denke in der aktuellen Variante müsste ich dann die 74HC595 mit 3.3V versorgen. Ist der 5V Pegel des AVR dann ein Problem?
Wie erzeuge ich die 3.3V am sinnigsten?
Fazit:
Ich gehen davon aus wenn ich zwischen die 74HC595 und die LEDs Vorwiderstände löten würde würde das funktionieren. Zwar hart am Limit der 74HC595, aber es würde wohl gehen.
Da ist Optimierungspotential da.
Da meine Software extrem flexibel ausgelet ist und beliebige Würfelgrößen unterstzützt wäre es schön da noch etwas mehr Spielraum zu gewinnen. Schön wären vor allem ICs zur Ansteuerung, die PWM selbst können. D.h. ich gebe über I2C, SPI etc den Wert vor und der IC berechnet PWM dafür.
Je mehr Logik ich in ICs auslagere, desto weniger Rechenpower benötige ich im AVR.
Ergo: Je mehr Logik außerhalb, desto mehr Leds können berechnet werden.
Die elektrischen Grenzen der Bauteile machen mir allerdings noch deutlich mehr sorgen.
Was man also bräuchte wäre einen Baustein wie den Max7221 im Dil Package (kleiner schwarzer Käfer mit vielen Beinen) der am besten über I2C angesteuert wird un PWM kann. Kennt da jemand was?
Dann bräuchte man auch so gut wie keine weitere Externe Hardware zur Ansteuerung und könnte problemlos mit 5V fahren.
Gefunden habe ich hierzu den MBI5030. Das ist ein 16 Kanal Led Treiber mit 12bit PWM! WOW!!!
Davon 3 Stück und man hätte schon die komplette PWM Sache abgedeckt und würden den Atmega damit nicht belasten.
Leider hat der Chip noch einige Nachteile:
-SPI wird unkonventionell angesteuert. Da is auch nix mit Hardware PWM
-Benötigt einen externen Takt mit maximal 8Mhz =>woher nehmen. da braucht man wieder Hardware... Ist aber ein kleines Problem. könnte man nen Atmega48 nehme. die kosten ja kaum was und können das Taktsignal ausschleifen.
-Löst nicht das Problem mit dem Ebenenmultiplexing
-45mA maximaler Ausgangsstrom... Naja geht bei 1:4 Multiplexing wohl, aber auch bei mehr noch?
-SMD Package (SSOP24). Wenns da nen Dil Adapter gäbe wäre das kein Problem
Und dann gibts da noch den TLC5940!!!
Dieser scheints quasi für meine belange gemacht zu sein!
-Dil28 Package
-12Bit PWM
-16 Kanal LED Treiber
-120mA maximaler Ausgangsstrom pro Kanal! Das ist super und sollte sogar für 1:10 multiplexing noch funktionieren!
Der Chip scheint außerdem keinen externen Takt mehr zu benötigen.
Hier wird er verwendet: http://www.thebox.myzen.co.uk/Hardware/Mini_Monome.html
Das Ding hat nur ein Problem. Der Chip scheint zwischen 7 und 8 Euro zu kosten....... Das ist starkes Stück. Eventuell bekommt man da Samples bei Ti? Wenn der Chip für mich taugt werde ich mal versuchen dort ein paar als Samples zu bestellen.
Stellt sich nun die Frage ob der ULN2803 geeignet ist für mein vorhaben. der kann wohl 500mA pro Kanal.
Meine Rechnung ergibt nun
16*3*80mA=3680mA...
oha....
Da drängt sich doch die Frage auf, ob ich das nicht besser diskret mit Mosfets aufbaue?
Mit denen habe ich allerdings keine Erfahrung. Welche kostengünstige Lösung würde sich anbieten?
So das war nun anstrengend, aber ich möchte ja zu einer möglichst guten und skalierbaren Lösung kommen. Ich zeichne kurz noch nen Schaltplan zu meinen überlegungen
so, ich hab mich nun mal durchgebissen.
Der TLC scheint wirklich das Richtige für mich zu sein.
Dieser besitzt 2 Modi.
-Grayscale für die PWM Regelung
-Dot-Corretion für den Ausgleich von Fertigungstoleranzen der LEDs.
Letzterer Speichert Einstellungen in einem internen EEPROM.
Da ich auf besonders gute Farbdarstellung nicht angewiesen bin habe ich den Modus einfach mal ignoriert und die Pins so an Mass und Vcc angeschlossen, dass immer der Grayscale Mode aktiv ist.
Als Widerstand für die Referenz habe ich 640 Ohm gewählt. Das führt zu einer maximalen Versorgungsstromstärke von 60mA pro Led.
Damit komme ich auf 60mA*16 pro TLC => 960mA..
Das ist immernoch zuviel. Die TLC können im Dil Package maximal 2.5W
mit 960mA komm ich dann aber fast auf 5W.
Als N-Fets habe ich die IRF630 gefunden.
Kann ich die hierfür verwenden?
Diese packen 9A. Das reicht sowieso dicke für alle Würfelgrößen.
Als Pulldown habe ich mal 1k Ohm gewählt.
Vorwiderstände brauche ich ja dann nicht mehr bei dem TLC wenn ich das richtig verstanden habe.
Aber wie löse ich nun das Problem mit der zu großen Leistung auf den TLCs? P-Fet zwischen Leds und TLC und damit den Vorteil der Strombegrenzung zu nichte machen? Den Strom reduzieren?
PWM realisiert ja dann der TLC. D.h. ich bräuchte hierfür keine Rechenleistung mehr im AVR.
Passt das dann mit dem Netztwerkcontroller am SPI und Softwarespi für die TLCs, oder bin ich dann immernoch zu langsam?
Die HC595 haben zwar 35 mA als absolute maximum rating für die Ausgänge, aber 1. ist nicht garantiert das die selbst im Kurzschlußfall so viel Strom liefern. Bei 3.3 V versorgung wäre das schon eher die Ausnahme. Zweitens ist das noch ein Limit von 70-75 mA für den gesamten Chip. Das Limit sind damit ca. 8-9 mA pro Ausgang.
Für die LEDs sind auch 5 V gar nicht verkehrt:
die blaue LED wird 3-3,5 V brauchen, dann ca. 500 mV Verlust für den HC595 und gut 1 V für den ULN2003. Da ist dann nurnoch 0,5 V für den Widerstand übrig. Weniger geht also kaum. Bei nur einer LED Farbe und Treibern aus der gleichen Charge könnte man gar auf die IDEE kommen den Strom über die Spannung an den HC595 (ca. 4,5 V) einzustellen. geht hier aber nicht.
Bei superhellen LEDs kann es gut sein das es auch mit dem Strom von nur 8 mA geht, hängt aber von den Randbedingungen ab !. Es gibt zum Teil auch Schieberegister ähnlich dem HC595, die mehr Strom vertragen können (z.B. STP16CL596).
Bei mehr Strom für die Ebenen wären MOSFETs statt des ULN möglich. Bis etwa 5 A könnte man die wohl auch noch direkt von µC Pin aus ansteuern.
Wenn man extra ICs nimmt, die einem das PWM Signal bereitstellen, hat man das Problem das PWM Signal mit dem Umschalten der Ebenen zu syncronisieren. Da Wäre ein Chip mit externem Takt schon gar nicht verkehrt. Schwierig wird das vor allem wenn man mehr als einen Chip für die PWM Signale hat.
Eine Möglichkeit wäre eventuell auch die LEDs direkt von einem µC zu Treiben, der dann auch die PWM Signaler erzeugen könnte. Wegen dem 200 mA Limit pro Vcc Pin wird man damit aber auf vielleicht 16 LEDs (je 20 mA) pro Chip kommen. Für den 4x4x4 Würfel also schon 3 µCs (z.B. Mega4. Bei nur 16 Kanälen hat man schon etwas mehr Reserve für Software PWM.
Der IRF630 geht nicht, weil kein Logic level. Außerdem braucht man keinen 200 V Typen. Richtig wäre ein Logoc Level N MOSFET für etwa 30 V und 10 A. Die meisten Typen sind in der Größe aber in SMD gehäusen zu kriegen, oft als 2 Stück im SO8. Mit etwas gefummel geht das noch auf Lochraster. Als Type im TO220 wüßte ich einen IRLZ24 - Denn sollte man noch gerade direkt treiben können.
Das Problem mit der Leistung am TLC... Treiber ist nicht ganz so groß. Man muß nicht rechnen Strom mal volle Spannung (5V) sondern nur Strom * Spannungsabfall. Da sollten nur rund 2 W rauskommen, ist aber immer noch viel für ein DIP gehäuse. Eventuell die Spannung etwas reduzieren, auf z.B. 4,5 V, wenn der Chip das mit macht.
Das Syncronisieren von PWM und Ebenenumschaltung sollte immerhin gehen mit dem TLC5940.
das ist ja schonmal ein anhaltspunkt.
An die Lösung mit den Slavecontrollern habe ich auch schon gedacht. Das könnte die Sache schon deutlich vereinfachen.
Nach meinem Verständnis fällt dann auch das Multiplexing weg, da ich für jeden Ebene Spalte, oder Zeile ja einen eigenen µC habe.
Mein Verkabelungsaufwand wird dann allerdings aber auch viel größer, da ich ja dann sinnigerweise Spaltenweise ansteuere und so pro Spalte 4 Kathoden rausführen muss (pro Ebene eine)
Von meinem Verständnis her scheint die Lösung mit den TLCs bisher die beste zu sein. Laut Datenblatt dürfen die Teile die 2W auch.
Schön, dass ich mich da verrechnet habe
Die Spannung reduzieren kann man auch. dei TLCs benötigen keine 5V damit sie arbeiten.
Ich könnte aber auch für die 1:4 Multiplexing Methode einfach auf 40mA gehen und mal probieren ob das hinhaut.
Macht es Sinn die TLCs irgendwie passiv zu kühlen, oder ist das vergeudete Mühe?
Wie sieht es denn bei den FETs für die IRLU120N aus?
Die sind Logic Level 100V 10A und sind in einem Package, das für Lochraster brauchbar ist. Dazu auch noch sehr günstig mit 36Cent.
Würden die funktionieren? Was für einen Pulldown würde ich da benötigen?
Irgendwie 100% zufrieden bin ich noch nicht mit der Lösung.
Eines geistert mir noch im Kopf herum. Was passiert wenn ich mit den TLC5940 nicht direkt die Leds fahre, sondern wiederrum Logic Level Fets?
Dieses mal einen P typ und die Leds dahinter mit Vorwiderstand hänge?
Gibt einen furchtbaren Lötaufwand, aber wäre das was?
Vielleicht hat ja jemand noch ne tolle Idee?
Am elegantesten wäre sicher die Lösung mit dem µC pro Spalte. Das wäre auch super skalierbar.
Hat da jemand noch kreative Ideen dazu?
Man müsste dann Atmega88 oder Atmega8 nutzen um Arduino verwenden zu können. Der 48 unterstützt den Bootloader nicht
so ich nochmal.
Ich habe mir die Sache mit den Atmegas als Slaves nochmal durch den Kopf gehen lassen.
Arduino muss nicht unbedingt sein und ist in diesem Fall auch nicht unbedingt einfacher. Es gibt soviele schöne Webserver, die ich auch verwenden könnet.
Die Schaltung mit den Slaves und dem Master habe ich angehängt.
es funktioniert wie folgt:
Der Atmega32 empfängt über SPI die Pakete, die über den ENC28J60 und das Netzwerk angekommen sind.
Empfangen wird dann so was wie 0 0 0 255 255 255.
Das bedeutet. Led in Spalte 0, Zeile 0 und Reihe 0 hat Rotwert 255 Grünwert 255 und Blauwert 255.
Der Atmega32 ermittelt nun welcher Slave für 0 0 0 zuständig ist und schickt Zeilen und Spalteninformation für die 2D Matrizen sowie die Farben an diesen.
Die Atmega48 erhalten zur Synchronisation mit dem Master das Taktsignal über den Taktausgang des Atmega32.
Der Atmega 32 kümmert sich selbst um die Umschaltung der Ebenen.
Immer wenn eine Ebene umgeschaltet wird wird über den PC2 des Masters ein Interrupt auf den Slaves ausgelöst. Diese schalten dann die Zeile ihrer 2D Matrix um.
Um das Stromproblem der Atmegas zu lösen habe ich für die Ebenen n Channel Fets gewählt und für die Anoden PNP Transistoren.
Jeder Atmega muss dabei dann 12 Software PWM Signale generieren wenn ein 4x4x4 Würfel verwendet wird.
Mit den Atmega48 Pins komme ich auf eine maximale Anzahl von 6x6 Leds pro Ebene. Bei 100mA Impulsstrom kommt man mit 10mA Referenzstrom auf eine maximale Größe von 10x6x6!
Das sollte dicke reichen. Will man mehr kann man die Würfel ja kaskadieren. Mit 4en kommt man dann auf 10x12x12.
Ist die Lösung, die ich erarbeitet habe so gut?
Folgendes steht noch offen?
1.) Sind die BC327 als PNP dafür geeignet? Kann ich diese direkt am Portpin schalten? Ist die Ansteuerung richtig?
2.) Wie groß muss ich die Vorwiderstände für die einzelnen Farben bei einer 4x4x4 Matrix wählen.
3.) Sind die IRLU120N geeignet Als Fets für die Ebenenanschaltung?
Ist der Pulldown Widerstand mit 1k Ohm richtig gewählt?
Sind die Fets richtig angeschlossen, oder ist da irgendwo noch ein Fehler?
Wenn die Verschaltung der LEDs so richtig ist, also mit gemeinsamer Anode, geht das so nicht. Dann müssen die µCs jeweils die Kathode gegen GND schalten und die FETs für die Ebenen müßten P_Typ sein, also gegen ca. +5 V schalten.
Die BC327 kann man so nicht direkt vom µC aus schalten, da müßten Widerstände dazu. Da man ja vom µC aus gegen GND schalten müßte, wären da entweder NPN Transostoren (z.B. BC33 als Emitterschaltung oder halt die ULN2003 möglich. PNP Transisoren als Emitterfolger würden auch gehen und spart die Basiswiderstände, dafür hat man aber etwas mehr Spannungsverlust.
Bis etwa 20 mA könnte man auch direkt vom µC aus Treiben, also ganz ohne Transistor.
Die Widerstände hängen vom nötigen Strom und den Treibern ab. Man wird auch je Farbe einen anderen Wert brauchen.
Die FETs IRLU120N wären eingschränkt nutzbar, wenn man N MOSFETs bräuchte, aber hier werden Wohl P-MOSFETs gebraucht. Da wird die Suche nochmal etwas schwieriger. Abgesehen vom Gehäuse wäre dann ein IRF7314 etwa richtig. Auf Lochraster müßte man halt ein paar Punkte Teilen (1 mal je FET).
1 K also Widerstand an der FETs ist schon ziehmlich klein, es geht aber.
. Bei nur 16 Kanälen hat man schon etwas mehr Reserve für Software PWM.
Berechtigungen
Zitieren
Lesezeichen