Info zu grosse RGB LED Panel

Der chaotische Hauptfaden

Moderatoren: Sven, Heaterman, TDI, Finger

Re: Info zu grosse RGB LED Panel

Beitragvon Fritzler » Di 7. Aug 2018, 19:15

Spannung runter bringt ganix und unter 4V wirds dann richtig bunt :lol:

Der Sreg IC des Panels ist sowieso mit 4,5V bis 5,5V angegeben, daher auch der HCT als Pegelwandler.

600FPS sind ja nich schlecht, bei mir geht eben mehr als die 8 fache Rechenleistung drauf.
Ersteinmal wird der RGB Framebuffer in 8 Arrays der Modulation zerlegt und dann kommt zum Clusterbitgeschubse ja noch das Bitgeschubse von MSB bis LSB für die Helligkeitsstufen dazu.
Aber so wies aussieht muss ich die FPGA Keule garnicht auspacken, die Rechenleistung scheint zu reichen.
Benutzeravatar
Fritzler
 
Beiträge: 5573
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk

Re: Info zu grosse RGB LED Panel

Beitragvon Matt » Di 7. Aug 2018, 19:23

hehe.. wollte dir sagen, du kannst nun meine FPGA-Aal nehmen. Das ist wirklich FPGA-Dampfhammer (149kLUT)

Lustigsweise ging meiner bis runter auf 2,8V, dann steigt AVR aus.
Benutzeravatar
Matt
 
Beiträge: 2372
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitragvon Fritzler » Di 7. Aug 2018, 22:12

https://www.ebay.de/itm/ieGeek-DC-5V-12 ... lnGaVqTFNg
25€ für 5V und 70A? Als MeanWell kostet das über 90€.
Das Ding explodiert doch beim ersten einschalten?

Bei deinem Aal muss auch der BlockRAM groß genug sein, da muss ich mal gucken.
Auf der Platine sind zwar 4 DRAM ICs, aber sowas hab ich mitm FPGA noch nicht angesteuert, aber alles zu seiner Zeit.
Benutzeravatar
Fritzler
 
Beiträge: 5573
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk

Re: Info zu grosse RGB LED Panel

Beitragvon Fritzler » Mi 8. Aug 2018, 16:00

Dimmen geht :D
https://youtu.be/jD5Gg2OpsDc

Auch wenns ab dem gesetzten MSB doch irgendwie zu hell wird.
Da muss ich wohl mal noch am Bitwinkel rumspielen.

Blöderweise musste ich auf 60fps erhöhen, denn sonst hats geflackert wie blöde :/
Macht also nurnoch 6 statt 12 Panels möglich.
Is eben etwas doof, dass die Schieberegister des Panels nur 25MHz können und nicht zB 40MHz oder 50.
Benutzeravatar
Fritzler
 
Beiträge: 5573
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk

Re: Info zu grosse RGB LED Panel

Beitragvon thinkpad » Mi 8. Aug 2018, 16:43

bin mal gespannt wie das hier so weiter geht.

Baut ihr Controller für direkten Videoinput oder vom Ethernet/ Festplatte?
thinkpad
 
Beiträge: 272
Registriert: Fr 6. Feb 2015, 16:53
Wohnort: Rhein Neckar

Re: Info zu grosse RGB LED Panel

Beitragvon Matt » Mi 8. Aug 2018, 17:00

Er und ich verfolgte andere Weg.

Aber was er und ich daraus machen wird, wird hier dokumentiert ;-)

Grüss
Matt
Benutzeravatar
Matt
 
Beiträge: 2372
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitragvon Fritzler » Fr 10. Aug 2018, 20:23

Video geht!
Zwar erstmal nur 32x16, weil mir die Pfostenbuchsen ausgegangen sind, aber geht.
Murphy mal wieder, von 10 oder 20 pol habe ich ganze Tüten voll, von 16pol hab ich aber nur ne Aldi Sortimentsbox Schublade mit 8 Stück gehabt.

Das Video flimmert leider wie sau, weil Display und Kamera verschiedene Frameraten haben und selbst beim angleichen der FPS im STM32 rennt das dann irgendwann auseinander.
Per Auge direkt gesehen siehts ganz gut aus.
https://youtu.be/h9qx7ENijSQ

