mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik POV Sphere mit WS2812 Stripe


Autor: C0dR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bin zur Zeit am bauen eines POV Globes und wollte hierzu einen 
Raspberry Pi nutzen sowie einen LED Streifen mit WS2812B LEDs.
Folgende Eckdaten zum Projekt:

LED-Streifen: 144 LEDs
Geplante Auflösung des Globes: 144x288 Pixel = 41472 Pixel gesamt
Geplante Wiederholfrequenz: 30 FPS

Nun habe ich das mal durchgerechnet (natürlich erst nach dem Bestellen 
des LED-Streifens...) und komme zu folgenden Timings:

1,25µs bei 800kbit/s
(50 + 144 * 3*8 * 1,25) µs = 4370 µs pro streifen/Zeile.
Jetzt habe ich natürlich nicht bedacht dass ich das ja noch mit der 
horizontalen Auflösung multiplizieren muss:
4370µs * 288 = 1,258s pro Frame.

Damit komme ich also niemals auf die 30 FPS (33,3 ms). Liege ich hier 
richtig und kann den LED-Streifen direkt wieder zurück schicken oder 
habe ich einen Denkfehler gemacht?

Was für einen Streifen würdet ihr mir denn empfehlen für so eine 
Anwendung bzw. gibt es überhaupt streifen mit der nötigen 
Geschwindigkeit? Schaff ich das überhaupt mit dem PWM/PCM Ausgang des PI 
oder muss ich auf etwas anderes gehen (SPI, Display Ausgang, USB?)

Autor: Mick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe deine Fragestellung nur kurz überflogen und die Berechnung nicht 
angeschaut. Eine Möglichkeit wäre, den Streifen zu teilen und dann vom 
Raspberry parallel anzusteuern.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Was für einen Streifen würdet ihr mir denn empfehlen für so eine
>Anwendung bzw. gibt es überhaupt streifen mit der nötigen
>Geschwindigkeit?

Einen Streifen mit APA102 (SPI).
Die PWM im WS2812 soll für POV auch nicht gut geeignet sein.
Zu langsam.

Autor: C0dR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
holger schrieb:
>
> Einen Streifen mit APA102 (SPI).
> Die PWM im WS2812 soll für POV auch nicht gut geeignet sein.
> Zu langsam.

Ok, hab ich mir jetzt angeschaut. Allerdings müsste ich, um das ganze 
bei 30 FPS bei 288 Spalten zu betreiben, die LEDs mit ca. 30 Mhz 
ansteuern. Schaffen das die APA102 und auch der Raspberry?

Autor: Reiner_Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C0dR schrieb:
> holger schrieb:
>>
>> Einen Streifen mit APA102 (SPI).
>> Die PWM im WS2812 soll für POV auch nicht gut geeignet sein.
>> Zu langsam.
>
> Ok, hab ich mir jetzt angeschaut. Allerdings müsste ich, um das ganze
> bei 30 FPS bei 288 Spalten zu betreiben, die LEDs mit ca. 30 Mhz
> ansteuern. Schaffen das die APA102 und auch der Raspberry?

Ich plane auch gerade einen POV Globe zu bauen, allerdings mit einem 
STM32 uC und auch etwas kleiner (48 LEDs) wegen der Fliehkräfte ;-)

Bei einem Test mit einem STM32F102 liefen die APA102 LED's mit gut 18 
MHz SPI Takt. Über die Feiertage teste ich mal mit den 42MHz bei einem 
STM32F407 board.

Ich würde mir an deiner Stelle aber mehr Gedanken zu der Stromversorgung 
machen... Die muss sich ja auch mit 30Hz mitdrehen ;-)

Und bei 144 RGD LED's kannst du den max. Strombedarf mit gut 60mA pro 
WS2812 LED rechnen... Macht immerhin knapp 9A... Nicht schlecht ;-)

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@C0dR (Gast)

