LED-Darstellungs Idee mit ein paar Hindernissen [Archiv]

Strahleman

11.01.2007, 14:50

Die Woche haben wir im Mathekurs eine Kreisfläche um sich selber drehen lassen, was eine virtuelle Kugel erzeugte.
Als ich zu Hause war, kam mir die Idee, dass man doch theoretisch den Rand der Kreisscheibe zur Hälfte mit LEDs bespicken kann, so dass beim Drehen der Kreisscheibe um die eigene Achse eine leuchtende 3D-Kugel entsteht.
Ich habe auch noch etwas weiter gesponnen. Lässt man die LEDs nun auch noch verschieden aufblinken kann man einfache (2-farbige) Muster in die Kugel "gravieren". Im Prinzip also eine erweiterte Propeller-Uhr (https://www.roboternetz.de/phpBB2/viewtopic.php?t=19005).

Nun treten bei meinen Vorstellungen aber noch folgende Unklarheiten auf:
Man nehme nun zum Beispiel eine Kreisscheibe mit 150mm Durchmesser (=> Umfang = 440mm). Die LED-Lichtspalte sei aus runden 3mm LEDs. Der Motor, der die Kreisscheibe dreht, hat 2400U/min (=> 40U/s).

Daraus ergibt sich, dass die LED-Reihe 157 einzelne Schritte (bei "aufgefächerter" Kugelfläche passen die LEDs 157 Mal nebeneinander) macht, bis sie die virtuelle Kugel von 150mm Durchmesser abgefahren hat. Der Motor braucht pro Umdrehung 0,025s. Das würde heissen, dass sich die LEDs alle 1,59*10^-4s schalten müssten (an- bzw. ausschalten, um ein Muster zu bekommen).
Ist eine solche genaue Zeiteinstellung per AVR oder Taktgeber überhaupt machbar?
Außerdem kommt noch hinzu, dass das Signal erst über eine Leitung (sagen wir einmal 7,5cm, da der AVR im Mittelpunkt der Kreisscheibe sitzt) transporiert werden muss. Kann die Zeit vernachlässigt werden? Oder muss sie auch mit beachtet werden, da die Schaltzeit für die LEDs sehr gering ist?

PICture

11.01.2007, 15:28

Hallo Strahleman!

Wenn die (vielleicht sogar RGB) LED's nur am Rande der Scheibe plaziert werden sollen, braucht man keine Scheibe, es reicht ein Kreis aus Draht o.ä. was den Luftwiderstand und damit verbundene Geräusche erheblich vermindert.

Die Schaltfrequenz 1/1,59E-4, also ca. 6,3 kHz ist für einen uC kein Problem.

Die Zeit für ein Signal durch die Leitung kann ruhig vernachlässigt werden, da die Elektronen bewegen sich im Leiter (wenn ich mir noch richtig erinnern kann) mit ca. 200 000 km/s. :)

MfG

PsiQ

11.01.2007, 15:37

das problem wird erstmal sein, dass du alle leds über schleifer ansteuern mußt.. Anzahl Schleifer=
Anzahl LEDs (getrenntes [+] mit vorwiderstand) + 1 (gemeinsame masse)
bei 2500upm wird son kabel schnell mal bisschen kurz O:)
bei 10dioden brauchst du 11 Schleifkontakte.

edit:

wenn der avr mit in dem holo-apfel ist, brauchst du nur 2 schleifer..
+ und - 5V
mit schalter, damit dus auch stoppen kannst ;-)

und wegen der steuergeschwindigkeit..
das menschliche auge ist viel langsamer..
Viele Leute bemerken bei 60Hz PC-Röhrenmonitoren nichtmal das Bildflimmern..

Strahleman

11.01.2007, 16:08

@PICture: Hm ist ein guter Vorschlag mit dem Drahtrahmen. Problem könnte dann nur sein, dass ich viele Kabel verlegen muss. Bei einer Scheibe kann man ja einfach Leiterbahnen drauf ätzen.

@PsiQ: Warum über Schleifer? Wenn ich wie gesagt eine Platine nehme, kann ich es ja über Leiterbahnen machen. Dann wickelt sich gleichzeitig auch nichts auf beim Drehen ;)
Ich habe ja in meinem Fall 40Hz. Habe mal gelesen, dass das Auge bei rund 25Hz träge wird, aber lieber bisschen mehr, dass es auch net flackert ;) War ja ausserdem nur nen Beispiel mit den 2400U/min ;)

Nun muss ich aber erst einmal einen AVR finden, den man dafür benutzen kann. Kennt jemand zufällig einen? Muss nichts besonderes sein, im Prinzip reicht ein AVR mit rund 73 Bits und einer Stromversorgung. Eingänge brauche ich nicht, da kein äußeres Signal kommt. Den Motor kann man ja über einen Trimmpoti grob steuern (zum Testen reicht es ;)).

Ratber

11.01.2007, 16:08

Gut,rechnen wir nochmal nach.

Motor : 2400 upm
Das macht 40 umdrehungen die Sekunde.(Uii,das reicht ja schon zum Zocken)

