Seite 1 von 4

Re: Info zu grosse RGB LED Panel

Verfasst: Di 7. Aug 2018, 19:15
von Fritzler
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.

Re: Info zu grosse RGB LED Panel

Verfasst: Di 7. Aug 2018, 19:23
von Matt
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.

Re: Info zu grosse RGB LED Panel

Verfasst: Di 7. Aug 2018, 22:12
von Fritzler
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.

Re: Info zu grosse RGB LED Panel

Verfasst: Mi 8. Aug 2018, 16:00
von Fritzler
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.

Re: Info zu grosse RGB LED Panel

Verfasst: Mi 8. Aug 2018, 16:43
von thinkpad
bin mal gespannt wie das hier so weiter geht.

Baut ihr Controller für direkten Videoinput oder vom Ethernet/ Festplatte?

Re: Info zu grosse RGB LED Panel

Verfasst: Mi 8. Aug 2018, 17:00
von Matt
Er und ich verfolgte andere Weg.

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

Grüss
Matt

Re: Info zu grosse RGB LED Panel

Verfasst: Fr 10. Aug 2018, 20:23
von Fritzler
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.

Re: Info zu grosse RGB LED Panel

Verfasst: Fr 10. Aug 2018, 23:42
von video6
Schade das ich mich da nicht gemeldet hatte als die Dinger aufkamen.
Aber OK

Re: Info zu grosse RGB LED Panel

Verfasst: Sa 11. Aug 2018, 00:38
von xanakind
Fritzler hat geschrieben: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.
Wenn du das 85A Netzteil brauchst, sag bescheid :-)

Re: Info zu grosse RGB LED Panel

Verfasst: Sa 11. Aug 2018, 09:27
von Fritzler
@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.

Re: Info zu grosse RGB LED Panel

Verfasst: Mo 13. Aug 2018, 20:47
von Matt
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.

Re: Info zu grosse RGB LED Panel

Verfasst: Mo 13. Aug 2018, 21:16
von Fritzler
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.

Re: Info zu grosse RGB LED Panel

Verfasst: Di 14. Aug 2018, 16:32
von Fritzler
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

Re: Info zu grosse RGB LED Panel

Verfasst: Mi 15. Aug 2018, 16:18
von Matt
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

Re: Info zu grosse RGB LED Panel

Verfasst: Mi 15. Aug 2018, 19:48
von Matt
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.

Re: Info zu grosse RGB LED Panel

Verfasst: Mi 15. Aug 2018, 20:00
von Matt
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.

Re: Info zu grosse RGB LED Panel

Verfasst: Mi 15. Aug 2018, 20:24
von Fritzler
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:

Re: Info zu grosse RGB LED Panel

Verfasst: Do 16. Aug 2018, 16:35
von Fritzler
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.

Re: Info zu grosse RGB LED Panel

Verfasst: Fr 17. Aug 2018, 20:26
von Matt
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)

Re: Info zu grosse RGB LED Panel

Verfasst: Fr 17. Aug 2018, 20:48
von Fritzler
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!

Re: Info zu grosse RGB LED Panel

Verfasst: Fr 17. Aug 2018, 20:52
von Matt
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.

Re: Info zu grosse RGB LED Panel

Verfasst: Fr 17. Aug 2018, 22:11
von Fritzler
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

Re: Info zu grosse RGB LED Panel

Verfasst: Sa 18. Aug 2018, 19:58
von Matt
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.

Re: Info zu grosse RGB LED Panel

Verfasst: Sa 18. Aug 2018, 20:14
von Fritzler
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:

Re: Info zu grosse RGB LED Panel

Verfasst: Sa 18. Aug 2018, 20:18
von Matt
Habe ich eben mit 250kBaud gesehen und beide Seite darauf eingestellt und diese Fehler bleibt allerdings weiterhin..

bäh!

Re: Info zu grosse RGB LED Panel

Verfasst: So 19. Aug 2018, 10:22
von Matt
Am Arsch! Ich hab vergessen, "FB_clear"-Befehl rauszuwerfen, der Framebuffer leert. Kein Wunder dass ich nur Streifen sehen, da diese Befehl dazwischenkommt und Bild löscht.





