Forum: Mikrocontroller und Digitale Elektronik Kleine Vorabfrage zu P3 RGB LED Projekt mit ESP32


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Daniel S. (supernova01)


Lesenswert?

Hi,

ich möchte eine etwas größere Matrix mit P3 Modulen bauen. Beipiel:
https://www.waveshare.com/wiki/RGB-Matrix-P2.5-64x64
In Summe 12 Stück 64x64 Pixel Module.

Randbedinungung: Nur die Grundfarben RGB und die daraus entstehenden 
Mischfarben, also LED im Pixel an oder aus, alles andere wäre eh schon 
viel zu viel.

Ich möchte das ganze mit einem ESP32 ansteuern und das "Bild" im 
Speicher halten. Also 64x64x12x2 Bit wären ja schon 144 kB Ram. Wenn ich 
recht sehe, hat der ESP32 160 kB.

Es wird eine relativ einfache kleine Anwendung darauf laufen, zwei 
Schriftwarten, Kästchen, Striche Kreise - mehr nicht.

Was ich mich frage, wenn ich die Module alle hintereinader schalte, ist 
es bei der Leistung des ESP32 160Mhz realistisch mit einem Muxing von 
1/32 ein stehendes Bild hin zu bekommen?
Ich habe dann sechs Lines mit einer Länge von 64x12, 768 Bit. Bei einem 
1:32 Scan, und 100 Hz als Wiederholrate müsste ich die Lines alle 0,3125 
ms wieder "befüllen".

Danke.

: Bearbeitet durch User
von Rainer W. (rawi)


Lesenswert?

Daniel S. schrieb:
> Also 64x64x12x2 Bit wären ja schon 144 kB Ram

Eher 18.4 ... 24.6 kB

von Daniel S. (supernova01)


Lesenswert?

hatte nicht wieder durch acht geteilt.

Ich würde ein Byte für zwei Pixel nehmen, da es dann einfache verwaltbar 
wäre.

64x64x12/2 = 24576 Bytes -> 24 kB.

Ich möchte erstmal nur abklären ob diese Idee so rein von der Hardware 
her umsetzbar ist...

: Bearbeitet durch User
von Daniel D. (danielduese)


Lesenswert?

> ist es bei der Leistung des ESP32 160Mhz realistisch
> mit einem Muxing von 1/32 ein stehendes Bild hin zu bekommen?

Ein stehendes Bild ja. Animation wird schwieriger. Du denkst an einen 
Tensilica Core? Bei dem sind die 160MHz nicht wirklich viel.

: Bearbeitet durch User
von Daniel S. (supernova01)


Lesenswert?

Daniel D. schrieb:
> Du denkst an einen
> Tensilica Core?

Ich habe vom ESP32 oder ESP8266 kaum einen Plan, habe jahrelange Atmel 
Erfahrung mit C-Programmierung. Die ESPs sind für mich sehr sehr 
umfangreiche Controller mit DMA und tausenden Funktionen die ich nicht 
kenne...

Ich möchte in diesem Fall mit der Arduino Umgebung schnell an Ziel 
kommen.

Die kleine Anwendung existiert bereits in C und läuft auf einer 
kleineren RG-Matrix mit einem Atmega128 seit 15 Jahren. Sie nutzt in 
Ihrer untersten Ebende  nur eine Funktion die SetPixel (x,y,color). 
Keine Animationen.

Ich möchte "nur" dahin kommen, den Speicherinhalt mit ausreichender 
Geschwindigkeit auf die Panel zu schreiben.

Da ich mit den ESPs keine Erfahrungen habe, möchte ich mich hier erstmal 
etwas umhören.

von Daniel D. (danielduese)


Lesenswert?

Alternativ ist die Waveshare Lib ja auch RP kompatibel. Der RP Pico ist 
sicher keine schlechte Wahl. Denn kannst du über die Arduino IDE 
programmieren und er hat einen zweiten Core. Das ist oft sehr hilfreich. 
Ein Core fürs shiftout der andere für die grafikroutinen. Und ein Cortex 
M0+ bei 133MHz ist schon ganz gut leistungsfähig für sowas.

: Bearbeitet durch User
von Daniel S. (supernova01)


Lesenswert?

Daniel D. schrieb:
> Das ist oft sehr hilfreich

