Cube 3x3x3 leicht gemacht (mit Fotos und Schaltplänen)

  • Exakt! - Bei superhellen LEDs ist der Unterschied in der Helligkeit zwischen 5 mA und 20 mA gar nicht so arg groß wie die Zahlen vermuten lassen - mit klaren LEDs kann man das Ding auch bei 5 mA schon als Taschenlampe benutzen... ;) - ich hatte beim ersten Cube auch mehr Strom, bin dann aber runtergegangen, weil's Batterie spart und man wirklich keinen großen Unterschied bemerkt... im Gegenteil, mir war das Ding im Dunkeln dann sogar *zu* hell....

    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!

  • Ich finde das hier alles echt super erklärt und als Anfänger komme ich damit auch ganz gut klar. Ich habe nur das Problem mit Assembler. Mein Porgramm zum übertregen des Programmes auf den ATtiny nimmt nur assembler und CC+. Aber es kennt den Befehl .db nicht. Kann mir da jemand weiterhelfen.

  • Ich kann die .hex Dateinen öffnen und auch übertragen. Bei den .bin Dateinen öffnet sich nur der Einzeiler:
    À••••••••••�í�¿ÀìæêN.Ý'].îçðà æ°àˆ'�“1â€â€é÷f$��ç�»ìäñà€à�à¢æѢ摑AàPà¢æ““€à�à æ�“œ“¢æM‘\‘ æ‘‘ð ðdÀ€à€“e
    Ünterstützt Ponyprog auch USB Programmer?

  • Moin!


    Da ich lieber Assembler verwende als Bascom, habe ich die Cubeansteuerung in Assembler geschrieben. Vielleicht braucht sie ja mal jemand.


    Wenn jemand den Code verwenden möchte, sollte er/sie die Frequenz seines AVRs ganz oben bei "Takt" eintragen und kann sich auch die Einblendungszeit eines Bildes unter "Bild_Dauer" anpassen. Der Wert für die Verzögerung wird dann aus den Werten berechnet. So kann der Code verendet werden, ohne das die Fuses geändert werden müssen!


    Für die Bilder aus der Muster.txt, das Programm für Assembler von Fightclub verwenden!


  • HI,
    ich hab mal ein paar Bilder in den Cube geladen, leider lässt der nach 170 Bildern die LEDs wild durcheinander blinken.
    Woran kann das Liegen? Außerdem währe es für mich nochmal interessant wie man die geschwindigkeit bei einem bestimmten bild erhöhen oder senken kann?
    Ich hab leider noch nicht so viel in Basic programmiert, währe für eure hilfe dankbar.
    Gruß

  • Hast Du die Bilder mit dem Editor von Fightclub erstellt...? - falls ja, kannst Du mal die Muster.txt hier reinstellen..? (Als Dateianhang) - im Endeffekt muss dann wohl da drin was faul sein...


    versch. Gewchwindigkeiten pro Bild geht mit dieser Software leider nicht, ist auch im Editor nicht vorgesehen, da müsstest Du selbst was programmieren.... bzw. such doch mal nach 4x4x4-Cube, da habe ich für irgendjemanden schon mal sowas in Bascom gemacht - weiß aber nicht mehr, für wen und welcher Thread das war... evtl. ist sogar hier irgendsoein Beispiel drin, aber der Thread ist jetzt auch schon wieder so unübersichtlich....

    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!

  • Also wie erwartet weise ich jede Schuld von mir :D Der Editor hängt die neuen Bilder einfach hinten an, dem ist egal wie groß das ganze ist. Meine Vermutung ist, dass Bascom das eben so weit kompiliert, wie es der Speicher des Tiny zulässt und den Rest schneidet er einfach weg. Dadurch entsteht wahrscheinlich ein leichter Versatz, da z.b. noch eine Zeile vom nächsten Bild da ist. Eine Alternative, was sogar noch wahrscheinlicher ist: Du hast mehr Bilder erstellt, als der Tiny speichern kann. Dadurch ist die Anzahl Bilder, welche am Anfang festgehalten wird nicht identisch mit der Anzahl Bilder, die er ablaufen lässt. Sobald er über die gespeicherten Bilder hinaus geht sagt der Speicher ihm "ich hab hier noch ein paar bilder". Da dem allerdings nicht so ist läuft der Tiny dann im Speicher Gott weiß wo hin. Eventuell liest er den Sourcecode ja sogar als Bilddatei aus. Dass dabei ein wildes Durcheinander entsteht ist klar.


    Soweit meine Vermutung.

  • Ja, das klingt logisch! - war auch nicht so gemeint, dass Du da irgendwas falsch programmiert hättest... ;) :)


    Das könnte schon sein, ein Bild belegt ja 6 Bytes, wären bei 170 Bildern dann 1020 Bytes - bei mir (Assembler) kein Problem, aber schon möglich, dass Bascom den Steuer-Code so arg aufbläst, dass bei 170 Bildern schon Feierabend ist....


    Anbei mal dieser andere Code (habe ich auf meiner Festplatte wieder gefunden ;)), bei dem jedes Bild nur einmal abgelegt werden muss und beliebig oft aufgerufen werden kann - mit einstellbarer Zeit pro Bild... schau' Dir das doch mal an, die Bilder selbst kannst Du mit dem Editor erstellen, den Ablauf musst Du dann "per Hand" eingeben....


    Das spart Speicher, weil sich bei so Cube-Animationen ja oft was wiederholt, Du musst hier dann nicht immer wieder die selben Bilder ablegen...


    EDIT: sehe gerade, das spart hier auch nur 2 Byte pro Bild - wenn Dir 256 Bilder reichen (mehr gehen in den Tiny eh' nicht rein :D), dann kannst Du noch "Bild" und "Dauer" als Byte deklarieren (und natürlich unten bei "Data" so angeben), dann sind's noch mal 2 Byte weniger pro Animationsschritt...

    Dateien

    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 ()

  • Ja, das klingt logisch!

    Ich denke auch, dass letzteres der Fall ist. Irgendwer hatte mal rausgefunden, dass nach 170 Bildern nämlich nichts mehr reingeht, weiß grad nicht wers war, glaub Tech wars. Wenn der Zähler dann mehr angibt ist natürlich Ende im Gelände. Nur komisch, dass da nur rund 1kB an Bildern reinpasst. Bei den 2kB des Tiny wären das ja schon 1kB nur für die paar Schleifen. Die Kommentare zu den Bildern kompiliert er ja auch nicht mit, von daher kann das ja auch nicht sein. Sehr komische Sache. Wäre ich nicht etwas in Eile würde ich mal aus Spaß nur den Code ohne Bilder kompilieren und dann mal schauen wie groß der ist. Vielleicht kann das ja mal jemand machen der grade Langeweile hat und uns mitteilen wie groß das entstandene File ist.

    war auch nicht so gemeint, dass Du da irgendwas falsch programmiert hättest... ;) :)

    Schon klar, war ja auch nicht ernst gemeint ;) :)

    EDIT: sehe gerade, das spart hier auch nur 2 Byte pro Bild - wenn Dir 256 Bilder reichen (mehr gehen in den Tiny eh' nicht rein :D), dann kannst Du noch "Bild" und "Dauer" als Byte deklarieren (und natürlich unten bei "Data" so angeben), dann sind's noch mal 2 Byte weniger pro Animationsschritt...

    Ist immerhin ne Ersparnis von 1/3.

    Das spart Speicher, weil sich bei so Cube-Animationen ja oft was wiederholt, Du musst hier dann nicht immer wieder die selben Bilder ablegen...

    Ich hatte grade überlegt, wieviele Mögliche Bilder es geben kann, aber 134217728 ist dann doch was viel :D Also soviele Bilder müsste man dann in den Speicher legen, dann könnte man jede Animation dadraus bauen :thumbup:

  • Ich hatte grade überlegt, wieviele Mögliche Bilder es geben kann, aber 134217728 ist dann doch was viel :D

    Na dann mal los....wer programmiert denn mal schnell die Software für Betrieb mit SD-Card um? :D

  • Hi,
    danke schonmal für die antworten also am Flash überlauf liegt es nicht. da sind noch 7% frei, laut Bascom.
    Hab die muster.txt selber schon nach fehlern durchsucht und keine gefunden. hab sie aber trotzdem angehängt.
    wieso hört der dann nach 170 auf? warum 170 und nicht 100 oder so. Versteh ich nicht. aber egal


    Danke Pesi ich versuch nochmal ein Programmablauf mit deinem code zu erstellen.


    Gruß

  • Wenn du nichts dagegen hast anstatt Bascom Assembler zu verwenden, damit läufen deine 240 Bilder durch! Du musst nur etwas die Muster.txt anpassen.


    Kann es sein das du die Bilderfolge zusammenkopiert hast?, denn die Aufzählung bei den Kommentaren sind etwas wirr. Wenn die Gesamtzahl nicht stimmt und es weniger als 240 Bilder sind, könnte daher der Fehler kommen. Im Bascom.Programm hollt sich doch das Programm die Anzahl der Bilder aus der ersten Zeile, oder? Wenn die Anzahl der Bilder geringer ist, sucht er die restlichen im Leeren und findet dann eventuell nicht mehr den Weg zurück...

  • Flabig, das hatte ich ihm ja auch schon empfohlen.... ;)


    Aber das ist schon seltsam: habe mal gezählt, es sind 239 Bilder in der Muster.txt (wenn ich mich nicht verzählt habe) - also sollte nur das letzte Bild falsch sein, warum er genau bei 170 abkackt, ist mir ein Rätsel.... ?(


    Kann mir jetzt nur noch vorstellen, dass es was an der Hardware ist (mal nen anderen Tiny nehmen, evtl. ist ja der Speicher beschädigt..?!?), oder sich der Compiler irgendwie zamspinnt - oder es ist wieder mal irgendsoein blöder Fehler, den man erst nicht sieht, und sich dann an die Stirn klatsch, "ja, klar!" ;)


    Und ich sehe anhand der Bildnummern, dass Du das da ja genau so machst, dass Du manche Bilder mehrmals benutzt - da wäre dann eben der andere Code gut geeignet, wie gesagt, da kannst Du auch noch Zeiten für jedes Bild extra einstellen....

    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!