https://www.youtube.com/watch?v=ooGHcZFvfVQ
Noch mit Debug-Pixel (unterste ist FrameSize, oberne ist FrameZähler)

Helligkeit : Dank Bitangle_Modulation erreicht es nur noch ca 60% Tastgrad, dazu ist es mit PWM über Widerstand & Diode gemischt, (10/255 PWM)
Rechnet ruhig selber aus ;-)


Mometan hab ich eher seltene Übertragungsfehler (der zum erlischte Bild führt) Dank Debug-Pixel kann ich sehen, dass FrameSize-Übertragung gescheitert ist. (auf 0 gesprungen, soll 512 sein)

IMG_20180819_104056.jpg
So sieht UART-Übertragung und ihre UART-Auslesroutine aus.
Man sieht viel Lücke, da AVR wesentlich schneller mit auslesen ist und bricht Auslesroutine ab, wenn der "kein Daten in Ringbuffer" -Flag erkennt.
Alls wird bis auf FrameCount (TPM2-Byte-Framezähler) und eine(Soft-) Register zurückgesetzt.
Bei nächste Ausles-Zyklus wird der anhand Register prüfen. Register steuert dann diese Zyklus , ob der auf Startbyte prüfen soll ,weiter Framebuffer füllen sollen oder auf Stop-Byte prüfen und ggf. alles zurücksetzen.

Zyklische Abbrechen (durch "kein Daten in UART RIngbuffer") von Auslesroutine ist gewollt, sonst geht FPS massiv in Keller und es flackert.
Man sieht gut dass Lücke 2 verschiedene Breite hat. Das kommt von Bitangle-Modulation

Re: Info zu grosse RGB LED Panel

Verfasst: Di 21. Aug 2018, 19:25
von Matt
Zu flackerende Bild wegen Übertragungsfehler.

Ich habe dazu Code kräftig umgebaut und mit UART Interrupt verflechten. Ist besser geworden und extrem schlank (1040byte grosse Code) , aber Flackern bleibt weiterhin.
Ich habe dann mit Hilfe von spezielle Eigenschaft von Tek TDS540 Fehler lokalisieren.

Glitch-Trigger habe ich eingesetzt, der auf Debug-Puls prüft. Pulslänge verrät USART "DataOverrun". (das passiert auch mit P.Fleury-Library)
IMG_20180821_190739.jpg
(ausgelöste Glitch-Trigger)

Boh, mich kotzt das flackerende Bild (mal minutenlang einwandfrei, mal alle paar sekunden flackern, willkürlich)
Auch, wenn ich Code reinschreibt, dass es bei auftreten von Datenüberlauf Register für TPM2 Übertragung zurücksetzen und auf nächste Startbyte warten. Dann sollte es nicht flackern . Es tut weiterhin.

Hab Ihr Tipp, wie ich mit UART besser machen könnte.?

BINGO: wenn Fehler auftritt, dann wird es neuinitaliseren. So ein Müll, deshalb tut meine "Massnahme" mit Register nicht.
Herausgefunden: Habe dann in Initialisierungsroutine eine Debug-Puls gepackt, sonst keiner und Oszi triggert bei flackerende Bild.

EDIT: Nachdem ich Debug-Puls für UART-Fehler wieder einbaut und dann sehe ich interessante an Bildschirm.
IMG_20180821_194357.jpg
Aus irgendnwelchere Grund startet µC neu, daher gibt Überlauf-Fehler von UART. Wohl wird alle Speicherzelle geleert , daher erklärt es mit flackerende Bild.

Re: Info zu grosse RGB LED Panel

Verfasst: Mi 22. Aug 2018, 20:16
von Matt
Auch mit Board mit Atmega 168 und andere Layout macht es weiterhin mit Flackern.
Auch wenn ich ihre USB-UART mit MAX232 und echte serielle Port umgegangen, geht mit Flackern weiter.

Alles ist durch Neustart des µC passiert. Ursache kenne ich noch nicht.
Noch eine Hinweis: µC startet auch unregelmässig neu, wenn es nicht mit Panel verbunden ist.

