www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik LED Kugel - Projektvorstellung


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

Bewertung
0 lesenswert
nicht lesenswert
Hoi!

Ich bastele derzeit an einer Idee und wollte die hier mal vorstellen, in 
der Hoffnung das Ganze etwas optimieren zu können:

Die Idee:
Was mir da im Kopf herumschwirrt ist ähnlich einer Propeller-Clock, 
allerdings sind die LEDs nicht auf einer Geraden sondern auf einem 
Halbkreis angeordnet. Durch Rotation ergibt sich dann eine Kugel. Etwas 
ähnliches findet sich z.B. schon auf Youtube. Eigentlich wollte ich 
klein anfangen aber während dem Planen ist der Ehrgeiz dann ein bisschen 
mit dir durchgegangen.

Das Konzept (Mechanik)(siehe Bild):
Der Halbkreis ist, um Unwuchten zu vermeiden, zu einem Vollkreis 
erweitert worden. Durchmesser 30cm. Der Kreis bietet ausserdem die 
Option, auf jeder Seite LEDs anzubringen und damit die Zeilenauflösung 
zu verdoppeln.
Die Achse in der Mitte ist Kugelgelagert. Der Kastenförmige Unterbau 
hält die Lager, bringt eine gewisse Masse um das ganze auf dem Tisch zu 
halten, und da unten befinden sich Außerdem die Riemenscheiben für 
Antrieb und Drehgeber sowie Schleifring. Das Ganze ist aus Lexan 
aufgebaut. In wieweit man die Sachen auf dem CAD-Bild erkennt weiss ich 
nicht, zur Not mache ich es noch bunter.

Elektronik
Hier existiert im Moment noch keine Hardware und das Konzept möchte ich 
zur Diskussion stellen:
Der Motor ist erstmal ungeregelt geplant. Allerdings soll die Drehzahl 
im Bereich um 25Hz liegen, damit ein stehendes Bild entsteht.
Ich möchte das ganze Drehzahlunabhängig gestalten, daher ist im Moment 
ein Drehgeber HEDS geplant. Auflösung 500 CPR
Als LEDs möchte ich RGB-LED vorzugsweise von OSRAM (siehe Bild 2) Das 
Ganze wird in Modulen aufgebaut. Immer 5 LEDs hängen an einen 
TLC5940(Konstantspannungsquelle mit 12Bit PWM) und jeweils 5 TLC hängen 
kaskadiert an einen FRAM-Speicher. Es existieren jeweils 2FRAMs pro 
Modul. Jeder RAM speichert 180° des Bildes. Sollte ich das Ganze 
irgendwann auf Bewegtbilder erweitern wollen kann auf diese Weise immer 
ein FRAM mit neuen Daten beladen werden.
Kommunikation erfolgt über SPI.
Die Steuerung soll ein AVR, vermutlich reicht ein Mega8 übernehmen. Über 
externen Eingang soll der Drehgeber einen Timer hochzählen. Alle halbe 
Umdrehung geht ein Signal vom AVR an den anderen IC dass der 2.FRAM 
angesprochen werden soll. Dann geht es weiter mit dem SPI Takt. Zudem 
generiert der AVR den PWM-Takt und das Reset-Signal das der TLC am Ende 
jedes Taktes benötigt.
Bei dem Baustein mit dem Fragezeichen habe ich noch keine Ahnung was ich 
verwenden könnte. Er übernimmt die Eingaben in die FRAMs. Das sind zum 
einen das Rücksetzen der Adresse auf 0000, zum anderen wäre da das 
Beschreiben des FRAM mit neuen Daten. Allerdings habe ich hier noch das 
Problem, dass, wollte ich Animationen darstellen, müsste ich alle 1/50Hz 
einen kompletten FRAM neu beladen. Das gibt ein Gigantisches 
Datenvolumen, selbst wenn ich vorher einen PC alles berechnen lassen 
würde. Daher will ich erstmal den Rest zum Laufen bekommen.

Problem ist im Moment auch noch, dass die FRAMs relativ teuer sind und 
allein die Bauteilkosten schon recht hoch wären.

Was kann ich besser machen, wo könnte ich Geld einsparen, ohne die 
Funktionen einzuschränken?

Gruß Tim

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

Bewertung
0 lesenswert
nicht lesenswert
Bild Nr 2

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Tim (Gast)

>Der Motor ist erstmal ungeregelt geplant. Allerdings soll die Drehzahl
>im Bereich um 25Hz liegen, damit ein stehendes Bild entsteht.

Das Bild stzeht auch bei 10 Hz, flimmert halt nur wie Sau ;-)

>Ich möchte das ganze Drehzahlunabhängig gestalten, daher ist im Moment
>ein Drehgeber HEDS geplant. Auflösung 500 CPR

