Info zu grosse RGB LED Panel

Der chaotische Hauptfaden

Moderatoren: Heaterman, Finger, Sven, TDI, Marsupilami72, duese

Matt
Beiträge: 6084
Registriert: So 24. Aug 2014, 21:22

Info zu grosse RGB LED Panel

Beitrag von Matt »

Moin Leute

Einige Leute hat es auf Treffen bekommen, grosse LED Panel von Ludwig. (es gibt 2 Version, einer ist quadratisch und andere ist Quader)
Wir gehen nur quadratische Panel an.

Ich habe es zum laufen gebracht.
Kleine Warnung: der braucht unheimlich viel Strom auf 5V Betriebsspannung. ( ich habe schon 3,1A bei ca 30% aktive Pixel erreicht)
Dafür ist es abartig hell.


Treiber ist ST2221C von SiTi
http://www.siti.com.tw/product/spec/LED ... -A.004.pdf
Jeder Farbkanal hat eigene SPI Kanal.
Eine Panel hat 16x16 Pixel (RGB) und ist in 4x4 Cluster aufgeteilt.

Beschaltung ist auf Platine, allerdings ist diese Pfostenstecker mit Schrift für Beschaltung Ausgang, daher bitte an gegenüberliegende Pfostenstecker anschliessen (hat exkat gleiche Beschaltung wie diese beschriftete Ausgang, eben Eingang)