Die LED'S passen Virtuell 157 mal nebeneinander.
Die Senkrechte Zahl lese ich hier aber lnirgends oder ich bin Blind.
Ich nem mal die hälfte des Umfanges also 157/2=78,5 also 78.

Bei 40 Umdrehungen die Sekunde blitzt jede Spalte 1/40/157=alle 159µs auf.
Bei rund 78 LED's pro Spalte liegt der Schaltltakt bei einfach gerechneten 2 Mikrosekunden also bei rund 490 Khz.
Jetzt muß aber ja einmal ein und wieder ausgeschaltet werden damit es aubere Punkte gibt also verdoppeln wir mal schnell und Landen bei einem Pixeltakt von rund 1 Mhz.

Das alleine könnte ien 16/20 Mhz Controller noch so schaffen aber du mußt ja auch noch mehrere Spalten- und Zeilenblöcke codieren sowie das Muster bereitstellen.
Da wirds dann eng.

Ich würde vorschlagen die Drehzahl auf die Hälfte zu reduzieren so sparst du schonmal 50% und die Darstellung ist mit 20 fps auch noch satt und genug.
Dann noch die Zahl der LED's etwas runtersetzen.
zb. wäre ein vielfaches von 8 Sinvoller.
Mit 48/56 oder 64 LED's wäre nochmal Zeit zu schinden.

Da stellt sich dann ein ganz anderer Pixeltakt ein der auch zu bewältigen ist.

Die Datenübertragung kann man übrigens auch Draht und Schleiferlos machen indem man den Motor als Datenstrecke nimmt.

PICture

11.01.2007, 16:34

@Strahleman

Wenn Du ein Standmuster sehen willst, muss die LED's Umschaltung mit der Drehzahl des Motors synchroniesiert werden, sonst wird der Muster sich zufällig ändern.

MfG

Strahleman

11.01.2007, 16:50

@PICture: Jop, weiss ich. Aber wie gesagt zu Testzwecken bin ich auch mit einer leichten Drehung des Musters zufrieden ;)
Es ändert sich ja nicht zufällig, sondern bekommt einen Drall in eine Richtung (je nachdem ob Motor zu schnell dreht oder zu langsam).

@Ratber: Jo, ist mir auch schon eingefallen den Durchmesser etwas zu verkleinern und die LEDs somit auf 64 zu begrenzen. Das entspräche einem Durchmesser von rund 125mm, dementsprechend ist der Umfang 392,7mm. So kommt eine Spaltenanzahl von knapp 131 raus.
Bei einem Motor, der 20U/s hat würde jede Spalte alle 381µs aufleuchten. Also mehr als doppelt so langsam wie vorher. Dementsprechend ist der Takt also auch "nur" rund 500kHz. Right?!

Welchen Controller würdet ihr denn für ein solches Vorhaben vorschlagen? Bin mit so großen Teilen noch nicht in Kontakt gekommen.

Murus

11.01.2007, 17:23

Eeeehm, da oben hats nen Fehler... Die Elektronen bewegen sich im Kabel relativ langsam (cm/s Bereich). Das Potential breitet sich dagegen knapp mit Lichtgeschwindigkeit aus.

Ratber

11.01.2007, 17:37

@Strahlemann

Ja,das lästsich nicht so genau beantworten weil ja zu der reinen Darstellung auch noch die Synchronisation und andere Softwareaustattung hinzu kommt.
Ich halte mich normalerweise an meine persönliche Faustformel von 1:20 also 1 Mhz Pixeltakt = 20 Mhz Controller Takt (Bei AVR.Andere Controllerfamilien sind da evtl. anders)

Mit 500 Khz wären das dann mindestens 10 Mhz also bist du mit einem 16Mhz AVR und sauberer Programierung ganz gut dabei.

Ich vermute mal das du dir im Web sicher schon die eine oder andere Propellerclock angesehen hast.
Da gibt es noch unmengen an Kniffen wie man das Ganze so darstellen kann ohne engpässe zu schaffen.

Ein Studium der einzelnen Lösungen lohnt da in jedem Falle.
Alleine schon wegen der Erfahrungen.

PICture

11.01.2007, 17:40

Du möchtest also ein 3D 64x128 pixel Grahikdisplay bauen. Finde ich sehr interresant, weil es wahrscheinlich noch nicht gibt.

Ich möchte Dir kein Controller vorschlagen nur mitteilen, das ich selber PIC Benutzer (aber nicht Fanatiker) bin. Wenn ich mich nicht täusche kennt sich der Ratber mit AVR's.

MfG

Strahleman

11.01.2007, 17:52

Danke für die Hilfe! Habe mir bis jetzt nur den einen Artikel zu den Propelleruhren durchgelesen, die Idee kam mir ja auch erst gestern Abend so richtig ;) Werde mich da auf jeden Fall einmal schlau lesen.

Ein AVR wäre schon schön, mit denen habe ich schon das ein oder andere gemacht. PIC ist für mich Neuland.

Ratber

11.01.2007, 20:50

@Picture

Du möchtest also ein 3D 64x128 pixel Grahikdisplay bauen. Finde ich sehr interresant, weil es wahrscheinlich noch nicht gibt.