Vollkommener Overkill. Ein einfacher Hallsensor für weniger als einen 
Euro oder ne Gabellichtschranke reichen völlig. Drehzahlmessung dann per 
Timer.

>TLC5940(Konstantspannungsquelle mit 12Bit PWM) und jeweils 5 TLC hängen
>kaskadiert an einen FRAM-Speicher.

Der FRAM wird kaum einen TLC ansprechen können. Da muss der AVR schon 
vermitteln.

>ein FRAM mit neuen Daten beladen werden.

Warum FRAM? Ist popeliger EEPROM zu billig?

>Die Steuerung soll ein AVR, vermutlich reicht ein Mega8 übernehmen.

Nicht vermuten, RECHNEN!

Bei 256 Spalten pro Umdrehung und 50 Zeilen (Pi mal Daumen) macht das 
bei 25 Hz ca. 156 us/Spalte. IN dieser Zeit müssen deine TLC gleaden 
werden, macht bei 50 Zeilen RGB = 150 Bit. Naja, 1us/Bit ist 
schnarchlangsam, SPI kann locker 8Mbit/s bei 16 MHz Takt.

>externen Eingang soll der Drehgeber einen Timer hochzählen.

Siehe oben.

>Problem, dass, wollte ich Animationen darstellen, müsste ich alle 1/50Hz
>einen kompletten FRAM neu beladen.

Wozu? Man kann so ziemlich jeden Speicher kontinuierlich auslesen.

>Problem ist im Moment auch noch, dass die FRAMs relativ teuer sind und
>allein die Bauteilkosten schon recht hoch wären.

Nimm EEPROM oder SRAM.

MFG
Falk

Autor: Daniel Gilbert (daniel-g)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehr geniale Idee,

Bin gespannt, wie das aussieht, wenns fertig ist. ;=)

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Falk

erstmal vielen Dank für deine Antwort, das hilft mir schon sehr viel 
weiter.

>Vollkommener Overkill. Ein einfacher Hallsensor für weniger als einen
>Euro oder ne Gabellichtschranke reichen völlig. Drehzahlmessung dann per
>Timer.

D.h. ich lasse den Controller sein Timing selbst organisieren und 
synchronisiere nur alle, z.B. Umdrehung? Setzt das nicht eine Konstante 
Drehzahl vorraus? Was würde ich mir denn da für einen Fehler einhandeln? 
Wäre natürlich viel schöner weil es technisch einfach ist und ich die 
Auflösung noch variieren könnte.

>Der FRAM wird kaum einen TLC ansprechen können. Da muss der AVR schon
>vermitteln.

Naja das schöne an dem FRAM wäre, dass er einen Befehl und eine 
Startadresse benötigt, und dann nacheinander unbegrenzt die Bits 
rausjagt mit jeder fallenden Flanke vom Clock ich könnte also den RAM 
direkt an die TLC hängen und müsste nur noch den Clock über den AVR 
bereitstellen. Der Vorteil der FRAMs wäre, neben der Idiontensicheren 
Ansteuerung, die hohe Geschwindigkeit gepaart mit serieller Verbindung. 
Ich muss das Ding ja in 20ms komplett beschreiben können wenn ich 
Animationen darstellen möchte. Würde das ein EPROM denn auch schaffen?
Beim SRAM hätte ich den Nachteil, dass ich zwischen RAM und TLC noch 
einen Parallel->Seriell Wandler bauen müsste.Das würde ich gerne 
vermeiden.

>Bei 256 Spalten pro Umdrehung und 50 Zeilen (Pi mal Daumen) macht das
>bei 25 Hz ca. 156 us/Spalte. IN dieser Zeit müssen deine TLC gleaden
>werden, macht bei 50 Zeilen RGB = 150 Bit. Naja, 1us/Bit ist
>schnarchlangsam, SPI kann locker 8Mbit/s bei 16 MHz Takt.

Hier muss ich glaube ich noch ein bisschen detailierter erklären.Hätte 
mich auch gewundert wenn ich das beim ersten Versuch schaffe:
Ich will eine Auflösung mind. Über 1Spale pro ° im Moment rechne ich 
allerdings sogar mit 500 Spalten.Nach unten lässt sich das ja noch immer 
korrigieren. Durch den TLc habe ich pro PWM-Kanal 12bit Auflösung (Ist 
das Overkill?) und bei 5 Kaskadierten, 16-Kanal TLCs kommen damit pro 
Spalte 960 Bit zusammen. Also 960 Bit pro 80µs. Daher die direkte 
Anbindung RAM-TLC. Da könnte ich terrorethisch bis 20MHz Clocken

