Info zu grosse RGB LED Panel

Matt · Beitrag von **Matt** » So 19. Aug 2018, 10:22

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)

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

Matt · Beitrag von **Matt** » Di 21. Aug 2018, 19:25

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)

(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.

Aus irgendnwelchere Grund startet µC neu, daher gibt Überlauf-Fehler von UART. Wohl wird alle Speicherzelle geleert , daher erklärt es mit flackerende Bild.

Matt · Beitrag von **Matt** » Mi 22. Aug 2018, 20:16

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  ///////////////////////////////////

Matt · Beitrag von **Matt** » Mi 22. Aug 2018, 21:37

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.

ferdimh · Beitrag von **ferdimh** » Mi 22. Aug 2018, 22:02

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

Matt · Beitrag von **Matt** » Mi 22. Aug 2018, 22:12

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.

Fritzler · Beitrag von **Fritzler** » Do 23. Aug 2018, 17:28

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

Auch wenn davon nur die Daten für 6 Panel sinnvoll sind.

Also doch mal nen FPGA DevBoard rauskramen.

Matt · Beitrag von **Matt** » Do 23. Aug 2018, 20:36

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

Matt · Beitrag von **Matt** » Mo 27. Aug 2018, 19:12

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)

Matt · Beitrag von **Matt** » Di 28. Aug 2018, 18:40

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.

Matt · Beitrag von **Matt** » Sa 1. Sep 2018, 16:17

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.

barclay66 · Beitrag von **barclay66** » So 2. Sep 2018, 08:17

Das Gold reißts locker wieder raus!

Fritzler · Beitrag von **Fritzler** » Mo 3. Sep 2018, 16:44

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?

Matt · Beitrag von **Matt** » Mo 3. Sep 2018, 17:12

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.
_____________________________________________________________________

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.

Enable-Signal, mit reparierte Tek 468 von Roechricht gemesst