Ja das kann ich mir vorstellen.

Ich denke die meisten "fertigen" Applikationen zielen darauf ab auf so 
einem Modul eine mehrere Bits lange Farbtiefe zu erzeugen und 
Animationen zu erzeugen. Da kommt man schnell an Grenzen, da man ja an 
jedem Pixel drei PWM erzeugen muss, also mit der Wiederholrate nochmals 
ordentlich nachlegen muss um ein flimmerfreies Bild zu bekommen.

Ich möchte "nur" eine Infotafel bauen, etwas Text, ein Paar Zahlen, 
Striche, Punkte und das höchste der Gefühle vielleicht eine Analoguhr wo 
sich der Zeiger jede Sekunde bewegt. All diese Applikationen habe ich 
bereits auf der RG-Matrix laufen.

Das Plugin für den ESP8266 habe ich hier schon am laufen. Vielleicht 
komme ich mit dem ja auch schon hin. So oder so muss ich mich minimal 
wohl mit einem Timer und dem zugehörigen Interrupt von dem Ding 
beschäftigen, das würde ich mir gern ersparen...

von Björn W. (bwieck)


Lesenswert?

Daniel S. schrieb:
> Ich möchte in diesem Fall mit der Arduino Umgebung schnell an Ziel
> kommen.

Ja, das wollen alle die damit arbeiten. Am Ende schlagen die hier auf 
weil das Ergebnis nicht oder unzufrieden geht. CopyPaste ist halt kein 
zuverlässiger Weg.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Daniel D. schrieb:
> Ein Core fürs shiftout der andere für die grafikroutinen.

Auf dem Pico reicht eine Statemachine zum Shiftout. Für WS2812 gibts da 
auch Beispiele im Repository. Da muss der Core nur ab und zu neue Daten 
zufüttern. Die Shifterei macht die SM.

Beitrag #7595127 wurde vom Autor gelöscht.
von Daniel S. (supernova01)


Lesenswert?

Björn W. schrieb:
> Am Ende schlagen die hier auf

Ich stehe aber nicht am Ende sondern am vorm Anfang. Wenn es so ist, 
dass es doch völlig kompliziert ist ein Ram Abbild von:

uint8_t Display[64x12][32];

zyklisch in sechs 768 Bit lange Register zu schreiben und dabei die 
entsprechende Zeile zu aktivieren, dann ist das so. Deswegen ja vorher 
hier die etwas abstrakte Frage.

von Daniel D. (danielduese)


Lesenswert?

Matthias S. schrieb:
> Für WS2812 gibts da
> auch Beispiele im Repository.

Von denen ist nicht die Rede

von Daniel D. (danielduese)


Lesenswert?

> Wenn es so ist,
> dass es doch völlig kompliziert ist ein Ram Abbild von:
>
> uint8_t Display[64x12][32];
>
> zyklisch in sechs 768 Bit lange Register zu schreiben und dabei die
> entsprechende Zeile zu aktivieren, dann ist das so. Deswegen ja vorher
> hier die etwas abstrakte Frage.

Glaub nicht, dass es so schwer ist.

> 100 Hz als Wiederholrate müsste ich die Lines alle 0,3125 ms wieder "befüllen"

Das geht aus irgendeinem Datenblatt hervor? Für mich sehen die Signale 
eher danach aus, in beliebiger Geschwindigkeit einmal das Display zu 
initialisieren und das zeigt entsprechend ein Bild an, bis dieses 
überschrieben wird. Oder täusche ich mich?

Wenn du ein Datenblatt des Displays hast, lade es mal noch hoch.

: Bearbeitet durch User
von Daniel S. (supernova01)


Lesenswert?

Daniel D. schrieb:
> Dass dies zyklisch sein muss

Ja

Daniel D. schrieb:
> einmal das Display zu initialisieren und das zeigt
> entsprechend ein Bild an

nein, das ist bei meinen RG-Modulen 16x16 (SLM-1606)so, da habe ich mal 
ein Beispielbild hochgeladen, ist ja schon 12 Jahre her... aber ich 
denke man sieht das ganz schön. Das Teil läuft immer noch genau so:

Beitrag "Wordclock X (LED Matrix SLM1606 Samsung 4x5) 80x64 RG LED"

