welchen Microcontroller? - 8x8x8 LED-Cube

Warten bis der DigiX verfügbar ist ... der wird 96 GPIO Pins haben oder 
einen x-beliebigen Controller und dann entweder per Schieberegister oder 
per I2C Portexpander die benötigten I/O Pins zur Verfügung stellen.

Alternativ multiplexen ... google einfach mal nach "charlieplexing" ... 
für Arduinos und ähnliche gibt's dafür ggf. auch schon fertige 
Beispiel-Boards .. etwa 
http://shop.cboden.de/Digispark/Charlieplex-LED-Erweiterungssatz.html

@ Vossela (Gast)

>gute elektronik und programmier Kentnisse besitze schätze ich ist ein
>8x8x8 LED-Cube auch keine überforderung für mich.

Kann sein, siehe LED-Matrix.

>Nun zu meiner eigentlichen Frage: Was für ein Microcontrollern ist für
>diesen Zweck empfehlenswert?

AVR, MSP430, 8051, PIC, whatever.

>Für den Würfel brauche ich zur Steuerung mindestens 72 I/O pins.

8x8+8=72, stimmt ;-)

>Ich würde etwas wie einen Arduino

Kann man machen.

>oder Raspberry Pi bevorzugen aufgrund

???
Ein 700 MHz Embedded PC mit 1/2 GB RAM für sie einen Käse? Ausserdem hat 
der Rasperry Pi kaum IOs, di müsste man per SPI-Portweiterung 
dranfummlen. Daber das macht die Sache nicht sonderlich sinnvoller.

>der simplen Handhabung und Programmierung bin allerdings offen für
>andere Vorschläge habe ja nicht die Erfahrung.

Je nach Können und Wünschen geht C, BASCOM, PASCAL, whatever.

Vossela schrieb:
> Ja die Steuerung direkt über den Computer hätte ich auch gerne (guter
> Punkt) aber ich hätte auch gerne die Möglichkeit ihn auf gespeicherten
> Programmen laufen zu lassen.
>

Dafür reicht auch ein Digispark für unter 9 Euro. Den kannst Du sowohl 
am USB als auch ohne betreiben und die Rechenpower reicht auch allemal.

Programmiert wird das Ding einfach über eine angepasste Arduino GUI 
(gibt's zum kostenlosen Download)

Vossela schrieb:
> Also was für µC hätten denn die benötigten 72 (oder mehr) I/O pins

Eher mehr. Wenn du alle LEDs unabhängig ansteuern willst, kommst du IMHO 
auf 8^3 = 512 IOs...
(=> Schieberegister?)

Porterweiterung per I2C: PCF8574
der stellt jeweils 8 weitere Pins zur Verfügung. Da er über 3 
konfigurierbare Adress-Pins verfügt, kann man 8 Stück davon an einem I2C 
betreiben. Da es darüber hinaus zwei Varianten des Bausteins gibt mit 
unterschiedlichen Adress-Räumen stehen damit theoretisch also 8 x 8 x 2 
= 128 Pins zur Verfügung.

I2C sollte jeder hablwegs aktuelle Controller können.

Boris B. schrieb:
> Eher mehr. Wenn du alle LEDs unabhängig ansteuern willst, kommst du IMHO
> auf 8^3 = 512 IOs...
> (=> Schieberegister?)

Ach ja: sollen das einfarbige oder RGB-LEDs sein? Dann müsstest du noch 
mal 3 nehmen (> 1500 IOs).

Vossela schrieb:
> Boris B. schrieb:
>> Eher mehr. Wenn du alle LEDs unabhängig ansteuern willst, kommst du IMHO
>> auf 8^3 = 512 IOs
>
> Der LED-Cube wird gesteuert indem man jede Ebene einzeln nacheinander
> durchgeht und alle LEDs in einer Reihe übereinander angesteuert werden
> also brauche ich 72 I/Os 8x8 für die einzelnen LEDs + 8 für die
> jeweiligen Ebenen ;)

Das ist absolut richtig. Wer da von 512 faselt hat wohl noch nie so 
einen Cube gemacht.

Aber hast du denn schon mal einen kleineren gemacht? Deine Frage (und 
dann noch Bezug zum Arduino) lassen vermuten dass sich deine Erfahrung 
in Grenzen hält. Willst du nicht erstmal mit einem 3x3x3 oder 4x4x4 
anfangen?

