guten Morgen Habe zusammen mit einem Kollegen ein Projekt in Überlegung, die Decke unseres Partyraums mit 100 ultrahellen LEDs (quadratisch angeordnet) zu verschönern und auch zur Ausleuchtung zu nutzen. Da ein einfaches Dimmen aller LEDs gleichzeitig sehr langweilig wäre, kam mir der Gedanke jede LED einzeln über 255 Stufen (1Byte) dimmbar zu machen, um so kleine Animationen auf der Decke laufen zu lassen. Habe im Forum schon nette Anregungen gefunden, zB mit einem Maxim Segmenttreiber oder Schieberegistern, leider aber keine aussagekräftigen Beispielschaltungen. Hättet ihr ein paar Links oder Schaltungen auf Lager? Kann mich an ein Mitglied (Flash Gordon) erinnern, der das ganze über 3 ICs gelöst hat. Natürlich möchte ich auch einen AVR verwenden, aber das Programm in BASCOM schreiben, da meine Assembler Kenntnisse leider sehr zu wünschen übrig lassen. ;) Kennt jemand vielleicht ein paar ähnliche Projekte, wie meines? Bin für jede Hilfe dankbar :)
Ach habe noch etwas vergessen. Da die Animationen schon bei 20Hz Wiederholfrequenz schon einen Speicherbedarf von knapp 2Kb pro Sekunde haben, wollte ich die Dateien auf eine SD Karte auslagern. Die Animationen selbst wollte ich per selbstgeschriebenem Programm am PC erstellen. Ist es möglich die Animationen in Echtzeit von der SD Karte zu holen oder sollte ich sie vorher im RAM des AVR cachen?
das sollte ja auch kein vollständiges Bild geben... außerdem ist der Raum ziemlich klein. Wie gesagt soll das ganze nur als Teilbeleuchtung dienen, so hell mögen wirs da unten eh nicht ;) Die LEDs stehen auf jeden Fall schon bereit.
Wenn es ganzu einfache animationen sein sollen alá eine LED (oder mehrer parallel geschaltete) dann kannste das doch einfach mit dem Microcontroller realisieren. Das mit dem Dimmen ist so eine Sache endweder ein PWM ausgang oder eine Software Lösung. Ich wollte auch meine LEDs Dimmen auf Seite 2 ist mein Post. bei mir waren es aber nur 3 versch. farbige LEDs die lansgam an gehen sollten und so unterschidliche farb effekte erziehlen sollen ist recht komplex
Ich dachte an ein Software PWM und eine Matrix. Quasi 20 Zeilen an den µC und 5 Spalten die ich über Transistoren nacheinander durchschalte. (Schieberegister) Es kommt halt auf den Aufwand und die Kosten an, drum habe ich mich erstmal auf 100 LEDs beschränkt weil ich mir auch zum Anfang nicht zu viel zumuten wollte.
Von einer Matrix-Schaltung möchte ich eher abraten. Ein Atmega kann bei 10 LED eine (Software-)PWM-Frequenz von etwa 2kHz schaffen, bei 20 LED sind es noch 1kHz (eher weniger, denn damit wären schon die meisten Register belegt und es müssten Daten aus dem sram geholt werden). Fängst du jetzt noch an zu multiplexen, kommst du auf eine effektive Frequenz von 200 Hz. -> Das käme für mich überhaupt nicht in Frage, ich empfinde alles unter 2kHz, vor allem aus dem Augenwinkel, als störend. Andere sind aber auch der Meinung, bei 100Hz schon kein Flackern mehr wahrnehmen zu können <- Wie wäre es aber mit folgender Lösung: Die einzelnen LED können nur an und aus geschaltet werden und zusätzlich alle gemeinsam gedimmt. Dieses dimmen ist einfach über die enable-Eingänge der Schieberegister möglich. Evtl. kann man dann auch die enable- Eingänge der Schieberegister einzeln ansteuern und so gruppenweise dimmen.
ja Treiber brauch ich, schon klar, wollte ich nur nicht extra erwähnen ;) @Jan: Deine Lösung ist leider nicht genug für diese Zwecke. Das mit den Enable Eingängen der Schieberegister habe ich auch schon gehört, nur diese "Grüppchenbildung" reicht einfach nicht. Ich möchte wirklich jede LED einzeln steuern können. Oder sollte ich mir für diese Zwecke lieber einen AVR nehmen, der möglichst viele Hardware-PWM Ausgänge besitzt und diese multiplexen? Oder mehrere AVRs nehmen? Rein rechnerisch kann ich die LEDs aber auch nicht weiter als 5 fach multiplexen, da ich sonst den Maximalstrom von 100mA überschreiten müsste um noch volle Helligkeit zu erzielen, oder liege ich da falsch? Der Nennstrom beträgt 20mA. (laut Datenblatt) @alpha: genau DESWEGEN wollte ich erstmal klein anfangen ;)
Gut, wenn es wirklich jede einzeln sein soll... Dann rate ich schon zu einer Lösung mit mehreren µC. Ein Master, der die anderen per SPI (o.ä.) mit Daten versorgt. Für die slaves kannst du dann einfach einen billigen avr nehmen, der z.B. 10 Ausgänge + SPI und 16Mhz hat. Da kämen z.B. der mega48 oder der tiny26 in Frage. Diese steuern dann jeweils 10 LED an, was sie mit 2kHz schaffen. Vielleicht kannst du auch 16 LED dranhängen... Der Master muss dann nur die Daten holen und verteilen, das sollte er ohne Probleme schaffen. Da ist dann auch noch Zeit für eine serielle Schnittstelle zum PC oder ein Display etc. >Rein rechnerisch kann ich die LEDs aber auch nicht weiter als 5 fach >multiplexen, da ich sonst den Maximalstrom von 100mA überschreiten >müsste um noch volle Helligkeit zu erzielen, oder liege ich da >falsch? Da möchte ich insofern widersprechen, da die Helligkeit einer LED bei 100mA nicht fünf Mal höher ist als bei 20mA, der Wirkungsgrad bei hohem Strömen lässt doch nach. Aber bei den üblichen superhellen LED dürfte das der Sache nicht schaden, die sind sowieso hell genug. (meistens ;-) )
@martin ich würde statt alle 100 leds über einen controller zu bedienen, mehrere controller nehmen (jeder controller kann dann von mir aus 20 leds bedienen). dann bekommst du kein timing-problem (255 stufen 100 leds pwm-grund-frequenz * 20 HZ flackerfrei = uiuiui Mhz) und kannst es später erweitern (kann ja sein das so ein party-raum ja wächst *ggg) die 5 controller für die teil-stücke von einem hauptcontroller zu steuern ist dann das kleinere problem. hoffe dieser ansatz ist nicht mit spatzen auf kanonen geschossen *gg gruß rene
Prinzipiell kannst Du das Problem nur so lösen, daß Du 13 Schieberegister nimmst und deren Takteingänge alle parallel schaltest und an einen Prozessorpin schaltest. Gleiches machst Du mit den Store-Eingängen. Jedem Schieberegister spendierst Du einen 8-fach Treiber, daran hängst Du über Widerstände Deine LEDs. Die Dateneingänge der Schieberegister kommen alle an verschiedene Portpins des Prozessors. Die Aufgabe des Prozessors besteht nun darin, die Zahlen 0-255 aus einem Array im SRAM (ein Byte pro angeschlossener LED) mit einem Timerwert zu vergleichen und wenn der Timer kleiner ist, eine 0 am betreffenden Portpin in das entsprechende Schieberegister zu schreiben und wenn der Timer größer gleich ist, eine 1. Dies machst Du für alle angeschlossenen Register quasi parallel (Zahlen kontrollieren -> 1 oder 0 an Daten-Portpins legen -> alle Register schieben, wenn 8x geschoben, Übernahmepin setzen und löschen -> weiter). Nur so erreichst Du eine genügend schnelle PWM-Frequenz für alle LEDs. Wie hoch der Spitzenstrom für die LEDs bei welchem Tastverhältnis (hier 1:8) sein darf, entnimmst Du deren Datenblatt.
Wieso zwingend PWM? bei vielen LCDs werden farbabstufungen dadurch erreicht, dass ein Frame in von mir aus 255 Frames unterteilt wird und je nach dem Bei wie vielen dieser Unterframes ein Pixel an ist ist a uch seine Helligkeit. Ist nur so ne Idee
Statt mehrere Controller zu verwenden, würde ich vorschlagen, einen speziellen Treiber für LEDs zu nehmen. Treibt 16 LEDs (in ich glaube 128 Helligkeitsstufen). Da ist der Treiber schon integriert. Wird durch ein serielles Protokoll angesteuert. Der Baustein, den ich meine, heißt TLC5923 von Texas instruments. In dieser Baugruppe gibt es verschiedene Ausführungen je nach Einsatzzweck. Es gibt aber auch von Maxim vergleichbare ICs. Greetz kmt
@Kai: Deine Idee finde ich am Besten, da gleich die Treiber mit integriert sind und das ganze seriell angesprochen und auch leicht kaskadier/erweiterbar ist. Hat schon jemand Erfahrungen mit solchen Bausteinen oder kann Beispiele/Links posten? Der einzige Nachteil ist leider, dass diese Bausteine scheinbar nur im SMD Format erhältlich sind. Kann man dies evtl mit einem Sockel umgehen?
Ich habe mal einige Experimente mit dem TL5923 gemacht. Alles sehr einfach handhabbar. Die Bauteile sind SMD, das ist richtig; es gibt aber von www.futurlec.com für wenig Geld passende Adapter- sockel auf DIP. Einfach auflöten - fertig. Greetz kmt
Die Philips Bausteine sehen sehr interessant aus, durch den I²C Bus, mit dem ich sowieso schon lange mal etwas spielen wollte. ;) Habe gerade feststellen müssen, dass es diese Bauteile weder beim großen C noch bei Reichelt gibt. Bei Letzterem wollte ich eigentlich alle Bauteile beziehen. Vielleicht habe ich mit den Maxim ICs mehr Glück, kennt jemand deren genaue Bezeichnung? Das mit den SMD Adaptern ist war eine gute Idee aber von Übersee wollte ich sowas nicht unbedingt bestellen ;) Kann mich an Sockel erinnern bei denen die Beinchen der ICs nach unten geklappt waren und dann in diesen Sockel gesteckt wurden (Kontakt an den Seiten).. oder sind das andere Gehäusetypen?
>Oder von Philips den PCA9633 9634 oder 9635. >Ansprechbar über I²C zum treiben (dimmen) von 16 LEDs. Philips SAA1064, kostet ~1.50, Reichelt. 32 LEDs, mehrstufig (+3mA,+6mA,+12mA), bis 120mA kann der Treiber direkt die LEDs anmachen, sonst mit Transistor. Steuerbar über I²C. I²C Bus für AVR kann ich dir nen Link schicken. Gruß Dani
Der IC klingt klingt interessant, da er auch im DIL Format erhältlich ist. Der einzige Problemfaktor ist die Helligkeitsregulierung die doch etwas "grob" ist.. 2³= 8 Stufen. Den merke ich mir aber auf jeden Fall schonmal vor. Falls du einen guten Link-tipp für mich hast, dann immer her damit. Kennt sonst noch jemand einen geeigneten IC, den man möglichst bei Reichelt bestellen kann? Was ist mit diesen Maxim ICs?
http://para.maxim-ic.com/cache/en/results/4959.html die Texas-Instruments-Teile kriegt man bei TI als Sample. Greetz kmt
okay werde mich demnach wohl zwischen der Methode mit mehreren AVRs und dem SAA1064 entscheiden. Die ICs klingen zwar verlockend, sind aber für mich außer Reichweite. Ich bedanke mich erstma für eure Tips ;)
@TravelRec hab dein Post bisher wohl etwas ignoriert =) Was meint ihr zu seinem Vorschlag? Könnte man damit eine Wiederholfrequenz von >200Hz schaffen?
Nach meiner Überschlagsrechnung schafft man damit bei 20 Mhz und 8bit maximal 160Hz. Das Problem ist einfach, dass schon alleine das Laden der ganzen Werte aus dem sram 200 Takte dauert. Vergleich und setzen des Bits für die Ausgabe dauert 2 Takte pro LED, dann die Ausgabe und "reintakten" braucht 4 Takte pro 13 LED. Dann noch zurückspringen und den Zähler erhöhen. Macht insgesamt 450 Takte. Mal 256 PWM-Schritte macht 120k Takte...
okay also ist dieses Verfahren eher ungeeignet, da meine Assemblerkenntnisse, wie gesagt, zu wünschen übrig lassen, könnte ich selbst diese Performance nicht erreichen. Ich werde mal mit meinem Kollegen sprechen und mit ihm über das weitere Verfahren diskutieren. Erstmal danke, vielleicht melde ich mich nocheinmal ;)
Hallo, Ich frage mich gerade, wenn wir zum Beispiel 100 LEDs multiplexing, zu jedem beliebigem Zeitpunkt wird nur eine einzige LED angesteuert. Theoretisch sieht man die eine angeschaltete LED nur 1/100 pro Sekunde, so im Grunde sieht man die LED weniger je mehr LEDs wir haben. Allerdings glaube ich dass wir auch ein Nachleuchten der LED haben, d.h. die LED leuchtet ein wenig laenger nachdem die LED im Grunde ausgeschaltet ist. Gibt es irgendwelche Erfahrungswerte wie lang dieses Nachleuchten andauert? Ich moechte mal vermuten, dass solange alle LEDs zumindest einmal innerhalb dieses Nachleuchten stattfinden kann, sollte eine angeschaltete LED als dieses visuell erkennbar sein. Was ich versuche zu verstehen ist, dass wenn wir z.B. 20-50Hz Wiederholungsfrequenz 100 LEDs ansteuern (an/aus) und wir koennen eine eine angeschaltete oder ausgeschaltete LED erkennen, warum erscheint eine angeschaltete LED nicht als ausgeschaltete LED, wenn wir genuegend LEDs haben, dass jede LED nur fuer eine minimale Zeit angesteuert wird (sollte zumindest gedimmt erscheinen, oder?) Danke, Marco
@Marco Bux >>Nachleuchten der LED haben ?? Das halte ich für ein Gerücht, LED´s leuchten nicht nach!! Schon garnicht in einem für uns Menschen detektierbarem Bereich. Wahrscheinlich verwechselst du das mit der Trägheit unser aller "Empfangsapparates" (Auge -> Gehirn). Gruß
Als Treiber könntest du auch ein TPIC6595 von TI nehmen! Das ist ein Schieberegister mit open collector ausgängen die um die 100mA pro Ausgang können (soweit ich mich jetzt erinnern kann)! Hab das mal für 16 Ausgänge verwendet und das funktionierte echt gut!
@wolfgang auch da hätten wir wieder das problem, dass dich diesen Baustein nicht bei Reichelt finden kann. ;)
>Ist es möglich die Animationen in Echtzeit von der SD Karte zu holen >oder sollte ich sie vorher im RAM des AVR cachen? ja, Echtzeit bedeutet nämlich, dass es auch Stunden, Tage, Monate oder sogar Jahre dauern kann. Nur der genaue Zeitpunkt (bis) wann es passiert, ist festgelegt. Zum Problem ansich: Es sollte möglich sein, mit einem Mikrocontroller und ein paar Transistoren (oder auch High- und Lowside-Drivern) die paar LEDs leuchten zu lassen. 256 Dimmstufen sind sowieso etwas viel (wetten?!). Wenn man es schafft, das "Bild" innerhalb von 40ms (25Hz) zu wiederholen, würde sich ein stehendes Bild ergeben. 100Hz wäre noch besser. 100Hz bei 10 Zeilen bedeutet, eine Zeilenfrequenz von 1000Hz (nennt man die so?) Dann wäre jede Zeile 1ms eingeschaltet; für einen Mikrocontroller ist das einen Ewigkeit. Wenn man die Spaltenansteuerung dann mit einem 75HC595 (Schiebregister mit Latch) macht, kann man schon die nächsten Daten da hineinschreiben, während die vorhergehende Zeile noch leuchtet. Für ein konstantes Muster bleibt der "Bildspeicher" halt immer gleich. Für die PWM muß man ihn halt regelmässig ändern.
Wirst wohl recht haben, dass 254 Dimmstufen etwas viel sind. Mir würden auch schon 50 reichen nur kann ich mir nicht vorstellen, dass das einen nennenswerten Geschwindigkeitsvorteil einbringt, oder irre ich da? Und würdest du da auch zu einer Software PWM raten?
>Und würdest du da auch zu einer Software PWM raten? ja. Das Ding ist doch vom Prinzip her ein Fernseher. Wenn sich da die Helligkeit eines Pixels ändert, dann merkt man das auch erst frühestens beim nächsten Bildaufbau. Bei 32(oder 64) Helligkeitsstufen bräuchte man dann 320ms (bzw. 640ms)um die komplette Helligkeitsskala zu durchlaufen. Vermutlich reichen auch 8 Stufen... Du musst dir nur ausdenken, wie man dann realiert, dass die LEDs entsprechend lange an sind...
Ich wollte es folgendermaßen realisieren: Einen 8Bit-Timer hernehmen, der mit einem bestimmten Prescale hochzählt und bei jedem Überlauf die nächste Spalte anwählt. Der "LED Dimmwert" bestimmt nun an welcher Stelle die LED nun wirklich eingeschaltet werden. Bei wert 0 werden sie gleich zu Beginn des neuen Zyklus eingeschaltet, bei 100 erst nach der Hälfte der Zeit (ca. halbe leuchtkraft) und bei 255 garnicht. Zu diesem Zweck wird der aktuelle Timer Wert permanent in einer Hauptschleife mit den Werten im Array verglichen. Wie gesagt, wollte ich in BASCOM programmieren. Reicht die Effizienz dieser Sprache überhaupt?
0 ist doch eigentlich aus und 255 an... Den Timer brauchst du nicht permanent vergleichen. Bei einem Interrupt werden einfach die neuen Werte übernommen, die in der Hauptschleife in ein Feld geschrieben wurden. In der Interrupt-Service-Routine (ISR) sollte man dann noch ein Flag setzen, damit die Hauptschleife den Interrupt mitgeteilt bekommt, und sich um die Aktualisierung des Feldes kümmern kann... Zu Bascom äussere ich mich lieber nicht... An deiner Stelle würde ich erst mal zusehen, dass ich eine LED-Matrix zum leuchten bekomme, und Muster ausgebe, ohne sie zu dimmen, und ohne dass es flimmert. Das Dimmen wäre dann der zweite Schritt.
Hmm dann werde ich wohl doch demnächst ma anfangen mich in Assembler einzuarbeiten. Stimmt, da werde ich nicht gleich mit Dimmen anfangen können, sondern erstmal Muster versuchen. Danke für die Tipps!
Du wirst kein Nachleuchten der LEDs, das für den Menschen erkennbar, ist verzeichen können. LEDs haben im Vergleich zu Glühbirnchen so gut wie kein Nachleuchten. Was du als Nachleuchten empfindest ist das Nachleuchten in deinem Auge. Dort gibt es das Nachleuchten zum filtern von Aliasingeffekten, da das Hirn die Bilder mit einer niedrigen Abtastrate erfasst. Das Nachleuchten kommt aber nicht von den LEDs. Wenn die LED also 1/100 der Zeit an ist und du sie normal beteibst, dann beträgt die Intensität der LED 0.01 der Ursprünglichen Intensität bei Dauerbetrieb. Was man da machen kann und auch oft macht, ist die LEDs mit stärkeren Strömen zu betreiben, die die LED bei Dauerbetrieb nicht vertragen würde, kurzzeitig aber, z.B. für 1/100 einer Sekunde, ohne weiteres verträgt. Kaufe dazu ordentliche LEDs mit Datenblatt und schaue dort die Maximum ratings an. Dort muss es eine angabe geben für den Spitzenstrom und auch eine Angabe wie lange man die LEDs mit Spitzenstrom betreiben kann. So kannst du die Intensität deines LED-Arrays erhöhen. Aber um den Faktor 100 auf Vollintensität wird das wohl nicht gehen. Aber du musst ja auch nicht mit 1/100 der Intensität rechnen. Wenn du ein 10x10 array für 100 LEDs aufbaust, dann können immer 10 gleichzeitig an sein! Was nach meiner Rechnur zum Intensitätsverlust um den Faktor 10 führt, also 1/10 der ursprünglichen Intensität. n8
>Glühbirnchen
Frisches Leuchtobst?
Die Dinger heissen immer noch Glühlampen (auch wenn die "endgültige"
Rechtschreibreform kommt)
Ich werde aber wahrscheinlich die LEDs in 25x4 anordnen und sie mit dem 4fachen Strom betreiben. (laut Datenblatt bis 100mA) Das sollte Verluste in Grenzen halten.
meinst du sowas: http://kiwi-l.ba-mosbach.de/~extern/moin.cgi/ThomasFleckensteinMt03/ hab ich zwar mit PIC gemacht, wäre aber auch mit AVR möglich
hmm jaa das kommt so in etwa in die Richtung. Ich weiß nun nicht genau, was dieser HimMel alles kann, aber der Aufbau wird der gleiche sein. Wie es scheint hast du Duo-LEDs verbaut, das wird der einzige Unterschied im Aufbau sein. Schade nur dass ich auf deiner Seite keine Schaltpläne finde (auch nicht zu dem ähnlichen Projekt 4gewinnt).
Bitte 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.