Also angekündig hat das schonmal jemand.
zb. 2004 auf www.ispf.de (http://www.ispf.de/images/projects/propclock/version4.jpg)

Was draus geworden ist ist unklar.

@Strahlemann

Wie gesagt,gehen tut es im Grunde mit jedem Controller egal ob AVR,PIC oder andere.
Er muß nur ausreichend Leistung haben umd die anstehenden Aufgaben zu bewältigen.

Strahleman

11.01.2007, 21:06

Achja: Das Muster soll (vorerst) nachträglich nicht geändert werden. Es wird also ein festes Muster bzw. LED-Aufleuchreihenfolge aufgespielt, die dann immer wieder abläuft. Es muss also fast nichts berechnet werden.

Mein Vater meinte, dass man es doch auch mit EEPROMs machen könnte, sprich Hex-Code reinschreiben und dann immer von Anfang bis Ende durchlaufen lassen und dann wieder zum Anfang springen. Also komplett ohne Controller, einfach EEPROMs plus Taktgeber, so dass das Ende des Codes in den EEPROMs nach genau einer Umdrehung erreicht ist.
Ist das auch möglich oder eher umständlicher als als mit einem AVR?

Ratber

11.01.2007, 21:55

Genau das macht man auch wenn das Muster nicht bei jeder Umdrehung anders wäre.

Einmal in den Speicher (Wie du schon sagtest als ozb. ein Prom) und dann von dort ganz platt immerwieder auslesen wobei eine einfache Schaltung die Synchronisation darstellt (zb. Hallsensor für den Nullpunkt und vieleicht eine geringfügige Drehzahlkontrolle).
Beim Motivwechsel wird dann kurz dunkel geschaltet und das neue Muster geladen.

Das sertzt die Anforderungen an den Controller sehr weit herunter.
So könntest du auch direkt über eine Rechnerschnittstelle arbeiten.(Die Geschwindigkeit des Wechsels hängt dann direkt von der Übertragungsrate ab)

Goblin

12.01.2007, 13:17

ich hab sowas schon einmal gesehen. war ein rotierender bogen in einer plexiglaskugel. mit rgb-leds.

edit:

hier mal ein link zu einer einfarbigen version:

http://www.magicball.de/

Bunt, allerdings zylindrisch:

http://www.youtube.com/watch?v=93HcgS4W_8g

Und einmal sphärisch in Farbe:

http://www.youtube.com/watch?v=mbxOCKajCIg

Strahleman

12.01.2007, 15:28

Goblin

12.01.2007, 15:41

wieso nen festes muster?

Strahleman

12.01.2007, 16:23

wieso nen festes muster?

Wollte so eine "virtuelle" Weltkugel realisieren. Ist etwas spektakulärer als ein herkömmlicher Globus. Da es nicht zwingend eine 1:1 Kopie der echten Weltkarte sein muss (kleine Inseln können ruhig verschwinden), fand ich das mit den LEDs eine schicke Lösung ;)

Alex20q90

12.01.2007, 16:52

Eeeehm, da oben hats nen Fehler... Die Elektronen bewegen sich im Kabel relativ langsam (cm/s Bereich). Das Potential breitet sich dagegen knapp mit Lichtgeschwindigkeit aus.

Es sind sogar cm/h ! Die Stossgeschwindigkeit ist allerdings Lichtgeschwindigkeit 300tkm/s

Ratber

12.01.2007, 17:13

Danke für die Links Goblin. Habe auch schon etwas gefunden: http://www.ispf.de/modules.php?name=News&file=article&sid=2

Genau sowas wollte ich bauen, halt nur mit einem festen Muster ;) Werde am Wochenende einmal etwas experimentieren ;)

Ja,deswegen hab ich es ja oben verlinkt.
Du hast auch gleich die richtige Seite aufgeschlagen.
zb. die Signalübertragung über den Drehtrafo mache ich genauso um auf schleifkontakte komplett zu verzichten.

Crazy Harry

12.01.2007, 22:08

ich hab mir diesbezüglich auch schonmal gedanken gemacht und bei der größe könnte man doch den motor in die kugel bauen. mit einem schrittmotor sotte man auch die synchronisation einfacher hinbekommen.

Ratber

12.01.2007, 22:12

Ja,wenn man ihn mit 2-4 Khz ansteuert ist das scheinbar kein Akt aber man sollte sich fragen warum es nur wenige machen wenn die Auflösung nach oben geht ;) :D

SprinterSB

12.01.2007, 23:19

So ganz kann ich die Berechnungen oben nicht nachvollziehen... Was meint ihr mit "Pixelgeschwindigkeit"?

Die Spalte kann man schlecht multiplexen, weil sich die LEDs weiterbewegen. Um saubere Spalten (Meridiane) zu erhalten müsste man also alle LEDs gleichzeitig und in möglichst gleichen Zeitabständen synchronisieren.

So eine ganze Spalte im 20kHz-Takt schreiben geht mit guter Software, 40 U/min sollten also kein Thema sein. Bei 40 U/min wird man es noch deutlich flackern sehen. Das liegt auch daran, daß das Display selbst nicht träge ist (im Vergleich zB zu einer floureszierenden Röhre).