Da kommst du ohne Schieberegister usw. aus wenn du einen AVR mit 
genügend Ports nimmst. Gleich nen 8er ist schon heftig.

gruß cyblord

Vossela schrieb:
> cyblord ---- schrieb:
>> Aber hast du denn schon mal einen kleineren gemacht? Deine Frage (und
>> dann noch Bezug zum Arduino) lassen vermuten dass sich deine Erfahrung
>> in Grenzen hält.
>
> Absolut richtig aber ist der Unterschied denn da wirklich so groß?

Ja enorm.
Beim 8er hast du ungleich mehr Aufwand. Das fängt bei Stromversorgung an 
(viel höhere Ströme), du brauchst mehr Speicher und natürlich die 
Ansteuerung der IO-Erweiterungen sind auch komplexer. Tu dir den 
gefallen und mach mal nen 3x3x3. Habe so einen, als das mit den Cubes 
aufkam, mit einem mega88 an einem Samstag schnell gemacht. Inklusive 
kleines VC# Programm um Animationen zu erstellen.

> Denn einen 3x3x3 oder 4x4x4 finde ich von den Möglichkeiten einfach
> nicht so Interessant
Die Implementierung ist interessant genug. Sieh es als Zwischenschritt 
zum 8er.

gruß cyblord

Hey Vossela,

ich habe als erstes Projekt überhaupt einen 8x8x8 Würfel gebaut, und es 
war keinesfalls zu schwierig. Der Schritt von 4^3 auf 8^3 ist meiner 
Meinung nach zu klein, als dass man ihn dazwischen schieben sollte.
Ich habe ein TI Stellaris Launchpad (Cortex M3 glaube ich, 80MHz) für 
damals 4€ benutzt, und mit diesem dann per Bit Angle Modulation über 
Schieberegister und MOSFETs dann den Würfel betrieben. D.h. ich kann 
jede LED unabhängig voneinander in 16 oder 32 Stufen dimmen. Per USB 
steuere ich dann mit einer selbstgeschriebenen Software den Controller 
an und füttert ihn mit den Daten. Das läuft so ziemlich in Echtzeit, ich 
merke jedenfalls keine Verzögerung zwischen Eingabe am PC und 
Darstellung. Ich habe allerdings auch schon etwas Programmiererfahrung 
im PC Bereich gehabt.
Stomversorgung funktioniert super mit einem stinknormalen PC Netzteil.

Ich kann Dir nur raten erstmal ein fertiges Controllerboard mit Debugger 
zu benutzen, da man sonst ohne Hilfsmittel wie Oszis etc. schnell 
frustiert ist, wenn der Controller nicht läuft.

Schöne Grüße,
Max

Ja und Nein. Das ganze läuft wie folgt:
1) Schieberegister mit Daten füllen. Diese befinden sich dann erstmal 
nur im Speicher der Register. Dies geschieht wärend die LEDs für die 
gegebene Zeit leuchten.
2) Momentan aktive Ebene ausschalten. -> Alle LEDs gehen aus.
3) Speicher aus den Schieberegistern an die Ausgänge übertragen. -> 
Immernoch sind alle aus
4) Neue Ebene einschalten. -> Jetzt gehen nur die gewünschten an.
Dann, während für eine gegebene Zeit die LEDs angeschaltet bleiben 
wieder mit 1 beginnen. Die Schieberegister setze ich nie zurück, sondern 
schiebe automatisch beim neuen Befüllen der Daten die alten ins Nirvana.
Ich hoffe das beantwortet Deine Frage.

Ich habe den Schaltplan mal angehängt, hier allerdings noch mit dem 
ursprünglich geplanten ATmega. Besonders die Schaltung für die Ebenen 
ist sicherlich nicht optimal, aber sowas passiert einem Anfänger eben 
mal ;-)
Ich kann Dir den Algorithmus bzw. den Code auf dem Controller gerne mal 
posten.

Bei Interesse gibt es hier eine kurze Doku über meine Version eines 
8x8x8 LED-Cubes mit dem ATmega32 als µC:
Beitrag "LED cube 8x8x8"