Hier Code für eine Panel , wo es einfach 2x 4stellige Zahl angezeigt wird und gleichzeitig hochgezählt wird.
Ist eilig geschrieben , aus paar Projekt geschnappt (daher findest du einige Verbesserungspotenzial und Ungereimheit (z.B. MAX504)

Code: Alles auswählen

#include <avr/io.h>
#include <util/delay.h>
#include <stdint.h>

/// ATMEGA 328p

#define ENABLE PD7 
#define LATCH PB0 
#define CLOCK PB1 

#define ROT PD6 
#define GRÜN PD5 
#define BLAU PD4 







void sendSPI (uint16_t SPIdata);

	uint16_t count = 0;
	uint16_t value ;
		
	uint16_t  	SPIstring [16];
	uint16_t 	SPIbuffer = 0;
	uint16_t 	SPIstring_count;
	
	uint8_t		bcd [5];
		


////////////////////////////////////////   M A I N   /////////////////////////////////////////////
int main(void)
{
    
    DDRD = 0xF0;		// PD0-3 als Eingang, PD4-7  als Ausgang setzen
    DDRB = 0x0F;		// PB0-3 als Ausgang, PD4-7  als Ausgang setzen
	PORTD = 0x0F;		// Pullup für PD0-3 aktivieren.
	// Initialisierung des LED
	PORTB |=  (1<<LATCH);	// ENABLE
	
	count = 0;
	
	
//////////////////////MAIN Schleife ///////////////////////////				
    while(1) 
	{
	_delay_ms (250); 		// Zyklusgeschwindigkeit von Hauptprogramm bestimmen.
	
	count++;
	value = count;
	
	bcd[0] = value % 10;    value = value/10;
	bcd[1] = value % 10;    value = value/10;
	bcd[2] = value % 10;    value = value/10;
	bcd[3] = value % 10;    value = value/10;
	bcd[4] = value % 10;    
	

	LED_putC (bcd[3]);
	LED_putC (bcd[2]);
	LED_putC (bcd[1]);
	LED_putC (bcd[0]);
	LED_putC (bcd[3]);
	LED_putC (bcd[2]);
	LED_putC (bcd[1]);
	LED_putC (bcd[0]);
	SPIstring_count = 0;
	
	
	
	PORTD |=  (1<<ENABLE);	// ENABLE
	sendSPI (SPIstring [0]);
	sendSPI (SPIstring [1]);
	sendSPI (SPIstring [2]);
	sendSPI (SPIstring [3]);
	sendSPI (SPIstring [4]);
	sendSPI (SPIstring [5]);
	sendSPI (SPIstring [6]);
	sendSPI (SPIstring [7]);
	sendSPI (SPIstring [8]);
	sendSPI (SPIstring [9]);
	sendSPI (SPIstring [10]);
	sendSPI (SPIstring [11]);
	sendSPI (SPIstring [12]);
	sendSPI (SPIstring [13]);
	sendSPI (SPIstring [14]);
	sendSPI (SPIstring [15]);
	
	
	
	
	
	
	
	/*
	setSPI (0x5552);	// "0" oben
	setSPI (0x2232);	// "1" oben
	setSPI (0x2452);	// "2" oben
	setSPI (0x2452);	// "3" oben
	
	
	
	setSPI (0x0255);	// "0" unten
	setSPI (0x0722);	// "1" unten
	setSPI (0x0712);	// "2" unten
	setSPI (0x0254);	// "3" unten
	
	
	
	
	setSPI (0x7554);	// "4" oben
	setSPI (0x3117);	// "5" oben
	setSPI (0x3116);	// "6" oben
	setSPI (0x2447);	// "7" oben
	
	
	
	
	setSPI (0x0444);	// "4" unten
	setSPI (0x0344);	// "5" unten
	setSPI (0x0255);	// "6" unten
	setSPI (0x0112);	// "7" unten

	
	setSPI (0x2552);	// "8" oben
	setSPI (0x5552);	// "9" oben
	setSPI (0x0000);	// " " oben
	setSPI (0x0220);	// ":" oben
		
	setSPI (0x0255);	// "8" unten
	setSPI (0x0346);	// "9" unten
	setSPI (0x0000);	// " " unten
	setSPI (0x0220);	// ":" unten

*/
	

	PORTD &=  ~(1<<ENABLE);	// ENABLE
	//_delay_us (250); 
	//PORTD ^=  (1<<ENABLE);	// ENABLE
	

	}

}
/////////////////////////////////   E n d    o f   M A I N   /////////////////////////////////////


////////////////////////////////   BCD to  bitmap converting  ///////////////////////////////////

void  LED_putC (uint8_t putChar ){
switch (putChar){
		case 0: SPIstring[SPIstring_count] = 0x5552; SPIstring[SPIstring_count+4] = 0x0255; break;
		case 1:	SPIstring[SPIstring_count] = 0x2232; SPIstring[SPIstring_count+4] = 0x0722;	break;
		case 2:	SPIstring[SPIstring_count] = 0x2452; SPIstring[SPIstring_count+4] = 0x0712;	break;
		case 3:	SPIstring[SPIstring_count] = 0x2452; SPIstring[SPIstring_count+4] = 0x0254;	break;
		case 4:	SPIstring[SPIstring_count] = 0x7554; SPIstring[SPIstring_count+4] = 0x0444;	break;
		case 5:	SPIstring[SPIstring_count] = 0x3117; SPIstring[SPIstring_count+4] = 0x0344;	break;
		case 6:	SPIstring[SPIstring_count] = 0x3116; SPIstring[SPIstring_count+4] = 0x0255;	break;
		case 7:	SPIstring[SPIstring_count] = 0x2447; SPIstring[SPIstring_count+4] = 0x0112;	break;
		case 8:	SPIstring[SPIstring_count] = 0x2552; SPIstring[SPIstring_count+4] = 0x0255;	break;
		case 9:	SPIstring[SPIstring_count] = 0x5552; SPIstring[SPIstring_count+4] = 0x0346;	break;
		}
		SPIstring_count++;
		if (SPIstring_count &0x04) SPIstring_count = SPIstring_count + 4; 
	}
///////////////////////// END  of  Data to  bitmap converting  ///////////////////////////////////



/////////////////////////////////SPI-STRING////////////////////////////////////////////
// 		Hier wird 16bit-Daten & Takt & /CS an SPI-PORT rausschicken & gesteuert. 
void sendSPI (uint16_t SPIdata){
	SPIbuffer = SPIdata ;	// Daten an MAX504 anpassen, 2 bit nach links verschieben
	
	int ii=1;
	while(ii <= 16) {				// 16mal wiederholen.
		ii++;
		PORTB &= ~(1 << PB1);		// Takt fallende Flanke
		_delay_us (1);				// Verzögerung von 1µS
		PORTD &= ~(1 << PD4);		// MOSI auf LOW
		PORTD &= ~(1 << PD5);		// MOSI auf LOW
		PORTD &= ~(1 << PD6);		// MOSI auf LOW
		if (SPIbuffer &0x0001) {		// wenn 1, dann MOSI = H
			PORTD |= (1 <<PD4) ;        
			PORTD |= (1 <<PD5) ;        
			PORTD |= (1 <<PD6) ;}        
		SPIbuffer = SPIbuffer >> 1 ;	// Byte um 1 nach links verschieben
		PORTB |= (1 <<PB1) ;		// Takt steigende Flanke
		_delay_us (1);				// Verzögerung 1µS
		}
		
	PORTD &= ~(1 << PD4);			// MOSI auf LOW
	PORTD &= ~(1 << PD5);			// MOSI auf LOW
	PORTD &= ~(1 << PD6);			// MOSI auf LOW
	
	
	PORTB |= (1 <<PB0) ;			// /Latch auf HIGH
	_delay_us (2);				// Verzögerung 1µS
	PORTB &= ~(1 << PB0);  			// /Latch auf LOW
	}
//////////////////////////////END of SPI-STRING////////////////////////////////////////////////		
	
Zuletzt geändert von Matt am Di 31. Jul 2018, 21:27, insgesamt 1-mal geändert.
Benutzeravatar
Fritzler
Beiträge: 12578
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Info zu grosse RGB LED Panel

Beitrag von Fritzler »

Hehe, dann kann ich ja endlich mal den QuadSPI von den STM32 nutzen :mrgreen:

Danach pack ich gleich die große Keule aus:
mplayer Plugin läuft auf Linux aufm ARM Kern eines ZYNQ7010 SoC FPGA und der FPGA Teil steuert die Panels an.
Nen mplayer PLugin hab ich schonmal fürs Weltherrschaftsdisplay geschrieben.
Da gibt dann eben nicht mehr über TCP aus, sondern direkt über den AXI Bus des ARM Prozessors zum FPGA rein.
Ich strebe 10Bit RGB PWM an und 30Hz Bildwiederholrate.

Mehr wird wohl nicht gehen bei 25MHz maximal Takt der LED Treiber:
16spalten * 16zeilen * 30Hz * 1024 PWM Stufen = 7,86MHz
Da kann ich dann noch 3 hintereinander hängen, dann is Schluss.
Matt
Beiträge: 6084
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitrag von Matt »

Korrekt, dass Helligkeit (pixeleinzeln) nur durch mehrfache Übertragen von Bild (je dunkler, wenigere aktive Bit, am besten auch noch verteilt (Flimmern)) beeinflussbar ist.

Mometan ist mit meine Code stumpf RGB gleich angesteuert. Für Anfang reicht es.

Grüss
matt
Benutzeravatar
RMK
Beiträge: 5360
Registriert: Di 20. Jan 2015, 14:59
Wohnort: östlich von Stuttgart

Re: Info zu grosse RGB LED Panel

Beitrag von RMK »

Hallo,
Matt hat ein paar Fotos in der WA-Gruppe gezeigt mit der Bitte diese auch in den Thread zu stellen.

Bild
Bild
Bild
Matt
Beiträge: 6084
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitrag von Matt »

Danke schonmal


Bild mit Netzgerät, das zieht der mit ~0,6A bei ca16% Puls an Enable-Eingang (PWM gedimmt)

Grüss
matt
Zuletzt geändert von Matt am Mi 1. Aug 2018, 16:10, insgesamt 2-mal geändert.
urmel
Beiträge: 1035
Registriert: Di 22. Apr 2014, 13:47
Wohnort: Karlsruhe & Wittlingen

Re: Info zu grosse RGB LED Panel

Beitrag von urmel »

@Ludwig, kannst du noch mehr von den Dingern besorgen? Gerne auch eine größere Portion...
Benutzeravatar
Chrissy
Beiträge: 1078
Registriert: So 11. Aug 2013, 16:46
Wohnort: Dresden JO61ua
Kontaktdaten:

Re: Info zu grosse RGB LED Panel

Beitrag von Chrissy »

Ja, kann ich. Der Schrotter hier in Dresden hat noch drei Gitterboxen voll. Hat bisher 1€ pro Stück genommen und es sieht bisher so aus, als würde er die noch eine Weile haben. Wir hatten im ersten Schwung 100 Stück besorgt, das war etwa eine fünftel Gitterbox. Allerdings wär es mir ganz lieb, wenn ich das nicht alles selbst in der Gegend rum schicken müsste, denn die Pakete mit den Dingern werden ab so etwa 10 Modulen pro Paket schon recht groß. Wenn wir da einen größeren Posten von holen würden, wäre es gut, wenn jemand mit Auto da wäre.

@Finger, @RMK: Sind eure Pakete schon angekommen?

Viele Grüße,
Ludwig
Matt
Beiträge: 6084
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitrag von Matt »

Und da ich Reisbrennenbedingt sowieso Dresden an diese Wochenende vorbeikommen, da kann ich meine Nissan damit vollmachen.
Ohne Scheiss kann ich damit 100€ pro Module verdienen, wenn ich so ne bescheueerte JDM -Zubehör damit bauen ( Rückleute mit unsinnige Funktion und JDM-Junkie fährt darauf ab. )

Aber diese Nissan hat kleine Kofferraum. (Ich denke sogar, kleiner als Mini..)
Zuletzt geändert von Matt am Mi 1. Aug 2018, 19:13, insgesamt 1-mal geändert.
Benutzeravatar
Chrissy
Beiträge: 1078
Registriert: So 11. Aug 2013, 16:46
Wohnort: Dresden JO61ua
Kontaktdaten:

Re: Info zu grosse RGB LED Panel

Beitrag von Chrissy »

Der Schrotter hat Wochentags bis 17:00 auf. Da könntest du morgen oder Freitag also hin fahren (ich würde wahrscheinlich auch mit kommen). Wenn du magst, kannst du morgen Abend oder Freitag auch im Turmlabor vorbei kommen. Alles Weitere per PN oder Whatsapp.

Ansonsten kann ich mir ja mal am Wochenende dein Rennen auf dem Lausitzring von oben anschauen, mein Flugplatz ist dort daneben und ich hab mich breit schlagen lassen, Samstag Windenfahrer zu machen, da komme ich vielleicht auch mal in die Luft...
Benutzeravatar
Landjunge
Beiträge: 451
Registriert: Mi 12. Jul 2017, 19:28
Wohnort: bei Uelzen / NDS

Re: Info zu grosse RGB LED Panel

Beitrag von Landjunge »

Bis vor kurzem haben wir auch die ST2221C-1 auf der Arbeit verwendet. Der neue Chip bzw. die Ersatztype ist ein DM13C

PS: Aufm Reisbrennen war ich 2012 auch in Oschersleben. Habe da mit meinem VW Golf den Leistungsprüfstand gefoltert :D

Bild
Benutzeravatar
RMK
Beiträge: 5360
Registriert: Di 20. Jan 2015, 14:59
Wohnort: östlich von Stuttgart

Re: Info zu grosse RGB LED Panel

Beitrag von RMK »

ludwig hat geschrieben: @Finger, @RMK: Sind eure Pakete schon angekommen?
Viele Grüße,
Ludwig
ja, vielen Dank, ist angekommen - ich hatte die allerdings tatsächlich kleiner erwartet. :shock:

macht nix, wir machen was draus. :)
urmel
Beiträge: 1035
Registriert: Di 22. Apr 2014, 13:47
Wohnort: Karlsruhe & Wittlingen