Main-Code ist nicht dabei, beschränkt nur auf Initialisieren (Port-Richtungsregister, UART, besagte Debug-Puls) und Marko "FB_to_DISP_BAM ()"

Code: Alles auswählen

#include <tpm2.h>

#define Column  32
#define Row		16
#define Pixel	(Column*Row)

#define UART_BAUD_SELECT(baudRate,xtalCpu) (((xtalCpu)+8UL*(baudRate))/(16UL*(baudRate))-1UL)

//BAM-spezifiziert
#define R0  0x00
#define R1  0x40
#define R2  0x80
#define R3  0xC0

#define G0  0x00
#define G1  0x10
#define G2  0x20
#define G3  0x30

#define B0  0x00
#define B1  0x04
#define B2  0x08
#define B3  0x0C


void FB_to_DISP_BAM ();

uint16_t	FrameCount = 0;  
 uint8_t  	FrameBuffer [Row][Column];  // Framebuffer, (column * row ) x 8bit
 uint16_t  	FrameBufferSelect;	// Variabel für  SPI-Senden (Bitschieberei )
 uint8_t 	PreBuffer ;
 uint8_t 	int_count;

// UART-spezifiziert
uint16_t	FrameSize;  
uint16_t 	Trash ;
uint16_t	value;

volatile uint8_t 	tpm2_reg ;
#define noTrash  0x80


// Command-Register
uint8_t Brightness;
uint8_t Gamma;
uint8_t Speed;
uint8_t Programm;
uint8_t StartColor;
uint8_t Timeout;
uint8_t Pixel_;
uint8_t Repetition;
uint8_t StartAdr;

// Framebuffer an Display senden mit Bitangle-Modulation.
void FB_to_DISP_BAM (){
	
	if ((int_count&0x01) ==1) {
		
		PORTD &= ~(1 << PD7);	//  /ENABLE aktiviert
		
		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)]&G2) PORTD |= (1 <<PD4) ;	// wenn 1, dann GRÜN = H
			if (FrameBuffer[(FrameBufferSelect>>5)][(FrameBufferSelect&0x1F)]&B2) PORTD |= (1 <<PD5) ;	// wenn 1, dann BLAU = H
			if (FrameBuffer[(FrameBufferSelect>>5)][(FrameBufferSelect&0x1F)]&R2) 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
		
		
		PORTD |= (1 << PD7);	//  /ENABLE deaktiviert
		// Latch-Puls
		PORTB |= (1 <<PB0) ;			// /Latch auf HIGH
		PORTB &= ~(1 << PB0);  			// /Latch auf LOW
		int_count++;
	}
	
	

	if ((int_count&0x01) == 0) {
		PORTD &= ~(1 << PD7);	//  /ENABLE aktiviert
		
		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)]&G1) PORTD |= (1 <<PD4) ;	// wenn 1, dann GRÜN = H
			if (FrameBuffer[(FrameBufferSelect>>5)][(FrameBufferSelect&0x1F)]&B1) PORTD |= (1 <<PD5) ;  // wenn 1, dann BLAU = H
			if (FrameBuffer[(FrameBufferSelect>>5)][(FrameBufferSelect&0x1F)]&R1) 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
		_delay_ms (2);
		
		//  /ENABLE deaktiviert
		PORTD |= (1 << PD7);	
		// Latch-Puls
		PORTB |= (1 <<PB0) ;			// /Latch auf HIGH
		PORTB &= ~(1 << PB0);  			// /Latch auf LOW
		
		int_count++;
		}
	
	
}



