mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik 200 LED Matrix mit nur 8 LEDs


Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach, das ist schon alt. Such mal nach "Propeller clock".

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Magnus Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann hast du aber nicht gerade viel im Internet recherchiert...

Autor: Matthias (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
das ist genau sowas hier
suggeriert dir 128+16 = 768RGB-LED's mit scheinbar 3072 Anschlüssen..

Autor: roquema (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: fnah (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
der ultimative thread dazu:
Beitrag "Kupferdrahtdurchmesser bei Spulen"

Autor: TobyTetzi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TobyTetzi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi nochmal,

das sind übrgens die LED Module.
Betückt mit 8 PLCC2 LEDs (vorne) und einem TPIC6C595 (hinten).
Ich habe mir die LPs als geritztes Nuzen zu je 4x30 herstellen lassen.

Falls jemand interesse an den LPs, bzw. den TPIC6C595 hat, ich habe noch 
genügend. ;-)

Gruß Toby



Autor: TobyTetzi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Her nochmal die Rückseite,

schade das man immer nur eine Datei einfügen kann! ;-)

Gruß Toby

Autor: TobyTetzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"...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...

??

Autor: Maddin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: TobyTetzi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TobyTetzi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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!!!

Autor: TobyTetzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bei Software SPI könnte man 3Bit parallel mit einem Clock shiften, wäre 
das schneller als 3x Hardware SPI?

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TobyTetzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Matthias,

kannst Du uns/mir evtl. weitere Detils zukommen lassen,
oder gibt es das Projekt evtl. sogar Online?

Gruß Toby

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Projekt gibt es (noch?) nicht online.
Was willst du wissen??

Autor: TobyTetzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ähm, 4 Helligkeiten pro Farbe -> 4*4*4 = 64 Farben insgesamt pro Pixel.

Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ä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

Autor: TobyTetzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TobyTetzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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..

Autor: TobyTetzi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TobyTetzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christoph Borowski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
siehe auch

http://www.thinkgeek.com/gadgets/lights/9162/?cpg=...

Ein Ventilator zur Anzeige von farbigen Graphiken.

Gruss
Christoph

Autor: Matthias (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TobyTetzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wollte mal fragen, ob es was neues gibt?

Matthias, gibt es dein Projekt schon online?

Gruß Tobi

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MaxPower (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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^^

Autor: MaxPower (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.