Re: Info zu grosse RGB LED Panel

Beitrag von urmel »

ludwig hat geschrieben:Der Schrotter hat Wochentags bis 17:00 auf. Da könntest du morgen oder Freitag also hin fahren (ich würde wahrscheinlich auch mit kommen). Wenn du magst, kannst du morgen Abend oder Freitag auch im Turmlabor vorbei kommen. Alles Weitere per PN oder Whatsapp.

Ansonsten kann ich mir ja mal am Wochenende dein Rennen auf dem Lausitzring von oben anschauen, mein Flugplatz ist dort daneben und ich hab mich breit schlagen lassen, Samstag Windenfahrer zu machen, da komme ich vielleicht auch mal in die Luft...
Ich muss mal gucken, aber ggf kommen wir da Ende August mit einem nur teilweise beladenen Sprinter vorbei, das wäre eine Option.
Benutzeravatar
Fritzler
Beiträge: 12578
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Info zu grosse RGB LED Panel

Beitrag von Fritzler »

ÖRGHS, das kleine Detail von Matt mit den 4x4 Clustern is ja wirklich leicht ekelig.

Das wird interessant das im FPGA oder zum testen erstmal in C Umzusetzen.
Also die Überführung vom Framebuffer in den Bitanglemodulationsbuffer welcher Seriell rausgeschoben werden kann.
Vor allem fängts unten rechts an und Framebuffer sind eher linear von oben links an aufgebaut :geek:

Hier mal als Video wo ich linear das Bit imemr um eins weiterschiebe:
https://www.youtube.com/watch?v=QPvpTJA-_BQ

Testaufbau:
Bild

edit:
1 Panel mit 16x16 px zieht mehr als 10A wenn alles an ist.
Bzw bei 10A rennt mein NT erstmal in dei Strombegrenzung. :lol:
Dabei ist es verdammt HELL, daher werde ich wohl eine globale Dimmung vorsehen.
urmel
Beiträge: 1035
Registriert: Di 22. Apr 2014, 13:47
Wohnort: Karlsruhe & Wittlingen

Re: Info zu grosse RGB LED Panel

Beitrag von urmel »

Ich würde das wohl mit einem Mapping-Buffer in RAM lösen, also den Frame in einen dem Panel entsprechenden Buffer umkopieren, auch wenn das Zeit frisst.
Ich würde vermuten, dass die verfügbaren Platinchen für LED-Wände das sehr ähnlich handhaben. Bringt halt effektiv einen Frame Latenz rein.
Benutzeravatar
Fritzler
Beiträge: 12578
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Info zu grosse RGB LED Panel

Beitrag von Fritzler »

So hab ichs ja auch vor.
Frisst eben Rechenzeit und zudem muss ich das für jeden Subframe machen (Bit Angle Modulation).
Mal gucken ob ich da mit dem Bitbanding bei den Cortex-M noch etwas Zeit sparen kann.
Glücklicherweise schafft einem "der größte Bitangle" etwas Zeit zum rumrechnen.
Da muss ich das Bild dann 2 mal vorhalten, einmal als Framebuffer und einmal als 8 Stück Bit Angle Buffer (welche zusammen so groß sind wie der Framebuffer).