ISR(USART_RX_vect)
/*************************************************************************
Function: UART Receive Complete interrupt
Purpose:  called when the UART has received a character
**************************************************************************/
{
  
    uint8_t data;
    uint8_t usr;
    uint8_t lastRxError;
 
    /* read UART status register and UART data register */ 
    usr  = UCSR0A;
    data = UDR0;
    
    /* */
    lastRxError = (usr & (_BV(FE0)|_BV(DOR0)));


		if (lastRxError) {
			PORTB |= (1 <<PB4) ;			// /Latch auf HIGH
			PORTB |= (1 <<PB4) ;			// /Latch auf HIGH
			PORTB |= (1 <<PB4) ;			// /Latch auf HIGH
			PORTB &= ~(1 << PB4);  			// /Latch auf LOW}	
			FrameSize = 0;
			tpm2_reg =0x11;
		}


			
		// Auf Datenblock-Ende prüfen
		if (data == TPM2_BLOCK_END_BYTE) {
			if (tpm2_reg == 0xAA){ // 
				tpm2_reg = 0x11;
			}
		}
		// von Datenblock zu FrameBuffer stecken
		if (tpm2_reg == 0xFF){
			if (FrameSize ==Pixel ) {
			FrameBuffer[(FrameCount>>5)][(FrameCount&0x1F)] = data ;}
			FrameCount++;
		}
		
		//  FrameSizeL-Byte sichern
		if (tpm2_reg == 0xEE) {
			FrameSize |= (data&0xFF);
			FrameCount =0;
			tpm2_reg = 0xFF;
		}				
		//  FrameSizeH-Byte sichern
		if (tpm2_reg == TPM2_BLOCK_TYPE_DATA) {
			FrameSize = (data<<8);
			tpm2_reg = 0xEE;
		}
		
		// Auf  TPM2-Datenblock-Byte prüfen
		if (data == TPM2_BLOCK_TYPE_DATA) {
			if (tpm2_reg == TPM2_SER_BLOCK_START_BYTE){
				tpm2_reg = TPM2_BLOCK_TYPE_DATA;
			}
			else {tpm2_reg = 0x11; }
		}
		
		// Auf  TPM2-Start-Byte prüfen
		if (data == TPM2_SER_BLOCK_START_BYTE){
			if (tpm2_reg == 0x11){
				tpm2_reg =TPM2_SER_BLOCK_START_BYTE; 
				PORTB |= (1 <<PB4) ;			// /Latch auf HIGH
				PORTB &= ~(1 << PB4);  			// /Latch auf LOW
			}
		}
		
			
		
		
		
		if (tpm2_reg == 0xFF){
			if (FrameSize == FrameCount) {tpm2_reg =0xAA;}
		}
	

		
		///////////////////////////////////
    
 
}

void uart0_init(uint16_t baudrate)
{


	/* Set baud rate */
	if (baudrate & 0x8000) {
		UCSR0A = (1<<U2X0);  //Enable 2x speed
		baudrate &= ~0x8000;
	}
	UBRR0H = (uint8_t)(baudrate>>8);
	UBRR0L = (uint8_t) baudrate;

	/* Enable USART receiver and transmitter and receive complete interrupt */
	UCSR0B = _BV(RXCIE0)|(1<<RXEN0)|(1<<TXEN0);

	/* Set frame format: asynchronous, 8data, no parity, 1stop bit */
#ifdef URSEL0
	UCSR0C = (1<<URSEL0)|(3<<UCSZ00);
#else
	UCSR0C = (3<<UCSZ00);
#endif



} /* uart0_init */


///////////////////////////////  Clearing of Framebuffer  ///////////////////////////////////
void clr_FB(){
	for(int I=-0; I< Pixel; I++){
		FrameBuffer [(I>>5)][(I&0x1F)] = 0x00;
		}
	}

///////////////////////////////   END of Clearing of Framebuffer  ///////////////////////////////////

Re: Info zu grosse RGB LED Panel

Verfasst: Mi 22. Aug 2018, 21:37
von Matt
Ich hab !!


Ich habe 200pf Kondensator an RX Eingang von Atmega und Masse angelötet und Oszi triggert seither nicht auf diese Initialisierung-Puls. Es ist schon 3 Minute her. Es ist nur aus Zufall entdeckt, da es mit Tastkopf an RX-Eingang spürbar weniger oft flackert.

Re: Info zu grosse RGB LED Panel

Verfasst: Mi 22. Aug 2018, 22:02
von ferdimh
Ich wollt gerade schreiben:
Man kann AVRs sehr gut durch kurzzeitige aber heftige Betätigung der CMOS-Schutzdioden zum Reset bringen...
Das hast du dann wohl auch rausgefunden ;-)

Re: Info zu grosse RGB LED Panel