Die eigentliche Frage ist also, wie man die 64 LEDs (fast) gleichzeitig aktualisieren will. Ein 8:8 MUX käme evtl in Frage, allerdings geht dadurch recht viel Helligkeit verloren, weil die sich zudem noch über die Breiten verteilt. Je heller, desto mehr verzieht sich die ganze Geometrie... Ein µC mit 70 Ports ist *fett*, scheidet also auch aus...

Portexpander scheint mir die beste Option, evtl. der 8*8 MUX. Mit den Portexpandern hat man zusätzlichen HW-Aufwand, hat aber die Möglichkeit, jeder LED ihren eigenen R zu geben. Dadurch könnte man Helligkeitsunterschiede, die durch die unterschiedliche Umfangsgeschwindigkeit bedingt sind, ausgleichen.

Wie auch immer, die 64 LEDs samt R müssen verdrahtet und ausgewuchtet werden.

Bei r=65mm und f=40Hz Rotation ergibt sich eine Äquatorialbeschleunigung (a = r·(2·pi·f)²) von ca. 420g *Taschenrechner-schüttel* ...scheint zu stimmen das *schluck*.

Ratber

12.01.2007, 23:46

So ganz kann ich die Berechnungen oben nicht nachvollziehen... Was meint ihr mit "Pixelgeschwindigkeit"?................usw.

Ja,wenn die komplette Elektronik im Rotor sitzt mag man ,öglichst parallel arbeiten können aber das wäre für die Anzahl der LED's fast unwirtschaftlich.

Man setzt normalerweise die Zentrale Steuerung in den sockel und nur die Anzeigeeinheit in den Rotor.

Dazwischen erfolgt dr Datenaustausch.
Klar,wenn du 8 Bit Parallel überträgst dann ist die Datenrate niedriger aber wie will man das machen ?

8 Schleifer ?
Monströs

8 Infrarot strecken ?
Nicht zu schaffen

8 Funkmodule ? (Ein Multiplexmodul ist wieder eine einzelne Serielle Leitung )
Wird auch wieder umfangreich.

Deswegen die Datenraten wenn alles Seriell geht.

Wie schon gesagt,wenn er nur ein festes Muster darstellen will dann ist das alles kein Problem.
Bei 64 LED und 2400 Upm sowie angenommene 128 Muster pro Umdrehung hat man bei Byteweiser Übertragung 40960 Bytes pro sekunde zu übertragen.
Dazu kommen die Operationen für die Adressierung also nochmal ein Byte pro Segment was dann schon 81920 Bytes/s entspricht.
Soweit wenn man es ganz einfach aus nem Speicher zieht.
Mit Controller wirds aufwändiger.
Der Controller muß sich diese Daten erst aus dem Speicher holen also nochmal eine Adressierung.
Das sind dann 122880 Bytes/s

In der Rechnung nicht enthalten sind andere Berechnungen für Synchronisation und Verwaltung sowie Features.

Kommen jetzt noch Farben dazu dann explodiert die Datenrate.

Ja,deswegen ist bei dem letzten Projekt von ISPF.de nix mehr zu höhren gewesen.
Bei der Zahl von Features ist schnell Ende oder man muß einen recht großen Aufwand treiben.
Letztens lief irgendwo ne Sendung wo einer ne Propellerklock in die Felgen gesetzt hatte.
Sah nett aus und war auch recht gut in der Auflösung.

8 oder 16 Bit Propeller mit vieleicht etwas Farbe (3x8 Bit RGB) ist da mit 8-Bit Controllern noch gut zu händeln.

Für mehr kann man sich gleich mit 16 oder 32-Bitern (zb. Arm) anfreunden.

SprinterSB

13.01.2007, 00:17

Wenn man in die Anzeige hineinsendet/überträgt, dann muss innen ja was sein, zum Empfangen/Auswerten/Ansteuern/Treiben... ...warum dann nicht gleich nen µC reinsetzen?

Wenn man ein 8*8 MUX mit superhellen LEDs macht, sollte die Helligkeit ausreichend sein, ohne daß man einen externen Treiber hernehmen muss. Anstatt Treiber 2 AVR-Ports +2R parallel und man ist bei 5mA, das ist kräftig hell mit geeigneten LEDs, bevorzugt grüne (520nm). Wobei ich 64 LEDs bei r=65mm schon sehr reichlich ist!

Von der Darstellungsgeschwindigkeit ist es dann IMHO kein Problem, selbst wenn Features dazukommen wie ne Uhr oder Lauftext und der Globe "nur" ein Bilschirmschoner ist. Andererseits...wegen dem Krach kommt ein Dauerbetrieb eher weniger in Frage.

kalledom

13.01.2007, 00:17

