So ganz kann ich die Berechnungen oben nicht nachvollziehen... Was meint ihr mit "Pixelgeschwindigkeit"?................usw.
Ja,wenn die komplette Elektronik im Rotor sitzt mag man ,öglichst parallel arbeiten können aber das wäre für die Anzahl der LED's fast unwirtschaftlich.

Man setzt normalerweise die Zentrale Steuerung in den sockel und nur die Anzeigeeinheit in den Rotor.

Dazwischen erfolgt dr Datenaustausch.
Klar,wenn du 8 Bit Parallel überträgst dann ist die Datenrate niedriger aber wie will man das machen ?

8 Schleifer ?
Monströs

8 Infrarot strecken ?
Nicht zu schaffen

8 Funkmodule ? (Ein Multiplexmodul ist wieder eine einzelne Serielle Leitung )
Wird auch wieder umfangreich.

Deswegen die Datenraten wenn alles Seriell geht.

Wie schon gesagt,wenn er nur ein festes Muster darstellen will dann ist das alles kein Problem.
Bei 64 LED und 2400 Upm sowie angenommene 128 Muster pro Umdrehung hat man bei Byteweiser Übertragung 40960 Bytes pro sekunde zu übertragen.
Dazu kommen die Operationen für die Adressierung also nochmal ein Byte pro Segment was dann schon 81920 Bytes/s entspricht.
Soweit wenn man es ganz einfach aus nem Speicher zieht.
Mit Controller wirds aufwändiger.
Der Controller muß sich diese Daten erst aus dem Speicher holen also nochmal eine Adressierung.
Das sind dann 122880 Bytes/s

In der Rechnung nicht enthalten sind andere Berechnungen für Synchronisation und Verwaltung sowie Features.

Kommen jetzt noch Farben dazu dann explodiert die Datenrate.



Ja,deswegen ist bei dem letzten Projekt von ISPF.de nix mehr zu höhren gewesen.
Bei der Zahl von Features ist schnell Ende oder man muß einen recht großen Aufwand treiben.
Letztens lief irgendwo ne Sendung wo einer ne Propellerklock in die Felgen gesetzt hatte.
Sah nett aus und war auch recht gut in der Auflösung.

8 oder 16 Bit Propeller mit vieleicht etwas Farbe (3x8 Bit RGB) ist da mit 8-Bit Controllern noch gut zu händeln.

Für mehr kann man sich gleich mit 16 oder 32-Bitern (zb. Arm) anfreunden.