>Raspberry Pi nutzen sowie einen LED Streifen mit WS2812B LEDs.

Schlechte Idee. DIe WS2812 sind eher langsam, die Himbeere nur mit 
Krampf schnell über SPI nutzbar.

>LED-Streifen: 144 LEDs
>Geplante Auflösung des Globes: 144x288 Pixel = 41472 Pixel gesamt
>Geplante Wiederholfrequenz: 30 FPS

Das sind satte 1800 U/min.

>1,25µs bei 800kbit/s
>(50 + 144 * 3*8 * 1,25) µs = 4370 µs pro streifen/Zeile.

Ja.

>Jetzt habe ich natürlich nicht bedacht dass ich das ja noch mit der
>horizontalen Auflösung multiplizieren muss:
>4370µs * 288 = 1,258s pro Frame.

Sieht so aus ;-)

>Damit komme ich also niemals auf die 30 FPS (33,3 ms). Liege ich hier
>richtig und kann den LED-Streifen direkt wieder zurück schicken

Ja.

> oder habe ich einen Denkfehler gemacht?

Nein.

>oder muss ich auf etwas anderes gehen (SPI, Display Ausgang, USB?)

SPI ist das Mittel der Wahl.

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Reiner_Gast (Gast)

>Ich würde mir an deiner Stelle aber mehr Gedanken zu der Stromversorgung
>machen... Die muss sich ja auch mit 30Hz mitdrehen ;-)

Schleifkontakte wurden vor über 100 Jahren erfunden und können viele 
Ampere übertragen.

Autor: Reiner_Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
>
> Schleifkontakte wurden vor über 100 Jahren erfunden und können viele
> Ampere übertragen.

Ja, damit wollte ich das auch versuchen. Hatte erst daran gedacht, das 
ganze per Induktion zu Übertragen. Aber da bin ich mir nicht sicher, ob 
das reicht.

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Reiner_Gast (Gast)

>Ja, damit wollte ich das auch versuchen. Hatte erst daran gedacht, das
>ganze per Induktion zu Übertragen. Aber da bin ich mir nicht sicher, ob
>das reicht.

Es reicht, wenn gleich 9A schon arg viel sind. Siehe

Royer Converter.

Autor: C0dR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> @ Reiner_Gast (Gast)
>
>>Ich würde mir an deiner Stelle aber mehr Gedanken zu der Stromversorgung
>>machen... Die muss sich ja auch mit 30Hz mitdrehen ;-)
>
> Schleifkontakte wurden vor über 100 Jahren erfunden und können viele
> Ampere übertragen.

Falk B. schrieb:
> @ Reiner_Gast (Gast)
>
>>Ja, damit wollte ich das auch versuchen. Hatte erst daran gedacht, das
>>ganze per Induktion zu Übertragen. Aber da bin ich mir nicht sicher, ob
>>das reicht.
>
> Es reicht, wenn gleich 9A schon arg viel sind. Siehe
>
> Royer Converter.


Ich wollte es erstmal mit einem Kugellager als "Schleifkontakt" 
versuchen. Wenn das nicht hinhaut sieht der Royer Converter echt sehr 
interessant aus.
Vielen Dank für die ganzen Infos und Tipps hier!

@Reiner_Gast: Mich würden deine Ergebnisse mit dem STM32F407 
interessieren, das könnte eventuell mein Ausweichplan sein falls ich aus 
dem Raspberry Pi nicht schnell genug die SPI Signale bekomme :)

Autor: Reiner_Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> @ Reiner_Gast (Gast)
>
>>Ja, damit wollte ich das auch versuchen. Hatte erst daran gedacht, das
>>ganze per Induktion zu Übertragen. Aber da bin ich mir nicht sicher, ob
>>das reicht.
>
> Es reicht, wenn gleich 9A schon arg viel sind. Siehe
>
> Royer Converter.

Danke für den Link, das schaue ich mir mal an.