Verfasst: Mi 22. Aug 2018, 22:12
von Matt
Board ist Arduino Nano V3.x. Chinese hat mir paar andersaussehende Board mit 168P drauf mit 328p vermischt . -.-

D.H. USB-UART Wandler und AVR sitzt an gleiche Spannung und Leiterbahnen ist kurz. Es sollte trotzdem nicht passiert, ausser wenn ich lange Kabeln an RX Eingang steckt. (ist bei mir nicht so)

200pf an RX Eingang gilt nur für Fall mit 250.000 Baudrate, Bei Baudrate 115.200 müsste es wohl grösser sein.

Re: Info zu grosse RGB LED Panel

Verfasst: Do 23. Aug 2018, 17:28
von Fritzler
DMA nach GPIO läuft jetzt auch.
Aber nur solange die CPU und der DMA nicht gleichzeitig auf den RAM zugreifen wollen.

Also wenn ich die Bit Angle Buffer einmal berechne und dann per DMA auf die GPIOs ausgebe.
-> schönes statisches Bild wie mit den 3 SPI Übertragungen
(aka der Startbildschirm mit den Dimmstufen in blau)

Sobald ich aber andauernd die Buffer neu berechne flackert das Display.
Der DMA verliert wohl zu oft die Busarbitrierung in der Busmatrix.
Dann gibt der Timer nen CLK aus, aber es kommen keine weiteren Daten -> einmal kurz ist das Bild verschoben.
Komischerweise bekomme ich aber keine FIFO Errors, die kommen erst wenn ich von 11MHz auf 22MHz umstelle.

Bei dicken Cortex-A SoC könnte man jetzt der Busmatrix sagen wer ne höhere Prio auf den SRAM Bus hat, aber nicht beim STM32:
2.1.10 BusMatrix
The BusMatrix manages the access arbitration between masters. The arbitration uses a
round-robin algorithm.
Hier ist wohl das Ende der Fahnenstange der STM32 erreicht.
Ich gebe grade theroetisch Daten für 30 Panel aus, nur so zur Info :geek:
Auch wenn davon nur die Daten für 6 Panel sinnvoll sind.

Also doch mal nen FPGA DevBoard rauskramen.

Re: Info zu grosse RGB LED Panel

Verfasst: Do 23. Aug 2018, 20:36
von Matt
Also,nicht nur ich bin am Ende des Fahnestange . ;-)

FPGA-Aal von mir, Tachyysema HV3 heisst es und kann dir eine Programmer zuschicken.
Lattice nennt ihm Downloadkabeln, hatte damals mehre aus Schrott mit verbrannte Treiber gerettet. Reparatur ist aber eine klacks.


PS: Seit ich 200pf Kondensator eingelötet habe, hat Oszi seit gestern nicht auf initialisierungspuls getriggert. (nur beim Einschalten wird es ausgelöst)


Grüss
Matt

Re: Info zu grosse RGB LED Panel

Verfasst: Mo 27. Aug 2018, 19:12
von Matt
Neues gibt es: Heute hab ich Frambebuffer zurück zum eindimensionale Array definieren (Rechnenzeit etwas sparen, wenigere Programmierungsaufwand)

Ziel: 3bit-RGB (= 512 Farbe, jeder Farbkanal hat nun 8 Helligkeitstufe) und wie erwartet stösst AVR 328p an Grenze.
Ziel erfüllt mit eine Nebenwirkung.
https://www.youtube.com/watch?v=mLhEVlP6niY

Nebenwirkung:
1.)Entweder 250kBaudrate , dann habe ich 65FPS (leicht schwankend wegen UART Interrupt) , allerdings ist Bildübertragungsgeschwindigkeit nur 13 FPS
2.)Oder 500kBaudrate und mehr, dann habe ich ca 40 FPS (flimmert übelst), dafür stimmt Bildübertragungsgeschwindigkeit (25 FPS)

Also: Ich wird AVR Taktfrequenz auf 20 oder 24Mhz erhöhen, wobei 24Mhz schon ausser Spezifikation ist. (ich bin zuversichtlich, dass 328p mit 24Mhz stabil läuft)

Re: Info zu grosse RGB LED Panel