Beim FPGA wirds dann lustig die BlockRAM Adressen zu berechnen.


Übrigens:
Durch die Flachbandkabel gehen wohl auch die 5V obwohl viel mit "NC" beschriftet ist.
So hatte ich die obere Hälfte des Panels erst mi dem Flachbandkabel angeschlossen, aber es leuchtete schon :shock:
Es müssen auch alle 3 5V Pins verbudnen werden, die sind getrennt in:
5V Power linke Pixel
5V Power rechte Pixel
5V Logik
Benutzeravatar
Fritzler
Beiträge: 12578
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Info zu grosse RGB LED Panel

Beitrag von Fritzler »

SCHEISS TANTALS!
Die ganze Bude stinkt!

Hab das Panel grade eingeschalten zum Testen: KRAWUMMS und STICHFLAMME, Rauchschwaden ziehen durch die Wohnung.
Ein Tantal hat den Hindenburg geübt. und sich dabei kurzgeschlosse, also hat das 10A NT noch die arme 4A Spule mit abgefackelt.

Es empfiehlt sich also die Tantals zu ersetzen gegen Elkos bevor man die Dinger in Betrieb nimmt.

Bild
Bild
Matt
Beiträge: 6084
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitrag von Matt »

Schon in meine Code arbeite ich mit Framebuffer , der andere Konzept hat und noch anders benannt wurde. (SPIstring !)

Allerdings ist Charaktererzeugung noch frickelig (4x8 Zeichensatz ist grütze, wird auf 6x8 umbauen, dafür macht 4x4 cluster es nicht leichter :roll: )
Erst wenn es mit Füllen von Framebuffer feritig ist, dann kommt Daten aus SPI zu Display. (in meine Code ist SPI noch *soft*)