Nur die Module sind nun wirklich durch, ich hatte noch welche, aber die 
letzten sind nun montiert/ausgetauscht und es gibt das Zeug nicht mehr. 
Sind ja auch sicher 20 Jahre alt. Also nun RGB und doppelte Auflösung 
sowie fast dreifache Größe, wenn dann richtig.

 ------- -------
| 64x64 | 64x64 |
|       |       |
 ------- -------
| 64x64 | 64x64 |
|       |       |
 ------- -------
| 64x64 | 64x64 |
|       |       |
 ------- -------    120 cm
| 64x64 | 64x64 |
|       |       |
 ------- -------
| 64x64 | 64x64 |
|       |       |
 ------- -------
| 64x64 | 64x64 |
|       |       |
 ------- -------
       40 cm

Diese Module

https://de.aliexpress.com/item/1005005380909356.html

Kommen in diesen Bilderrahmen:

https://www.amazon.de/gp/product/B00Q2IFJVE

Daniel D. schrieb:
> Wenn du ein Datenblatt

Das habe ich gerade zufällig gefunden:

https://www.mikrocontroller.net/attachment/517705/LED_Matrix_Controller_V5.pdf

Das ist das schön beschrieben. Das 64x64 Modul hat 2x32 Zeilen. Dabei 
wird die Zeile mit fünf Bit selektiert.  Es hat dann noch pro Hälfte 
drei 32 Bit Register für jede Farbe (RGB).

Die Module machen also ein 1:32 Muxing.

Ich würde das so lösen
im Init
{
 Zeile =0
 Bit=0
 OE aus
}

im Zyklus
{
 In einer Schleife von Bit 0-767
 {
  Ausgabe von Display[Bit][Zeile] //Byte an 6 Pins legen,
  //2 Bit ungenutzt / R1,R2,G1,G2,B1,B2,nu1,nu2
  Clock puls erzeugen
  Bit++
 }
 OE aus
 Zeile an A-E ausgeben //Zeile auswählen (eine ist immer aktiv)
 Latch pulsen
 OE an
 Zeile++ (0 bis 31)
}

Eigentlich sind das nur Schieberegister...ähnlich des 595

Im SLM1606 gibt es nur ein Schieberehister auf dem 16x16 Modul mit 2x256 
Bit - keine Zeile, dafür ein Reset für den definierten Startpunkt...Die 
sind so gestrickt dass sie, wenn man sie nur clockt, den Registerinhalt 
stumpf wiederholt ausgeben... das könenn diese Module mit HUB75 
Schnittstelle nicht, leider.

: Bearbeitet durch User
von Daniel D. (danielduese)


Lesenswert?

Verstehe.

Dann wird das mit 12 Panels wohl schon eine ordentliche Herausforderung 
an die Geschwindigkeit.

Ich nehme das "nicht so schwer" zurück.

von Daniel S. (supernova01)


Lesenswert?

Daniel D. schrieb:
> Dann wird das mit 12 Panels wohl schon eine ordentliche Herausforderung

Der Controller hat 160 MHz das ist schon ordentlich Dampf. Zumal 
deswegen ja auch "nur" an oder aus der einzelnen Grundfarben. Mehr 
brauche ich nicht.

Ich denke das könnte klappen, habe aber mit dem ESP keine Erfahrung.

Der Controller muss 768 Bit in 312,5 µs ausgeben, das wäre die 100 % 
Auslastung.

: Bearbeitet durch User
von Daniel D. (danielduese)


Lesenswert?

Daniel S. schrieb:
> Der Controller hat 160 MHz das ist schon ordentlich Dampf.

Das sind aber noch nicht 160.000.000 Befehle in der Sek, die er 
abarbeiten kann, sondern Systicks.

> Der Controller muss 768 Bit in 312,5 µs ausgeben, das wäre die 100 %
> Auslastung.

"Ausgeben" bedeutet viele Sprungbefehle, Clock Signal und Daten 
abwechselnd als I/O Signale erzeugen.

Am besten du testest mal mit einem Panel und misst die Zeit, die dein 
Programm tatsächlich benötigt.

Nicht umsonst nutzt die DFRobot Matrix Library Assemblerbefehle im 
C-Code, um das shift out zu beschleunigen.