Verfasst: Di 28. Aug 2018, 18:40
von Matt
Heute auf Arbeit habe ich Theorie mit "TTL" Grab gemalt. Ich lagerte da Framebuffer , SPI und Bitangle-Modulation zu Hardware aus.
Rechnerisch müsste ich schon Fast-TTL oder CPLD mit sauschnelle SRAM nutzen (max 10-12ns Zugriffzeit)
Alles nur wenn ich SPI-Taktfrequenz von 25Mhz ausnutzen will, mit halbe Taktfrequenz ist es weitaus einfacher zu schaffen.
Dann füllt AVR /STM SRAM mit Daten auf, währendessen MSB-Bit auf Panel angezeigt wird. Da hat µC mehre Mirkosekunden Zeit, den SRAM aufzufüllen, da schafft AVR auch schon mit vorab-Sortieren von Byte (wegen 4x4 Cluster)

Schmierblatt wird ich morgen zeigen. Ich wird es warscheinlich nicht umsetzen. Da ich schon mit 3bit-RGB irgendwie zufrieden bin.

Re: Info zu grosse RGB LED Panel

Verfasst: Sa 1. Sep 2018, 16:17
von Matt
auawei , vergessen Schmierblatt einzuscannen.. egal.

Wichtiger ist: Ich habe Halter für Panel zusammengeschweisst und am ende mit chice goldene Hammerschlaglack lackiert. (wärendessen kämpfe ich mit Ameisenplage in Werkstatt bei Eltern , gnarf, in ne Schublade ist Ameisenest !!)


Meine Schweiss-Fähigkeit ist immernoch zu wünschen übrig.

Re: Info zu grosse RGB LED Panel

Verfasst: So 2. Sep 2018, 08:17
von barclay66
Das Gold reißts locker wieder raus!

Re: Info zu grosse RGB LED Panel

Verfasst: Mo 3. Sep 2018, 16:44
von Fritzler
Weis ganich was du hast, das sieht doch super aus.
Mal abgesehen davon, dass es doch eh HINTER den Panel verschwindet.

Ich werd die Panels wohl mit Aluprofil zusammenschrauben.

Wo bleibtn das TTL Grab? :mrgreen:

Re: Info zu grosse RGB LED Panel

Verfasst: Mo 3. Sep 2018, 17:12
von Matt
http://fs5.directupload.net/images/180903/rlzd49k3.jpg
"TTL Grab "
http://fs1.directupload.net/images/180903/m4myzx53.jpg
" TTL Grab , Steuerung"
Mittweile würde ich es nicht so machen.. aber das ist wie gesagt nur Theorie, der ich nicht umsetzen werde(mir ist eines Tag auf Arbeit langweilig)
Bei TTL Grab geht bis 1024 Pixel zyklische Latch-Ansteuerung, darüber wird mit 25Mhz SPI sehr eng bei kleinste BAM-bit (52µs).
Da sollte man Enable-Ansteuerung nutzen.
Jetzt erkenne ich, dass meine Rechnung mit Zyklusszeit von kleinste BAM -Bit auch falsch ist. Egal, denn es wird nicht umgesetzt.

Erste Link zeigt Bild, deren untere Hälfte Berechnung zeigt, wie es um Timing von SRAM ging. Schon recht hart ! Selbstverständlich beträgt SPI-Takt 25Mhz.
Den kommt in Ablage, der ich wohl nicht mehr daraus was zusammenlöten.
_____________________________________________________________________
IMG-20180829-WA0007.jpg
Atmega 328p ist auf 24Mhz Quarz gequält und meine Hirnknoten ist gelöst.
Jetzt läuft der mit 8Bit RGB ! (ich müsste doch einfach nur während SPI Übertragung /ENABLE-Signal zurücksetzen)
Dafür ist Display wesentlich dunkler geworden. Panel hat aber immernoch dermass viel Helligkeitsreserve, denn ich habe PWM auf 30/255 hochgeschraubt, sodass es wie vorher hell ist.
IMG_20180830_192531.jpg
Enable-Signal, mit reparierte Tek 468 von Roechricht gemesst :lol: (der mit Mostek ROM-Tod )