Um was zu erkennen muss man echt 5m weit von weg stehen :lol:
Zudem ist das so helll, dass man fast erblindet!

Der mplayer spielt das Video unter Linux ab und sakliert es runter auf 23x16, dann wirds meinem mplayer PLugin übergeben, was das über 1MBaud UART raushustet.
Da geht dann in den STM32, der das per DMA in den Framebuffer hustet.
Von da aus war ja schon alles fertig.
Benutzeravatar
Fritzler
 
Beiträge: 5573
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk

Re: Info zu grosse RGB LED Panel

Beitragvon video6 » Fr 10. Aug 2018, 23:42

Schade das ich mich da nicht gemeldet hatte als die Dinger aufkamen.
Aber OK
Benutzeravatar
video6
 
Beiträge: 2077
Registriert: Mi 23. Sep 2015, 09:18

Re: Info zu grosse RGB LED Panel

Beitragvon xanakind » Sa 11. Aug 2018, 00:38

Fritzler hat geschrieben:https://www.ebay.de/itm/ieGeek-DC-5V-12V-24V-LED-Netzteil-Trafo-Adapter-Schaltnetzteil-fur-Strip-Leiste/263784217088?hash=item3d6ac3ba00:m:ms1oCLbesrrXelnGaVqTFNg
25€ für 5V und 70A? Als MeanWell kostet das über 90€.
Das Ding explodiert doch beim ersten einschalten?

Bei deinem Aal muss auch der BlockRAM groß genug sein, da muss ich mal gucken.
Auf der Platine sind zwar 4 DRAM ICs, aber sowas hab ich mitm FPGA noch nicht angesteuert, aber alles zu seiner Zeit.

Wenn du das 85A Netzteil brauchst, sag bescheid :-)
Benutzeravatar
xanakind
 
Beiträge: 3670
Registriert: So 11. Aug 2013, 21:55
Wohnort: in der nähe von Frankfurt/Main

Re: Info zu grosse RGB LED Panel

Beitragvon Fritzler » Sa 11. Aug 2018, 09:27

@xana
Dein NT Aal brauch ich zusätzlich zu den 25€ Chinaböllern.

Insgesamt brauch ich 500A :lol:
Wobei ich die Panels wohl wirklich in 2 Phasen auf maximal 50% Helligkeit dimmen werden um Strom zu sparen.
Benutzeravatar
Fritzler
 
Beiträge: 5573
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk

Re: Info zu grosse RGB LED Panel

Beitragvon Matt » Mo 13. Aug 2018, 20:47

Oder Lötarbeit: Rset an alle Panel austauschen.


Ich bin auch mit Code weiter. Framebuffer ist ja bereits funktionsfähig , inkl. SPI(Software zwingend, wegen 3Kanal-SPI)

Ich überlege, ob ich RGB , jeweilig 2 Bit , damit realisieren werde. (gesamt 64 Farbe)
Charakter-Satz ist 100% fertig. (sogar dort wird mit unterschiedliche Zeichenabstand arbeiten) Mag nicht wirklich Monospace für Anzeige .

Bei mir ist es eher nebenbei programmieren, daher bin ich ned so weit wie er.
Benutzeravatar
Matt
 
Beiträge: 2372
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitragvon Fritzler » Mo 13. Aug 2018, 21:16

Ich mach das hier auch nur nebenbei :lol:
Also 3 oder 4 Bit pro Farbe wird wohl auch mitm AVR gehen.
64 Farben werden aber für statische Schriften wohl locker reichen.

Inzwischen hab ich noch Gammakorrektur eingebaut und mit 8Bit "PWM" kann ich somit 32 Graustufen pro Farbe.
Also insgesamt 32768 Farben, das ist noch weeiiit weg von 24bit RGB Truecolor.
Sieht aber VIEL besser aus als direkt die 8Bit pro farbe auf die "PWM" loszulassen.