: Bearbeitet durch User
von Daniel S. (supernova01)


Lesenswert?

Der Controller muss 768 Bit in 312,5 µs ausgeben, das wäre die 100 % 
Auslastung. Bei 160 Mhz bewegt sich das ganze im Bereich 6,25 ns pro 
Befehl, sofern das bei dem ESP so ist - keine Ahnung.

Sagen wir mal er braucht für die Ausgabe von 768 Bit 6 Befehle pro 
Bitausgabe (Keine Ahnung wie viele es sind) dann sind es 6,25 ns x 768 x 
6 = 28 µs - da ist dann noch etwas Luft bis 312,5 µs - aber ob das 
wirklich so ist...

Daniel D. schrieb:
> Am besten du testest mal mit einem Panel und misst die Zeit, die dein
> Programm tatsächlich benötigt.

Jo, und es wäre schön wenn hier noch jemand Erfahrungen teilt... darauf 
hoffe ich.

Daniel D. schrieb:
> nutzt die DFRobot Matrix Library Assemblerbefehle

Was ist das? Ich habe 20 Jahre Assembler gemacht, aber auf dem PIC nicht 
auf dem ESP. Ich würde aber eh versuchen alles in C zu machen, möglichst 
ASM nah vom Aufbau her, sodass es gut übersetzt werden kann. Das ist 
etwas näher dran als dieses Arduino Cpp geschluntze.

: Bearbeitet durch User
von Daniel S. (supernova01)


Lesenswert?

Daniel D. schrieb:
> Am besten du testest mal mit einem Panel und misst die Zeit, die dein
> Programm tatsächlich benötigt.

Zwei drei Panel habe ich hier, muss mir mal einen Moment Zeit nehmen. 
Das schöne ist, ich kann den Code gleich so schreiben als wären alle 12 
angeschlossen und nur eins anschließen... müsste gehen...

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Daniel D. schrieb:
> Matthias S. schrieb:
>> Für WS2812 gibts da
>> auch Beispiele im Repository.
>
> Von denen ist nicht die Rede

Ja und? Das ist ja auch nur ein Beispiel für die Benutzung der 
Statemachines. Das Vorhaben hier ist ein perfekter Job für die Dinger. 
Und es gibt ja im RP2040 nicht nur eine.

von Daniel D. (danielduese)


Lesenswert?

Dann nur noch eine Idee zum Ende: Mikrocontroller sind ja nicht der 
große Kostenpunkt bei dem Projekt.

Du kannst den Gesamtaufbau modularer gestalten. Mehrere Controller mit 
fertiger Library zB von Waveshare, die jeweils nur dazu in der Lage sind 
über UART Bitmap-Daten zu empfangen und ein einzelnes Panel anzusteuern.

Dann bekommst du später auch keine Probleme, was deine 120cm Strecke 
angeht.

Viel Erfolg

von Daniel D. (danielduese)


Lesenswert?

Daniel S. schrieb:
> Daniel D. schrieb:
>> nutzt die DFRobot Matrix Library Assemblerbefehle
>
> Was ist das?

https://wiki.dfrobot.com/64x64_RGB_LED_Matrix_-_3mm_pitch_SKU_DFR0499

von Daniel D. (danielduese)


Lesenswert?

Matthias S. schrieb:
> Ja und? Das ist ja auch nur ein Beispiel für die Benutzung der
> Statemachines. Das Vorhaben hier ist ein perfekter Job für die Dinger.
> Und es gibt ja im RP2040 nicht nur eine.

Hab ich missverstehen. Ja, die könnten das beschleunigen.

von Daniel S. (supernova01)


Lesenswert?

Daniel D. schrieb:
> die jeweils nur dazu in der Lage sind
> über UART Bitmap-Daten zu empfangen und ein einzelnes Panel anzusteuern.

Ist eine Möglichkeit. Ich kenne "Waveshare" nicht.

Daniel D. schrieb:
> Dann bekommst du später auch keine Probleme, was deine 120cm Strecke
> angeht.

Das kann ein Problem sein, jedoch haben die Module Repeater für alle 
Signale, sodass man mit Reflexionen eigentlich keine Probleme bekommen 
dürfte, sie sind ja fürs kaskadieren gemacht... für große Video 
Leinwände...und da müssen dann eigentlich noch 100 mal mehr Daten rüber