Ganze Geschichte mit Framebuffer ist wegen 4x4 Cluster gezwungen.

Das mit fälschliche Bezeichnung von NC ist mir auch aufgefallen, als ich Flachbandkabel angeschlossen habe,leuchtet andere Hälfte auch mit.
(Ich dachte anfangs, dass 5V einfach über LED Platine durchverbunden ist.)


Also, am Freitag war ich mit Ludwig bei Schrotter und habe alle kleinere RGB Panel mitgenohmen, der meine Kritik erfüllt.
Max einstellige AnzahlLED beschädigt, dafür schwarze Plastik gut erhaltet.
Oder max paar LED beschädigt, dafür gewissenmass Plastik-Beschädigung.
(Alle besteller bekommen von mir Nachrichten und Mail)

Ich habe auch paar andere Format eingeladet, den behalte ich aber.
Zuletzt geändert von Matt am So 5. Aug 2018, 13:15, insgesamt 1-mal geändert.
xanakind
Beiträge: 12537
Registriert: So 11. Aug 2013, 21:55

Re: Info zu grosse RGB LED Panel

Beitrag von xanakind »

Matt hat geschrieben:dafür macht 4x4 cluster es nicht leichter :roll: )
Ich vermute, diese Panels stammel aus alten Videowänden.
Vorallem, wenn die beim Schrott in solch Grossen Mengen liegen.
Benutzeravatar
Fritzler
Beiträge: 12578
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Info zu grosse RGB LED Panel

Beitrag von Fritzler »

@Matt
du darfst eben nicht glech 2 Dinge af einmal machen, dann wirds eklig im Code ;)
Mach dir eben nen Linearen Framebuffer und da malst du rein, dann kommt der "Clusteringlayer".
Der macht den SPI Bistream für die Panel schmackhaft.

Hast du mal nen Bild von der Rückseite der 16x32 Panel für mich?
Und da hab ich doch glatt verpennt bei dir ne Bestellung aufzugeben :/

@xana
Jo die scheinen sehr alt zu sein.
Kein Multiplexing und keine RGB LEDs, sondern getrennte.
Matt
Beiträge: 6084
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitrag von Matt »

quaderformige (ist eher 8x16 ) Panel ist für mich unattraktiv,denn eine Pixel (2x Rot, Grün, Blau) ist riesig, ca 2x2cm.
Treiber ist anders, MBI5024, aber ansteuern ist auf erste Blick identisch wie ST2221C.

Das mit Code, ich schrieb schon: hohe optimierungspotenzial.
Ich würde auch mittweile mit progmem oder ähnlich arbeiten, der dann mit maskisierte Zähler (oder ähnlich) ihm auswählen und zu SPI schicken.
Dann hab ich, wie du gesagt hast, lineare Framebuffer, der ich dann einfach direkt rumwühlen kann.

Jap, der ist irgendwie alt, aber geil zum basteln :D

Grüss
Matt
Benutzeravatar
Fritzler
Beiträge: 12578
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Info zu grosse RGB LED Panel

Beitrag von Fritzler »

Aso?
Die großen Panels sind nicht einfach die kleinen Panels in doppelt so groß?
Dann hat sich das Projekt für mich erstmal erledigt, für nur 32x32 an Displaygröße treib ich den Aufwand nicht.
(4+1 Panels hab ich eben grade hier liegen)

Wenn die Großen 16x32 gewesen wären, dann hätt ich damit gerne ein 192x112 Display gebaut gehabt.
Mit nur 108 Zeilen angesteuert wär das dann pro Seite 1/10 FullHD zum guten skalieren.
Matt
Beiträge: 6084
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitrag von Matt »

Nö, ist wirklich 1dpi oder so :lol:

Darum schrieb ich "unattraktiv"

EDIT: Hersteller ist warscheinlich: https://www.act-thielmann.at/led-videow ... rmationen/
Denn grosse unattraktive LED Panel hat gleiche Mechanik wie paar Panel aus diese Link.
Matt
Beiträge: 6084
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitrag von Matt »