Bei den von mir geplanten 48 RGB LED's sinds zum Glück "nur" gut 3A...

Autor: Reiner_Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C0dR schrieb:
> @Reiner_Gast: Mich würden deine Ergebnisse mit dem STM32F407
> interessieren, das könnte eventuell mein Ausweichplan sein falls ich aus
> dem Raspberry Pi nicht schnell genug die SPI Signale bekomme :)

Ich schau mal, ob die APA102 die 42 MHz schaffen und werde dann 
berichten...

Beim PI hätte ich jetzt bedenken, ob der das richtige Timing schafft für 
die einzelnen Segmente. Wenn du bei den 288 Pixeln Breite bleibst, dann 
wären das 30x288 = 8640 Datenaktualisierungen pro Sekunde, die möglichst 
genau erfolgen müssen damit das Bild ruhig bleibt.

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Reiner_Gast (Gast)

>Beim PI hätte ich jetzt bedenken, ob der das richtige Timing schafft für
>die einzelnen Segmente. Wenn du bei den 288 Pixeln Breite bleibst, dann
>wären das 30x288 = 8640 Datenaktualisierungen pro Sekunde, die möglichst
>genau erfolgen müssen damit das Bild ruhig bleibt.

Und das bitte auch phasensynchron. Wenn gleich die Himbeere rein von der 
Hardware genug pOwer dafür hat, glaube ich nicht, daß man mit den 
üblichen Mitteln und dem darauf laufenden Linux das hinbekommt. Dazu 
müßte man das Ding pur ohne Linx porgrammieren oder wenigstens einen 
echt guten Low Lever Treiber schreiben. Beides ist ziemlich 
anspruchsvoll.

Ein AVR oder einer der aktuellen 32 Bitter OHNE Linux und ähnliches ist 
das DEUTLICH einfacher handhabbar. Braucht man wiklich 42 MHz, um die 
LEds schnell genug zu laden? Kann man einfach ausrechnen.

f_SPI = f_fps  N_columns  N_LED * Bit_per_led

macht bei 30 fps, 288 Spalten, 144x3 LEDs (RGB) * 8 Bit/LED = 29,9 MHz.

Uuups ;-)

Autor: Reiner_Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> Ein AVR oder einer der aktuellen 32 Bitter OHNE Linux und ähnliches ist
> das DEUTLICH einfacher handhabbar. Braucht man wiklich 42 MHz, um die
> LEds schnell genug zu laden? Kann man einfach ausrechnen.
>
> f_SPI = f_fps  N_columns  N_LED * Bit_per_led
>
> macht bei 30 fps, 288 Spalten, 144x3 LEDs (RGB) * 8 Bit/LED = 29,9 MHz.
>
> Uuups ;-)

Naja... eigentlich kommst es noch schlimmer...

1.) Die APA102 brauchen 32 Bits pro RGB LED (die ersten 8 Bits sind für 
die allgemeine Strombegrenzung für die 3 LEDs gedacht)

2.) Es wird ein Startframe (32x 0-bit) und ein Endframe (32x 1-Bit) 
benötigt. Macht demnach rechnerisch 146 LEDs

Somit Gibt das ganze dann 30 x 288 x 146 x 32 = 40,4 MHz

Doppel-Upps ;-)

Autor: Torsten C. (torsten_c) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reiner_Gast schrieb:
> Ich plane auch gerade einen POV Globe zu bauen,
> allerdings mit einem STM32 uC

Ein STM32 mit 8-Bit parallel über DMA hat vergleichbar wenig 
RAM-Overhead im "Grafikspeicher" und holt so ziemlich alles raus, was an 
Taktrate mit APA102 bzw. WS2812 möglich ist.

Soll das Bild on the fly berechnet werden? Oder soll ein Film von einer 
SD-Karte abgespielt werden?