>Wozu? Man kann so ziemlich jeden Speicher kontinuierlich auslesen.

Das verstehe ich noch nicht ganz. Ich muss doch für Animationen alle 
25Hz ein neues Bild laden. Da ich 2 Speicher für 360° habe also alle 
180° einen Speicher mit dem halben Bild beladen.


Ich hoffe ich konnte mich jetzt noch etwas genauer erklären. Sind meine 
Vorstellungen jetzt kompletter Irrsinn?


@Daniel
Ich auch ;o) Danke.


Gruß Tim

Autor: Skua (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sowas hab ich doch schon gesehen.

>Das verstehe ich noch nicht ganz. Ich muss doch für Animationen alle
>25Hz ein neues Bild laden. Da ich 2 Speicher für 360° habe also alle
>180° einen Speicher mit dem halben Bild beladen.

Eine Animation muss nicht so viele Bilder haben.

512 Schritte wären eine rundere Zahl als 500.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tim wrote:

> D.h. ich lasse den Controller sein Timing selbst organisieren und
> synchronisiere nur alle, z.B. Umdrehung?

Im Idealfall: jede Umdrehung.
einfach die Zeit messen, wie lange die letzte Umdrehung gedauert hat und 
annehmen, dass die nächste Umdrehung genauso lange dauern wird. Du 
kennst die Zeit, du weist wieviele Spalten du bei einer Umdrehung haben 
willst. Daher kannst du ausrechnen in welchem Zeittakt die nächste 
Spalte angezeigt werden muss.

> Setzt das nicht eine Konstante
> Drehzahl vorraus?

Das System ist ja auch träge. Die Drehzahl ändert sich ja nicht 
sprunghaft, sondern von einer Umdrehung zur nächsten nur ganz wenig.

Autor: Winfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...und wenn es nicht träge genug ist, dann lass einfach etwas mehr Masse 
mit rotieren...

Autor: Johnny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab auch mal so ein Propellerdisplay gebastelt; die Elektronik und 
Firmware waren Peanuts. Aber die Mechanik mit dem Auswuchten etc. haben 
viel Schweiss gekostet und mehr als ca. 15 Umdrehungen pro Sekunde waren 
bei meinem Aufbau definitiv nicht drin, ohne das mir das Ding um die 
Ohren geflogen wäre.
Ich denke, bei Deinem Ansatz mit der Mechanik müsste die "Kugel" auch 
oben gelagert sein. Eine gewisse Unwucht wirst Du immer haben und je 
nach Umdrehungsgeschwindigkeit können sich dann Bewegungen aufschaukeln.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>mit 500 Spalten.
>PWM-Kanal 12bit Auflösung
>960 Bit zusammen pro SPalte.
>Also 960 Bit pro 80µs. Daher die direkte
>Anbindung RAM-TLC. Da könnte ich terrorethisch bis 20MHz Clocken


Hast du schonmal gerechnet?

Wenn du, sagen wir mal 500Spalten hast. Jede Spalte hat 960Bits (Das 
wären 80LEDs). Somit brauchst du 60kilobyte an Videospeicher.

Wenn du das jetzt mit 25U/s rotieren lässt, dann musst du diese 60kB 
innerhalb einer 25stel Sekunde ausgeben (Und danach per Flanke gültig 
machen). Das ergibt eine Bitrate
von 60'000Byte mal 25Hz = 1,5Megabit je Sekunde.

Klar. SPI kann das. Kein Problem.

Aber:

Schonmal bedacht, dass die Daten irgendwo her kommen müssen?

Du willst ja wohl "Videos" abspielen. Wo sollen die denn herkommen? Wie 
kommen diese Datenmengen (immerhin 60KB je Bild) auf die drehende 
Elektronik??
Oder willst du die on-the-fly berechnen..?


>kompletter Irrsinn?

Ich sehe das so.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Tim (Gast)

>synchronisiere nur alle, z.B. Umdrehung?

Ja.

>Ich muss das Ding ja in 20ms komplett beschreiben können wenn ich
>Animationen darstellen möchte.

????
FRAM ist KEIN Videospeicher. Da gibt es nix zu schreiben. Du LIEST aus 
einem Speicher un gibst es auf die TLCs.

> Würde das ein EPROM denn auch schaffen?

Dein Konzept ist Murks.

>Beim SRAM hätte ich den Nachteil, dass ich zwischen RAM und TLC noch
>einen Parallel->Seriell Wandler bauen müsste.

Das ist dein AVR!

>Das würde ich gerne vermeiden.

Geht nicht sinnvoll und ist auch kein Problem.

>>Bei 256 Spalten pro Umdrehung und 50 Zeilen (Pi mal Daumen) macht das
>>bei 25 Hz ca. 156 us/Spalte. IN dieser Zeit müssen deine TLC gleaden
>>werden, macht bei 50 Zeilen RGB = 150 Bit. Naja, 1us/Bit ist

Uuuups, 150 Bit wären ja nur RGB mit 1 Bit Auflösung.

>schnarchlangsam, SPI kann locker 8Mbit/s bei 16 MHz Takt.

>Ich will eine Auflösung mind. Über 1Spale pro ° im Moment rechne ich
>allerdings sogar mit 500 Spalten.

Fang mal ne Nummer kleiner an. Ich ahb mal so ein Ding gebaut, 
allerdings als einfachen Kreis, nicht Kugel. Da waren 256 Spalten / U 
schon zeimlich gut. Und es ist sinnlos, in Drehrichtung ne tierische 
Auflösung zu haben, die man in axialer Richtung nicht hat.

>Nach unten lässt sich das ja noch immer
>korrigieren. Durch den TLc habe ich pro PWM-Kanal 12bit Auflösung (Ist
>das Overkill?)

Nicht für LED-Enthusiasten ;-)