Aber danke für die Anregungen und Überlegungen...

Ich würde meine Applikationen:

https://www.mikrocontroller.net/attachment/160286/IMG_8817.JPG

wirklich gern noch mal zwanzig Jahre nutzen.

: Bearbeitet durch User
von Daniel D. (danielduese)


Lesenswert?

Daniel S. schrieb:
> meine Applikationen:

Ausgezeichnet

von Daniel D. (danielduese)


Angehängte Dateien:

Lesenswert?

Daniel S. schrieb:
> Daniel D. schrieb:
>> Dann bekommst du später auch keine Probleme, was deine 120cm Strecke
>> angeht.
>
> Das kann ein Problem sein,

Hab die Schematik nicht verstanden. Sah aus wie wenn zwischen jeweils 6 
Panels eine 120cm Strecke überbrückt werden muss.

Mit dem Bilderrahmen wirds klar.

von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

Ich würde auch empfehlen, jedes Modul mit einer eigenen Intelligenz zu 
versehen. Man kann "ganz klein" mit Hard- und Software sehr übersichlich 
für ein Modul anfangen, später wird nur noch repliziert und die Module 
können beliebig angeordnet werden.

Es gibt übrigens eine Version des ESP32 mit LAN-Anschluss 
("WT32-ETH01"), kostet beim Ali 10,- das Stück. Die kannst du von einem 
beliebigen Rechner aus mit UDP "vollballern" ...

Durch den Standard-LAN-Anschluss hat man auch keinerlei Probleme mit 
UART-Kollissionen, Timing, Kabelei, Pullups- und Downs ... einfach 
Billig-Switch und fertig.

: Bearbeitet durch User
von Daniel S. (supernova01)


Angehängte Dateien:

Lesenswert?

Frank E. schrieb:
> jedes Modul mit einer eigenen Intelligenz zu
> versehen.

Ich schaue erstmal wie weit ich mit einem Controller komme, vorher wäre 
es Unsinn sich mit einem Konzept zubeschäftigen dass mehrere Controller 
einbezieht. Ich befürchte aber auch, dass es wohl nötig sein könnte...

Ich habe mir nun ein "NodeMCU V3" mit dem ESP8266 (ESP-12E Basis) 
geschnappt:

https://42project.net/hello-world-erstes-projekt-mit-dem-esp8266-nodemcu-v3-und-der-arduino-ide-getting-started/

da der hier gerade noch rum flog und ich dafür die Arduino Treiber schon 
mal installierte hatte.

Ich habe gestern drei Stunden gebraucht um das wieder zum laufen zu 
bekommen, der Testprogramm Blink wollte einfach nicht erneut da rauf. 
Ende vom Lied war dass ich Arduino 2.1.1 installiert habe. Warum auch 
immer, das lief ja schon mal.

Dann noch Ärger mit den Boardeinstellungen, für diesen Lolin node MCU V3 
muss man Node MCU V1.0 als Board auswählen  - muss man erstmal alles 
wissen und ergoogeln...naja egal, irgendwann lief es.

Mein erstes Klimperprogramm läuft nun erstmal mit den Arduino 
digitalwrite zeugs, erzeugt natürlich ein grotten timing, aber nach 
zwanzig Minuten gefummel, stimmen nun Alle Signale CLK, LAT, OE usw... 
die Routine ist so geschrieben wie ich sie oben angedeute habe und holt 
sich die Daten bereits aus einem 64x32 Byte großem Puffer. Dort habe ich 
mal drei Pixel in unterschiedlichen Farben initialisiert.

Im nächsten Schritt möchte ich gern ASAP vom digitalWrite weg und direkt 
ins IO Register des ESP greifen, da das bei den Atmels mit den bekannten 
Labeln PORTA PORTB auch von dort aus ging, müsste es ja auch ein 
Äquivalent dazu vom ESP-12E geben, danach schaue ich gerade...ich mache 
das am liebsten mit Bitoperationen, das ist Hardware"näher". Ich brauche 
für mein Projekt 14 IOs zum Panel, bis jetzt kann ich nur 11 frei 
ansteuern. Deswegen habe ich die RGB Lines der oberen Hälfte erstmal auf 
GND gelassen.