Da ist mir noch eingefallen wie ich die Bit Angle Modulation Stufen die kürzer als die SPI Übertragungszeit sind doch noch nutzen kann für 11 oder 12Bit an Graustufen.
Die untersten LSB brauchen alle solange wie das LSB bei 8Bit, aber sie werden nur sehr kurz mit dem Output Enable zum leuchten gebracht.
Da dann die LED auch nie voll an sein kann ist das dann auch gleichzeitig die Displaydimmung zum NT sparen.

Oder die Brechstange ansetzen!
Son STM32F0 ist beim Ali für unter 1€ zu haben.
-> 1 Controller pro Panel und Party is!

Das Problem an diesen alten Panels ist, dass die kein 1:8 oder 1:16 scan haben, daher ist viel Idlezeit auf dem SPI.
Hier wird immer das gesamte Panel aktualisiert.
Bei den neuen Panels mit zB 1:16 Scan schiebt man dieselbe Datenmenge pro Zeile rein und hat dann 16 statt 1 Panels angesteuert.
Dann lässt man die Zeile kurz aufleuchten, das geht auchnoch schneller, weil die LEDs durch das Multiplexing/Scan ne Stromerhöhung haben.
Währenddessen wird schon die nächste Zeile reingeschoben.
Diese Panels haben auch nur 25MHz auf den Schieberegistern.

Zur Verdeutlichung was ich mit Idle meine:
blau = LATCH
gelb = CLK

Bild
Am 4. Divstrich von links geht ein BAM los.
Da geht der LATCH kurz hoch für die Daten des 7.Bit und diese sind lange an, danach wird Bit6 übertragen.
nach etwas Timerwarten wird Bit6 gelatcht.
Die Bitübertragunf (CLK Signal) geht imemr recht schnell, aber dann passiert nicht viel auf dem SPI bis wieder gelatched wird.
usw, man sieht wie sich die Zeiten halbieren.

Am unteren Ende der Bitskala wirds dann eng:
Bild

Bei Panels mit "Scan" könnt ich da jetzt schön schachteln, bei denen hier nicht.
Dazu muss dann aber der LATCH aufgetrennt werden, also ich bau mir den "scan" selber, aber eben panelweise und nicht zeilenweise.
Soll heißen ich kann mit einem SPI 4 Module hintereinander ansteuern und davon vllt noch 3 Zeilen wenn ich mit getrenntem Latch schachtele.
Benutzeravatar
Fritzler
 
Beiträge: 5573
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk

Re: Info zu grosse RGB LED Panel

Beitragvon Fritzler » Di 14. Aug 2018, 16:32

GEIEL! 11Bit an Graustufen pro Farbe gehen jetzt!
Jetzt wird nen Video nicht mehr alleinig Quietschbunt abgespielt, sondern es taucht auch mal ne Farbe auf wie "Hautfarbe".
Sind ja nun auch 262144 Farben statt 32768, also das 8fache Farbspektrum.

Ersteinmal hab ich den SPI so umgebaut, dass die Daten kurz vor dem Latch übertragen werden.
Der Timer triggert nen IRQ -> IRQ Handler setzt neue Timerzeit und triggert den DMA -> "DMA hat fertig" IRQ pulst dann den Latch Pin.
Das ist eine Vorbereitung auf das verschachtelte Senden zu mehreren Panelzeilen mit aufgetrenntem Latch.
(blau = LAT, gelb = CLK)
Bild

Bisher wurden 8Bit an das Display gesendet und das LSB der 8Bit hatte die kürzeste Sendezeit.
Jetzt werden hinter dem LSB noch weitere 3 Bit gesendet (mit demselben Zeitabstand).
Die anderen Bits müssen dafür etwas zusammenrücken mit ich immernoch 60Hz Wiederholrate habe:
Bild