> und bei 5 Kaskadierten, 16-Kanal TLCs kommen damit pro
>Spalte 960 Bit zusammen. Also 960 Bit pro 80µs.

Sind aber nur 25 Zeilen. Macht satte 12 Mbit/s. 8-0
Das verschafft auche inem grösseren 32 Bit Prozessor schon langsam einen 
roten Kopf. Der AVR ist damit vollkommen überfordert. Hier braucht es 
einen CPLD oder FPGA.

>Das verstehe ich noch nicht ganz. Ich muss doch für Animationen alle
>25Hz ein neues Bild laden. Da ich 2 Speicher für 360° habe also alle
>180° einen Speicher mit dem halben Bild beladen.

Ja und? Du hast dich unverständlicherweise in deinen FRAM verbissen. 
Vergiss die Dinger. Die sind im wesentlichen nur dort sinnvoll, wo oft 
Daten netzausfallsicher gespeichert werden müssen, als EEPROM Ersatz für 
Neureiche ;-)

>Ich hoffe ich konnte mich jetzt noch etwas genauer erklären. Sind meine
>Vorstellungen jetzt kompletter Irrsinn?

Für einen Anfänger klassisch über seinen Möglichkeiten. ;-)

Mein Tipp. Bau das ALLES erstmal mit einfachen Schieberegistern ala 
74HC595 auf, dort kannst du dann das 1 Bit RGB fahren. Wenn dann ALLES 
läuft (Elektronik UND Mechanik), dann denk über 12 Bit RGB nach.

MFG
Falk

Autor: Tim Kamikater (kamikater)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Skua

Guter Tipp, das sind noch Überbleibsel von dem Plan mit dem HEDS. Wenn 
ich das in Software löse kann ich das dann ideal an den Speicher 
anpassen, der mir zur Verfügung steht.

@Karl heinz

Würde ich das dann in etwas so realisieren dass ich einen Timer laufen 
lasse, die Umdrehungserkennung macht mir ein interrupt, dort wird der 
Timerwert genommen und durch die Auflösung dividiert. Und für jede 
Spalte Auflösung polle ich dann den Timer?

@Winfried & Johnny
Das sind interessante Aspekte dich ich so leider noch garnicht bedacht 
habe. Gerade das mit dem fehlenden Lager oben könnte echt ein Problem 
werden. Ich werde meine Konstruktion wohl einfach mal an die 
Bohrmaschine spannen und schauen wie sie sich verhält. Da habe ich zwar 
keine Drehzahlmessung aber dann habe ich mal ein grobes Gefühl.

@Matthias
Bedacht habe ich das bereits. Dazu kommen ja noch so späße wie Overhaed 
für die Adressierung. D.h. es wird nochmal etwas mehr. Die einzige 
Möglichkeit die ich hier im Moment sehe wäre, einen richtigen PC die 
Vorarbeit machen zu lassen (Umrechenen des Bildes in die Kugelform, 
Anpassung der Helligkeit, an den Polen müssen die LEDs ja dunkler sein, 
und optimieren der Daten für die Hardware) Dann müsste er das ganze noch 
komprimieren. Da bliebe für die Hardware "nur" noch entpacken und 
verteilen, was natürlich noch immer ein gigantischer Aufwand ist. 
Allerdings ist das bisher nur eine Option die ich mir offenhalten 
möchte. Dazu fehlt mir im Moment die Erfahrung und ich möchte irgendwann 
ja auch mal fertig werden. Sollte es sich niemals realisieren lassen, 
dann müsste ich beim 2. Versuch das Konzept hier vollkommen verändern.