Eventuell wäre ein RasPi Zero vielleicht im Vorteil.
Kann der RasPi 8-Bit parallel über DMA?
Und muss man dazu eigene Linux-Treiber programmieren?

Der µC/RasPi soll doch im drehbaren Teil sein und darf weder groß noch 
schwer sein, oder?

: Bearbeitet durch User
Autor: Reiner_Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> Soll das Bild on the fly berechnet werden? Oder soll ein Film von einer
> SD-Karte abgespielt werden?

Bei meinem Vorhaben geht's um statische Darstellung bzw. on the fly...

Wie das bei dem Vorhaben von C0dR ausschaut, kann ich nicht sagen.

> Eventuell wäre ein RasPi Zero vielleicht im Vorteil.
> Kann der RasPi 8-Bit parallel über DMA?

Glaube ich nicht.
Was sollten denn 8-Bit parallel bei einem einzelnen Streifen bringen?

> Der µC/RasPi soll doch im drehbaren Teil sein und darf weder groß noch
> schwer sein, oder?

Da sich hier Fliehkräfte entwickeln die ausgewuchtet werden müssen, ist 
klein und leicht vorteilhaft...

Autor: Torsten C. (torsten_c) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reiner_Gast schrieb:
> Was sollten denn 8-Bit parallel bei einem einzelnen Streifen bringen?
Die Daisy Chain an sieben Stellen unterbrechen und dann an acht Stellen 
einspeisen, damit man auf eine höhere Drehzahl kommt und das Bild nicht 
flackert.

: Bearbeitet durch User
Autor: Reiner_Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> Reiner_Gast schrieb:
>> Was sollten denn 8-Bit parallel bei einem einzelnen Streifen bringen?
> Die Daisy Chain an sieben Stellen unterbrechen und dann an acht Stellen
> einspeisen, damit man auf eine höhere Drehzahl kommt und das Bild nicht
> flackert.

Ist aber nur was für gute Augen und ruhige Finger... bei den Stripes mit 
144 LED/m sind das bei 5 mm LED Außenmaß nur gut 2 mm Abstand bis zum 
nächsten LED-Gehäuse ;-)

Autor: Markus M. (adrock)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
...die PWM der WS2812B arbeitet nur mit um die 400Hz wimre. Diese 
scheiden also definitiv aus, sonst hättest Du bei 30fps komische Muster 
alleine schon durch die PWM.

Die APA102 verwenden wohl ZWEI PWM Frequenzen: Eine niedrige für die 
"globale" Helligkeit pro LED (582 Hz) und eine hohe für die RGB-Werte 
(19.2KHz), siehe auch hier:

https://cpldcpu.wordpress.com/2014/08/27/apa102/

Ob sie für Dein Vorhaben geeignet sind hängt also auch davon ab, ob die 
582Hz PWM zu einem konstanten "ein" wird wenn man auf max. Helligkeit 
geht. Andernfalls hättest Du dann ebenfalls mit Artefakten zu rechnen.

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, das Vorhaben ist in Summe mehr als ambitioniert. Bei 30 fps und 
288 Spalten macht das 8640 Hz Spaltenfrequenz. Man müßte also eine PWM 
mit 8,6 kHz laufen lassen und das synchron zur Drehung. Machbar, aber 
anspruchsvoll. Die guten, alten TLC5940 & Co lassen sich mit bis zu 30 
MHz takten, dort hat man eine Chance. Trotzdem würde ich empfehlen, das 
Alles erst mal ne Nummer kleiner zu bauen, vielleicht mit 1/4 der LEDs.

Autor: Reiner_Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> Naja, das Vorhaben ist in Summe mehr als ambitioniert. Bei 30 fps
> und
> 288 Spalten macht das 8640 Hz Spaltenfrequenz. Man müßte also eine PWM
> mit 8,6 kHz laufen lassen und das synchron zur Drehung. Machbar, aber
> anspruchsvoll. Die guten, alten TLC5940 & Co lassen sich mit bis zu 30
> MHz takten, dort hat man eine Chance. Trotzdem würde ich empfehlen, das
> Alles erst mal ne Nummer kleiner zu bauen, vielleicht mit 1/4 der LEDs.