Dann gibts noch ein paar Probleme, manche IO Pins kann ich noch nicht so 
nutzen, meistens stört es die Kommunikation zum ESP wenn ich dort IOs 
des Panels dran hänge, ich muss mal gucken wo der CH340 dran hängt und 
vor allem was es mit den Pins S1, S2 und S3 lauf sich hat...Dazu wäre 
ein Blockschaltbild vom ESP natürlich hilfreich...

Echt interessant auf was man so stößt:

file:///C:/Users/Strahelefrau/Downloads/ESP12-E-Datenblatt-2.pdf

Ich hätte eigentlich ein etwas 2000 Seiten langes PDF erwartet...

Besser:

https://www.espressif.com/sites/default/files/documentation/esp8266-technical_reference_en.pdf

: Bearbeitet durch User
von Sebastian W. (wangnick)


Lesenswert?

Hier schon geschaut: https://github.com/pixelmatix/SmartMatrix?

LG, Sebastian

von Daniel S. (supernova01)


Lesenswert?

Sebastian W. schrieb:
> Hier schon geschaut

Nein, danke für den Link.

Dort baut alles darauf Farbtiefen auszugeben, ich möchte ja tatsächlich 
"nur" die Grundfarben rot an,aus, grün an,aus, blau an,aus - dafür dann 
aber 12 64x64 Panel mit einem 1:32 Scan ansteuern.

Geht hier schon mit den GPIO los bei dem ESP, meine Güte.

Naja, wenn ich dann dort etwas lese von DMA usw... aber vielleicht 
könnte man sich dort etwas "klauen" aber ob man das findet und versteht 
um es zu modifizieren ... das steht auf einem andren Blatt...

von Daniel S. (supernova01)


Lesenswert?

Das Ding ist natürlich flexibel ausgelegt, für alle Modelle mit 
1:8,1:16, 1:32, 1:40 Scan (Muxing), es verfügt über Layer, hat 
Schriftarten/Zeichensätze, kann sogar animiert Gifs konverteiert 
abspielen und sogar ein Spectrum analyser -> cool ... aber sehr sehr 
viel Overhead.

Ich brauche ja "nur" Speicher aufs Display ausgeben. Allein die Sourcen 
sind sicher über 40 Dateien.

In esp32_i2s_parallel.c

static void fill_dma_desc(volatile lldesc_t *dmadesc, 
i2s_parallel_buffer_desc_t *bufdesc);

In MatrixEsp32Hub75Calc.cpp

gehts um Semaphoren und Tasks - das hört sich für mich nach einem 
Betriebssystem an.

In Esp32MemDisplay.h

dort wird "nur" eine Ausgabe gemacht...

Was mich etwas wundert ist dieser Satz: "You can chain several panels 
together to create a wider or taller display than one panel would allow. 
Set kMatrixWidth and kMatrixHeight to the overall width and height of 
your display. If your display is more than one panel high, set 
kMatrixOptions to how you tiled your panels:"

Da müsste es doch Leistungsgrenzen vom Speicher des ESP und auch beim 
Timing geben...

Ich bin nun gerade hier:

https://www.instructables.com/RGB-LED-Matrix-With-an-ESP8266/

: Bearbeitet durch User
von Sebastian W. (wangnick)


Lesenswert?

Daniel S. schrieb:
> Da müsste es doch Leistungsgrenzen vom Speicher des ESP und auch beim
> Timing geben...

Ich bin auch nicht sicher, ob diese Bibliothek deinen Anforderungen 
entspricht.

Ich verwende sie erfolgreich für unsere 64x64 beleuchtete Hausnummer, 
allerdings mit einem Teensy 3. [Zur Weihnachszeit kommt da immer eine 
Animation mit Tannenbäumen, rot-weiss funkelnden Christbaumkugeln und 
einem von Zeit zu Zeit durchziehenden Kometen drauf; da bleiben schon 
immer mal Leute stehen :]. Ich hatte auch schon angenehmen Kontakt zu 
Louis.

Mit dem ESP32 gibt es aber wohl noch gravierende Einschränkungen. Zum 
Beispiel ist dort die von dir angedachte Bittiefe 3 nicht möglich. Es 
wird dort für den ESP32 auf eine andere Bibliothek verwiesen: 
https://github.com/pixelmatix/SmartMatrix/wiki/ESP32-Port.