@Falk
Auch dir vielen Dank für die vielen Tipps, ich lerne hier gerade eine 
Unmenge dazu.

>FRAM ist KEIN Videospeicher. Da gibt es nix zu schreiben. Du LIEST aus
>einem Speicher un gibst es auf die TLCs.

Würde mich das nicht erstmal nur auf ein Bild beschränken?

>Dein Konzept ist Murks.

Okay kannst du das noch etwas spezifizieren? Es muss ja besser werden. 
Was passt da noch überhaupt nicht, ausgehend von den Dimensionen (wobei 
wir Animation in Echtzeit mal besser im Hinterkopf behalten, also 
erstmal nur RGB größer 1Bit pro Farbe und möglichst hohe Auflösung):
-die TLC im allgemeinen
-die TLCs kaskadieren
-die Speicherbausteine pro 180°
-allgemein extern speichern
mehr fällt mit gerade nicht ein.
Oder drehen wir den Spieß mal um: Kannst du mir erklären wie du deinen 
Entwurf aufgebaut hattest?

>Das ist dein AVR!

Kapiert, dann ergibt sich nur noch ein Problem. An den Ring müssen ja 
mehrere dieser Module. Könnte ein AVR so viel auf einmal bewältigen? Um 
mal meinen Irrsinn im vollen Ausmaß vorzustellen: Ich rechne im Moment 
bei einem Platz pro LED mit 4mm auf einen Halbkreis mit 300mm 
Durchmesser. Das sind 235LED. Das sind gigantische Dimensionen...
Durch den modularen Aufbau hätte der AVR einzig das Managment aller 
Module zu übernehmen. Den Rest macht die jeweils zuständige Hardware.

>Fang mal ne Nummer kleiner an.

Ich verspreche hoch und heilig das Ganze langsam anzugehen. Ich werde 
sowieso zunächst alles auf Steckbrettern aufbauen und dann evtl. auch 
mit Signalgenerator und Oszi quälen. Mir geht es darum, alles bis in 
diese Dimension auszulegen. Wenn ich später feststelle alles ist so 
schnell dass auch mehr möglich gewesen wäre und alle anderen Komponenten 
machen nicht mit weil es so nicht geplant war. Werde ich mich auch ewig 
darüber ärgern. Aber umso wichtiger ist es mir jetzt, das Konzept 
gescheit zu machen.

>Nicht für LED-Enthusiasten ;-)

Ich habe da nochmal drüber nachgedacht. Was habe ich eigentlich von 
einer 12-Bit PWM pro Farbe, also 36bit-Farben? Selbst PCs machen doch 
nicht mehr als 24Bit? Wenn also die letzten 4Bit jeder PWM eh nur 0 
sind, könnte ich mir das doch auch sparen. Gibt es serielle Current 
Sinks mit 8-Bit PWM?

>Sind aber nur 25 Zeilen. Macht satte 12 Mbit/s
Jupp, das wäre auch meine Zahl (pro Modul...) Da hat mein LAN weniger. 
Aber ich würde gerne Hardwareseitig die Option wenn möglich behalten.

>Ja und? Du hast dich unverständlicherweise in deinen FRAM verbissen.
Da muss ich dir Recht geben. Mir hat die einfache Ansteuerung in 
Verbindung mit der hohen Geschwindigkeit so gut gefallen. Aber so 
langsam sehe ich ein, dass das nicht sein muss.

>Für einen Anfänger klassisch über seinen Möglichkeiten. ;-)

Gebe ich dir Recht. Mein Problem ist, ich habe noch 2 Semester in denen 
ich genug Freizeit zusammenbekommen kann. Danach wird es vermutlich zu 
knapp um großartig voranzukommen. Ich möchte daher jetzt etwas 
Anständiges hinbekommen. Das muss gehen. Umso wichtiger ist, dass das 
ganze schon auf dem Papier funktioniert, und ich bin euch sehr dankbar 
dass ihr mir dabei helft. Zudem bin ich zwar noch unerfahren, aber lerne 
sehr schnell. Ich bin überzeugt, dass ich das mit Ruhe, Geduld, viel 
Ausprobieren und eurer Hilfe hinbekomme.

@all
Vielen Dank für eure Kommentare

Gruß Tim

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zb. TLC5941, PWM frequenz ist max. 30MHz bei 12 Bit = 4096 Stufen = 
30MHz/4096 = 7324/sec. 7324/25U=292, 292/500 Spalten = 0.584. Dh. die 
TLC und ihre 12Bit PWM müsste 2x schneller sein damit sie überhaupt in 
deiner Konfigutarion funktioniert, mal abgeshen vom Problem der 
Synchronisation im Timing. Vergiß die TLCs mit interner PWM, du musst 
die Teile nehmen ohne PWM und dafür extern selber die PWM machen.

