Kleine Bastelei: "Borg-Cube" 3x3x3

  • das reimt sich sogar! :P


    angeregt durch Gefachsimpel in http://diesem Thread dachte ich mir, jetzt muss ich endlich auch mal so nen "Cube" bauen - da das aber ne Sache für einen Abend werden sollte, habe ich mal nur 3x3x3 gemacht... das Dings ist nur 4,5 cm Kantenlänge klein, soll aber ja auch eher was für den Schreibtisch werden o.ä.


    Hier schon mal ein Video zum Appetit anregen: ;)



    Also angefangen, erst mal Löcher in ein Brett, damit das halbwegs sauber wird, darin die Ebenen zusammengelötet:



    Diese dann zu dem Cube verbunden:



    Cube auf Platine mit Kleinkram, angeschlossen an mein Tiny2313-Board:



    Das ist vielleicht ein krummes Ding! 8o - aber egal, soll ja nur als Ausgabehardware dienen, damit ich sehe, was die Software so macht. Im Prinzip gefällt mir das mit den klaren LEDs (hatte gerade keine anderen) auch besser, Nachteil: die unteren LEDs strahlen in die oberen rein, deswegen sieht das teilweise so aus, als würden die mitleuchten, obwohl sie eigentlich aus sind. Das ist in echt aber nicht so arg wie auf dem Video... trotzdem werde ich versuchen die LEDs unten noch schwarz zu lackieren, ausserdem kommt evtl. noch Frostspray über das Ganze...


    Schaltplan für das Teil (Anoden an den Säulen, Kathoden an den Ebenen):
    EDIT: Achtung! - der Schaltplan ist veraltet! - den neuen gibt es hier.



    Die LEDs laufen rechnerisch mit diesen Vorwiderständen (390 Ohm) auf 5 mA, ausserdem im Taktverhältnis 1:2 (durch das Multiplexen), dafür sind sie schon ganz schön hell!


    Zur Software (die ist unten verlinkt, ich habe .asm durch .txt ersetzt, weil die Forensoftware kein .asm nimmt):
    EDIT: Software rausgenommen, da nicht mit der neuen Hardware kompatibel - hier gibt es eine passende Version in Bascom


    Wie ein dem anderen Thread schon angesprochen, habe ich mir das ganz einfach gemacht, also nix mit Schieberegistern, direkt an den AVR.


    Die "Bilder" sind im Flash abgelegt, immer 6 Byte für einen kompletten Cube - die Ebenen (je 2 Byte) werden in einer ISR durchgescannt...


    hier war folgende Situation: ich brauche 9 Bit für die Säulen, also eh' schon 2 Byte pro Ebene im "Bildspeicher" - also habe ich gleich noch die nächsten 3 Bit für die Ebenen genommen, ich muss in der ISR also keine Bits rumschieben o.ä., nur die 2 Bytes an 2 Ports ausgeben, fertig!


    Hier mal ein Beispiel:


    .db 0b00001001, 0b11101111 ; Outline
    .db 0b00000101, 0b01000101
    .db 0b00000011, 0b11101111


    EDIT: Diese Bitbelegung wurde geändert, Ebenen sind nun Port D 4-6!


    ... die grünen Bits sind für die 9 Säulen, die roten Bits bestimmen, welche Ebene grad dran ist. Da sind noch 4 Bit frei, man könnte also zu jedem Bild noch ne Dauer, Helligkeit o.ä. speichern...


    da fällt mir grad ein: auch so eine Art "Overscan-Modus" wäre da möglich - z.B.:


    .db 0b00001001, 0b11111111
    .db 0b00001101, 0b11111111
    .db 0b00001111, 0b11111111


    würde bedeuten: die oberste Ebene ist beim kompletten Multiplex-Durchlauf an, die zweite nur bei 2/3 und die unterste nur bei 1/3 - sollte also nen Würfel geben, der von unten nach oben heller wird... mag jetzt aber nicht das Video nochmal machen.... kommt später, falls das funktioniert...


    Das zamlöten und die Steuersoftware waren gestern nacht schon fertig, ich musste mir dann natürlich noch Bilder überlegen und in Bits übersetzen - das hat doppelt solange gedauert wie der Teil davor, aber das ist ja auch das, was Spaß macht :D -


    btw.: da wäre es natürlich super, wenn man eine SW am PC hätte, in der man Animationen am Bildschirm entwerfen kann, und die SW macht dann die Bitmuster draus - gleich in einer .inc-Datei... aber PC programmieren kann ich nicht..


    Mir würden noch 1.000 weitere Muster einfallen, leider ist erst mal der Speicher voll (bzw. mein Programmzähler erlaubt nur 256 Schritte...).


    Die Steuer-SW selbst belegt nur 202 Byte, die restlichen 1.488 von insg. 1.690 sind die abgelegten Muster.


    Was jetzt als nächstes kommt:


    - Speicheroptimierung: diese Animationen bestehen ja aus immer wieder wiederholten Frames, d.H. von den 247 im Speicher sind etliche gleich - also werde ich gleich nen Speicher für die ganzen "Grundbilder" machen, der Programmzähler liest dann ne Tabelle aus, in der die Nummer des Frames steht


    die mach' ich dann in 16 Bit, 1. damit ich mehr als 256 Schritte haben kann und 2. eben noch Dauer, Effekte etc. zu jedem Schritt speichern kann. Ausserdem gibt es dann ein "Ende"-Flag, damit man nicht immer oben die Zahl der Schritte im Speicher eintragen muss.


    Ziel ist eine Animation von 10 Minuten, die sich in der Zeit nicht wiederholt :D


    - im Zuge dessen wird der Speicher, aus dem die ISR liest, in's Ram verlegt - wäre also theoretisch möglich, dass man darin auch Bilder *irgendwie* rechnerisch per SW erzeugt - so wie auf jeder Grafikkarte auch...


    - In die Multiplex-Routine kommt noch ne PWM mit rein - das ist ganz easy, momentan bekommt jede Ebene ja 1/3 der Zeit, per PWM dann halt z.B. nur noch 1/8, damit lässt sich der Cube insgesamt oder sogar extra pro Ebene dimmen...


    na, da leg' ich mal los und schaue mal, wie weit ich heute komme... 8o

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

    3 Mal editiert, zuletzt von Pesi ()

  • Hübsch hübsch. Habe mir grade den Code mal angeschaut, aber Code von anderen verstehen ist nie so ganz einfach, is zumindest meine Meinung und jetzt ists mir auch schon was spät um mich da noch rein zu hängen ;) Hätte ich was mehr Zeit... huch sind ja Semesterferien :D Muss mal schauen, dass meine anderen Sachen fertig werden und dann werd ich mich auch nochmal vor den Cube hängen, du hast jetzt wieder meine Neugierde geweckt ;)

  • Hallo


    Wow, gefällt mir schonmal gut! So soll meiner auch werden, allerdings nicht in ASM geschrieben, da versteh ich ja kein Wort?! :huh: Und hat der ATTiny nur 1,5k Speicher? Ist ja reichlich wenig :(


    Freue mich schon auf die Erweiterung :rolleyes:

  • Hochsprache ist ..... - also für sowas... mein Steuercode hat gerade mal 202 BYTE (!) - würde mich mal interessieren, was da rauskommt, wenn Du das in C oder gar Bascom schreibst... angesichts dessen sind die 2k Flash vom Tiny schon riesig!


    Wie schon gesagt, meine Software ist schnell und schmutzig programmiert - jedes Bild, das während der Animation läuft, belegt 6 Byte im Speicher - diese Stellen, wo das mal langsamer läuft, da kommt einfach mehrmals hintereinander das selbe Bild! - und Animationen die öfter durchlaufen, liegen halt öfter im Speicher...


    Die Zahl der *unterschiedlichen* Bilder ist gar nicht so groß, man kann durch geschicktes Programmieren (da bin ich *eigentlich* grad dabei, aber jetzt schreib ich schon wieder hier :P) diese 1.488 Byte DATEN auf geschätzt 400 zusammendrücken - wie auch schon gesagt, ich gehe davon aus, dass ich da in den Tiny 2313 ein Programm mit 10 Minuten Laufzeit reinbekomme...


    Wie Assembler verständlich machen...? - Viele Sachen sind gar nicht soo anders, wenn's bei mir z.B. heisst


    ldi Speed, 64


    würde das in Bascom wohl


    Speed = 64


    heissen... Unterschied: Du definierst "Speed" zuerst als Byte (das Bascom dann wohl im Ram ablegt...?), bei mir ist's ein Register, das ich mir selbst (geschickt) aussuchen muss...


    Bitschiebereien sehen ähnlich aus, was ich so gesehen habe....


    Du fragst halt "if Ebene = 3", ich sage "cpi Ebene, 3" ("Ebene" mit "3" vergleichen) und dann, was passieren soll, wenn's gleich ist oder nicht ("brne" - branch on not equal, wenn's nicht gleich ist, dann da & dort weitermachen....)


    das mit dem Z-Pointer bei mir wäre bei Euch wohl ein Array... Ihr müsst Euch bei Subroutinen etc. um nix kümmern, ich muss z.B. das Statusregister sichern - also Assembler erfordert mehr Aufmerksamkeit für's Detail, dafür kommt eben wesentlich kleinerer/schnellerer Code bei raus... bei dem Du der Maschine wirklich *Schritt für Schritt* sagen kannst, was sie machen soll.. wer weiß schon, was das Teil macht, wenn Du in Bascom "Wait 10 ms" hinschreibst...?


    Zum Verständnis meiner Software (ich habe mich bemüht, das sehr gut zu kommentieren :D)):


    - die Bilder liegen einfach der Reihe nach im Speicher.


    - es gibt einen "Bild"-Zähler, der diese der Reihe nach hochzählt (ca. im 0,5-Sek-Takt) und zwar von 0 weg (nicht 1)


    - dann gibt's noch nen Ebenen-Zähler, der wird in der ISR durchgezählt (ebenfalls von 0 weg)


    - ich lade den Z-Pointer mit der Anfangsadresse der Daten - er zeigt also auf das erste Byte


    - nehmen wir mal an, es soll gerade die zweite Ebene des zweiten Bildes angezeigt werden - dann ist der Bild-Zähler "1" (weil das erste Bild ja "0" ist), der Ebenen-Zähler auch.


    also rechnet die ISR: 6x Bildzähler + 2x Ebenen-Zähler = das 8. Byte im Bildspeicher - das ist genau das, das die 2. Ebene im 2. Bild repräsentiert - also holt er sich das (und das nächste dazum das gehört zusammen) und gibt diese 2 Bytes an die 2 Ports aus...


    Und das macht diese ISR halt 244x in der Sekunde, damit das so aussieht, als wenn der ganze Cube leuchten würde - in Wirklichkeit ist es immer nur eine Ebene auf einmal...

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Was heisst "rumgequält"...?!?! - das ist eine Freude! :P


    nee, mein' ich ernsthaft - hier hast Du die Möglichkeit, selbst zu bestimmen, was wo landet - das erfordert natürlich ggfs. Planung ...in Bascom kannst Du (wahrscheinlich) beliebig oft sagen "Dim xy as Byte", das legt das dann (vermute ich) im Ram ab, und bei nem kleinen Speicher wächst dann evtl. irgendwann der Stack rein, und Du wunderst Dich, warum Deine SW rumspinnt...


    aber zum Thema: ich habe das mit dem "Overscan" mal ausprobiert - bringt nicht soo viel - die LEDs, die die ganze Zeit leuchten sind zwar schon *etwas* heller, aber nicht so deutlich - erstaunlich eigentlich....


    wegen der Mechanik eines Cubes wird ja gerade parallel hier weiterdiskutiert... die dort angesprochene "Erst Säulen bauen"-Methode hat mich auf eine Idee gebracht: warum denn immer Cube? - man kann sowas ja z.B. auch in 3x3x30 bauen als hohe schlanke Säule - darüber dann sowas laufen lassen wie die vorletzte Animation in meinem Video und man hat eine "LED-Alternative" zu so ner "Blubbersäule" 8o


    ich glaub' das muss ich auch noch irgendwann mal bauen... Problem: 30 Ebenen durchmultiplexen ist Sch****, also dann hier die Säulen - kein Problem, aber man braucht (so & so) 30 Leitungen für die Ebenen, da wäre dann schon ein Schieberegister angesagt - der Verkabelungsaufwand bleibt trotzdem...


    da hab' ich mir gedacht, das wäre doch ne Idee (egal ob für so ne Säule, oder einen Riesen-Cube), wie wäre es, wenn gleich an jeder LED ein 1-Bit-Schieberegister *direkt* dran wäre? - also z.B. für nen *wirklich* großen Cube je eine LED und sowas in nem Tischtennisball o.ä., und das dann mit nur 5 Leitungen (Vcc, GND, Clock, Data, Strobe) durchverbunden...?


    Da wären die IC-Experten gefragt: gibt's sowas, ein 1-Bit-SR in z.B. nem 8-poligen IC? - ich weiß, man könnte das auch mit nem Tiny "simulieren", aber hier besser ein Teil für 10 Cent oder so...? Wobei man mit dem Tiny natürlich nicht nur ein/aus, sondern auch gleich PWM mit 256 Abstufungen machen könnte...


    Mein SW-Update wird heute wohl nicht mehr fertig... ich schreibe immer ein paar Zeilen, und dann kommt auch schon wieder so ne "Neuer-Beitrag"-Mail - da "muss" ich dann natürlich gleich nachschauen... bin wohl internetsüchtig :D

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • als freude empfind ich das nicht, wenn ich noch erst gucken muss wo ich was genau hinschreiben muss. Ich bin es halt seit Jahren gewohnt alles in Hochsprache zu schreiben, weil die paar kB mehr auch keinen stören. Bei dem begrenzten Speicher ist das natürlich dann problematisch, da hast du recht.
    Die Idee mit der Säule ist auch nicht schlecht. Wünsche aber viel Spaß dabei die 270 LEDs zu verlöten :D
    Deine Idee mit den 1Bit-Schieberegistern an allen LEDs verstehe ich irgendwie nicht so ganz und ich habe irgendwie die Vermutung, dass du, selbst wenn es funktioniert, dadurch keinen besseren, sondern nur einen höheren Verkabelungsaufwand bekommst.

  • Der Würfel ist doch schon mal ganz schick geworden Pesi :thumbsup:


    Die Säule ist ja auch mal eine Super Idee. Ich hätte da auch einen Vorschlag zur robusten und einfacheren Gestaltung. Mal sehen, ob ich am Wochenende Zeit habe und an die Fräse komme, dann bastel ich zumindest mal den Anfang zusammen.

  • ....und Dank Deinem Frostspray sieht er jetzt auch richtig gut aus! 8o


    wegen dieser 1-Bit-SR-Sache nochmal: das wäre halt für was größeres gedacht, z.B. 10x10x10, auch in größeren mechanischen Dimensionen, also nicht einzelne LEDs, sondern eher Leuchtkugeln in TT-Ball-Größe o.ä.


    irgendwo gab's hier auch schon mal ein Foto von sowas, finde es nur grad nicht...


    der Sinn dahinter war der: bei ner herkömmlichen Cube-Ansteuerung hast Du ja 100 Leitungen für die Säulen und 10 für die Ebenen - macht 110..


    bei der von mir erwähnten Methode müsstest Du nur ein Signal durch den ganzen Cube durchschicken, da die Schieberegister ja schon *im Cube* drin sind, also geht das insg. mit 5 Leitungen für den ganzen Cube...


    und nachdem jede LED ihr eigenes Bit hat, ist der "Bildspeicher" praktisch *im Cube*, d.h. er hält das angezeigte Bild von selbst, also auch keine Probleme mit schlechter Helligkeit wegen Multiplex....


    so in der Art (halt dann je nach Cube-Größe meinetwegen 1000 Kugeln durchverbunden):



    Die Geswchwindigkeit spielt dabei keine sooo große Rolle, weil ja kein Multiplex da ist - es muss ja nur ein Refresh pro neuem Bild gemacht werden, bei meinem Cube z.B. sind das auch bei den schnelleren Animationen vielleicht 3-4 Bilder pro Sekunde.....


    und wenn die Schnittstelle schnell genug ist, könnte man eben statt Bits (Kugel nur an/aus) auch gleich RGB-Daten übertragen, so in der Art wie hier schon mal angedacht (runterscrollen bis zum Ende des Beitrags)....


    Andy: bin schon gespannt! :)

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • achso jetzt hab ichs, du willst quasi das x-fach schieberegister in einzelne zerteilen und die dann immer direkt an die LED klemmen. Auch keine schlechte Idee. Aber: Wenn du zwischen 1000 leds entlang gehst hast du 999*5 Leitungen im Vergleich zu sonst 110 wie du bereits gesagt hast. Ich denke mal der Verkabelungsaufwand ist dann immernoch höher. Sagen mir zumindest die Zahlen :D

  • Im Grunde schiebt man doch erstmal 1000 Daten rein, die dann immer aus dem vorherigen Schiebregister "rausfallen" und ins nächste kommen. Im Grunde hast du doch durch die Reihenfolge eine klare Adresse bsp "das 503. Schieberegister". Man hat dann zwar immer einen Delay, indem man erstmal wieder 1000 Daten in einer langen Polonaise durch alle SR schieben muss. Wieso sollte es nicht funktionieren?

  • Sorry, da ist wohl etwas nicht ganz klar rübergekommen, das kommt davon, wenn man so knappe Beiträge schreibt, weil man grad in mehreren Threads aktiv ist.... :D - ich glaube, ich muss mich doch mal wieder etwas von dem Forum fernhalten...


    Lötmeister, erst mal noch vielen Dank für den Link - sieht interessant aus das Teil.... aber ich war da leider nicht ganz genau, ich bräuchte *eigentlich* ein SR mit Latch, also sowas wie 1/8 74HC4094...


    Wegen dem "Bussystem" - meinst Du das oben gepostete, oder das in dem anderen, verlinkten, Thread... das sind nämlich 2 paar Stiefel... evtl. ist da auch was durcheinandergekommen, weil ich so schnell von der SR-Idee zu der Tiny-Idee weiter bin....


    oben das mit den Schieberegistern: das funktioniert so - wenn da ein Latch mit drin ist, daher auch die "Strobe"-Leitung: ein Schieberegister muss ja nicht adressiert werden, in dem Fall schiebt man halt einfach 1.000 Bit durch die 1.000 Kugeln, das zuerst geschickte Bit landet in der 1.000sten Kugel, das zuletzt geschickte in der ersten... dann "Strobe" und die Kugeln übernehmen das... so wie bei ner Matrix mit 4094-SR halt auch... also das, was Fightclub so nett mit "Polonaise" bezeichnet hat... 8o - ich wiederhole ihn da jetzt, hatte das aber vorher schon getippt....


    Bei der Idee in dem anderen Thread, das war auf die RGB-Lösung mit Tinys bezogen: da machen *die* die Arbeit, das auseinanderzudivieren... Du gibst ein "Start"-Signal (also z.B. ne Pause, so wie bei DMX), dann geht der Datenstrom los. Der erste Tiny nimmt sich die ersten 3 Bytes, die nächsten schickt er weiter (aber ohne die, die er schon genommen hat). Für den 2. Tiny sind also die Bytes 4-6 die "ersten 3 Bytes" usw. - so landet letztlich jedes Byte da, wo es hin soll.


    Wegen der Verkabelung, Fightclub: ich meinte ja 110 Leitungen *vom Controller zum Cube* gegenüber 5 - *innerhalb* des Cubes sieht es ja anders aus:


    bei mir - wie von Dir schon berechnet - 999 x 5 (wobei die 5 dann z.B. ein Flachbandkabel wären), also als Einzeladern wären es 4.995 Verbindungen


    bei nem normalen Cube sind's auch schon mal 990 für die Säulen (100 Säulen, je 9 Verbindungen) und dann noch mal die Verbindungen innerhalb der Ebenen (je 99 zwischen den 100 LEDs einer Ebene) und von jeder Ebene nach unten, also hier noch mal insg. 1.000 Verbindungen...


    insgesamt ist der Vergleich also 4.995 zu 1.190 - *nicht* 999x5 zu 110!!


    Wobei bei mir das dann einfach 100 Ketten sind, die z.B. aufgehängt werden (man könnte den Cube also z.B. auch ganz einfach zum Transport "zerlegen"), bei der "normalen" Variante hast Du ja auch noch die gnazen Querverbindungen, das ist vom Aufwand her größer, als einfach ne lange Kette....


    aber wie gesagt, da reden wir halt von nem Teil 10x10x10 (ohne mehr Kabel auch in Full RGB möglich) mit 2 m Kantenlänge... bei so nem kleinen Fummel-Cube würde ich auch nicht an jede LED noch ein IC hinhängen... :D


    Zefix! ich finde einfach dieses Bild nicht, von diesem Leuchtkugel-Vorhang, der das verdeutlichen würde, was ich meine....


    EDIT: eine Zahl war falsch, Tippfehler...

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

    Einmal editiert, zuletzt von Pesi ()

  • So, jetzt hab' ich's - der Thread-Titel heisst sogar (na, wie wohl?) " LED - Cube" 8o :wacko:


    sowas meinte ich mit dem "Ketten-System" - auch so *ungefähr* von der Größe her (evtl. weniger Kugeln halt mit größeren Abständen....) - das müsste doch zumindest *ungefähr* so auf die Art funktionieren...? ?(


    P.S.: da geht'S jetzt rein um die Theorie! - habe nicht vor, sowas zu bauen (ausser ich gewinne im Lotto, aber dazu müsste ich erst mal spielen :D)

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Hm? - ach, *da* stammt die Verwirrung her! :D - also in meiner Zeichnung fehlt ja praktisch alles, die Kugeln sind einfach ne "Black Box" wo oben 5 Leitungen rauskommen und unten 5 reingehen... ich habe das ja auch nicht als Bussystem bezeichnet...


    Also, um genau zu sein: Vcc, GND, Clock und Strobe werden da durchgeschliffen, Data geht natürlich in das jeweilige Schieberegister rein und der Übertrag hinten wieder raus zur nächsten Kugel...


    Bei der Tiny-Version übrigens so ähnlich: da muss es auch jeweils nen eigenen Pin für Daten von der vorhergehenden Kugel und Daten zur nächsten Kugel geben - sonst kann der ja nicht die 3 Bytes "entfernen"....


    mit Clock-Leitung wäre das ne synchrone Übertragung, bei ner asynchronen würde es evtl. sogar mit nem Tiny 25 ausgehen - siehe hierzu diese Überlegungen (runterscrollen), ein asynchrones serielles Protokoll per Software.... ist halt immer nur die Frage, die Balance zwischen HW-Aufwand und max. möglicher Refresh-Rate....


    ich weiß, asynchrone Übertragung ohne Quarz usw. - aber dazu: mein Bruder arbeitet bei nem Lohnentwickler/Fertiger Zuliefererindustrie - die machen Komponenten für Automobil, Geldautomaten, Kassensysteme, Getränkeautomaten, ... also alles, wo ein embedded System drin ist. Der sagt, die verwenden oft gar keinen Quarz, sondern kalibrieren den internen RC-Oszi mit dem dazugehörenden Register - soll teilweise sogar genauer als Quarz sein ?( :blink:

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • So, mal wieder was zum eigentlichen Thema: auf "vielfachen" 8o Wunsch hier mal ein Schaltplan mit den LEDs:
    EDIT: Achtung! - der Schaltplan ist veraltet! - den neuen gibt es hier.



    Achtung: bei dem ersten war ein Tippfehler - da kommt öfter mal die Säule 7, das ist natürlich Quatsch! - noch ne Änderung hier: der Quarz fällt weg - dann ist das noch mal was einfacher, für so ne Anwendung braucht man ja keine quarzstabilen 16 MHz... SW muss natürlich angepasst werden, sonst flimmert das Dings und läuft zu langsam... stelle ich noch rein.... übrigens: hier fehlt der Puffer-Kondi am Tiny2313 (einfach 100 nF von Vcc nach GND), den vergesse ich immer auf dem Schaltplan, weil der eh' selbstverständlich ist...


    Ahh, die LEDs: sieht aus wie ne Matrix, ne? :D - genau wie ich schon gesagt habe, so ein Cube ist ja nur ne zusammengefaltete Matrix - die Ansteuerung ist die selbe, nur dass die LEDs anders im Raum verteilt sind.. aber jetzt bitte keine Fragen nach ner 3D-Skizze, anhand des Plans sollte man schon rausfinden können, wie man den Cube zusammenlöten muss...


    Und wer mal ne (kleine) Matrix machen will, danach wurde ja auch schon öfter gefragt: selbes Prinzip, am µC sind noch ein paar Pins frei, hier würde z.B. - ohne Schieberegister - 10x5 gehen, damit kann man schon ne kleine Laufschrift machen - mit nem Mega8 natürlich deutlich mehr...


    Ich bin jetzt im Cube-Fieber, löte gerade den nächsten zusammen - wieder 3x3x3, das reicht mir (SW ist ja auch schon "fertig"), der Effekt an sich ist ja bei nem 5x5x5 auch nicht "spektakulärer" - dank besserer Planung (wie genau Beinchen biegen usw.) und genauerer Arbeit wird der auch schöner und geht trotzdem schneller als der Erste.... das wird dann aber mal ein "freischwebender", so wie der vom Raimund...


    Ich werde dann auch ein Layout für die Ansteuer-Platine machen - ich habe schon vor, da noch ein paar zu bauen - geht ja fix, kostet fast nix, und für den geringen Aufwand ein echt guter Effekt! - Das Layout stelle ich dann natürlich auch hier rein....

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

    Einmal editiert, zuletzt von Pesi ()