Jetzt brauchts einen weiteren Timer, der den Output Enable steuert.
Der Timer wird im "DMA hat fertig" IRQ Handler gesteuert.
Dieser Timer läuft im PWM Modus, ganz wichtig: dazu noch im One Pulse Mode.
PWM auf 100% ist dann die maximale Bitzeit des Output enable.
Die eigentliche Bitzeit wird durch den Prescaler des Timers bestimmt, also beim dimmen hat man 4 stellige Freiheitsgrade :lol:
Also hiermit lässt sich das Display dann auchnoch dimmen.
Bei Bit 7 bis 0 ist der nOE so lange low (=aktiv) wie auch die Bitzeit vorher war.
Bei den noch kleineren Bits (ich nenn sie -1, -2 und -3) wird dann der nOE Impuls gekürzt.
Das sollte im OSzi Screenshot gut zu sehen sein:
(blau = nOE, gelb = CLK)
Bild

Da das Panel jetzt nicht mehr zu 100% an sein kann, sinkt auch die Stromaufnahme deutlichst von 12A auf "nurnoch" 8,7A bei alles weiß :lol:
Das verringert den Strom genug, dass ich doch nicht nochmal 50% von wegdimme, für den Strom komm ich günstig genug an NTs.
Weiterhin wird das Display auch nicht mehr so verdammt hell durch die vielen Graustufen pro Farbe.
Daher rbauch ich also auch 100% Helligkeit.

Nur die Gammakorrekur Nachschlagtabelle gefällt mir am unteren LImit noch nicht so ganz:
Code: Alles auswählen
static const uint16_t pwmtable[] = {
0, 1, 1, 2, 2, 2, 2, 3, 3, 3,
4, 4, 5, 5, 6, 7, 8, 9, 10, 11,
12, 14, 15, 17, 20, 22, 25, 28, 32, 36,
40, 45, 51, 57, 65, 73, 82, 92, 104, 117,
132, 149, 168, 189, 213, 240, 270, 304, 343, 386,
435, 490, 552, 622, 701, 789, 889, 1002, 1128, 1271,
1432, 1613, 1817, 2047, 2047};

Da stehen mir zu oft die gleichen Zahlen, aber das wird selbst bei 14Bit nicht viel besser.

Apropos Netzteil:
Lieber Freund, hallo, es tut mir leid, dieses Produkt ist heiß wegen des Verkaufs. Das letzte wurde gekauft, bevor Sie es gekauft haben. Die neue Charge muss lange warten. Werden wir Ihnen eine Rückerstattung geben? Wir entschuldigen uns für die Unannehmlichkeiten, warten auf Ihre Antwort, ich wünsche Ihnen ein glückliches Leben.

ich mach dir gleich den Hintern heiß, weil du dein Warenwirtschaftssystem nicht unter Kontrolle hast!

ABER!
Ich hab nen NT gefunden was noch billiger ist.
5V 70A für 26€ warens.
Hier gibts 5V 60A für 17€ :shock:
(ihr müsst weiter runter scrollen auf "5V 60A 300W Dünschnitt"):
https://www.ebay.de/itm/Schaltnetzteil- ... 0506.m3226
Benutzeravatar
Fritzler
 
Beiträge: 5573
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk

Re: Info zu grosse RGB LED Panel

Beitragvon Matt » Mi 15. Aug 2018, 16:18

Dank dir, ich verstehe nun, wie Bitangle-Modulation funktioniert.
Je höherwertige Bit ist, desto länger ihre angezeigte Subframe (entsprechend Bit) ist. Da spart man massiv SPI Übertragung (und Rechenleistung). (8Bit Auflösung = 8x SPI Übertragung anstelle 256)
Bit 2^0 hat 1ms Länge, Bit 2^1 hat 2ms, lässt fortsetzen.
Ich verstehe nun, was für Problem du gekämpft hast.


Das Bitangle-Modulation wird ich auch in meiner intergiert.
Ich habe gemesst., wie lang soft-SPI für 32x32 braucht (genauso gleich wie 16x64) , ca 4,5ms. :? (meiste Zeit hat Bitverschieberei für Auswählen von Framebuffer-Byte gebraucht, 4x4 Cluster :roll: )
Glaub, ich steigt auf STM um.. (paar Material ist unterwegs)
Aber ich kann damit auch leben und den Übertragung so verschachteln, dass ich keine verlorene Zeit habe, dafür wird Latch-Ansteuerung abgetrennt und wird zu andere Zeitpunkt auslösen.
IMG_20180815_160841.jpg
Benutzeravatar
Matt
 