Gruß Hagen

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Tim Kamikater (kamikater)

>Würde ich das dann in etwas so realisieren dass ich einen Timer laufen
>lasse, die Umdrehungserkennung macht mir ein interrupt,

Input Capture Interrupt.

>Timerwert genommen und durch die Auflösung dividiert. Und für jede
>Spalte Auflösung polle ich dann den Timer?

Timer pollt man nicht, man reagiert per Interrupt. Aus der Zeit für 
ein Umdrehung kann man leicht die Zeit für ein Spalte ausrechnen. Diese 
Zeit Schreibt man in den Timer und lässt ihn eine INterrupt auslösen. 
Entweder per CTC- Modus oder Output COmpare Funktion.

>Möglichkeit die ich hier im Moment sehe wäre, einen richtigen PC die
>Vorarbeit machen zu lassen (Umrechenen des Bildes in die Kugelform,
>Anpassung der Helligkeit, an den Polen müssen die LEDs ja dunkler sein,
>und optimieren der Daten für die Hardware)

Ja, das klingt vernünftig.

>möchte. Dazu fehlt mir im Moment die Erfahrung und ich möchte irgendwann
>ja auch mal fertig werden. Sollte es sich niemals realisieren lassen,
>dann müsste ich beim 2. Versuch das Konzept hier vollkommen verändern.

Anders herum wird ein Schuh draus. Erst mal was einfaches bauen, dann 
komplexer werden.

>>FRAM ist KEIN Videospeicher. Da gibt es nix zu schreiben. Du LIEST aus
>>einem Speicher un gibst es auf die TLCs.

>Würde mich das nicht erstmal nur auf ein Bild beschränken?

???
Was hindert dich, in den Speicher (welcher Art auch immer) mehrere 
Bilder abzulegen und dann passend auszugeben?

>erstmal nur RGB größer 1Bit pro Farbe und möglichst hohe Auflösung):

Siehe oben. Mach es erstmal EINFACH!

>Oder drehen wir den Spieß mal um: Kannst du mir erklären wie du deinen
>Entwurf aufgebaut hattest?

Nix wildes. Ein einfacher Hallsensor von Reichelt mit kleinem 
Stabmagneten für die Synchronisation, hing direkt am ICP vom AVR.
Dann 8 LEDs direkt an einem Port dran, fertig.

>mal meinen Irrsinn im vollen Ausmaß vorzustellen: Ich rechne im Moment

Du sagst es, Irrsinn. Back am Anfang mal kleine Brötchen.

>mit Signalgenerator und Oszi quälen. Mir geht es darum, alles bis in
>diese Dimension auszulegen.

Das ist falsch. Bau es erstmal EINFACH. Ich wiederhole mich.

> Wenn ich später feststelle alles ist so
>schnell dass auch mehr möglich gewesen wäre und alle anderen Komponenten
>machen nicht mit weil es so nicht geplant war. Werde ich mich auch ewig
>darüber ärgern.

Und du wirst dich nioch dreimal mehr ärgern, wenn du das Ganz in den 
Sand setzt, weil du deine Fähigkeiten massiv überschätzt hast . . .

>einer 12-Bit PWM pro Farbe, also 36bit-Farben? Selbst PCs machen doch
>nicht mehr als 24Bit?

Nicht wahr . . . ;-)

>sind, könnte ich mir das doch auch sparen. Gibt es serielle Current
>Sinks mit 8-Bit PWM?

Warum PWM? Nimm den TLC5922 oder was ähnliches, der hat 7 Bit 
Konstantstromeinstellung. Das reicht locker.

>Aber ich würde gerne Hardwareseitig die Option wenn möglich behalten.

Vergiss es für den Anfang.

>knapp um großartig voranzukommen. Ich möchte daher jetzt etwas
>Anständiges hinbekommen. Das muss gehen.

Du willst zu viel auf einmal und wirst auf Maul fallen.

>dass ihr mir dabei helft. Zudem bin ich zwar noch unerfahren, aber lerne
>sehr schnell. Ich bin überzeugt, dass ich das mit Ruhe, Geduld, viel
>Ausprobieren und eurer Hilfe hinbekomme.

Wenn du meinst.

MfG
Falk

Autor: Tim Kamikater (kamikater)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen
Totschlagargument. Aber wir wäre das in der Theorie? Müsste ich da nicht 
mehrere PWM-Zyklen pro Spalte haben damit ich eine scheinbar variable 
Helligkeit bekomme? Oder erhalte ich den Effekt durch die hohe 
Drehfrequenz von selbst

@Falk