Das mit den 2N7000ern vor den IRLM6402 kam aus dem Grund, dass der uC 
nur 3.3V liefert, ich den Würfel aber mit 5V betreibe.
Die TLCer wäre sicherlich auch eine gute Sache. Hat aber auch spaß 
gemacht die ganzen Bauteile zu löten, und sieht interessant aus ;-)

Wasn Niveau... Unzufrieden mit Deinem Leben? Neidisch?

Max TBA schrieb:
> Wasn Niveau... Unzufrieden mit Deinem Leben? Neidisch?

Der Ton ist doch auf Forumstandard ;-)

Allerdings hat er in der Sache recht. Ein solches Mammutprojekt als 
"erstes" Projekt, lediglich mit etwas Programmiererfahrung am PC, wer 
soll das glauben?

Wenn es stimmt dann hättest du dafür min. 1 Jahr Vollzeit gebraucht. 
Große Elektronikerfahrung konntest du ja nicht haben, war ja dein erstes 
Projekt. Also entweder du hast dich da richtig lange reingehangen oder 
einfach kopiert und lediglich nachgebaut.

gruß cyblord

Digi Spark schrieb:
> google einfach mal nach "charlieplexing"

Besser nicht.
Die üblichen Edelbastlerlösungen überschreiten alle weit die 
Spezifikationen des MCs.

MaWin schrieb:
> aber an der
> Animationssoftware dafür scheitert es meist.

Sehe ich auch als das Hauptproblem an.
Sinnvoll wäre vielleicht, eine Scriptsprache zu implementieren und dann 
die Jobs als Text zu speichern (Dimme LED123 von 0 auf 80% in 5s).

Also wenn du an deinen Vorgaben nix ändern willst (72 IOs) würde ich dir
den ATMEGA2560 empfehlen, der hat 88 davon.

Ist auch sonst ein ganz nützlicher Controller, der wird deinen
Anforderungen bestimmt gerecht.


BTW: Der Cube wurde bekanntlich schon x-1000-fach aufgebaut, da gibt es
unterschiedliche Lösungsansätze. Es führen bekanntlich viele Wege nach
Rom :)

Ich Würde ja die LEDs nicht einzeln Ansteuern sondern eher mit 
Schiberegistern Arbeiten oer Multiplexen.

Wenn du aber wirklich nen Controller mit 72 I/O Pins nehmen möchtest 
würde ich dir den ATxmega128A1-U empfeheln.

1:8 ist auch gar nicht so schlecht in Hinsicht darauf, dass es sein 
erstes Projekt ist.

Lieber etwas kleinere Ströme, das ist etwas einfacher.

Das Dimmen habe ich mit Bit Angle Modulation (warum auch immer das so 
heißt) gemacht. Es gibt beispielsweise hier eine Seite auf der es 
erklärt wird:
http://www.batsocks.co.uk/readme/art_bcm_3.htm

Mein Timer Interrupt sieht so aus:

1

void Timer0IntHandler(void)

2

{

3

    static unsigned char iteration = BMM_DEPTH-1;

4

    unsigned char i;

5

    static unsigned char ucRow = 7;

6

    static volatile unsigned char *ucMatrixPtr = ucMatrix;

7

8

    // Clear the timer interrupt.

9

    ROM_TimerIntClear(TIMER0_BASE, TIMER_TIMA_TIMEOUT);

10

    // Load new timeout and restart timer

11

    ROM_TimerLoadSet(TIMER0_BASE, TIMER_A, (0x00000100 << iteration) );

12

    ROM_TimerEnable(TIMER0_BASE, TIMER_A);

13

14

15

    // turn off all floors

16

    ROM_GPIOPinWrite(GPIO_PORTA_BASE, 0xFC, 0);

17

    ROM_GPIOPinWrite(GPIO_PORTE_BASE, 0x03, 0);

18

    delay(0xDF);

19

20

    // load the storage registers from the shift registers

21

    ROM_GPIOPinWrite(GPIO_PORTE_BASE, STCP, STCP);

22

    ROM_GPIOPinWrite(GPIO_PORTE_BASE, STCP, 0);

23

24

    // turn on the current floor

25

    ROM_GPIOPinWrite(GPIO_PORTA_BASE, 0xFC, (1 << ucRow));

26

    ROM_GPIOPinWrite(GPIO_PORTE_BASE, 0x03, (1 << ucRow));

27

28

29

    // prepare next tick

30

31

    if (iteration == BMM_DEPTH-1)

32

    {

33

      iteration = 0;

34

35

        if (ucRow < 7)

36

        {

37

            ucRow += 1;

38

        }

39

        else

40

        {

41

            ucRow = 0;

42

            // set pointer to start

43

            ucMatrixPtr = ucMatrix;

44

        }

45

    }

46

    else

47

    {

48

        iteration++;

49

    }

50

51

    // prefill the shift registers for the next tick

52

    for (i = 0; i < 8; i++)

53

    {

54

        ROM_GPIOPinWrite(GPIO_PORTB_BASE, 0xFF, *ucMatrixPtr);

55

        ucMatrixPtr ++;

56

        ROM_GPIOPinWrite(GPIO_PORTE_BASE, SHCP, SHCP);

57

        ROM_GPIOPinWrite(GPIO_PORTE_BASE, SHCP, 0);

58

    }

59

}