Hallo,
ich habe das gleiche Problem, LEDs gleichzeitig zu steuern, allerdings nicht 64, sondern 600...1000 Stück !!!
Dazu baue ich mit einem µC (PIC16F877 ??? oder 80C166 !!!) einen 8-Bit / 16-Bit-Bus auf, also 8 / 16 Bit Daten und 8 Bit Adressen (= 256 * 8 bzw. 256 * 16 LEDs).
Dann nehme ich für jeweils 8 / 16 LEDs oder LED-Reihen eine Platine mit:
1 x 74HC686 (8-Bit-Vergleicher für Card-Select),
1 bzw. 2 x 74HC373 (8-Bit-Latch),
1 bzw. 2 x 74HC273 (8-Bit-Latch mit Reset),
1 bzw. 2 x ULN2803A (Treiber).
Mit dem 80C166 habe ich schon so einen Bus aufgebaut, dazu Platinen mit jeweils 64 Ein- und 64 Ausgängen zur konventionellen Steuerung von Modellbahnen, ähnlich einer SPS. Die Software ist bisher nicht fertig geworden.

Der Vergleicher sorgt nach Anlegen der 8-Bit-Adresse für die Auswahl der gewünschten Platine / Latch und der 'auserwählte' 74HC373 übernimmt nach einem kurzen Write-Impuls die 8 / 16 Daten-Bits.
Die 74HC273 haben einen gemeinsamen Reset, damit beim Einschalten alles Low ist und haben einen gemeinsamen Latch zur Übernahme der im 74HC373 befindlichen Bits.
Das ist alles :-)

Quatsch. Ein weiteres Problem wird sein, wo hole ich die ganzen Bit-Muster-Daten her und wo lege ich sie im PIC ab ??? Beim 80C166 ist etwas mehr Platz.
Wie erzeuge ich meine erforderlichen Bit-Muster für die vielen vielen LED's. Es müssen ja nicht immer alle 600...1000 Bits übertragen werden. Wenn z.B. 8 / 16 LEDs eine Zeit lang dunkel oder hell bleiben und am gleichen 74HC273 hängen, muß dieses Byte / Word nicht neu übertragen werden.
Die andere Frage ist, wieviel Probleme gibt es beim seriellen Schieben von bis zu 1000 Bits auf einer Bus-Länge von bis zu 3 m ?
Bei Parallel-Betrieb ist das nicht so problematisch, weil der Datenwechsel im Mikrosekunden-Bereich liegt.
Ja ja, und mit welcher Taktgeschwindigkeit muß ich letztendlich die Bits parallel oder seriell 'transportieren' ?
Also, es fehlt mir noch eine Idee zur Berechnung und Reduzierung der Bits.

Jakob L.

13.01.2007, 00:36

Hallo Strahleman,

bist du sicher, dass du die Kugel mit einer Geschwindigkeit von 40 U/s rotieren lassen willst? Dabei bewegen sich die äusseren Teile der Kugel mit einer Geschwindigkeit von knapp 70 km/h. Die Fliehkraft ist etwa 480x so stark wie die Erdbeschleunigung. Wenn die Kugel ein Gewicht von 0.2 kg hat (und das Gewicht zum grössten Teil aussen ist), dann wirkt eine Fliehkraft von 950N (ca. 95 kg). Wenn die Kugel nicht stabil genug ist, dann fliegen Teile davon mit 70 km/h durch den Raum. Die Kugel muss natürlich möglichst exakt symmetrisch sein, da auch eine kleine Unwucht die Konstruktion zerstören könnte.

Gruss
Jakob

Ratber

13.01.2007, 00:41

Wenn man in die Anzeige hineinsendet/überträgt, dann muss innen ja was sein, zum Empfangen/Auswerten/Ansteuern/Treiben... ...warum dann nicht gleich nen µC reinsetzen?

Ja,davon red ich doch die ganze Zeit. ;)

wegen dem Krach kommt ein Dauerbetrieb eher weniger in Frage.

Überlegen wir mal über welchen Krach wir da reden.

Da kommen ja nur zwei Quellen in Frage.

Einmal der Motor und einmal die Luftverdrängung des Rotors.

Den Motor bekommt man rech schnell auf akzeptable Lautstärken wenn man zv. einen Kopfmotor aus nem Vodeorecorder nimmt oder was ähnliches.

Beim Rotor muß man schon auf die Aerodynamik achten denn jede Kante bringt ein Geräusch.
Eine Glaskugel drumrum ist nicht nur Schön,Pflegeleicht und schutz vor versehentlichem reingreifen sondern dämpft auch noch so nebenbei.
(Eine Möglichkeit von vielen)

Quatsch. Ein weiteres Problem wird sein, wo hole ich die ganzen Bit-Muster-Daten her und wo lege ich sie im PIC ab ??? Beim 80C166 ist etwas mehr Platz.

Ja deswegen der externe Speicher und die zusätzlichen Zugriffe.

@Jakob

Genau so isses und deswegen ja mein Vorschlag die Drehzahl auf die hälfte zu reduzieren.
Da hat man immernoch eine Wiedrholfrequenz von 20
Reicht doch auch.
Die Fliehkräfte reduzieren sich dabei erheblich.

Strahleman

14.01.2007, 00:43

Ratber

14.01.2007, 01:41

Ich habe es mir so gedacht, dass man zwei Mega8 Controller nimmt, in dessen EEPROMS die notwendigen Daten schreibt ("Leuchtreihenfolge" der LEDs bei jedem Bit) und dem Controller einfach sagt, dass er das EEPROM lesen soll. Zusätzlich wird der interne Counter von den Controllern gesetzt, so dass er nach 128 Bit (also den 128 Schritten für eine Umrundung) wieder das Programm wiederholt. Geht das?

