Autor:
Kai Franke
(kai-)
Datum:
Hallo E-Techniker und µC Liebhaber! Als ich letzlich hier ein wenig durchs Forum gestöbert habe, bin ich auf mehrere Leute gestoßen, die sich riesige LED Matrizen aufbauen um dann Grafiken oder sonstiges anzeigen zu lassen. Abgesehen vom Stromverbrauch und Lötaufwand braucht man auch sehr viele ICs mit sehr vielen Beinchen. Um das ganze mit weniger LEDs zu lösen, überlegte ich mir eine 8 LED Leiste rotieren zu lassen. Dadurch decke ich ein Feld von pi*r², also 3,14*8*8 = ~200 LEDs ab. Ein µC soll die LEDs jetzt alle 10° neu ansteuern, die Stromversorgung geschieht über Schleifkontakte, der µC ist mit an Board. Ein Motor bekommt eine schicke Regelung, damit er immer auf gleicher, einstellbarer Drehzahl bleibt. Die Drehzahl liegt bei 1333 U/min, womit sich 22,2U/s einstellen und damit für das menschliche Auge nicht mehr zu erkennen ist. Als µC ist ein ATMEGA16 mit 8MHz geplant, was den Vorteil hat, dass ein Interrupt alle 10000 Clocks ausgelöst werden muss um genau auf 10° Refreshrate zu kommenn. Eine Lichtschranke soll der rotierenden Scheibe "sagen" wann eine Umdrehung vorbei ist, damit die Grafik nicht selbst rotiert. Die Bilder werden in einem Array aus Characters gespeichert, was aus 36 chars besteht ( 360°/10°) Dadurch muss der µC nur noch den char auslesen und auf den Port schreiben. Sollte das so wie ich mir das vorstelle funktionieren lässt sich das ganze noch erweitern. Folgende Erweiterungen wären möglich: - Erweiterung auf 16/24 LEDs - variable Helligkeit der LEDs - Multicolor LED zur Darstellung von allen Farben Was meint ihr dazu? Ist das so machbar? Habe ich irgendwelche Probleme übersehen? Was brauche ich für einen Motor, der 1300U/Minute mit Ballast packt? sonstige konstruktive Vorschläge? Gruß Kai
Autor:
Kai Franke
(kai-)
Datum:
OK, das mit der Propeller clock kannte ich noch nicht, aber ich habe noch kein solches Display gesehen, auf dem richtige Grafiken dargestellt werden, außerdem auch noch keine mit mehr als einer Farbe
Datum:
Dann hast du aber nicht gerade viel im Internet recherchiert...
das ist genau sowas hier suggeriert dir 128+16 = 768RGB-LED's mit scheinbar 3072 Anschlüssen..
Datum:
Hier mal ein paar aus meiner Linksammlung: http://www.luberth.com/analog.htm http://www3.sympatico.ca/surfin.dude/creative/cloc... http://www.metricmind.com/clock/clock.htm http://hot-streamer.com/hilo90mhz/electronics/prop_clock.htm http://freenet-homepage.de/vordermayer/pr_clock.htm http://www.ispf.de/modules.php?name=Forums&file=vi... http://www.bobblick.com/techref/projects/propclock... Besser als Schleifkontakte ist eine induktive Energieübertragung. Feststehende und mitrotierende Spule...
Hallo Kai, so etwas vielleicht? http://www.rc-heli.de/board/index.php?topic=57220.0 Leider braucht eine RGB Version eine menge Strom, den ich bei meiner Anwendung nicht zur verfüung habe. Gruß Toby
Her nochmal die Rückseite, schade das man immer nur eine Datei einfügen kann! ;-) Gruß Toby
Datum:
Hallo, habe schon wieder ewas vergessen, ich weiß nicht mehr, wo genau, aber ein William hat mit einem Pic einen 32 RGB LED "Magic Ball" gebaut. Ach, da ist es ja : Rotor Display mit 32 RGB LEDs : http://home.versatel.nl/edithenwilliam/william/magic.htm Gruß Toby
Autor:
Kai Franke
(kai-)
Datum:
Hey Toby, das sieht richtig klasse auch, vorallem sehr klar und nicht so verwaschen wie manch andere :D theoretisch könnte ich was von deinen Platinen schon gebrauchen, allerdings hab ich kein PIC Programmiergerät, sondern bin nur mit Atmel und MSP430 ausgestattet. für mich wäre interessant zu wissen was du für eine Auflösung hast, d.h. nach wie viel Grad wechseln die LEDs? und wie hast du das mit der Stromversorgung gemacht? Mit welchem Programm hast du die Konvertierung von Bild auf Winkelmaß Umrechnung gemacht? Was macht dein Motor für eine Umdrehung/Minute? Das mit dem RGB ist auch nicht das, was ich mir vorstelle. Ich wollte das Bild eigentlich nicht alles in einer wechselnden Farbe, sondern ein Bild, bei dem jeder Pixel jede Farbe sein kann. Ich weiß, dass das sehr schwer zu realisieren ist, aber möglich ist es bestimmt :D Danke für die Beiträge, die zeigen mir wenigstens, dass das was ich vor habe alles möglich ist.
Datum:
"...as mit dem RGB ist auch nicht das, was ich mir vorstelle. Ich wollte das Bild eigentlich nicht alles in einer wechselnden Farbe, sondern ein Bild, bei dem jeder Pixel jede Farbe sein kann. Ich weiß, dass das sehr schwer zu realisieren ist, aber möglich ist es bestimmt :D..." HÄ?? Ich würde sagen, das ist genau das: Jeder der Pixel kann unabhängig von anderen Pixeln eine von acht möglichen Farben annehmen.. "..Ich wollte das Bild eigentlich nicht alles in einer wechselnden Farbe.." Was soll das heißen?? Das Bild wechselt nicht die Farbe, wenn es das nicht soll... ??
Datum:
er meint, das er nicht ein bild nimmt, einfarbig - sagen wir mal das ganze bild ist rot, und dann das ganze bild, einfarbig dargestellt, von rot nach gelb, nach grün, nach blau wechselt, sondern das das bild eben mehrfarbig ist, wie ein bild als original farbbild, eben aussieht, also zu einem zeitpunk aus unterschiedlichen farben besteht. mit anderen worten, jede rgb led, soll zu einem zeitpunkt, eine andere farbe haben können als, die nächste, also getrennt angesteuert werden können... m.
Hallo Kai, im obrigen Bild habe ich eine Auflösung von 32x512. Also 512 Spalten pro Umdrehung. Die LEDs, 32 an der Zahl, sind im 1 cm Abstand montiert. Ich nutze auch einen AVR, einen ATmega8, keinen Pic. Die LED Modul Platinen haben bei etwa 8x1cm je 8 LEDs und 8 Rs auf TOP, und den TPIC6C595 auf Bottom. Dann haben die LPs je 5 Pads auf der 1cm Seite, dort kann man per SPI dann die LEDs ansteuern. (VCC, Mosi, SCK, CS, GND). Auf einer Seite kommen die Daten rein, auf der anderen wieder raus. Nimt man un z.B. 2 Mdule (also 16 LEDs), muß man 16 Bit schieben, und kann so alle LEDs einzeln ansteuern. Ich habe eine 2s Lipo Zelle auf dem Propeller montiert. Es gibt auch Lösungen mit Kugellagern, Shleifern und Spulen, aber das kann ich leider nicht nutzen. Kugellager, kein Platz, Schleifer, mögliche Knackimpulse, die meine RC Anlage stören Spulen, HF Abstrahlung, die ebenso stören könnten. Ich habe ein VB6 Programm, dort kann ich Bilder importieren, Text in verschieden größen und Schriftarten schreiben. Dann werden die Daten in einem externen SPI EEProm gespeichert. Bild im Anhang, Demo verschiedener Schriften, Auflösung 48x512, Außendurchmesser 1350mm. Der Mtor auf dem Bild macht leider nur ~300 U/min. Es flackert bei der Drehzahl etwas. Im Hubschrauber dann, habe ich Drehzahlen von 1500-2000 U/min. Gruß Toby
Hier ist übrigens noch ein Bild, wo der Text, der mit dem VB Tool erstellt wurde, angezeigt wird. Die roten LEDs sind immer an, nicht vom MC gesteuert. Da zwischen sind 16 grüne LEDs, die Text schreiben. So soll es mal im meinen RC-Heli eingebaut werden. Leider habe ich ein paar Probleme mit dem IR Signal zur Referenzspalte. Daher muß ich erstmal einen Hall Sensor nutzen. Mit dem IR Signal, welches im RC5 Code sendet, wollte ich noch zwischen Bildern im Flug umschalten. Und dann habe ich noch EEProm Probleme, das steht aber in einem anderem Thread. Leider noch ohne Reaktionen. Gruß Toby
Datum:
@ Maddin (Gast): Genau das trifft doch auf mein Beispiel zu: ... aussieht, also zu einem zeitpunk aus unterschiedlichen farben besteht. mit anderen worten, jede rgb led, soll zu einem zeitpunkt, eine andere farbe haben können als, die nächste, also getrennt angesteuert werden können...... Genau das geht dort!!!
Datum:
Hallo. Nun streitet doch nicht darüber! Das anzuzeigende Bild soll halt nicht einfarbig sein, sondern aus mehreren Farben, halt RGB, sein. Die Frage ist, wie steuert man so eine Anzahl LEDs in der Geschwindigkeit an?! Per SPI halte ich doch für etwas zu langsam, da bei RGB ja drei mal soviele Daten gebraucht werden, als bei einer einfarb Version. Gruß Toby
Datum:
bei Software SPI könnte man 3Bit parallel mit einem Clock shiften, wäre das schneller als 3x Hardware SPI?
Datum:
Also diese Uhr hat ne parallele Ansteuerung der RGB-LEDs. Die Nachfolgeuhr, also V2 ;-) wird eine Ansteuerung mit SPI bekommen. Das ist geschwindigkeitsmäßig schon getestet... PS: Ich streite nicht, ich reg mich nur dann auf, wenn man offensichtliches nicht akzeptiert...
Autor:
Kai Franke
(kai-)
Datum:
Habe das offentsichtliche akzeptiert, habe dein Bild übersehen, bei allen anderen war alles nur einfarbig. Die Ansteuerung der LEDs wollte ich eigentlich einfach über den Mikrocontroller regeln, der alle LEDs selber treibt. Das einzige Problem daran ist, dass ich neue Bilder nur durch erneute Programmierung hinzufügen könnte. Sobald ich in den RGB Bereich gehe, werden das allerdings riesige Datenmengen. Danke Toby für die Erklärungen deiner Version, interessieren würde mich ob dein Motor störend laut ist, da ich das hier als Ersatz einer LED Matrix geplant habe, man sieht aber, dass du dir schon sehr viel dabei gedacht hast, gute Arbeit! Mit EEPROM kenn ich mich leider auch nicht aus, kommt aber alles noch. MfG Kai
Datum:
Hallo Matthias, kannst Du uns/mir evtl. weitere Detils zukommen lassen, oder gibt es das Projekt evtl. sogar Online? Gruß Toby
Datum:
Das Projekt gibt es (noch?) nicht online. Was willst du wissen??
Datum:
Hallo, ich habe mich ja auch schon mal mit einer RGB Version beschäftigt. Wie steuerst Du die LEDs an? Ich dachte, ich mache es so wie William, mit seinem Magig Ball, per SPI Schieberegister. Kasskadiert wären die Schieberegister dann so: Rot1-Grün1-Blau1-Rot2-Grün2-Blau2-..... Will ich aber nun nur ein rotes Bild anzeigen, müsste ich trotzdem alle Daten für Grün und Blau mit schicken. Außerdem weiß ich nicht, ob man so bis zu 64 RGB LEDs ansteuern kann. Dann dachte ich an 3x SPI, und alle 3 Busse parallel zu takten. Das geht aber nur mit Soft SPI, und ob das schnell genung ist? Rot1-Rot2-... Grün1-Grün2-... Blau1-Blau2-.... Wie machst Du die Index Auswertung des Nullpunktes? Ich habe entwerder einen HallSensor, einfachste Möglichkeit. Oder ein IR Empfangsmdul, SH5110-36. Dabei benötigt man allerdings wieder einen Sender in der Basis, der 1. das 36Khz Signal moduliert, und 2. in einem Code sendet, da es ohne Code (bei mir RC5) zu störungen kommt. Das RC5 Protokoll dauert aber wieder eine gewisse Zeit, bis es übertragen wurde (glaube, es waren 24ms), das wiederum das Bild verdreht. Ist der Rotor z.B. oben (Spalte0) beginnt die Basis mit dem Senden des RC5 Codes. Bis es fertig übertragen ist, ist der Rotor allerdings bei 1500 U/min schon 3/4 Umdrehungen weiter gelaufen. Bei einer Drehzahl von 2500 U/min hat der Rotor schon fast eine ganze Umdrehung gemacht. So weit,... Gruß Toby
Datum:
>Dann dachte ich an 3x SPI, und alle 3 Busse parallel zu takten. >Das geht aber nur mit Soft SPI, und ob das schnell genung ist? >Rot1-Rot2-... >Grün1-Grün2-... >Blau1-Blau2-.... Ist schneller als HW-SPI ;) 3-5 Takte um 3 RGB Bits in parallel rauszuschieben per Software. Bei 16 RGB LEDs sind das dann 48-80 AVR Takte. Mit HW-SPI schiebst du sequentiell die RGB Bits raus, in eine Shiftregisterkaskade. Für 16 RGB LEDs also 16 * 3 Bits = 48. Per HW-SPI benötigst du 2 Takte pro Bit macht also 2*48= 96 AVR Takte für 16 RGB LEDs. 96 Takte im Vergleich zu 48 Takten, 3 fach Soft-SPI wäre also doppelt so schnell. Das zum Ersten ;) Zum Zweiten vereinfacht sich die Farbdekodierung. Angenommen unser Pixel besteht aus 6 Bits in einem Byte die wir nutzen möchten. Von den 6 Bits jeweils 2 Bit pro Farbe -> RGB. Macht 64 Farben insgesamt. Nun machst du folgendes PORTD zb. benutzt 6 Pins. In zweiergruppen sind diese Pins miteinander verknüpft und diese 3 Leitungen sind die Daten Leitungen der 3 Shiftregister, für RGB. Also PD0 und PD1, PD2 und PD3, PD4 und PD5 zusammengeschaltet. Immer nur einer der zusammengeschalteten PINS ist auf Ausgang der andere auf Eingang geschaltet. Wenn wir DDRD also so setzen das PD0, PD2, PD4 auf Ausgang ist und PD1,PD3,PD5 auf Eingang und wir ein Farbbyte auf PORTD ausgeben dann werden die Bits 0,2 und 4 am Ausgang anliegen. Also die Farbbits R0,G0,B0. Wenn wir DDRD so einstellen das PD1,PD3,PD5 aus Ausgang und die anderen auf EIngang stehen dann geben wir die Farbbits R1,G1,B1 aus. Wir haben einen 3 fach 2 zu 1 Multiplexer über PORTD realisiert. Nun legst du an PD6 noch den Shiftregistertakt. Die Ausgabe eines Farbbytes sähe dann so aus OUT DDRD, MUX_SELECT einmalig am Anfang, MUX setzen OUT PORTD, Farbpixel_0 OUT PIND, PD6 toggle Shiftregstertakt OUT PORTD, Farbpixel_1 OUT PIND, PD6 usw. eben für 16 RGB LEDs 16 mal. Um eine komplette Pixelspalte darzustellen benötigst du nun 3 separate Ansteuerungen, dh. möchtest du zb. 256 Pixelspalten pro Umdrehung haben dann müssen die register 3 * 256 pro Umdrehung gefüttert werden. 1 Pixelspalte besteht also aus 3 Unterteilungen und das muß in unserem MUX berücksichtig werden. 1. Teil Spalte Setze DDRD so das PD1,PD3,PD5 auf Ausgang sind, ergo Farbbits R1,G1,B1 werden aus den Farbbytes ge-muxt, dekodiert und in die Register geschoben. 2. Teil Spalte, mache nichts weiter, sondern nutze das Muster aus 1. Teilspalte weiter 3. Teil SPalte, stetze DDRD auf PD0,PD2,PD4 als Ausgang, die Shiftregister werden also mit den Farbbits R0, G0, B0 aus den Pixeln gefüttert. Wir zeigen also pro Pixelspalte, 2 mal die höherwertigen Farbits und 1 mal die niedrigwertigen Farbbits der Pixel an. Insgesamt müssen wir pro Farbspalte 2 mal die Register füttern. Das Pixelbyte ist so kodiert 76543210 xxbbggrr Also Bit 0+1 = Rot, 2+3 = Grün, 4+5=Blau. Zuerst zeigen wie 2 mal die Farbits R1, G1, B1 an und dann 1 mal die Farbbits R0, G0 und B0. Farbwert=Leuchtsequenz pro Spalte=PWM Duty ab=cde 00=000=0 01=001=1 10=110=2 11=111=3 Die ersten zwei Bitspalten -> cd -> sind identisch mit dem höherwertigen Farbbit -> a. Die letzte Bitspalte -> e -> ist identisch mit -> b. Diese dekodierung und Verteilung auf die Shiftregistereingänge macht unser MUX über PORTD und DDRD. Aus unseren 2 Bits pro Farbe wird so eine PWM deren Leuchtdauer der LED identisch mit den Farbbits ist. Dritter Vorteil: Wenn wir gute Shiftregister benutzen, zb. TLC59xx dann hätten wir ja 3 Shiftregister Kaskaden, jeweils eine für Rot,Grün und Blau. In diese Shiftregistern sind programmierbare Konstantsromquellen integriert. Extern mit einem Widerstand. Nun kann man 3 programmierbare Widerstände benutzen die an RSet der 3 Shiftregisterkaskaden angeschlossen werden. Wir können also für die Farben Rot,Grün,Blau die Helligkeit einstellen, also Farbbalance und Gesamthelligkeit. Nachteil: Verdrahtung. Pro 16 RGB LEDs benötigt man 3 solche TLC59xx Shiftregister. Von diesen muß an jede der RGB LEDs 3 Leitungen gehen. Bei einer sequentiellen Verdrahtung wäre das einfacher. Gruß Hagen
Datum:
Ähm, 4 Helligkeiten pro Farbe -> 4*4*4 = 64 Farben insgesamt pro Pixel. Gruß Hagen
Datum:
Ähm, an den Pins PD0 + PD1 liegt Dateneingang der Rot Shiftregisterkaskade, an PD2+PD3 der für Grün und PD4+PD5 der für Blau. An PD6 könnte zb. der gemeinsamme Takt der Register liegen. Pro Farbbit also folgende Sequenz in Sofwtare LD temp, Pixel_Pointer++ <- X,Y,Z Register OUT PORTD, temp OUT PIND, PD6 das wären 4 AVR Takte in diesem Falle, 64 Takte für 16 RGB LEDs. Wenn man aber PD6, den Takt der Register, zb. an einen der PWM Ausgänge eines Timer hängt, dann entfällt -> OUT PIND, PD6, ergo 3 Takte pro Farbbits= LED. Bei 16 LEDs also 48 Takte plus bischen Kleinkram der Initialisierung in der ISR und das Pulsen der Strobeleitung der Register. Gruß hagen
Datum:
Hallo Hagen, also wenn ich es richtig verstehe, haben wir auch schon mal drüber diskutiert, teile ich jede Spalte nochmals durch 3. Dann kann ich, gehen wir mal von einer LED aus, 3 Bit Helligkeit darstellen. 3 mal Helligkeit mal 3 mal Farbe (RGB) macht also 64 Mögliche Farben. So weit so gut, das ist ja schon viel zu viel des Guten. Es würde ja schon reichen, wenn man 7 verschiedene Farben darstellen könnte. Also, nur an oder aus, bei jeder LED und jeder Spalte. Wie sieht so eine Software SPI eigentlich aus? Kann man die Teile aus der MMC Routine von U.Radig nehmen, oder weiß jemand ein Thread oder eine Seite, wo es evtl. ein Beispiel dazu gibt? Gruß Toby
Datum:
Ganz einfach:
uint8_t DisplayRAM[256, 16] = {}; // 256 Spalten, 16 LEDs uint8_t* DisplayPixels = &DisplayRAM[0,0]; uint8_t DisplayRow = 0; ISR(TIMER_XYZ) { if (DisplayRow == 1) { return; } else if (DisplayRow == 0) { DDRD = (1 << PD1) | (1 << PD3) | (1 << PD5) | (1 << PD6) | (1 << PD7); } else { DDRD = (1 << PD0) | (1 << PD2) | (1 << PD4) | (1 << PD6) | (1 << PD7); } uint8_t* pixels = DisplayPixels; // 1.) PORTD = *pixels++ PIND |= 1 << PD6; PORTD = *pixels++ PIND |= 1 << PD6; // 16 mal bei 16 RGB LEDs // 2.) PIND |= 1 << PD7; // Strobe für Shiftregister PIND |= 1 << PD7; if (++DisplayRow == 3) { DisplayRow = 0; DisplayPixels = pixels; } } |
So sähe deine ISR aus die pro Umdrehung 3 * 256 aufrufen wird. Das Soft-SPI beginnt bei 1.) und endet bei 2.) mit der Anzeige der Daten in den Registern an deren Ausgängen. PD7 und PD6 wären die Bits 6+7 in unserem Pixelbyte. Diese müssen immer auf zb. 10 stehen. PD6 = 0 am Anfang ist unser Registertakt, PD7=1 ist unsere Low-Active Strobeleitung der Register. Natrülich nur wenn man diese Leitungen auch an PORTD anschliest. Lässt man PD6+PD7 frei dann stehen diese beiden Farbbits für andere Sachen zur Verfügung, zb. Masken, Hintergundflags, Alphawert (Durchsichtigkeit) des Pixels, Kantenmarker für Sprites usw. ALso für die Grafikengine die später unseren DisplayRAM beackert. >Es würde ja schon reichen, wenn man 7 verschiedene Farben darstellen >könnte. Also, nur an oder aus, bei jeder LED und jeder Spalte. Ja aber es wäre kompilizierter. 16 Farben pro Pixel benötigt 4 Bits eines Bytes. Diese 4 Bits immer nur in 1 Byte zu speichern wäre genauso "ineffizient" wir gleich 6 bits und 64 Farben zu benutzen. In 1 Byte 2 solcher Pixel zu speichern würde die Dekodierung im Soft-SPI stark verlangsammen. Denn für 8 Farben müssten wir unser Byte so kodieren 76543210 xxxxHBGR RGB sind Farbbits, H ist ein Heligkeitsbit, wir haben also 8 echte Farben in zwei unterschiedlichen Helligkeiten. Bei 8 Farben benötigen wir 3 Bits. In einem Byte gespeichert wäre nochmal ineffizienter und Platzverschwendung. Oder pro Byte 2*3 Bits für 2 Pixel. Macht die Dekodierung wieder komplizierter. Ich meine die 64 Farben Logik ist das Optimum in diesem Falle, aus Sicht was man hat und was dafür an Resourcen benötigt werden. 1.) pro Pixel 1 Byte vereinfacht die Ansteuerung des DisplayRAMs 2.) keine externe Hardware nötig für die schnelle Dekodierung der PixelBits eines Pixelbytes hin zu den Shiftregsitern 3.) sehr schnell in der Performance, pro Pixelspalte 3 mal der Aufruf der ISR und nur bei 2 von diesen Aufrufen müssen wir was in der ISR machen. Also 1 Aufruf der ISR, wenn DisplayRow== 1 ist, wird in der ISR garnichts gemacht. 4.) einfach in Software zu programmieren Gruß Hagen
Datum:
Man kann nun den Aufwand nochmals reduzieren. Statt pro Umdrehung 3*256 die ISR aufzurufen benutzen wir nur 2 * 256 Aufrufe. Vorrausgesetzt wir benutzen TLC95xx Register mit Konstantstromtreibern für die LEDs dann können wir für die 1. Teilspalte den Strom doppelt so hoch einstellen als für die 2. Teilspalte. Wir sparen uns eine PWM mit 3 Teilschritten und erledigen das über die Konstantstromtreiber der Register. Der Performancetechnische Gewinn ist aber relativ klein, da wir ja bei der obigen Methode wenn DisplayRow=1 ist sowie so die ISR schnell verlassen. Interessant wird diese Idee aber wenn man mehr als 64 Farben darstellen möchte. Zb. 5 Bits pro Farbe = 3*5=15 Bits pro Pixel = 32768 Farben in 2 Bytes pro Pixel. Mit der PWM Methode würden wir also 32 Teilschritte benötigen, mit der Konstantstrommethode aber nur 5 solcher Teilschritte pro Pixelspalte. Bei jedem dieser 5 Teilschritte stellen wir den Konstantstrom der Register um das Doppelte höher ein. Gruß hagen
Datum:
Ja, also: Geplant sind zwei Fügel mit je 32RGB-LEDs. Die Ansteuerung mit SPI dauert ca 35µs mit Interrupteinsprung. Getestet wurde dies mit einer Ansteuerfrequenz von ca 10kHz (entspr. 40Umd/sek). Und die herauszuschiebenden Daten wurden schon (wie später gedacht) aus einem Video-Array geholt mit diesem Inhalt: 1024Bytes Rot, 1024Bytes Grün, 1024Bytes Blau Das wurde mit einem Oszi gemessen. Dabei werden 24Bytes geschoben. (Die aus obigem Array 'wild' herausgeholt werden. DIe Reihenfolge ist: rot0,rot1..rot7,grün0...grün7,blau0...blau7,rot8..rot15,grün... also immer in 8-LED Schritten mit je 8xR 8xG 8xB - Bitwert. Als Schieberegister nehme ich die 74HC595. (Die Flügelplatinen mit je 12x 74HC595 sind schon fertig geroutet, Anschluss: 3V3, GND, SCK, MISO, MOSI, LCK, EN ) Es werden mit jedem Drehwinkel-weiterdrehen (komisches Wort) ALLE Leds mit neuen (alten) Werten NEU bedient.. Ich würde (aus Sicht der Software) dringend von so einer Anordnung abraten: rot1,grün1,blau1, rot2,grün2,blau2, rot3... Als WInkelerkennung habe ich selbstkonstruierte Lichtschranken drauf. Bisher SFH4600=> SFH320FA, wird aber bei V2 ersetzt durch SFH4600=>BPW34FS. Auch schon getestet. Soweit klar? Oder hast noch fragen
Datum:
Hallo Matthias, ich habe mal versucht, 3 Schieberegister mit 8 RGB PLCC2 LEDs zu routen. Habs gleich wieder aufgegeben! ;-) Die LEDs hatten einen Abstand von etwa 1cm, die Schieberegister waren Bottom. 24xR und 8xPLCC2 RGB LED auf TOP. Aber sage mir, warum hast Du zu den "Flügeln" 7 Leitungen. 5 reichen doch völlig aus, und MISO brauchts Du da bestimmt nicht, da die HCs ja nichts senden. LCK, was ist das? Gruß Toby
Ja, bei mir sind die LEDS im Raster 2,54mm angeordnet (auf dem Bild weiter oben im Post waren das noch etwa 3,5mm). ALso: Ich habe zwei Flügel und brauche somit entweder zwei SPI-Schnittstellen, oder eine und ich schieb dur den einen Flügel durch, also brauche MISO und MOSI als hin&rück. DIe 74HC595 haben zwei! Takteingänge, einer zum Daten schieben, und einen zum Daten ausgeben. SOmit schiebe ich "in aller Ruhe" die Daten heraus, und zwar die für den kommenden Takt! Wenn der da iat, ('Winkel'interrupt), dann nur noch kurz LCK und die Daten sind am Ausgang/bei den LEDs. Dann können in aller Ruhe die nächsten Daten gesendet werden... Anschluß der Platine ist ein Steckverbinder: 2x6pol: je 1x MISO,MOSI,SCK je 1x EN,LCK 4x GND 3x 3V3 Ich hab mal den Schaltplan des Flügels drangehangen..
Hallo Mattias, du hättest auch die beiden Leitungen RCK und G zusamen schalten können. ich zitiere hier mal Hagen: Schließe sie so an wie im Anhang. An CLOCK der SPI Takt, an DATA den Datenausgang des SPI und ENABLE an den SS Pin des AVR's. ENABLE muß auf High stehen damit deine LEDs leuchten. Wird Enable kurzzeitige auf Low gesetzt so passieren zwei Dinge. 1.) die Ausgänge werden deaktiviert, auf HighZ, und 2.) werden die Daten der Shiftregister in die intenrenen Speicherregister übernommen. Danach wird Enable wieder auf High gesetzt und nun werden die Ausgänge entsprechend der Speicherregister angesteuert, sprich deine LEDs leuchten im neuen Muster. Solange nun ENABLE auf High ist kannst du über DATA und CLOCK die internen Shiftregister mit neuen Daten füllen OHNE das dies sofortige Auswirkungen auf deine LEDs hat. Somit leuchten deine LEDs im aktuellen Muster und denoch kannst du im Hintergrung die neuen Daten senden. Erst wenn diese komplette über DATA/CLOCK gesendet wurden wird ENABLE wiederum kurz von High nach Low nach Highgepulst,und schon leuchten die nächste Zeit die LEDs im neuen Muster. Dies geht mit der Beschaltung aus dem Wiki nicht. Dort müsste man entwerder ENABLE auf Low setzen und somit alle LEDs aus, solange man Daten sendet, oder aber man sähe sofort bei jedem CLOCK die neuen Daten an den Ausgängen. D.h. die Vorteile der 74*595 Chips werden nicht genutzt. Zitat Ende. Ich selber nutze diese Schaltun und es geht einwandfrei. Man kann genüsslich die neuen Daten schieben, obwohl die HCs (LEDs) noch im alten Muster leuchten. Wenn die neue Spalte erreicht ist, kurz den Enabel High/Low, und die neuen Daten liegen an den Ausgängen der HCs an. Was mich noch interessieren würde, wie goß sind deine Platinen geworden? Hast übrigens die gleichen RGB LEDs, wie ich, die sind für den Preis echt Super. Gruß Toby
Datum:
Ach,
hab ich ganz überlesen.
Ich habe ja auch 2 Flügel.
Ich habe aber beide Flügel parallel angeschlossen, nur den Enable für
jeden Fügel getrennt.
In etwa so:
linker Flügel MC rechter Flügel
VCC ------- VCC --------- VCC
SCK ------- SCK --------- SCK
EN1 ------- EN1
EN2 --------- EN2
Data ------ Data -------- Data
GND ------- GND --------- GND
Gruß Toby
Datum:
siehe auch http://www.thinkgeek.com/gadgets/lights/9162/?cpg=... Ein Ventilator zur Anzeige von farbigen Graphiken. Gruss Christoph
Nein. ich habe beide Signale bewusst NICHT verbunden: Weil dadurch kann ich einerseits die Daten zum richtigen Zeitpunkt übernehmen, und zweitens und unabhängig davon, mit einer schnellen PWM an dem ENABLE Eingang alle LEDS dimmen... So hab ich mir das gedacht... ;-) Die Flügelplatine ist 95x30mm groß. Im Anhnag mal ein Bild von top/bottom
Datum:
Hallo Matthias, das sieht doch echt gut aus. Eine menge Arbeit, das zu routen. Ich habe gestern mal 8 RGB-LEDS mit 3 Schieberegistern versucht, auf einer Platine 15x100 mm zu routen. Das ist für mich schon fast unmöglich! Ich hoffe, man kann dein Projekt online weiter verfolgen. Übrigens, der Ventilator ist ja auch der Hammer, muß man so was kaufen, um zu sehen, wie er aufgebaut ist? Gruß Toby
Datum:
Hallo, wollte mal fragen, ob es was neues gibt? Matthias, gibt es dein Projekt schon online? Gruß Tobi
Autor:
Kai Franke
(kai-)
Datum:
schön, dass sich hier noch einer für interessiert! Ich habe mich etwas damit beschäftigt, allerdings habe ich keine Propellar Clock draus gemacht, sondern ich habe es ins Fahrrad eingebaut. Hab mal alle bisherigen Prototypen in einen Ordner geschmissen und den geuploaded: http://rapidshare.com/files/62529985/demo.rar jetzt bin ich gerade dran eine Leiste mit über 60 RGBs zu entwickeln
Datum:
hey - hallo erstmal an alle Kai´s, Matze´s, Tobi´s, Hagen´s und allen anderen Leuten hier! Ich verfolge Eure Projekte schon seit langem mit großem interesse und bin echt -und jetzt bildet Euch nichts darauf ein - Begeistert!!! Nun - da gibt es etwas was mir schon seit langem im Kopp rumschwirrt, aber ich bin techniker/Tüftler und kein elektroniker... Bräuchte also schon a bissl hilfe bei der umsetzung! Sehr interessant ist der letzte Beitrag von Kai in dem er von seinem neuen projekt mit 60 RGB´s schreibt! Nun - ich würd gerne 100 RGB´s ansteuern - bei etwa 60Hz! Ziemlich schnell also - stellt sich die Frage - KANN man sowas datentechnisch überhaupt realisieren? ob nun im Propeller-clock-style, oder wie der Magic-ball weiss ich noch nicht so genau, aber für mich ist eben wichtig das es 100 RGB´s und mehr sind...nach möglichkeit... Bin dankbar für jeden Vorschlag! mfg MaxPower
Datum:
@ MaxPower (Gast) >Nun - ich würd gerne 100 RGB´s ansteuern - bei etwa 60Hz! Viel Holz für einen Anfänger. >Ziemlich schnell also - stellt sich die Frage - KANN man sowas >datentechnisch überhaupt realisieren? Aber immer. Schau dir mal die LED-Videowände an. Wieviele LEDs dort wohl verbaut sind? :-0 LED-Matrix AVR-Tutorial: Schieberegister >nicht so genau, aber für mich ist eben wichtig das es 100 RGB´s und mehr >sind...nach möglichkeit... Technisch kein Problem. Ob deine Kenntnisse und Fähigkeiten aber dazu ausreichen ist eine andere Frage. MFG Falk
Autor:
Kai Franke
(kai-)
Datum:
hallo Fan! :D bei mir wurden es jetzt sogar 72 SMD RGB LEDs, also fast schon 100 da ich das ganze im Rad habe und mir wegen 3,6V nur 8MHz zur Verfügung stehen benutze ich allerdings 4 ATmega8 zur Ansteuerung. Außerdem hätte ich ansonsten Probleme mit dem Speicherplatz. Wenn du dich schon mit 60Hz zufrieden geben willst, reicht selbstverständlich auch ein Controller. Wenn du mir verrätst was du vorhast kann ich dir eventuell auch weiter helfen. 100 LEDs hört sich sehr nach Mood Light an und das habe ich auch gerade vor. Das Programm steht schon, ein Prototyp ist auch schon gebaut und funktionstüchtig mit Lauflicht und Farbtoneinstellung. Das ganze ist dann auch modular erweiterbar (bis zu 50 Modulen pro Controller; 6 RGBs/Modul) Also verrat was du vorhast, die Idee wird dir schon niemand klauen und wenn, dann ist sie so gut, dass es jeder bauen sollte^^
Datum:
hey hey... na dasss ging ja schnell...!!! Die sache mit den 60 Hz iss einfach - weil ich das im bereich des souverän machbaren halte! nur...also mein plan iss - ich hab da etwas gebaut wodurch die Lamellen sich in senkrechter richtung (horizontal?) bewegen!!! eine höhe von min. 1m - 4 lamellen sollen es werden - so das ich im endeffekt 2 bildschirme mit recht gutem - und hoffentlich flackerfreien darstellungen habe!!! Was sagste dazu?
Autor:
Kai Franke
(kai-)
Datum:
hab das jetzt noch nicht ganz verstanden, aber stimmt das, dass du 100 RGBs/Lamelle haben willst? senkrecht nach oben heißt vertikal :P Gibt es von deiner Konstruktion auch Bilder? Kannst mich auch gerne im ICQ adden, suche immer wieder gerne irgendwelche Sachen, die mich vom Lernen abhalten^^ ICQ: 177eins8drei299
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten