Hallo allerseits, ich steige neu in die Materie von Microcontrollern ein und da ich recht gute elektronik und programmier Kentnisse besitze schätze ich ist ein 8x8x8 LED-Cube auch keine überforderung für mich. Nun zu meiner eigentlichen Frage: Was für ein Microcontrollern ist für diesen Zweck empfehlenswert? Für den Würfel brauche ich zur Steuerung mindestens 72 I/O pins. Ich würde etwas wie einen Arduino oder Raspberry Pi bevorzugen aufgrund der simplen Handhabung und Programmierung bin allerdings offen für andere Vorschläge habe ja nicht die Erfahrung. Mit freundlichen Grüßen Vossela
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
Grundsätzlich ist nahezu jeder µC dazu geeignet. Das hängt ganz von Deinen Anforderungen ab. Ich würde den Würfel über Ethernet ansteuern wollen und dafür einen PIC32 nehmen: http://de.rs-online.com/web/p/entwicklungskits-prozessor-mikrocontroller/6868657/
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. Hat das Raspberry Pi nicht die Möglichkeit es direkt über USB oder Ethernet anzusteuern? Und das Multiplexing könnte ich dort dann ja z.B. über eine Prototyping Board wie dieses machen oder? http://www.makershed.com/Prototyping_Pi_Plate_Kit_for_Raspberry_Pi_p/mkad53.htm
@ 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: > aber ich hätte auch gerne die Möglichkeit ihn auf gespeicherten > Programmen laufen zu lassen. ???, das geht doch.
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)
Okay dann lassen wir die Idee mit dem Raspberry Pi mal raus ;) Also was für µC hätten denn die benötigten 72 (oder mehr) I/O pins oder die Möglichkeit für eine simple I2C Porterweiterung. Habt ihr da eine große Übersichtsliste oder einfach direkte Vorschläge?
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.
:
Bearbeitet durch User
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).
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 ;)
> Was für ein Microcontrollern ist für diesen Zweck empfehlenswert? Die Frage ist, was für Animationen du auf dem Würfel laufen lassen willst. Von simplen ein/aus Pixeln bis zu 3d Raum Videos eine interaktiven computersimulierten Welt ist alles drin, und braucht natürlich unterschiedlichen Rechenpowert. Ein LED Cube selbst aufzubauen, ist strunzsimpel, aber an der Animationssoftware dafür scheitert es meist. > Für den Würfel brauche ich zur Steuerung mindestens 72 I/O pins. Nein. 4 IRF7314 und 8 TLC5917 wären eine sich natürlich ergebende Ansteuerung und benötigt 18 Pins um schnell angesprochen werden zu können. Ein RPi ist eher ungeeignet, es sei den du lässt Linux weg, denn für den LED-Cube brauchst du wollen allem mikrosekundengenaues Timing.
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
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ß? Denn einen 3x3x3 oder 4x4x4 finde ich von den Möglichkeiten einfach nicht so Interessant MaWin schrieb: > Die Frage ist, was für Animationen du auf dem Würfel laufen lassen > willst. Aufgrund dessen dachte ich an die Möglichkeit zur direkten Ansteuerung über USB oder Ethernet. Sodass simple 3d animationen wie Wellenfunktionen und ähnliches direkt über den µC laufen können und dass dann z.B. Musikgesteuerte Animationen und kleine Spiele wie Space Invaders über den Computer eingespeist werden können
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
:
Bearbeitet durch User
@ Max TBA Danke hast du dann über das Schiebregister die einzelnen MOSFET gates geschaltet und nach jedem Schritt das Schieberegister geleert, oder verstehe ich das grade falsch?
Hallo,ich brauch bei meinem 12 pins.8 für die Mosfets und 4 für die Schieberegister.Selbst aufwendige schnelle Animationen sind kein Problem.
Angehängte Dateien:
-
Schaltplan_LED.png
27 KB
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"
> Ich habe den Schaltplan mal angehängt Prinzipell ok, aber die IRLML6402 können direkt an den uC, spart 24 Bauteile, und wenn man statt 74HC595 den TLC5917 verwendet, spart man sich 196 weitere Bauteile.
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 ;-)
Max TBA schrieb: > 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. Ja du mich auch. Nimm den Mund nicht so voll. Sollte das nur entfernt stimmen hast du weniger als 1% selbst gemacht, sondern nur nachgebaut.
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.
du kannst auch den HT1632C von Holtek Semiconductor nehmen. http://www.holtek.com.tw/english/docum/consumer/1632c.htm Kaskadierung ist bei dem Baustein möglich wie auch dimmen etc. Damit kannst Du jede MCU nehmen, um den den LED-Controller zu betreiben. Hier kannst Du den Baustein kaufen: http://www.aliexpress.com/item/Free-Shipping-20pcs-lot-HT1632C-Driver-Chip-for-LED-Dot-Matrix-Unit-Board-256/1180946546.html 20 Stück kosten 9,81 EUR plus Versand.
> Ich Würde ja die LEDs nicht einzeln Ansteuern Kann er ja auch nicht, seine 72 reichen ja nur zum 1:8 Multiplexing der 512 LEDs.
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.
Max TBA schrieb: > ich kann > jede LED unabhängig voneinander in 16 oder 32 Stufen dimmen. eine letzte Frage habe ich so spontan noch wodurch hast du das dimmen verwirklicht?
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
Max TBA schrieb: > Ich kann > es dir gerne mal zukommen lassen sehr gerne zu dem Code den du gepostet hast: das hat doch nichts mit dem BAM Verfahren zu tun das ist doch nur das einlesen der Daten vom Rechner und das umsetzen im uC oder sehe ich das falsch? 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.?
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.
:
Bearbeitet durch User
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.