Mal rechnen:

2 Mega8 a 512 Byte EEProm also 1K für das komplette Muster.
64 LED's wolltest du pro Spalte haben also 8 Byte pro Spalte.
Auf jeden Mega 8 fallen also 4 Byte.
1K / 8Byte = 128 Spalten pro Umdrehung.
Dein "Bild" wäre also 128x64 Pixel groß.

Zeichne mal deine Weltkarte auf diese 128x64 Pixel und entscheide ob das reicht.

Technisch denke ich das es machbar wäre.
Genau kann ich es erst sagen wenn ich weiß wie schnell der Zugriff auf die internen EEProms ist.

Ja,könnte gehen.
Aber du kannst auch gleich nen einzelnen Mega32 nehmen der hat 1K EEProm bzw. nen M64 wo 2K Platz für 2 Motive bzw. eine höhere Auflösung bieten würde.

Spinnt man das mal aus Spaß weiter dann bietet sich ein M128 an der einen Bus mit bringt und wo man eben mal 64K Externene Speicher adressieren kann.
Als SMD nicht sehr groß beitet er für wenige Euros eine Menge Potential.

Nur mal so als Gedankenanstoss

kalledom

14.01.2007, 01:51

Bei 64 LEDs und 128 "Bit" pro Umdrehung, nennen wir es mal Spalten, benötigst Du 64 LEDs * 128 Spalten = 8192 Bits / 8 Bit = 1024kByte Speicher; die dürfte der Mega8 nicht haben, der PIC auch nicht.
Und da sind wir wieder bei dem Problem mit der Datenmenge. Selbst wenn Du das irgendwie komprimiert bekommst, es wird für AVR und PIC immer noch zu viel sein.
Für Deine Aufgabe könnte ich mir gut 8 Eproms / Eeproms vorstellen (8 Datenbits * 8 Eproms = 64 LEDs), deren Adressen an einem einfachen Adresszähler angeschlossen werden, der von einem (variablen) Takgenerator (z.B. Timer 555) angesteuert wird.
Da nur 128...512 Adressen = 7...9 Adress-Bits benötigt werden, können mit den restlichen 5...8 Adressbits per Mäuseklavier oder einem zweiten, ganz langsamen Taktgenerator mit Adress-Zähler andere Bitmuster ausgewählt werden.
Einziges Problem: die Erzeugung der 8-Bit-Muster (Hex- oder Bin-Datei) für jedes Eprom und evtl. das Brennen ? Brennen kann ich allerdings (fast) alles.
@Ratber
Du hast Recht, 1kByte ist drin, aber .... das Auslesen bedarf, zumindest beim PIC und wahrscheinlich auch beim AVR, einer Byte-Sequenz, die Zeit viel kostet.

Ratber

14.01.2007, 02:05

@Kalledom

Einziges Problem: die Erzeugung der 8-Bit-Muster (Hex- oder Bin-Datei) für jedes Eprom und evtl. das Brennen ? Brennen kann ich allerdings (fast) alles.

Muß nicht unbedingt Eprom sein.
EEProms oder Flash tuts auch.

Alternativ die Daten auf großem seriellem Flash und beim Start des Systems in ein Ram kopieren wo der Zugriff nun kein Problem darstellt.

Es geht auch noch um einiges Trickreicher aber im moment möchte ich das nicht zu komplex werden lassen.

Du hast Recht, 1kByte ist drin, aber .... das Auslesen bedarf, zumindest beim PIC und wahrscheinlich auch beim AVR, einer Byte-Sequenz, die Zeit viel kostet.

Das ist beim AVR eigentlich weniger das Problem denn die gängigen 8-Bit AVR's sind RISC-Controller.
Dh. sie führen die allermeisten Befehle in "einem" Systemtakt aus.
So kommt ein 16Mhz Getaktetet MEGA auf fast 16 Mips
Bei 1K*20=20K die Sekunde hat der Controller also rund 780 Takte pro Byte an Zeit.
Da stirbt er eher an Langeweile :D :D

Also selbst bei nur 8 Mhz würde er noch viel Zeit haben um irgendwelchen anderen Zirkus zu veranstallten.
(zb. Doppelter Speicher der im Hintergrund geladen wird (Shadow Memory) oder noch etwas Komunikation usw.)

Ich sehe da kein größeres Problem.
Die Arbeit wird sich mehr darauf konzentrieren passende Bauteile zu bekommen und den ganzen Vorgang sauber zu timen damit keine unschönen Versatzkanten auftauchen.

Strahleman

14.01.2007, 12:00

Ja,könnte gehen.
Aber du kannst auch gleich nen einzelnen Mega32 nehmen der hat 1K EEProm bzw. nen M64 wo 2K Platz für 2 Motive bzw. eine höhere Auflösung bieten würde.
Problem dabei ist nur, dass ich ja auch 64 Pins für die LEDs brauche. Ein Mega32 hat leider nicht so viele. EIn einzelner ACR wäre mir persönlich auc hlieber, da man so das synchronisieren umgehen kann und sich die Schaltung etwas vereinfacht. Leider habe ich aber nichts passendes gefunden.