Kleine Verbesserung gibt allerdings noch: ich müsste BAM-modulation von SPI-Übertragungszähler zu Interrupt-Zähler verbinden ,sonst schwankt Helligkeit wegen Interrupt durch UART. Wenn UART dazwischenfunkt , bei SPI -Übertragung, dann braucht SPI länger (ca 15%,da merkt merkt deutlich als leichte Flackern)





Zu Ständer, es ist mittweile montiert und Bestellung an (Ex-)Angelika ist raus.
Netzteil wird ich wohl flache alte 300W PC Netzteil mit 25A auf 5V Schiene nehmen.
IMG-20180902-WA0005.jpg
_________________________________________________________________________

Ne Info:
Ich bin fündig, was um Stromstecker anging.
https://www.reichelt.de/jst-buchsengeha ... 85109.html
https://www.reichelt.de/jst-crimpkontak ... dr::185109

Re: Info zu grosse RGB LED Panel

Verfasst: Mo 10. Sep 2018, 10:08
von Fritzler
Hmpf!
Jetz wollt ich hier auch reinschreiben welche Stecker fürn Strom das sind und du schiebst das hier vor mir frech als edit rein :lol:
JST VH3,96mm kann ich bestätigen.

Hab ich per Zufall rausgefunden, weil der Anschluss der Akkus unserer Messgeräte passend aussah und auch passte.
Allerdings sind die Reicheltpreise etwas unverschämt, 10cent pro Kontakt, weil man die einzeln kaufen muss statt nem 100er Abschnitt für 1€ oder so.
Beim Ali gibts die Kontakte direkt als 100er Bündel an 20cm 0,5mm² (AWG iwas) drangecrimpt.
Das Angebot kann ich gerne nochmal raussuchen.
Jedenfalls hab ich mich dazu entschieden es beim anlöten zu lassen, die Kabel sind dann an der Kupferschiene abschraubbar wenns mal ab muss.
Oder die Aluwinkelprofile als Stromschiene nutzen? 3mm Dick und als 35x35 sollte das auch wenig Innenwiderstand mitbringen.

Den Schaltplan hab ich im FPGA so ähnlich geplant.
Durch die Nutzung vom internen BlockRAM wirds aber eher keine Timingprobleme geben, nur das Problem ob genug BlockRAM vorhanden ist. (also nix neues)
Im Blockram liegen die Daten dann schon vorsortiert wegen den 4x4 Clustern.
Die Vorsortierung übernimmt eine kleine Hardwareschaltung beim Reinschreiben in den BlockRAM, dann brauch ich keine fette CPU mehr.
Die Daten werden von einem STM32F4 kommen und zwar per QuadSPI im langen Zeitraum des längsten Bitangles.
(Oder gleich ArtNet als Hardwarestatemachine basteln? Is ja nur UDP)
Dafür muss ich meine Bitangles nochmal umdrehen, denn momentan übertrage ich zuerst den Längsten.
Das muss ich jetzt zuletzt machen, damit alle Daten durch sind bevor was neues reingeschrieben wird.
Die Bitangle Bits landen nicht im RAM, die werden immer live erzeugt um 50% RAM zu sparen (8Bit pro Pixel vs 12Bit).

Durch das Interleaving auf dem SPI zu den Modulen wird es einen zentralen Starttimer geben, dessen Auslösewerte sind ja durch die STM32 Experimente bekannt.

Henry hat mir vorgeschlagen 74ABT245 als Treiber und Pegelwandler zu nehmen, die sind noch shcneller als 74ACT245.
1ns Propdelay statt 3,8ns :shock:
Sowie bis zu 60mA können die am Ausgang Treiben und bei Mouser sind die auchnoch günstiger als ACT!

Re: Info zu grosse RGB LED Panel

Verfasst: Mo 10. Sep 2018, 16:14
von Matt
Bringt nicht wirklich, da du warscheinlich alle Signal über Treiber schickst. Daher ist Verzögerung kompensiert. ;-)
Ist der mit BiCMOS ? *Datenblatt gucken* Ja, der ABT hatte mich damals geägert, dass der Ausgang nicht auf 5V hochkommt. (Ihre High-Latte reicht nicht mehr als 3,7V )