Wie gesagt... eben deswegen plane ich meines ja auch "nur" mit 48 LEDs 
und gut 120 Pixel Breite

Autor: Torsten C. (torsten_c) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und dann?
Nur 0x00 und 0xFF senden, damit es keine Interferenzmuster mit dem PWM 
gibt?

.oO( Welch ein Hinweis von adrock,
     da hätte ich auch schon mal dran denken können.)

Autor: Andreas M. (andiator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C0dR schrieb:
> Ich wollte es erstmal mit einem Kugellager als "Schleifkontakt"
> versuchen. Wenn das nicht hinhaut sieht der Royer Converter echt sehr
> interessant aus.
> Vielen Dank für die ganzen Infos und Tipps hier!

Die eignen sich leider nicht für sowas. Man hat keinen permanenten 
Kontakt, da doch etwas Luft inkl. Schmiere dazwischen.
Außerdem kann es bei größeren Strömen zu Funken kommen, die mit der Zeit 
den Kugellager beschädigen.
Obs für die ersten Tests reicht, kann ich aber nicht sagen :)

MfG,
Andreas

Autor: Torsten C. (torsten_c) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für Schleifer hatte ich mir mal Ersatzteil-Kohlebürsten für 
Modellbau-Motoren besorgt. Ich weiß nicht, wie lange eine Kupferschicht 
auf einem PCB hält. Vielleicht könnte man die Schleifringe gleich auf 
das Platinen-Layout ätzen.

Ich hatte damals Märklin-Ersatzteile genommen. Irre teuer.
Vielleicht gibt es bei HobbyKing oder so auch billigere.

Autor: Frank E. (Firma: Q3) (qualidat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die eigentliche "Ausschüttung" der Pixeldaten würde ich per Arduino oder 
Teensy machen, da ist man "näher dran" an der Hardware. Empfang der 
Daten z.B. per WLAN (UDP), Stromversorgung über Schleifringe oder 
Kugellager.

Um die erforderliche Drehzahl zu reduzieren: mehrere Streifen, z.B. 4 
oder 6 von Pol zu Pol nehmen.

Um die zu transferierende Datenmenge zu reduzieren (allerdings dann 
nicht mit Arduino wegen zu wenig Speicher), einen internen Bildpuffer 
über mehrere Umdrehungen ausgeben ... reduziert zwar die Frame-Rate, 
macht das Bild aber flackerfrei(er).


Schleifring 230V 10A vom Chinamann für ca. 20,-

https://i.ebayimg.com/images/g/gqIAAOSw9GhYiYTb/s-l1600.jpg

: Bearbeitet durch User
Autor: C0dR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> Reiner_Gast schrieb:
>> Ich plane auch gerade einen POV Globe zu bauen,
>> allerdings mit einem STM32 uC
>
> Ein STM32 mit 8-Bit parallel über DMA hat vergleichbar wenig
> RAM-Overhead im "Grafikspeicher" und holt so ziemlich alles raus, was an
> Taktrate mit APA102 bzw. WS2812 möglich ist.
>
> Soll das Bild on the fly berechnet werden? Oder soll ein Film von einer
> SD-Karte abgespielt werden?
>
> Eventuell wäre ein RasPi Zero vielleicht im Vorteil.
> Kann der RasPi 8-Bit parallel über DMA?
> Und muss man dazu eigene Linux-Treiber programmieren?
>
> Der µC/RasPi soll doch im drehbaren Teil sein und darf weder groß noch
> schwer sein, oder?

Also mein Plan war, dass die einzelnen Frames von einer PC Software 
(Selbstgeschrieben) aus einem Video vorbereitet werden und die fertigen 
Pixeldaten über LAN an den Raspberry übertragen werden, dieser buffert 
sich dieses und zeigt es dann auf dem Globe an. 40 Mhz ist deutlich mehr 
als ich gedacht hab, eventuell sollte ich wirklich 2 Streifen nehmen und 
die FPS halbieren.
Bisher hab ich auf dem PI einen Realtime Kernel drauf, laut Datenblatt 
kann dieser SPI bis 125 Mhz. Ich hatte gehofft damit bekomme ich das 
hin. Würde denn der STM32 hier mehr Sinn machen?

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C0dR schrieb:
> Bisher hab ich auf dem PI einen Realtime Kernel drauf, laut Datenblatt
> kann dieser SPI bis 125 Mhz.

Es geht ja nicht nur um die reine Transferrate. Du musst auch das Timing 
präzise hinbekommen.

Autor: Reiner_Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> C0dR schrieb:
>> @Reiner_Gast: Mich würden deine Ergebnisse mit dem STM32F407
>> interessieren, das könnte eventuell mein Ausweichplan sein falls ich aus
>> dem Raspberry Pi nicht schnell genug die SPI Signale bekomme :)
>
> Ich schau mal, ob die APA102 die 42 MHz schaffen und werde dann
> berichten...
>