(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.

_________________________________________________________________________

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

Fritzler · Beitrag von **Fritzler** » Mo 10. Sep 2018, 10:08

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

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

Sowie bis zu 60mA können die am Ausgang Treiben und bei Mouser sind die auchnoch günstiger als ACT!

Matt · Beitrag von **Matt** » Mo 10. Sep 2018, 16:14

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

Matt · Beitrag von **Matt** » Mo 10. Sep 2018, 20:17

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

Botanicman2000 · Beitrag von **Botanicman2000** » Di 11. Sep 2018, 12:13

Hallo Matt

welche Abmessungen hat denn das Display?

Gruss Uwe

Fritzler · Beitrag von **Fritzler** » Di 11. Sep 2018, 12:19

Er hat wohl 4x2 gebaut.
Ein panel hat 19,2x19,2cm²

Also 76,8x38,4cm²

doofi · Beitrag von **doofi** » Di 11. Sep 2018, 12:26

Sorry für das nitpicking, aber das "Quadrat" gehört da nicht hin...
Ansonsten natürlich einen Heidenrespekt für dieses Hardcoregefrickel!!

Fritzler · Beitrag von **Fritzler** » Di 11. Sep 2018, 12:47

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!

doofi · Beitrag von **doofi** » Di 11. Sep 2018, 12:52

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²

doofi · Beitrag von **doofi** » Di 11. Sep 2018, 12:55

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.

xoexlepox · Beitrag von **xoexlepox** » Di 11. Sep 2018, 14:14

"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?

doofi · Beitrag von **doofi** » Di 11. Sep 2018, 15:46

Da hat die USA doch mal damit rumexperimentiert. Bedazzler oder so hieß das Gerät glaub ich.

Matt · Beitrag von **Matt** » Di 11. Sep 2018, 15:51

Bei mir wird eher nur 25A auf 8 Panel, da AVR grottenlangsam in SPI Übertragung ist. Also max ca 1/4 Dutycycle (Rechnung haut wieder hin, 80-90A/4 = 20-22A)

Grüss
Matt

Matt · Beitrag von **Matt** » Do 27. Sep 2018, 17:42

Das ist Plan, wie man es anschliessen wird.

rgb8bitpaneltpm2.txt: (6.01 KiB) 113-mal heruntergeladen

Diese Textdatei, bitte ins hex umbenennen und ins AVR 328p brennen.

Idealweise nihmt man Arduino Nano V3 (mit CH430 und Atmega328p drauf) und lötet auf 24Mhz Quarz um.
Dann spielt man HEX über ICSP auf Atmega auf.

Es spricht über TPM2 Potokoll , man sollte auf Kanal 1536 stellen ( ist eher Anzahl von überzutragene Byte) und Baudrate auf 500.000 stellen.

(Randnotiz: ich nutze nie Ardunio-Umgebung aber sehr gerne Arduino Board, ich löte niht für 2,5€ Atmega 328 mitsamt Quarz und ICSP Header zusammen)
(Randnotiz2: Aktuelle Code hat noch leichte Unzugänglichkeit mit leichte flimmern durch Interrupt verlangsamte Bitanglemodulation)

Fritzler · Beitrag von **Fritzler** » Mo 1. Okt 2018, 17:40

So langsam dämmerts mir was ich da fürn Projekt an Land gezerrt hab

Jedenfalls war ich heute in Dresden und hab mir die dort im Turmlabor gebunkerten 36 Panels abgeholt bevor die Ersties das mitnehmen können

Vielen Dank dafür an Ludwig und Hendrik!

Der Chinamann brachte die letzten Wochen auch gleich noch 200 Pfostenbuchsen vorbei von denen ich 180 crimpen muss.
4 Einzelbestellugen zu 50 Stück, weil bei ner 4fach Bestellung die Versandkosten explodierten.
Wenn ihr so wollt, dann bekommt ihrs eben so

Aber nun zum eigentlichen Fang:
Bild

Das Display soll aus 9x5 Panel bestehen, das macht 80x144Pixel, also fast 16:9
Es sind 2 Zeilen zu viel, egal.
Bild

So langsam erahnt man die Dimensionen, 172cm klingt so klein wenn mans ausrechnet.
Aufm Fußboden ausgelegt ist das RIESIG!
Achso: und 1m hoch!
Bild

@Matt
Der FPGA selbst ist super!
BlockRAM und LUTs bis zum Abwinken.
Er hat aber nur 32GPIO von der Platine runtergeführt, das wird etwas knapp, wenn ich LAN will.
(Pixeldatenempfang über Art-Net)
Dann brauch ich 36GPIO und nen DebugUart will ich eigentlich auchnoch für den SoftCPU Core.
Eigentlich könnte man ja auch die Serdes links nutzen zum Pixeldaten raushusten.
Nur hat die Platine nur 8 Links und ich brauch eben 15, ARGH!
Ich bin noch nicht Schlau geworden ob man die Serdes Links auch als GPIO nutzen kann.

Matt · Beitrag von **Matt** » Mo 1. Okt 2018, 17:56

Du nihmst halt 2te FPGA als Porterweiterung über serdes

Nicht kleckern sondern klotzen !

Ja, mir ist schon mit 4x2 Konfig ziemlich fett.

Zu Crimpzange für Pfostenbuchse wie in Bild, ich habe tatsächlich Zange dafür.

Achja, Martin aus Wellenkino hat gefilmt. Da wurde meine "Riesen" Display auf MakerFaire hingestellt .
http://www.wellenkino.de/makerfaire/2018/v3.mp4

Fritzler · Beitrag von **Fritzler** » Mo 1. Okt 2018, 18:34

Welche Wiederholfrequenz hasten jetz eigentlich?
Die Kameraaufnahme flimmert ja nicht.
Dafür haste abern kleinen Versatz von oberer Panelreihe zur Unteren.

Jow, türlich könnt man jetz 2 FPGA nehmen, dann wird aber die Synchro lustig.
Daher wirds wohl ne Zweichiplösung aus FPGA und nem STM32.
Verbunden über nen QSPI, dann reichen die GPIOs auf jedenfall.

Dabei hatte ich auch mal überlegt selber nen FPGA auf ne Platine zu löten, aber alles was es noch in TQFP gibt hat zu wenig BlockRAM.

Ne Crimpzange für Pfostenbuchen hab ich auch, die Kosten ja nix.

Matt · Beitrag von **Matt** » Mo 1. Okt 2018, 18:52

Auf Kamera fällt Flimmern nicht ganz auf, aber wenn man davor steht und es mit statische Bild angesteuert wird, dann fällt man es auf
(da es um 15% des Helligkeit durch UART Interrupt schwankt)
Ich hatte mal gemesst und es nicht notiert.
Ich denk mal: Es liegt um 65 FPS, der natürlich dank UART Interrupt zwischen 55 und 65 FPS pendelt. Es flimmert aber nicht wirklich wegen diese Wiederholungsrate. (BAM sei dank)

Versatz liegt an JINX!, der nicht synchron über 4 USB-UART Wandler sendet.
Klar, wie will ich 2x4 aufbauen, wenn EINE Atmega 328p schon mit 2 Panel an Anschlag läuft.
Erst recht mit nur 2kB RAM!

Serdes läuft soweit ich weiss mit sehr hohe Datenrate. und für eine GPIO zwecks Synchronisierung hat man immer übrig

Fritzler · Beitrag von **Fritzler** » Di 2. Okt 2018, 14:36

Da kannste ja jetzt mehr Funktionen von jinx als ich.
Interessant, dass der über 4 UART raushusten kann.

Der 74ABT245 ist wohl auch nicht gut genug, dass er die Panels mit 22MHz takten kann.
Es gibt imemrnoch massigst Pixelfehler bei diesem Takt, HMPF.

Aufm Oszi erkennt man aber, dass er schon viel schneller ist als der HCT.
Man achte auf das Propagation Delay.

74ABT245:
Bild

74HCT245:

Aber sobald der gelbe Eingangspegel seine 3,3V erreicht hat flacht die Flange des Ausgangs ab.
3,3V -> 5V pegelwandeln und Bustreiben geht wohl eher nicht, doof.
Also mal Pegelwandeln und Bustreiben getrennt probieren?

barclay66 · Beitrag von **barclay66** » Di 2. Okt 2018, 16:29

Hi,

probiere doch mal den TXB0108. Der kann +/-50mA treiben und braucht bei Vcc 3,3V/5V 5,2ns oder weniger zum Schalten (laut Dabla). Sollte reichen für 100MHz oder mehr...

Gruß
barclay66

Fritzler · Beitrag von **Fritzler** » Di 2. Okt 2018, 16:57

Der TXB0108 ist genau das Gegenteil von dem was man haben will, der ist nämlich bidirektional und kann somit keine Leitungen treiben.

Die Bidiraktionalen müssen ja irgendwie erkennen wer grade treibt.
Daher geben dir nur einen kurzen Puls auf die Leitung bei einem Pegelwechsel und halten dann den Pegel über einen hochohmigen Widerstand.
Wenn der Pegel vom Pin und dem Ausgangsreiber über den Widerstand abweicht, dann bekommt die andere Richtung die Pulsbehandlung.

Bei langen Leitungen führt das dann zu einem wunderbaren oszillieren.
(Rat mal woher ich das weiß?

)

Da gibts durchaus nen 74xyz245 mit 2 Spannungen zum Pegelwandeln, muss den erstmal wieder finden.

edit: 74LVC8T245, 74LVCC4245

Matt · Beitrag von **Matt** » Di 2. Okt 2018, 17:29

ODER !

74ACT14 und so ähnlich als Treiber. Dann wird Problem mit abgeflachte Dach über 3,3V wegen Schmitttrigger umgegangen.

Ich weiss nicht genau, wie Treiber bei dir beschaltet und verwndet wird ist.

Lange Leitung und hohe Datenrate (da ist 25Mhz schon kritisch) ist schon mit Problem vorprogrammiert.
Da ist schon zwingend, deren Ende mit Terminator abschliessen, dann klingelt es nicht mehr.
Wenn ich Lust habe, dann kann ich herausfinden, was für Impedanz von Flachbandkabeln hat. Ich schätze mal 200 ohm.
(Nur wenn jeder zweite Leitung Masse ist und mit Daten/Takt/Latch/Enable in Rhythmus abwechselt)

Zu FPGA mit zu wenige GPIO, ich schlage dir vor: Ausgang mit ECL Schieberegister erweitert

Ich habe mehre ECL Schieberegister, der kann bis zu 250Mhz gehen.
MC100E141 kann bis 700Mhz schieben, da ist Lattice ECP3 schon längst am Taktkotzgrenze.

Grüss
Matt

Fritzler · Beitrag von **Fritzler** » Di 2. Okt 2018, 19:09

74ACT245 war ja eh in Planung, Henry hatte mir dann aber die ABT mal gegeben.
Die ABT sind jedoch fixer als die ACT.

Also die 25MHz hab ich mir in Kopf gesetzt, weil die Schieberegister auf den Panels das als fmax haben.
Auf den Panels selber sind 74HC245 als Buffer eingesetzt. (Daher hatte ich ja zuerst den 74HCT245 probiert.)
Zudem wird auf den Panels garnix terminiert, auf keinem Signal und weder auf Aus- noch Eingängen.
Das muss also ohne gehen, weils nicht vorgesehen ist.

Richtig "geil" sieht das Taktsignal übrigens nach 2 Panels (=4 Platinen aus).
UARGHS:
Bild

Hier dann noch mit Daten dazu.
blau = CLK in 10 oder 20MHz (sihe Oszi Messungen)
gelb = Bits blau
Bild

Man sieht das Problem

So soll das Testbild aussehen:
Bild

So siehts aber bei 20MHz aus:
Bild

Der fliegende Aufbau:
Bild

Matt · Beitrag von **Matt** » Di 2. Okt 2018, 19:36

schon klar,. mit 20cm lange Kabeln geht schon. Es wird aber schon (!)mit 50cm Kabeln ziemlich ekelhaft.

Das Pixelfehler, der verschluckt Takt und Pixeldaten. Auch wenn 25Mhz in Datenblatt geschrieben ist, low und high-Puls auch mit minimale Länge definiert.
Wenn Treiber wegen nur 3,3V Pegel zu kurze High-Pegel erzeugt. Da ist also Wurm drin.

Fritzler · Beitrag von **Fritzler** » Mi 3. Okt 2018, 10:36

Dann gehen wir doch mal den CLK Pfad bei 20MHz durch.

So siehts vor und hinter dem 74HCT245 auf der Lochrasterplatine aus:
Bild

gelb: 74HCT245 Ausgang vom Lochraster
blau: Ankunft an der Panel Platine
Bild

gelb: 74HCT245 Ausgang vom Lochraster
blau: 74HC245 Ausgang von LED Panel Platine
Bild

Was mir aufgefallen ist, dass nach jeder Panelplatine der CLK Impuls um 3ns länger wird.

Nach Platine1: 27ns
Nach Platine2: 30ns
Nach Platine3: 33ns
Nach Platine4: 35ns

Für mehr Takt müssten also wohl die 74HC245 auf der Panelplatine ersetzt werden gegen ACT.
Das wäre nen ziemlicher Aufwand, weil 4 ICs Pro Panel.

Chefbastler · Beitrag von **Chefbastler** » Mi 3. Okt 2018, 10:54

Fritzler herzlich willkommen in der Welt des Voodoos.

In dem Frequenzbereich wird es langsam Spannend mit Masseführung und Signalleitungsführung und Signallaufzeit über die leitung(CLK, DATA leitungen sollten geleich lang sein), und bei längeren Leitungen spielt dann auch mal die terminierung schnell mal ne Rolle.

20Mhz hören sich nach wenig an, ist aber wenn es sich um Rechteck Signal handeln soll eher specktral mit 200Mhz anzusehen.

Ich fürchte eher dass die Panels im originalbetrieb eher mit 10Mhz liefen.

Der 74LVC541A Könnte da noch was bringen bei 20Mhz und entsprechender Leitungsführung:
https://assets.nexperia.com/documents/d ... VC541A.pdf

PS: Der Leitungstreiber IC auf deiner Lochrasterkarte würde sich über nen Kerko freuen. Der Elko da in der Ecke ist da bei den Frequenzen meist etwas ungeeigent da zu träge.

Fritzler · Beitrag von **Fritzler** » Mi 3. Okt 2018, 11:18

Der Kerko ist nur nicht zu sehen, der ist unter der Platine direkt an den Versorgungspins.

Der 74LVC541 geht nicht, weil er nur ne VCC von max. 3,6V hat.
Nur 5V tolerante Eingänge bringen ja nix wenn die Schieberegister ICs unbedingt 5V sehen wollen.

Da frag ich mich dann aber wirklich wie diese Panels in der original Videowall betrieben wurden.
So ist es ja nur möglich 2 Panels in Reihe zu schalten und das bei ner Wiederholfrequenz von maximal 90Hz.
Oder die haben noch viel früher angefangen am Output Enable rumzuspielen *kopfkratz*.
(Dann werden die Panels ja schonwieder etwas dunkler, aber dann spar ich mir Netzteilstrom)

Also mit 15MHz will ich die Teile durchaus noch prügeln, mal an der PLL spielen mit das mit dem SPI Taktteiler klappt.

Chefbastler · Beitrag von **Chefbastler** » Mi 3. Okt 2018, 11:36

Fritzler hat geschrieben:.

Der 74LVC541 geht nicht, weil er nur ne VCC von max. 3,6V hat.
Nur 5V tolerante Eingänge bringen ja nix wenn die Schieberegister ICs unbedingt 5V sehen wollen.

Meinte die LV Typen. Der rennt mit 5V und ist 3,3V Input tolerant.

Der LVC wäre immerhin noch mit Absolut maximum Rating VCC 6,5V angegeben und als "functional" wurde nur ne Mindestspannung angegeben. Die warscheinlichkeit das es funktioniert wäre warscheinlich hoch aber in einem Amtlichen Gerät würde ich das auch nicht machen.

Wobei diese die geschwindigkeit des ABT eigenlich auch nicht wirklich toppen.

Fritzler · Beitrag von **Fritzler** » Mi 3. Okt 2018, 11:47

Dafür gibts ja die LVC8T und LVCC

Jedenfalls, bei 15MHz ist auch schon schluss.
Panel 1 ist noch super und bei der oberen Hälfte von Panel 2 kommts zu ersten Fehlern.
Bei Panel3 ist dann ganz Schluss.

edit:
Selbst 3 Panel in Reihe bei 10 Mhz gehen nicht, shice.

Bastelbruder · Beitrag von **Bastelbruder** » Mi 3. Okt 2018, 13:20

Der Impuls wird immer breiter weil die Schaltschwelle nicht in der Mitte liegt. Das ist das ganze Geheimnis.

Mit 3 Volt auf 5 V-"kompatible" Eingänge ist ok, aber mit 5 V funktioniert das nicht so ideal. Ein Spannungsteiler aus 100 und 220 Ohm beseitigt das Problem und dämpft gleichzeitig die Überschwinger etwas ab damit nicht irgendwelche parasitären Dioden* sich unangenehm bemerkbar machen. Die durchschnittliche mehr-Stromaufnahme von 8 mA muß halt sin wenn die Chips nicht zueinander passen.

*Eine Parasitärdiode ist keine separate Diode sondern eher ein Stromspiegel, der eventuell denselben Strom nochmal von der gegenüberliegenden Spannungsquelle zieht. Und die Dinger sympatisieren miteinander über die ganze Chipfläche ...

Fritzler · Beitrag von **Fritzler** » Do 4. Okt 2018, 13:56

Bastel, es geht doch in die andere Richtung.
Der sendende STM32/FPGA hat 3,3V IOs und die Panels wollen 5V.
Daher steckt da nen 74HCT245 zwischen, der 5V bekommt.
DER zieht die CLK Impulse nicht um 3ns in die Länge, sondern die 74HC245 auf den Panels. Diese bekommen aber 5VCC und 5VIO.

Ansonsten is das mit der Schaltschwelle ja einleuchtend.
Im FPGA werde ich den CLK wohl eher als 30/70 DC Impuls ausgeben, denn der CLk Impuls darf kürzer sein als die Hold Time am Dateneingang der Schieberegister.
Dann gehen vllt wieder 3 Panels in Reihe mit 60Hz oder 2 Panels in Reihe mit 90 oder 120Hz flimmerfrei.

Aber ich hab mich intern schon darauf eingestellt, dass ich wohl ne 4fach Verschachtelung bauen muss und jedes Panel bekommt seine eigene LAT und nOE Leitung.
Also jedes Panel bekommt Daten für sich und keine Reihenschaltung mehr.
Das bedeutet aber auch, dass das Display nurnoch 8x5 sein wird statt 9x5 Panels.
Weiterhin besteht es dann aus linker und rechter Hälfte, also 2 FPGA Boards brauchts, die werden dann von nem STM32 per QSPI gefüttert und gesynced.

Fritzler · Beitrag von **Fritzler** » Mo 13. Mai 2019, 18:24

AAAAHH! Nurnoch so ~2 Monate zum Treffen!

Da hab ich mich doch spontan entschlossen am Display weiterzumachen.
Jedenfalls sind die DMA Probleme jetzt weitgehend gelöst.

Der DMA sendet die Bits schön brav mit 14MHz auf die GPIO.
Es gab ja mal noch son flimmern, denn der Bitzähltimer hat beim stoppen gejittert.
Bitzähltimer?
Naja die DMA Ausgabe ist recht kompliziert gebaut, da die Panels ja nur Schieberegister sind und dadurch darf keine Taktflanke zu viel am Ende sein, sonst verrutscht das Bild.
Aber genau das kam ab und zu vor.
TIM1 des STM32 zählt die Zeit wie lange der DMA braucht um alle Bits auszugeben.
TIM8 erstellt eine PWM, das ist der Takt der Schiebregister und immer wenn TIM8 überläuft wird der DMA getriggert ein neues uint16-t auf die GPIO zu legen.
Damit das eigentlich nicht jittern kann läuft TIM8 im Gating Modus, also TIM8 läuft nur solange TIM1 läuft.
Das hatte aber trotzdem gejittert?! Da ist wohl das interne Eventsystem etwas zu träge, sobald TIM1 mit dem 4fachen Takt (durch den Prescaler eingestellt) von TIM8 läuft funktioniert das!

JAY!

Aber wie gehabt, dabei darf keiner weiter gleichzeitig auf den SRAM oder AHB1 zugreifen.
Selbst ein UART pollen -> RUMMS.
Daher liegt im SRAM1 exklusiv der Bitangle Buffer und in SRAM2 liegt der per SPI geholte Framebuffer. Der SPI DMA wird nur laufen, wenn grade keine GPIO Ausgabe erfolgt.
Das muss ich also intern noch verschränken.
Das Programm selbst läuft komplett aus dem Data CCM (Core Coupled Memory).
Das Linkerscript wird so langsam … unauf ... äh ... interessant.

Da die Panels nicht mit vollen 25MHz laufen (die SREG können das, aber die verbauten 74HC Bustreiber verzögern den CLK zu krass), kann ich nicht mehr 3 in Reihe packen, sondern immer nur eines betreiben.
Momentan sind 2 in Reihe und schaffen 60Hz Wiederholfrequenz, das flimmert aber noch leicht, also müssens 120Hz werden.
Ist aber kein Problem, weil ich ja noch die 3fach Verschachtelung habe.
Zudem veranstaltet meine Kamera bei den 120Hz keine Flimmerparty mehr bei den Aufnahmen.

Daher wird das Display gedrittelt, pro Drittel ein Controller (STM32F407).
Die Daten kommen von einem Zentralhirn per SPI über LVDS über Ethernetkabel.
Laut einer TI Appnote gehen da noch 200mbit über 5m CAT5, das ist mehr als genug.

Dazu muss ich aber mal gucken ob dann nicht das Zentrahirn überlastet ist wenn 3 SPI Slaves gleichzeitig per DMA bedient werden müssen und die Daten müssen ja auch noch reinkommen!

5*9 Panel zu16x16px und 60fps sind mal eben 2,1MByte/s!
Mal gucken wie ich diese Datenrate aus einem Linuxrechner rausgepopelt bekomme.
(wegen meinem mplayer Plugin).

Ein RasPI hätte einen SPI Ausgang, aber ob der FullHD Videos mit 60fps abspielen, downscalen und auf den SPI schieben kann?
Ich bezweifle es.

Fritzler · Beitrag von **Fritzler** » Mo 13. Mai 2019, 19:21

Hier der neue Testverhau.
Jetzt werden 2x3 Panel getestet und nicht mehr nur 1x2.
Um die Pixelverteilung über die Panelzeilen zu testen und um mal alle 3 Verschachtelungen gleichzeitig zu sehen.
Durch die Auftrennung der LAT/nOE Signale kann ich jede der 3 Panelspalten einzeln ansteuern.
Wenn also Spalte 0 grade keine Daten bekommt, kann ich zB Spalte 1 ansteuern.
Bild

So langsam merk ich wie groß und vor allem SCHWER das wird.
Die 6 Panel zusammen wiegen schon ordentlich was und nehmen gut Platz weg.

Trotz 4 Zusatzsignalen kann ich bei einem 16Pol Flachbandkabel bleiben, denn es sind genug NC vorhanden.
Glücklicherweise zusammen am unteren Rand (Pin 13-16).
Dafür muss ich zwischen 2 Panels am Flachbandkabel rumschnippeln:
Bild

Schlussendlich wird die Pegelwandlerplatine auch etwas größer:
Bild

Fritzler · Beitrag von **Fritzler** » Di 14. Mai 2019, 20:13

Läuft! Würd ich ma sagen:
https://www.youtube.com/watch?v=eXhdq72zRSU
Ersteinmal nur per intern erzeugter Animation.

Also GPIO DMA mit 2xRGB und die ANsteuerung der 3 Panels pro Zeile.
Alles mit 120Hz, kein flimmern mehr auf der kamera und im Auge auch nicht!

Als nächstes dann mal noch ein STM32Disco Brett raukramen und das "Daten per SPI holen wenns zeitlich grade passt" implementieren.

Bild

Dazu hatte ich ja erstmal den BAM umgedreht mit ich Zeit habe.
Die kleinste Leuchtzeit kommt nun zuerst und wird dann immer größer.
Ansonsten will ich 60fps Video erreichen und habe 120HZ Wiederholrate.
Also 2 Wiederholungen pro Frame habe ich Zeit für alles.

Ersteinmal wird per SPI der neue Framebuffer in den Pausen gezogen (Das Bussystem des STM32 ist ja bekanntlich auf Vollanschlag).
Danach wird der neue BAM Buffer vom ARm kern im Core Coupled Mem berechnet und in der "Austastlücke" in den SRAM1 kopiert.

SPI Empfangen und berechnen könnt ich auch schachtelnw enn die Rechenzeit nicht hinkommt.

Chefbastler · Beitrag von **Chefbastler** » Di 14. Mai 2019, 20:29

Oha da in deinem Video sind ganz schön viele LEDs Defekt?
Lassen die sich austauschen?

Fritzler · Beitrag von **Fritzler** » Di 14. Mai 2019, 20:42

Nö, das Projekt ist eben wortwörtlich Schrott!

Die LEDs sind in schwarzer Pampe vergossen wegen der Wetterfestigkeit.
Selbst wenn man die tauscht wird man nicht mehr haargenau dieselben bekommen und somit sieht man das auch wieder.
Auf einer der Platinen habe ich jetzt auch schon Reparaturarbeiten gesehen, da wurde eine leiterbahn mit einem Draht nachgezogen, der Subpixel geht aber.

Heute kam auch das von Xana gekaufte NT an und im Karton befand sich noch Qualitätsaal (die Beamerlüfter müssen jetz wohl weg

) Sowie LED LED LED, imemr gerne,

5V/200A, aber mit Steckkontakten zum reinschieben in einen Server?.
Daher mal aufgemacht und doch Schraubkontakte gefunden -> Perfekt!

Auch schön Modular aufgebaut.
der Deckel ist die PFC und der Boden das eigentliche NT.
Aus den Schalttrafos kommen Kupferschienen raus!
Bild

Matt · Beitrag von **Matt** » Di 14. Mai 2019, 21:05

Also, meine Karton ist auch angekommt

.

Ja, das ist Problem mit tote LED. (nahezu nur mechanische Schäden)
Und noch eins: an ihre Lötstelle (hinten) kommt man zur grösste Teil nicht ran. Grund: Treiber-Platine ist draufgelötet. Möchtest du mehr als 100 Lötstelle entlöten und Platine rausziehen ? Ich jedensfalls nicht.

Einzig was man machen kann: vorsichtig kaputte LED um Gehause befreit und helles SMD LED drauflöten. Um geringe bis keine Unterschiede zu erreichen, hat man nicht leicht. Daher: Scheiss drauf !.

Ich habe etwa 8 Stück Wahl 1A ( maximal 1 kaputte LED) und ist teils in 2x4er Panel verbaut.

Grüss
Matt