@kalledom: Das mit den EEPROMs habe ich ja vor einigen Posts auch schon erwähnt. Problem ist nur, dass ich sie nicht brennen kann und ich keine Lust habe nur für ein paar EEPROMs knapp 100Euro hinzublättern. Da mache ich das lieber per AVR.

Ratber

14.01.2007, 15:05

@Strahlemann

roblem dabei ist nur, dass ich ja auch 64 Pins für die LEDs brauche. Ein Mega32 hat leider nicht so viele. EIn einzelner ACR wäre mir persönlich auc hlieber, da man so das synchronisieren umgehen kann und sich die Schaltung etwas vereinfacht. Leider habe ich aber nichts passendes gefunden.

Hä ?
Entschuldige aber deiner Logik kann ich nicht folgen.

Erstens kannst du die LED's nicht alle an einen Controller hängen denn das packt der nicht.

Zweitens,selbst wenn es ginge würden deine zwei Mega8 auch nicht reichen denn die haben nur 28 Pinne von denen du aber nicht alle nutzen könntest.
Wie soll also ein Mega8 32 LED's treiben können ?

Um Latches und Treiber für die LED's wirst du so oder so nicht herumkommen und eine Adressierung dieser Komponennten ist auch Angesagt.

So brauchst du nur 2 Ports für die ganze Ausgabe und das schafft auch ein Mega8 alleine.
den Mega32 hab ich nur vorgeschlagen weil er 1K internes EEProm hat und ohne Trickserei ein komplettes Muster tragen könnte.

Mit einem Mega8 ginge es auch,dann muß nur ein Externes Paralleles EEProm (Oder Flash ,Prom,Was auch immer) angeschlossen werden.
Das kann übrigens mit an den kleinen Minibus.
Zeit ist reichlich vorhanden. (Siehe 780 Takte)

Wenn du platz sparen willst dann spare bei der Bauform.
Hier ist in jedem Falle SMD angesagt.
Alleine schon wegen dem Gewicht.

SprinterSB

15.01.2007, 11:30

Bei 64 LEDs und 128 "Bit" pro Umdrehung, nennen wir es mal Spalten, benötigst Du 64 LEDs * 128 Spalten = 8192 Bits / 8 Bit = 1024kByte Speicher; die dürfte der Mega8 nicht haben, [...]

Mit dem ATmega8 passt das. Die Daten legt man natürlich ins Flash. Der EEPROM ist aus zwei Gründen ungeeignet dafür
-1- zu klein
-2- zu langsam

Daten aus dem Flash zu lesen geht ebenso schnell, wie Daten aus dem SRAM zu lesen (AVR, richtige Software vorausgesetzt).

Die 8k Flash des ATmega8 reichen locker für die zu erledigende Aufgabe, das Programm (ohne diese Daten) wird -- wiederum gute Software voarausgegetzt ;-) -- ca. 2-3k verbrauchen, d.h. Synchronisierung, Expander versorgen, Kommunikation (zB UART, RC5, ...) etc.
Es wäre sogar noch genügend Luft für einen Font, wenn man zB Laufschrift will!

Falls es wirklich eng werden sollte, fängt man eben mit einem ATmega88 an oder mach ein Upgrade auf den (hat das gleiche PinOut wie ATmega8) und wechselt evtl auf den ATmega168 (wie ein Mega8 mit 16k).

Ratber

15.01.2007, 11:52

Öha,stimmt.
Den Flash hab ich jetzt ganz verdrängt. ](*,)

Aber nicht vergessen,Der Flash ist nur 10.000 bis max 20.000 (Mehr kann ich auch nicht rauskitzeln) mal beschreibbar.
Sollte man im Auge behalten wenn das Muster nicht fest ist bzw. sehr häufig nachgeladen wird.

Wie gesagt,ich würd nen M128 nehmen und alles übern Bus erschlagen.
Da ist dann Platz für erweiterungen.

Edit:
Immer diese fehlenden Buchstaben.
Ich glaub meine Tastatur is langsam fällig

kalledom

15.01.2007, 11:56

Das ist aber alles sehr eng und wenig flexibel.
Da würde ich einen 8-Bit-Bus mit 8...16 Adress-Bits vorziehen, an dem 8-Bit-Latchs mit Treiber für die LEDs und ein RAM-Baustein, von mir aus noch ein Eeprom / Flash, angeschlossen sind.
Der RAM-Baustein könnte aus dem AVR-Flash, dem externen Eeprom / Flash oder über die serielle Schnittstelle 'gefüttert' werden.
Die Latchts / LEDs können dann die Bits vom RAM, dem AVR-Flash oder dem externen Eeprom / Flash bekommen.
Da wäre wenigstens etwas Spielraum drin.

Strahleman

16.01.2007, 23:53

Also noch einmal ganz langsam für mich, denn ich habe mir es wohl doch etwas zu einfach vorgestellt ;)
Ich dachte, ich nehme zwei AVRs mit genug Ausgängen, und hänge an die Ausgänge die 64 LEDs. Dazu werden die beiden Controller synchronisiert und mittels Counter oder externem Zähler "gesteuert". Das abzubildende Muster wird also intern in den AVRs gespeichert und bei jedem Takt vom Zähler wird ein Schritt ausgelesen. Nach 128 Schritten springt er zurück auf den Anfang. Mehr nicht.