Da muss ich allerdings noch die Schleifen für die Ebenen und die 
Timer-Dauern vertauschen, da ich gemerkt habe, dass durch die größeren 
MOSFETs der Ebenen diese viel langsamer umschalten und ich viele 
wertvolle Zyklen verschenke.
In dem Array ucMatrix stehen die Daten, die vom PC empfangen werden. 
Diese werden vom PC (da schneller) schonmal so sortiert, dass der uC 
damit möglichst wenig Arbeit hat und immer nur den Pointer ein Byte 
weiterschieben muss.
Nach initialisierung und starten des Timers geht der uC in eine leere 
Schleife und alles wichtige passiert dann in diesem Interrupt. Dazu gibt 
es noch einen Interrupt, der die Daten vom PC empfängt. Das ist dann 
prinzipiell alles was auf dem uC passiert.

Auf der Windows-Seite spreche ich den uC mit einem selbstgeschriebenen 
Programm an, welches per libusb die Daten per Bulk-Transfer verschickt. 
Es ist in c# in VS2012 geschrieben und relativ übersichtlich. Ich kann 
es dir gerne mal zukommen lassen, es ist ziemlich universell und enthält 
keine Zeile mit uC-spezifischem Code, ausser der Anzahl an BAM 
iterationen und Größe des Würfels. Es gibt schon ein paar Klassen von 
Objekten, z.B. Punkte, Kugeln, Rechtecke und eine 'Snake', die du auf 
den Würfel zeichnen lassen kannst.

Schöne Grüße,
Max

Vossela schrieb:
> oder setzt du es am Rechner um indem du die LED der einzelnen Ebenen
> dann von 8 ticks zum beispiel nur 6 mal anschaltest etc.?

So in etwa. Ich habe 4 Ticks, die z.B. 256, 512, 1024 und 2048 Zyklen 
lang sind. Je nach Helligkeit berechnet dann der PC welche (kombination) 
von diesen Ticks die LED an sein musss. Wichtig ist die Zeile

1

ROM_TimerLoadSet(TIMER0_BASE, TIMER_A, (0x00000100 << iteration) );

die den Timer jeweils die gegebenen Zyklen zählen lasst. Diese Methode 
erziehlt die gleichen Ergebnisse, als wenn man den Takt nur auf 256 
Zyklen setzt, und dann die LEDs nur x von y Zyklen eingeschaltet lässt, 
nur ist viel effizienter.

Der Empfang der Daten über USB ist in diesem Interrupt überhaupt nicht 
enthalten. Er liegt in einem anderen Interrupt, der einfach nur neu 
ankommende Daten in ucMatrix schreibt. Diese 'Zeichen'-Funktion kümmert 
sich also tatsächlich nur ums Multiplexen der LEDs. Der PC muss wissen, 
in welcher Form und Reihenfolge die Daten von dieser Funktion gebraucht 
werden, so dass der Pointer jedesmal einfach nur einen Punkt 
weitergeschoben werden muss, ohne die Position der Daten im Array jedes 
mal neu zu berechnen. Das würde wahrscheinlich auch nicht soo viel 
ausmachen, aber ich wollte die Arbeit des uCs zugunsten der Anzahl der 
BAM Iterationen möglichst optimieren.

Noch eine Anmerkung: Der Funktionsaufruf delay(0xDF) war nur zum 
debuggen von falsch dimensionierten Widerständen und sollte möglichst 
viel kleiner sein.