Dennoch ist der Quellcode oder die Doku vielleicht an der einen oder 
anderen Stelle für dich nützlich.

LG, Sebastian

: Bearbeitet durch User
von Daniel S. (supernova01)


Lesenswert?

Sebastian W. schrieb:
> Ich verwende sie erfolgreich für unsere 64x64 beleuchtete Hausnummer

Eine coole Idee, kannst ja mal ein Bild posten. Was für ein Gehäuse hast 
du denn genutzt.

Sebastian W. schrieb:
> Ich bin auch nicht sicher, ob diese Bibliothek deinen Anforderungen
> entspricht.

Das macht nichts, ist sowieso alles nicht mal eben so.

Was mein Start angeht, so scheint es so, als würde es vom Speicher her 
mit dem 8266 gehen:

Auslastung für ein (64x64) Modul im Ram samt Arduino overhead:

. Variables and constants in RAM (global, static), used 30128 / 80192 
bytes (37%)
║   SEGMENT  BYTES    DESCRIPTION
╠══ DATA     1496     initialized variables
╠══ RODATA   920      constants
╚══ BSS      27712    zeroed variables

Auslastung für 12 (64x64) Module:

. Variables and constants in RAM (global, static), used 52656 / 80192 
bytes (65%)
║   SEGMENT  BYTES    DESCRIPTION
╠══ DATA     1496     initialized variables
╠══ RODATA   920      constants
╚══ BSS      50240    zeroed variables

Ich habe gesehen dass für die Nutzung der 64x64 die 2x3 RGB Lines in 
"reihe" geschaltet wurden um mit den IOs hin zu kommen, statt 6 lines 
mit 64 Bit hat man so 3 Lines mit 128 Bit an einem Modul. So habe ich 
nun mal einen ESP32 dual core bestellt, auch da es dort mehr IOs gibt.
Der muss nun erstmal ankommen...

Bis dahin bin ich für jeden Tip dankbar wie man ein Datenfeld von

uint8_t DisplayRam[64*12][32];  // mit 3(4) Bit pro Pixel

Zyklisch über 6 Pins an sechs lines: R1, R2, G1, G2, B1, B2 mit je 768 
Bit mit so viel Dampf ausgibt dass man 100Hz pro Pixel als Wiederholrate 
erreicht. Immerhin sieht meine Takterzeugung momentan noch so aus:

    digitalWrite(HUB75_CLK, HIGH);
    digitalWrite(HUB75_CLK, LOW);

:-) erbärmlich.

Wenn man interne Hardware wie I2C nutzt, hat man ja nur eine Datenline, 
hier werden aber ja sechs benötigt...welcher Trick oder welche int. 
Hardware  dort genutzt wird, das würde mich wirklich brennend 
interessieren.

: Bearbeitet durch User
von Daniel S. (supernova01)


Lesenswert?

The ESP32 can continuously shift data from RAM through the I2S 
peripheral in parallel to GPIO pins, without using up CPU cycles.

Okay

nun also hier
https://www.waveshare.com/wiki/RGB-Matrix-P3-64x64

: Bearbeitet durch User
von Daniel S. (supernova01)


Lesenswert?

Daniel S. schrieb:
> gehts um Semaphoren und Tasks - das hört sich für mich nach einem
> Betriebssystem an.


#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "freertos/semphr.h"
#include "freertos/queue.h"

oh man, aber wenn es sein muss...

von Heinz R. (heijz)


Lesenswert?

ich verstehe ja zugegeben nicht warum man sich das antut

Das sind "Rest-Kacheln" von irgend einem Videowand-Hersteller

Dafür gibt es Controlloer von Linsn, Novastar, Colorlight usw

Das Zeug ist mittlerweile so dermaßen billig geworden  - lohnt es sich 
echt noch hier das Rad neu zu erfinden?

Aber jeder wie er mag....

von Daniel S. (supernova01)


Lesenswert?

Ja, nö - ich möchte eigentlich auch nichts neues erfinden, gern was 
fertiges nehmen. Die Module sind einfach attraktiv, waren die SLM-1606 
von Samsung vor 20 Jahren auch...

Bitte 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
Noch kein Account? Hier anmelden.