so, neues gibt es: lineare Framebuffer für 16x32 realisiert.. Code ist skalierbar, allerdings müsste Bitverschieberei neu berechnet werden.

https://www.youtube.com/watch?v=_AJ3Xvvj5Uo
Zuletzt geändert von Matt am Di 7. Aug 2018, 20:56, insgesamt 1-mal geändert.
Benutzeravatar
Fritzler
Beiträge: 12578
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Info zu grosse RGB LED Panel

Beitrag von Fritzler »

Sieht gut aus!

Da ich übrigens von Matt 10 Panels bekomme und von Ludwig nochmal 3, ist das Projekt wieder aktiv!
Vielen Dank dafür schonmal.

Momentan sind alle 3 SPI mit DMA dabei den RGB Pixelstream ins Display zu schieben.
Funktioniert aber blöderweise erstmal nur bis 10MHz Takt, dann gibts Pixelfehler.
Obs Reflexionen sind oder der 74HCT245 als 3,3V->5V Pegelwandler abschmiert kann ich dank kaputtem Tastkopf grade nicht sagen.

Mit dem STM32F407 auf 168MHz schaffe ich bei 16x16 Pixel eine Bildwiederholrate von 2200Hz HARR HARR!
Dabei bebrenzt das Clusterbitgeschubse. Die SPI Überttragung ist bei 10MHz in 25µs durch.

Mal durchrechnen ob das langt:
Bei 10MHz SPI kann ich 6 Panels an den STM hängen und bei 20MHz wärens 12 Stück.
Die Bitschubsrechenleistung wird 12 mal so groß bei 12 Panels -> 183Hz Bildwiederholrate
(Dazu dann vllt noch Empfang über Ethernet und USB, also die Rechenleistung reicht)

Bei 24fps Sollwiederholrate und 8 Bit für die Bit Angle Modulation habe ich 1s/24fps/256 Zeit für eine SPI Übertragung, das sind: 162µs Zeit.
Das geht alles auf! :twisted:

Im Anhang mein Code zum Bitschubsen, ist aber noch nicht supergeil kommentiert.
Zudem sind die Schleifen noch ausgerollt damit man direkt sieht was es tut.
Der ist skalierbar indem man weitere Aufrufe der Funktion "build_bam()" aufruft und per Offset in den Bit Angle Buffer kotzen lässt.

1 Panel:

Code: Alles auswählen

while(1){
	
		framebuf[x][y][0] = 255;
		framebuf[x][y][1] = 255;
		framebuf[x][y][2] = 255;
		
		panel_start(bambuf);
		
		build_bam(	framebuf,
					0, 0,
					bambuf, 0);
		
		panel_testwait();
		latched();
		
		framebuf[x][y][0] = 0;
		framebuf[x][y][1] = 0;
		framebuf[x][y][2] = 0;
		x++;
		if (x >= DISP_ZEILEN){
			x = 0;
			y++;
		}
		if (y >= DISP_SPALTEN){
			y = 0;
		}
		delay(DELYTIME*10);
	}
2 Panel nebeneinander wie bei Matt:

Code: Alles auswählen

while(1){
	
		framebuf[x][y][0] = 255;
		framebuf[x][y][1] = 255;
		framebuf[x][y][2] = 255;
		
		panel_start(bambuf);
		
		build_bam(	framebuf,
					0, 0,
					bambuf, 0);
		
		build_bam(	framebuf,
					0, 16,
					bambuf, (16*16)/8);
		
		panel_testwait();
		latched();
		
		framebuf[x][y][0] = 0;
		framebuf[x][y][1] = 0;
		framebuf[x][y][2] = 0;
		x++;
		if (x >= DISP_ZEILEN){
			x = 0;
			y++;
		}
		if (y >= DISP_SPALTEN){
			y = 0;
		}
		delay(DELYTIME*10);
	}
Dateianhänge
panel_bam.c
(6.21 KiB) 160-mal heruntergeladen
panel_bam.h
(826 Bytes) 159-mal heruntergeladen
Zuletzt geändert von Fritzler am Di 7. Aug 2018, 19:00, insgesamt 1-mal geändert.
Matt
Beiträge: 6084
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitrag von Matt »