>Timer pollt man nicht, man reagiert per Interrupt. Aus der Zeit für
>ein Umdrehung kann man leicht die Zeit für ein Spalte ausrechnen. Diese
>Zeit Schreibt man in den Timer und lässt ihn eine INterrupt auslösen.
>Entweder per CTC- Modus oder Output COmpare Funktion.

Müsste ich dann einen zweiten Timer mitlaufen lassen, der mir die 
Umdrehungszeit misst?

>???
>Was hindert dich, in den Speicher (welcher Art auch immer) mehrere
>Bilder abzulegen und dann passend auszugeben?

Baum vor lauter Wald nicht gesehen. Gut, dann könnte ich sogar in 
gewissen Grenzen animieren. Aber rein theoretisch überlegt: Wenn ich 
Bilder hätte die sich in Echtzeit verändern, z.B. sowas wie ein Video, 
dann müsste ich doch jedes Bild während der Übertragung irgendwo 
zwischenspeichern?

>Warum PWM? Nimm den TLC5922 oder was ähnliches, der hat 7 Bit
>Konstantstromeinstellung. Das reicht locker.

Wie muss ich das mit den 7Bit da denn verstehen. Bekomme ich da einfach 
linear einen Anteil von I_MAX? Also quasi I = I_MAX/128 * Wert  ? 
Versteh das im Datenblatt noch nicht so ganz. Und gehe ich dann recht in 
der Annahme dass es keine LEDs gibt, bei denen Helligkeit und Strom 
proportionales Verhalten zeigen?

Sodele, ich bin dann mal einsichtig. Also einen Speicher, SRAM oder 
EPROM. Der kann extern beschrieben werden, z.B. über nen Pfostenstecker 
auf der Platine und dann ein Kabel dran. Der AVR ließt die Daten aus dem 
Speicher und stopft sie über SPI in die Leitung zu den kaskadierten TLC. 
Die TLC ohne PWM, muss nachher noch schauen was es da alles gäbe.

LED habe ich inzwischen was anderes von Osram gefunden. Nennt sich LATB 
T68. Kann mir dazu jemand was sagen? Die sind so verdächtig viel 
billiger als die LRTB G6TG.

Ein weiterer Fortschritt: Ich habe meine Konstruktion mal an die 
Bohrmaschine geklemmt. Leider fehlt mir noch ein guter Treibriemen aber 
mit der improvisierten Variante kam ich kurzzeitig auf gute Drehzahlen. 
Es scheint solider zu sein als ich befürchtet hatte. Läuft sehr stabil 
und rund.

Gruß Tim

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Tim Kamikater (kamikater)

>Müsste ich dann einen zweiten Timer mitlaufen lassen, der mir die
>Umdrehungszeit misst?

Nöö, Timer 1 macht das problemlos.

>gewissen Grenzen animieren. Aber rein theoretisch überlegt: Wenn ich
>Bilder hätte die sich in Echtzeit verändern, z.B. sowas wie ein Video,
>dann müsste ich doch jedes Bild während der Übertragung irgendwo
>zwischenspeichern?

Sicher, aber das liegt um Grössenordungen über deinen (aktuellen) 
Fähigkeiten, behaupte ich mal.

>linear einen Anteil von I_MAX? Also quasi I = I_MAX/128 * Wert  ?

Ja.

>Versteh das im Datenblatt noch nicht so ganz. Und gehe ich dann recht in
>der Annahme dass es keine LEDs gibt, bei denen Helligkeit und Strom
>proportionales Verhalten zeigen?

Nöö, LEDs sind sogar ziemlich gut linear. Allerdings ist der 
physiologische Helligkeitseindruck was anderes, siehe LED-Fading.

MFG
Falk

Autor: Tim Kamikater (kamikater)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Falk.

>Nöö, Timer 1 macht das problemlos.

Halt, da stehe ich noch immer auf dem Schlauch. Ich habe doch 2 
Messungen:
1.Messung eines einzelnen Intervalls, nach dem eine neue Spalte 
angezeigt wird
2.Messung der Dauer einer kompletten Umdrehung (bzw. je nach 
Sensorsystem)

Ich könnte natürlich messen nach der wievielten Spalte meine Umdrehung 
erreicht ist und wo genau der Timer dann steht?

>Sicher, aber das liegt um Grössenordungen über deinen (aktuellen)
>Fähigkeiten, behaupte ich mal.

Kein Zweifel. Aber ich bin neugierig wie sich so etwas umsetzen ließe.

>Nöö, LEDs sind sogar ziemlich gut linear. Allerdings ist der
>physiologische Helligkeitseindruck was anderes, siehe LED-Fading.

Joa, darüber habe ich vor 2 Wochen eine Klausur geschrieben... Aber das 
sind dann alles eher mathematische Probleme und experimentieren. D.h. 
ich hätte hier noch immer eine realistische Möglichkeit, 21 Bit 
Farbtiefe zu erreichen?

