4x4x4 Led RGB Cube

[Besserwessi]

Für ein flimemrfreies Bild, sollte wie man Fehrnsehen eine Widerhohlfrequenz ab etwa 100 Hz ausreichen - mehr ist dazu eigentlich nicht nötig. Nur um die Wärmebelastung für die LEDs besser zu verteilen wäre eine höhere PWM Frequenz etwas besser. Das gilt vor allem wenn man mit dem LED Strom relativ hoch geht.
Das PWM Signal muß mit dem Umschalten der Ebenen Syncron laufen. Es muß also immer eine ganze Zahl von PWM Zyklen benutzt werden. Am einfachsten ist es dabei jeweils nur einen Puls bzw, eine Periode des PWM Signals zu nehmen und dann auf die nächste Ebene weiter zu schalten. Es ist besser nur je einen Puls zu nutzen und dafür lieber die Gesamt-Wiederhohlfrequenz höher (z.B. 400 Hz) zu wählen. Für mehr Auflösung könnte man die Helligkeitsinformation dann auch über ein paar Peroden verteilen (Dithering).

15 Kanäle mit 400 Hz als PWM sind für Software PWM (8 Bit) mit einem AVR bei z.B. 10 MHz kein wirkliches Problem. Wenn ich das richtig sehe braucht man aber für einen 4x4x4 RGB Cube insgesamt 192 Kanäle, also für jede LED einen, und davon jeweils 48 Kanäle gleichzeitig.

Mit wirklich guter Optimierung in ASM bin ich auf etwa 7-8 Zyklen pro kanal und PWM Schritt gekommen. Also als obere Genze für 8 Bit PWM Frequenz von etwa Fcpu / (7*256*Kanalzahl). Das gibt dann etwa 60-70 Hz für die 192 Kanäle und Bits. Das setzt dann aber reines ASM vorraus und ist noch ohne die aktualisierung der Daten.

Edit:
hab gerade gesehen das Design wurde ja auf 5x5x5 RGB geändert. So wie ich das sehe sollte da ja jeder µC 15 kanäle und dann noch 1:5 gemultiplext, also 75 LEDs versorgen. Das ist noch schaffbar mit Software PWM, braucht aber handoptimierten ASM Code für den kritischen Teil. Auf 400 Hz Widerhohlfrequenz wird man nicht kommen, aber 100-150 Hz sollten ja auch schon reichen.

[Ls4]

Es geschehen noch Zeichen und Wunder, aber ich habe nun tatsächlich etwas weiter am Würfel gerabeitet. Die Hardware ist soweit komplett fertig und ich arbeite nun an der Software.
Entschieden habe ich mich dazu anstatt einem Router oder AP nun einen Raspberry Pi zu verwenden und dort die Dateien abzulegen die geladen werden sollen. Das aktuelle Frame wird als byte Array der Größe 375 an den Master (Atmega 644p) geschickt, der dann die Mosfets durchschaltet (Multiplexing) und bei jedem Umschalten die aktuell relevanten 5*15 Bytes an die Slaves schickt, die dann jeweils die 15 8 bit PWM Kanale mit den empfangenen Werten ansteuern. Ich plane die 8 bit PWM Routine aus dem Wiki zu verwenden und diese von 8 auf 15 Kanäle auszubauen.
Auf allen Mikrocontrollern läuft Arduino. Das ist für mich als Informatiker eine sehr intuitive Art und Weise zu programmieren. I2C funktioniert soweit
Und Nachrichten über UDP kann ich mittlerweile ebenfalls vom Raspberry Pi empfangen. Auf dem Raspberry Pi läuft ein Processing Sketch.
Ein Problem gibt es aktuell dennoch:

Das Sketch sendet alle Sekunde (momentan) ein Byte Array der Größe 375.
Mit folgendem C Code kann ich das auf dem X86 Testweise auch empfangen:

n = recvfrom(sock, buf, 1024, 0, (struct sockaddr *) &from, (socklen_t *)&fromlen);
for(int i=0;i<256;i++){
unsigned int number=uint8_t(buf[i]);
}



Auf dem Master verwende ich die hypermedia UDP library.
nachdem ich hier mein Char Array empfangen habe:

word len = ether.packetReceive();
word pos = ether.packetLoop(len);

if (pos) {
char * pixels=(char *)&ether.buffer[pos];
for(int i=0;i<256;i++){
unsigned int number=uint8_t(pixels[i]);
Serial.println(number);
Serial.println(" ");
if(number%10==0){
Serial.println("\n");
}
}

}
Gibt die Konsole am x86 leider nur quatsch aus. Wenn ich einen String als char array sende ist die Konsolenausgabe allerdings vollkommen korrekt.
Ich vermute ein Problem bei der Endianness. Hatte da mal jemand ein ähnliches Problem?

Viele Grüße,
Tim