Beiträge: 2372
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitragvon Matt » Mi 15. Aug 2018, 19:48

Fazit: AVR (Atmega328p an 16Mhz ) ist schon grenzwertig, 32x32 grosse Panel, RGB 2Bit, schafft der so etwa 66FPS (keinerlei _delay-Befehl bis auf eine Stelle wegen Bitangle-Modulation)

Flaschenhals ist Software-SPI !
Code zeigt alte Version ohne Bitangle-Modulation (einige Stelle ist wegen Timing optimiert) Ups, da gibt 2 zu optimierte Stelle .
Code: Alles auswählen
for(int i=-0; i< Pixel; i++) {                // Cluster-Zuordnung erzeugen.
      FrameBufferSelect = ((i &0x0C)<<3)|((i&0x30)>>2)|((i &0x40)<<1)|((i&0x80)>>3)| (i&0x303);  // das ist Bitverschieberei wegen 4x4 Cluster, kostet am meiste Rechnenzeit.)
      
      PORTB &= ~(1 << PB1);      // Takt fallende Flanke
      PORTD &= ~(1 << PD4);         // GRÜN auf LOW
      PORTD &= ~(1 << PD5);         // BLAU auf LOW
      PORTD &= ~(1 << PD6);         // ROT  auf LOW
      if (FrameBuffer[(FrameBufferSelect>>5)][(FrameBufferSelect&0x1F)]&0x01) PORTD |= (1 <<PD4) ;   // wenn 1, dann GRÜN = H
      if (FrameBuffer[(FrameBufferSelect>>5)][(FrameBufferSelect&0x1F)]&0x02) PORTD |= (1 <<PD5) ;     // wenn 1, dann BLAU = H
      if (FrameBuffer[(FrameBufferSelect>>5)][(FrameBufferSelect&0x1F)]&0x04) PORTD |= (1 <<PD6) ;   // wenn 1, dann ROT  = H
       PORTB |= (1 <<PB1) ;         // Takt steigende Flanke
      }
   PORTD &= ~(1 << PD4);         // GRÜN auf LOW
   PORTD &= ~(1 << PD5);         // BLAU auf LOW
   PORTD &= ~(1 << PD6);         // ROT  auf LOW
   
   // Latch-Puls
   PORTB |= (1 <<PB0) ;         // /Latch auf HIGH
   PORTB &= ~(1 << PB0);        // /Latch auf LOW



Ich kann es schneller machen, wenn ich Hardware-SPI realisieren werden. Lohnt aber nicht. STM32-Umsteig ist überfällig.
Zuletzt geändert von Matt am Mi 15. Aug 2018, 20:00, insgesamt 1-mal geändert.
Benutzeravatar
Matt
 
Beiträge: 2372
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitragvon Matt » Mi 15. Aug 2018, 20:00

Optimierte SPI-Funktion bringt ca 4 FPS mehr, ich habe jetzt 70 FPS.
Ich wollte Latch-Puls optimieren, dass der zusammen mit Takt fällt. Doof dass ST2221 nicht flankengetriggerte Latch hat)

Code: Alles auswählen
   for(int i=-0; i< Pixel; i++) {                // Cluster-Zuordnung erzeugen.
      FrameBufferSelect = ((i &0x0C)<<3)|((i&0x30)>>2)|((i &0x40)<<1)|((i&0x80)>>3)| (i&0x303);
      
      PORTB &= ~(1 << PB1);      // Takt fallende Flanke
      PORTD &= ~((1 << PD4)|(1 << PD5)|(1 << PD6));// GRÜN auf LOW, BLAU auf LOW, ROT  auf LOW
      if (FrameBuffer[(FrameBufferSelect>>5)][(FrameBufferSelect&0x1F)]&0x01) PORTD |= (1 <<PD4) ;   // wenn 1, dann GRÜN = H
      if (FrameBuffer[(FrameBufferSelect>>5)][(FrameBufferSelect&0x1F)]&0x02) PORTD |= (1 <<PD5) ;     // wenn 1, dann BLAU = H
      if (FrameBuffer[(FrameBufferSelect>>5)][(FrameBufferSelect&0x1F)]&0x04) PORTD |= (1 <<PD6) ;   // wenn 1, dann ROT  = H
       PORTB |= (1 <<PB1) ;         // Takt steigende Flanke
      }
   PORTD &= ~((1 << PD4)|(1 << PD5)|(1 << PD6));// GRÜN auf LOW, BLAU auf LOW, ROT  auf LOW
   
   // Latch-Puls
   PORTB |= (1 <<PB0) ;         // /Latch auf HIGH
   PORTB &= ~(1 << PB0);           // /Latch auf LOW