Darf ich dich mal noch nach Empfehlungen für LEDs fragen? Was gibt es 
denn noch gutes, bevor ich mich wieder so an einer bestimmten 
festbeisse?

Danke übrigens, dass du mich hier so geduldig zurück auf den Teppich 
holst!

Gruß Tim

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich habe doch 2 Messungen:
>1.Messung eines einzelnen Intervalls, nach dem eine neue Spalte
>angezeigt wird
>2.Messung der Dauer einer kompletten Umdrehung (bzw. je nach
>Sensorsystem)

Nein.

Das erste ist keine Messung.

Du hast nen Timer und das Signal für jede Umdrehung. Mit dem Timer misst 
du diese Zeit für eine Umdrehung. (Timerwert) Jetzt gehst du davon aus, 
dass sich diese Zeit bei der nächsten Umdrehung nicht ändert. Also 
nimmst du diese Zeit und teilst sie durch die Anzahl der Spalten 
(deshalb am besten 2^N nehmen). Diese Zeit musst du warten, bis eine 
neue Zeile erreicht ist. Also brauchst du zwei Interrupts:

Input-Capture:
Hier wird zwischen zwei Aufrufen die Zeit ermittelt und durch die 
Spaltengeteilt.
Etwa so:
ICP_ISR
{
  //-- Zeit ermitteln -------------------
  akt_Timerwert = TCNTx;
  Zeit_pro_Umdr = ( akt_Timerwert - letzter_Timerwert );
  letzter_Timerwert = akt_Timerwert;
  //-- Spaltenzeit ermitteln ------------
  Spaltenzeit = ( Zeit_pro_Umdr >> K );  // Konstante K=lb(Anz_Spalten)
  //-- Zeitpunkt für nächste Spalte -----
  OCRx = ( akt_Timerwert + Spaltenzeit );
  //-- Spalte NULL ausgeben -------------
  ...
}
OCRx_ISR
{
  //-- Zeitpunkt für nächste Spalte -----
  OCRx += Spaltenzeit;
  //-- Spalte N ausgeben ----------------
  ...
}

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>@Hagen
>Totschlagargument. Aber wir wäre das in der Theorie? Müsste ich da nicht
>mehrere PWM-Zyklen pro Spalte haben damit ich eine scheinbar variable
>Helligkeit bekomme?

Nö, ne PWM in irgendeiner Form benötigtst du bei unterschiedlichen 
Helligkeiten pro Farbe sowieso. Du kannst versuchen den TLC trotzdem zu 
nehmen. Ein kompletter PWM Zyklus wäre dann zb. nur 10 Bit statt 12 Bit 
breit. Dh. du müsstest den PWM Takt des TLCs (max. 30Mhz) so anpassen 
das der TLC zb. nur die ersten 1024 PWM Zyklen (10 Bit) statt die 4096 
(12 Bit) durchläuft. Ist aber ein heiden Aufwand denn du musst trotzfdem 
die 12 Bits pro LED schieben, im SRAM speichern, sehr wahrschenlich von 
16Bit auf 12Bit runterkonvertieren beim Senden zum TLC usw.

Oben wurde angedeutet das man die Enstellmöglichkeiten des Stromes der 
TLC's mißbrauchen könnte. Das geht auch nicht, erstens nicht vom Timing 
(Settlingtime der Stromsenken) und zweitens sind diese meistens nur 7 
Bit breit was für die Datenübertragung vom AVR hin zum TLC sehr 
umständlich ist.

Drittens sind die meistens TLCs nicht für externen Multiplexing 
geeignet, gibt glaube nur einen TLC der spezielle 
Multiplexingfähigkeiten hat und aktiv das störende Nachleuchten der LEDs 
beim schnellen Multiplexing beseitigt.

Viertens, bevor du überhaupt so ein Projekt anfängst lohnt es sich 
wirklich einen Plan zu machen und alles vorher exakt durch zu rechnen. 
Alleine schon der Strombedarf der LEDs, der Verdrahtungsaufwand, wie 
speicherst du die Bilddaten im SRAM/ext. Speicher und wie sollte dieses 
Datenformat möglichst so konstruiert sein das man effizient die LEDs 
ansteuern kann, usw. usw.

Gruß Hagen

Autor: Volker Zabe (vza)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo.
erst nachdenken, dann planen und rechnen.
Das Bild ergiebt einen Kreis. Das heist, dass die obersten und untersten 
Zeilen nur sehr wenige "Pixel" haben. Daraus ergiebt sich das jede Zeile 
ein anderes Timing braucht, damit die Pixel gleich breite haben.

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.