Du kannst eine andere Weg nehmen: Betriebsspannung für Panel auf 3,3-4V absinken und gucken, ob Pixelfehler weiterhin auftritt.
Warum ich diese Tipp gebe: Erforderliche Pegel für High sinkt mit kleinere Betriebspannung ab.
UND ich rät inzwischend, dass Betriebsspannung für LED (nicht LOgik) auf 4V absinken, es kommt für Treiber gut (weniger Verlustleistung).
In Datenblatt von MBI5024 schreibt man vor, dass Betriebsspannung für LED über Diode hängen sollen, damit Stromspiegel nur 0,4-0,8V SPannungsabfall sieht.


Achja, mit volle Atmega-Power habe ich ca 600FPS (mit simple Bit-Verschieberei und soft-SPI )
Für meine angedachtene Ziel ist es mehr als genung.

Grüss
Matt
Benutzeravatar
Fritzler
Beiträge: 12578
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Info zu grosse RGB LED Panel

Beitrag 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.
Matt
Beiträge: 6084
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitrag 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.
Benutzeravatar
Fritzler
Beiträge: 12578
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Info zu grosse RGB LED Panel

Beitrag 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.
Benutzeravatar
Fritzler
Beiträge: 12578
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Info zu grosse RGB LED Panel

Beitrag 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.
thinkpad
Beiträge: 846
Registriert: Fr 6. Feb 2015, 16:53
Wohnort: Rhein Neckar

Re: Info zu grosse RGB LED Panel

Beitrag von thinkpad »

bin mal gespannt wie das hier so weiter geht.

Baut ihr Controller für direkten Videoinput oder vom Ethernet/ Festplatte?
Matt
Beiträge: 6084
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitrag von Matt »

Er und ich verfolgte andere Weg.

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

Grüss
Matt
Benutzeravatar
Fritzler
Beiträge: 12578
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Info zu grosse RGB LED Panel

Beitrag 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.
Benutzeravatar
video6
Beiträge: 6794
Registriert: Mi 23. Sep 2015, 09:18
Wohnort: Laage bei Rostock

Re: Info zu grosse RGB LED Panel

Beitrag von video6 »

Schade das ich mich da nicht gemeldet hatte als die Dinger aufkamen.
Aber OK
xanakind
Beiträge: 12537
Registriert: So 11. Aug 2013, 21:55

Re: Info zu grosse RGB LED Panel

Beitrag 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 :-)
Benutzeravatar
Fritzler
Beiträge: 12578
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Info zu grosse RGB LED Panel

Beitrag 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.
Matt
Beiträge: 6084
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitrag 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.
Benutzeravatar
Fritzler
Beiträge: 12578
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Info zu grosse RGB LED Panel

Beitrag 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.
Benutzeravatar
Fritzler
Beiträge: 12578
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Info zu grosse RGB LED Panel

Beitrag 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
Matt
Beiträge: 6084
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitrag 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
Matt
Beiträge: 6084
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitrag 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.
Zuletzt geändert von Matt am Mi 15. Aug 2018, 20:00, insgesamt 1-mal geändert.
Matt
Beiträge: 6084
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitrag 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.
Benutzeravatar
Fritzler
Beiträge: 12578
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Info zu grosse RGB LED Panel

Beitrag 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:
Benutzeravatar
Fritzler
Beiträge: 12578
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Info zu grosse RGB LED Panel

Beitrag 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.
Matt
Beiträge: 6084
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitrag 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)
Benutzeravatar
Fritzler
Beiträge: 12578
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Info zu grosse RGB LED Panel

Beitrag 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!
Matt
Beiträge: 6084
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitrag 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.
Benutzeravatar
Fritzler
Beiträge: 12578
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Info zu grosse RGB LED Panel

Beitrag 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
Matt
Beiträge: 6084
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitrag 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.
Dateianhänge
IMG-20180818-WA0016.jpg
Benutzeravatar
Fritzler
Beiträge: 12578
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Info zu grosse RGB LED Panel

Beitrag 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:
Matt
Beiträge: 6084
Registriert: So 24. Aug 2014, 21:22

Re: Info zu grosse RGB LED Panel

Beitrag von Matt »

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

bäh!
Antworten