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
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
> 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
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.
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
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...
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.
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.
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.
Matthias S. schrieb: > Für WS2812 gibts da > auch Beispiele im Repository. Von denen ist nicht die Rede
> 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
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
Verstehe. Dann wird das mit 12 Panels wohl schon eine ordentliche Herausforderung an die Geschwindigkeit. Ich nehme das "nicht so schwer" zurück.
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
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
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
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...
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.
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
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
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.
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
Angehängte Dateien:
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.
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
Angehängte Dateien:
-
IMG_0580.JPG
240 KB -
IMG_0582.JPG
240 KB
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
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...
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
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
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
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
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...
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....
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...
Thread beobachten
Seitenaufteilung abschalten
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.