Also, du und ich denke mittweile ähnlich, wie man es lösen kann.
Mit BlockRAM, könntest du meine FPGA-Aal dafür nutzen ? (mittweile schreibe ich das zu oft)
Nach meine Berechnung geht popelige AVR locker mit RAM-füllen und (wegen 4x4 Cluster) sortieren (dafür 11 Leitung, 8 ist Datenleitung)
Einzige Limit: 2kb SRAM bei Atmega328p , d.h. max 512 Pixel.

Ich fand mittweile Grund für bescheuerte 4x4 Cluster: wenig Aufwand für Layout von Platine (somit auch EMV-Gründe, kürzere Leitung zu Treiber ist besser)



Ja, das Kontakt ist reichlich teuer, aber es ist einmalige Sachen und einige Leite weiss, wieviel ich hochwertige Crimpzange besitze (Harting und Molex).
Daher ist es kein Problem und habe gestern Stromversorgung zusammen gecrimpt. Es ging schnell und gut, dank gute Werkzeug.

Grüss
Matt

Re: Info zu grosse RGB LED Panel

Verfasst: Mo 10. Sep 2018, 20:17
von Matt
OT

Eine Hinweis: ich wird meine HEX-Daten für 2x Panel (32x16) mit TPM2 Potokoll & 0,5MBaud veröffentlichen. (noch mit SPIzähler für Bitangle-Modulation)
Allerdings erst nach MakerFaire. (d.H. Nächste Wochen)

Grüss
Matt

Re: Info zu grosse RGB LED Panel

Verfasst: Di 11. Sep 2018, 12:13
von Botanicman2000
Hallo Matt


welche Abmessungen hat denn das Display?

Gruss Uwe

Re: Info zu grosse RGB LED Panel

Verfasst: Di 11. Sep 2018, 12:19
von Fritzler
Er hat wohl 4x2 gebaut.
Ein panel hat 19,2x19,2cm²

Also 76,8x38,4cm²

Re: Info zu grosse RGB LED Panel

Verfasst: Di 11. Sep 2018, 12:26
von doofi
Sorry für das nitpicking, aber das "Quadrat" gehört da nicht hin...
Ansonsten natürlich einen Heidenrespekt für dieses Hardcoregefrickel!!

Re: Info zu grosse RGB LED Panel

Verfasst: Di 11. Sep 2018, 12:47
von Fritzler
Wo solln das sonst hin @ doofi?

Vor allem gilt es zu bedenken, dass ein Panel 12A bei 5V zieht.
Das sind bei 8 Panels mal eben 96A wenn alle Pixel weiß sind.
Oder eben auch 480W an LED, das ist HELL!

Re: Info zu grosse RGB LED Panel

Verfasst: Di 11. Sep 2018, 12:52
von doofi
Fritzler hat geschrieben:Wo solln das sonst hin @ doofi?
In Deinem Fall gar nirgends.
Wenn dann "
19,2cm * 19,2cm = 368,4 cm² "

1000x sorry und nicht persönlich nehmen; ich kann manchmal nicht anders.

Edit:
lol. jetzt habe ich mich selber vertan.
368,64 cm²

Re: Info zu grosse RGB LED Panel

Verfasst: Di 11. Sep 2018, 12:55
von doofi
Fritzler hat geschrieben: (...)
Das sind bei 8 Panels mal eben 96A wenn alle Pixel weiß sind.
Oder eben auch 480W an LED, das ist HELL!
Wie geil. "Audience blinder" mit RGB.

Re: Info zu grosse RGB LED Panel

Verfasst: Di 11. Sep 2018, 14:14
von xoexlepox
"Audience blinder" mit RGB.
Ich vermute mal, mit der "richtigen" RGB-Musterfolge haut dir dein "Audience" ab, oder fängt an zu kotzen -> Ggf. auch als "Abwehr" einsetzbar?

Re: Info zu grosse RGB LED Panel

Verfasst: Di 11. Sep 2018, 15:46
von doofi
Da hat die USA doch mal damit rumexperimentiert. Bedazzler oder so hieß das Gerät glaub ich.