Ihr meint nun aber, dass ihr es über einen Bus machen würdet, an den ihr LED-Treiber (ich denke mal wie den LM3914) hängt. Richtig? Was muss denn dazu noch alles zusätzlich außenrum gelötet werden? Wie gesagt, ich wollte erst einmal experimentieren und nicht gleich ein programmierbares Teil aufbauen. Daher bevorzuge ich die einfachste Variante (ein festes Muster, so wenig um die Controller rum wie nötig).

Ratber

17.01.2007, 00:05

Ich dachte, ich nehme zwei AVRs mit genug Ausgängen, und hänge an die Ausgänge die 64 LEDs.

Nein das geht nicht.

Der Controller kann zwar bis zu 30mA an einem Pin liefern aber nicht an allen gleichzeitig.

Dazu kannst du nicht alle Pinne nutzen.
Einge sind reserviert.
Vcc,Gnd,Avcc,Agnd,Reset usw.

Schau mal ins Datenblatt da stehts drinne.

Ein Treiber ist also nötig.

kalledom

17.01.2007, 00:11

Wenn Du 2 AVRs synchron von einem Zähler ansteuern möchtest, sind pro AVR schon mal 8 Pins für Eingänge weg; dann brauchst Du ja schon bald 3 AVRs, um die 64 LEDs ansteuern zu können. Ist alles nicht sehr glücklich.

Als Basis empfehle ich Dir, mit einem AVR, PIC oder was auch immer, einen 8 Bit Datenbus mit z.B. 8...16 Adressleitungen, Schreib- und Lese-Signal aufzubauen.
An diesen Bus kannst Du für die 64 LEDs erst mal 8 Latchs 74HC(T)273 mit 8 Treibern ULN2803A anschließen (8 * 8 Bit = 64 LEDs). Dafür werden 3 Adressleitungen benötigt (3 Bit = 8 Möglichkeiten).
Die Daten würde ich am Anfang im AVR speichern und von dort an die Latchs schicken.
Diese 'Geschichte' kannst Du nach Belieben erweitern oder mit nur 8...16...32 LEDs beginnen.
Später kannst Du an diesen Bus beliebigen Speicher oder andere 8 Bit-'Sachen' mit dran hängen.

Ratber

17.01.2007, 00:16

Als Basis empfehle ich Dir, mit einem AVR, PIC oder was auch immer, einen 8 Bit Datenbus mit z.B. 8...16 Adressleitungen, Schreib- und Lese-Signal aufzubauen.

Ja,das sag ich ja auch die ganze Zeit.

Ein M128 würde sich da schon aufdrängen.
Neben genug Speicher bringt der auch noch einen kompletten Bus mit.

Hab ich das nicht schonmal gesagt oder bilde ich mir das ein ? :-k

kalledom

17.01.2007, 00:22

Alternativ könntest Du auch 255 kleine Platinchen nach folgendem Schaltplan aufbauen und damit 255 * 8 = 2040 LEDs ansteuern.
Die Eingänge kannst Du ja weg lassen.
Bliebe nur noch das winzige Problemchen: wo kommen die Daten-Bits her ?

PICture

17.01.2007, 00:58

Hallo!

@Strahleman

Mein Vorschlag: mach es am Anfang, ganz einfach. Probiere zuerst ein paar feste Muster, die Du ohne Kontroller mit DIP-Schalter programmieren kannst und erst wenn Du mit dem Ergebniss zufrieden bist, denk weiter. :)

MfG

SprinterSB

17.01.2007, 00:59

hmmm. so ein Parallelbus ist je recht aufwändig. Nicht unbedingt von der Ansteuerung, aber vom Layout, man muss ja alle Adress-, Daten- und Handshahe-Leitungen verlegen.

IMHO genügen Expander selbst als Treiber. Expander (bzw. serial to parallel latches) wie 74*594/74*595 haben an den Ausgängen Bustreiber, die zum Treiben einer LED reichen (20mA). Mit guten LEDs ist das bei weitem Hell genug.

Führt man eine PWM an die Enables der Expander, kann man sogar die Helligkeit der Anzeige einstellen -- dabei ist die PWM unanhängig von der sonstigen Ansteuerung.

Die Ansteuerung der Expander/Treiber ist einfach: Jeder bekommt eine serielle Leitung von µC. Aller bekommen das gleiche Taktsignal und den gleichen Strobe, um die Daten auszugeben. Das wären nur 11 Leitungen:
-- 8 serielle Leitungen für die seriellen Daten SER0...SER7
-- 1 Takt für die seriellen Daten (SCK)
-- 1 Takt für die Latches (RCK) zum gleichzitigen Aktualisieren aller Ausgänge
-- 1 PWM bzw. Enable zum Dunkeltasten bzw. Helligkeitssteuerung.

Signalbezeichnungen sind wie in

https://www.roboternetz.de/wissen/index.php/Portexpander_am_AVR