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
Angehängte Dateien:
-
mechanik.png
49 KB
@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
Sehr geniale Idee, Bin gespannt, wie das aussieht, wenns fertig ist. ;=)
@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
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.
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.
...und wenn es nicht träge genug ist, dann lass einfach etwas mehr Masse mit rotieren...
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.
>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.
@ 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
@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
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
@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
@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
@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
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
>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:
1 | ICP_ISR
|
2 | {
|
3 | //-- Zeit ermitteln -------------------
|
4 | akt_Timerwert = TCNTx; |
5 | Zeit_pro_Umdr = ( akt_Timerwert - letzter_Timerwert ); |
6 | letzter_Timerwert = akt_Timerwert; |
7 | //-- Spaltenzeit ermitteln ------------
|
8 | Spaltenzeit = ( Zeit_pro_Umdr >> K ); // Konstante K=lb(Anz_Spalten) |
9 | //-- Zeitpunkt für nächste Spalte -----
|
10 | OCRx = ( akt_Timerwert + Spaltenzeit ); |
11 | //-- Spalte NULL ausgeben -------------
|
12 | ...
|
13 | }
|
14 | OCRx_ISR
|
15 | {
|
16 | //-- Zeitpunkt für nächste Spalte -----
|
17 | OCRx += Spaltenzeit; |
18 | //-- Spalte N ausgeben ----------------
|
19 | ...
|
20 | }
|
>@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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.