IMG-20180815-WA0018.jpg

Beweis, dass ich Bitangle-Modulation hinbekommt habe. (überlagerte Bit leuchtet heller, da Hintergrund gesetzte Bit1 und Schrift gesetze Bit2 hat = vermischt, ergibt beide gesetzte Bit.
Benutzeravatar
Matt
 
Beiträge: 2372
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitragvon Fritzler » Mi 15. Aug 2018, 20:24

Für HW SPI bräuchsteste nen neueren AVR mit 1 SPI und 2 USART die im SPI Mode laufen.
Aber ja lohnt eben nicht.
Zudem kannste ja noch das TPM2 "Protokoll" einbauen, dann kannste das Teil mit JINX und Konsorten per PC steuern.
So hab ich Testpatterns aufs Panel schicken könne um Fehler zu sehen.
Jinx: http://www.live-leds.de/
TPM2: http://www.ledstyles.de/index.php/Threa ... steuerung/

Ich frag mich was ST geraucht hat:
Beim UART wurde ne PLL verbaut für ordentliche Baudraten.
Beim SPI nicht, sondern nur die üblichen 2^n Teiler, dabei trifft man ja nicht immer das Maximum der Taktrate eines SPI ICs.
So teuer kann die PLL nicht sein, so ein F413 hat einfach mal 10 UARTs mit also 10 PLLs :mrgreen:
Mit 84MHz aufm APB komm ich somit "nur" auf 21MHz oder eben gleich 42MHz.

Zudem ist mein Ansatz mit den 3 SPI auch etwas Käse, aber reicht zum ersten Testen.
Als nächstes:
Den DMA direkt auf das Outputregister der GPIO Pins loslassen.
Ein Timer taktet den DMA und stellt den CLK bereit.
CLK Bereitstellung über das OCR1 Register und 50/50 PWM im PWM Mode.
Das UpdateEvent des Timers (aka Überlauf oder ARR erreicht) wird den DMA Takten.
Dann kann ich genau 25MHz auf dem SPI erreichen und gebe noch Daten für 5 Panelzeilen aus.
Denn eine STM32 GPIO Bank ist 16Bit Breit.

Weiterhin kann ich dann mit 25MHz 3 Panels hintereiannder schalten.
(Dabei erreiche ich dann doch noch 120Hz Refreshrate, yay!)
Mit Latch Aufteilung und verschachtelter SPI Nutzung kann ich dann nochmal 3 dieser 3er am selben SPI Betreiben.
(So PI mal Daumen ist dafür genug Zeit)
Also eine Zeile kann aus 9 Panels bestehen.
Oben habe ich schon 5 Zeilen aus Panels erwähnt.
Also was wirds? -> 9x5 Panels, macht 144x80px, das ist sogar fast 16:9 (eine LED Zeile fehlt)
Mit Matts Panels und was Ludwig noch dem Schrotter abgeluxt hat komme ich auch haarscharf auf die benötigte Menge Panels.
Der Schrotter hat jetzt wohl nurnoch diese großen 8x16 Panels mit 1dpi. Die sind dann doch etwas groß für Frickelspaß.
Das Display hat dann jetzt schon 1,5x0,96m².

Zur Rechenleistung:
Da wirds wohl keinen FPGA brauchen, bei 11bit Graustufen auf eiem 168MHz STM32F4 braucht eine Panel 4x4 Cluster Umwandlung 700µs.
Bei 45 Panels sind das dann 31,5ms oder maximal erreichbare 31,7fps.
Mit dem IRQ Handler Overhead und reinkommenden Daten könnte das noch etwas knapp werden.
Also eskalieren wir mal hoch zu einem STM32H7 mit dicken 400MHz, dazu haben die dann noch L1 Cache für noch mehr Rechenleistung.
Da komm ich dann auf genug Rechenleistung um 60fps Videos anzuzeigen.
(auf den 32x16 konnte ich jetz auch schon 60fps Videos anzeigen, son Video ist dann dermaßen flüssig!)

Die Daten sollen dann per ArtNet eintrudeln
144x80px zu 3Byte RGB und 60fps sind dann so 2Mbyte/s, das sollte passen mit LAN.

Wenn du dann Fragen zum STM32 hast, frag ich helf da gern :geek:
Benutzeravatar
Fritzler
 
Beiträge: 5573
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk

Re: Info zu grosse RGB LED Panel

Beitragvon Fritzler » Do 16. Aug 2018, 16:35

Verschachtelung auf dem SPI geht jetzt auch.
Da mir die Pfostenbuchsen ausgegagen sind, konnt ichs nur der Reihe nach testen durch LAT/nOE umstecken, abers geht :mrgreen:
Zwischendurch gans noch ne Racecondition, mit Debug Pinwackeln fürs Oszi liefs, nachm rausnehmen nicht mehr.
-> Die Timer wurden nicht synchron genug gestartet.

Ersteinmal hab ich meine awesome Photoshopskills ausgepackt um zu überprüfen überhaupt genug Zeit ist zum Verschachteln.
Bisher war das ja nur augenscheinlich ermittelt durch einen geübten Blick auf den Oszischirm.
blau: phase 0
rot: phase 1
grün: phase 2
Bild
PAAASST! (da is aber immernoch Platz!)
Dann die Pixel des Offsets am Anfang gezählt und daraus die Timerticks berechnet :lol:

Also mal per Portpin wackeln aufm Oszi angucken ob denn auch die Realität dem Photoshop entspricht.
Ersteinmal mit 2 facher Schachtelung, ein Ausschnitt:
Bild

Jupp läuft, hier jetzt mal mit SPI wieder an und blau ist imemrnoch der Timer GPIO Ausgang zum auseinanderhalten der Übertragungen:
BildBild

Also mal 3 fach, Ausschnitt:
Bild

Achja und ich hab noch auf 12Bit hochgeschalten.
Das macht jetzt 128Graiustufen pro Farbe, aber das Display wird dann schon recht dunkel.
Daher isses per #define umschaltbar zwischen 11 und 12 Bit.
Benutzeravatar
Fritzler
 
Beiträge: 5573
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk

Re: Info zu grosse RGB LED Panel

Beitragvon Matt » Fr 17. Aug 2018, 20:26

Boh, du bist Profi (ohne Ironie, nicht meine Profibild entsprechend :lol: )

Aber echt, man überlegt immmer, ob man da Verbesserung rausholen kann.
Ging mir genauso und hab mit obrige beide Code für SPI Übertragung schon eindrucksvoll gezeigt, dass Unterschied gibt.


Deine Hinweis mit TPM2 ist super, ich habe gestern schon angefangen Library für TPM2 zu schreiben. Allerdings habe ich eine Zweifel beim durchlesen von TPM2 Potokoll: ob Antwort von Display auch genauso gleiche Datenblock-Formwie beim Empfang haben müsste? (0xC9, 0xDA,0xFramesizeH, 0xFramesizeL,Framesize*Daten, 0x36)
Benutzeravatar
Matt
 
Beiträge: 2372
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitragvon Fritzler » Fr 17. Aug 2018, 20:48

Dazu kann ich nix sagen, ich antworte nie.
Jinx schickt aber auch nie ein Paket auf das geantwortet werden müsste.

Ich kipp hier grade vom Stuhl wie billig der neue STM32H750 ist.
Grademal 5€ im LQFP100. :shock: Der STM32F205 für die E-Last war teurer!
Das Ding hat: 400MHz, 2x16kbyte L1Caches, 1MB RAM, 128k Flash, Peripherie bis zum Abwinken. Hab ich schon die Double Precision FPU erwähnt?
Die AVRs könn einpacken! :mrgreen:

Seite 17 die Übersicht: https://www.st.com/resource/en/datashee ... h750ib.pdf
*sabber*

Mouser willse mir nicht verkaufen wegen AES Kern :roll:
AVNET schon!
Benutzeravatar
Fritzler
 
Beiträge: 5573
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk

Re: Info zu grosse RGB LED Panel

Beitragvon Matt » Fr 17. Aug 2018, 20:52

alda, da hat der 32H750 mehr als hundsgewöhnliche PC :lol:

Erstmal fange ich mit ST32F103 an...Ich sollte mich ja beim Umsteigen nicht von Stuhl kippen.


@TPM2 OK, alles klar. Dann lasse ich Command-Teil so wie es ist. Wichtiger ist Daten-Teil.
Benutzeravatar
Matt
 
Beiträge: 2372
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitragvon Fritzler » Fr 17. Aug 2018, 22:11

Es passt sogar alles an den H750, auch wenn die Ethernetschnittstelle mal wieder mit der Schrotflinte auf die Pins verteilt wurde.
Das wird nochn Spaß die TXD/RXD Signale bei 25MHz mit halbwegs gleicher Länge an den PHY zu routen.
Achja: Auf 2 Lagen!
Denn bei Elecrow gilt:
10x10cm² 2 Lagen -> 4,90$
10x10cm² 4 Lagen -> 44,90$

PORTD geht komplett drauf für den DMA nach GPIO für 5x RGB Signale.
Ansonsten noch 3 GPIO für die Latches und 3 Timerausgänge für die nOE.
Der Rest ist etwas Hühnerfutter für EEPROM Anschluss und Debug UART.
Da ist noch genug frei um per Tastendrücke Muster aufm Display anzuzeigen.
Bild
Benutzeravatar
Fritzler
 
Beiträge: 5573
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk

Re: Info zu grosse RGB LED Panel

Beitragvon Matt » Sa 18. Aug 2018, 19:58

Sagmal, ist da Baudrate 115200 bei AVR mit 3% Fehler dramatisch bei Jinx! Ansteuerung.? Hab Pixelfehler und Streifen.

Massive Pixelfehler, wenn ich Zeitschleife dazwischen einbaut, dann blitzt Grafik auf, als ob man CRT TV mit Kamera abfilmt.




Erst wenn ich byteweise Auslesen mit Warten auf glütige Daten (anstelle "UART_NO_DATA") realisiert, dann ging einermass.
Dafür ging FPS runter auf 20-30. Natürlich geht es so nicht.
Überlauf-Fehler schliesse ich 100% aus.

Dummerweise kann Jinx! nicht weniger als 11520 Baudrate, sonst könnte ich mit 57,6kBd testen.
Dateianhänge
IMG-20180818-WA0016.jpg
Benutzeravatar
Matt
 
Beiträge: 2372
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitragvon Fritzler » Sa 18. Aug 2018, 20:14

Mit nem 16MHz Quarz mit BRR=8 haste laut meiner schlauen Exceltabelle sogar 3,5% Fehler dazu dann noch der Fehler des USB UART Adapters.
Das is schon sehr daneben.

Mit nem 20MHz Quarz würdeste bei BRR = 10 nurnoch 1,4% Fehler haben.
Zudem kann Jinx 250kbaud und der AVr hat dann bei 16MHz und BRR=3 so 0% Fehler :mrgreen:
Benutzeravatar
Fritzler
 
Beiträge: 5573
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Friedrichshagen/Am Wasserwerk

Re: Info zu grosse RGB LED Panel

Beitragvon Matt » Sa 18. Aug 2018, 20:18

Habe ich eben mit 250kBaud gesehen und beide Seite darauf eingestellt und diese Fehler bleibt allerdings weiterhin..

bäh!
Benutzeravatar
Matt
 
Beiträge: 2372
Registriert: So 24. Aug 2014, 21:22

VorherigeNächste

Zurück zu Allgemeine Diskussion

Wer ist online?

Mitglieder in diesem Forum: Bumbum, enebk, Google [Bot], radixdelta, reutron, scotty-utb und 22 Gäste

span