@C0dR:

Kurzes Update hierzu...
mit 22,4MHz SPI Takt erfolgt die APA102 Ausgabe noch fehlerfrei...
ab 24MHz SPI Takt fangen die Fehler an...

Autor: C0dR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reiner_Gast schrieb:
>> C0dR schrieb:
>>> @Reiner_Gast: Mich würden deine Ergebnisse mit dem STM32F407
>>> interessieren, das könnte eventuell mein Ausweichplan sein falls ich aus
>>> dem Raspberry Pi nicht schnell genug die SPI Signale bekomme :)
>>
>> Ich schau mal, ob die APA102 die 42 MHz schaffen und werde dann
>> berichten...
>>
>
> @C0dR:
>
> Kurzes Update hierzu...
> mit 22,4MHz SPI Takt erfolgt die APA102 Ausgabe noch fehlerfrei...
> ab 24MHz SPI Takt fangen die Fehler an...

Ach mist, das ist echt schade...heißt ich muss dann wohl auf halbe 
Umdrehungszahl/Framerate gehen und zwei Streifen nutzen...

Autor: Josef T. (t_joe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hatte auch mal überlegt, dass ich mir einen solchen Globe baue, fand 
aber leider nie die Zeit dafür!
Aber hier ein Gedanke, den ich damals hatte. Wenn du mit den FPS etwas 
runter gehst und dafür aber 2 LED Streifen gegenüberliegend machst (der 
eine Zeigt Spalte 1,3,5,..usw an und der andere Spalte 2,4,6,..usw) dann 
könnte man etwas Rechenleistung einsparren ohne gravierenden 
Qualitätsverlust des Bildes! Es kam aber nie soweit, dass ich das mal 
ausprobieren konnte, also auch keine Garantie darauf, dass es wirklich 
so ist!

Gruß
Josef

Autor: C0dR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Josef T. schrieb:
> Hatte auch mal überlegt, dass ich mir einen solchen Globe baue,
> fand
> aber leider nie die Zeit dafür!
> Aber hier ein Gedanke, den ich damals hatte. Wenn du mit den FPS etwas
> runter gehst und dafür aber 2 LED Streifen gegenüberliegend machst (der
> eine Zeigt Spalte 1,3,5,..usw an und der andere Spalte 2,4,6,..usw) dann
> könnte man etwas Rechenleistung einsparren ohne gravierenden
> Qualitätsverlust des Bildes! Es kam aber nie soweit, dass ich das mal
> ausprobieren konnte, also auch keine Garantie darauf, dass es wirklich
> so ist!
>
> Gruß
> Josef

Ja das ist dass was ich meinte mit halber Framerate und zwei streifen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.