Display-Refresh-Rate

[Ion (Gast)]

Ich habe letztends für ein 2.5" 16Bit parallel 3.3V Display an einem 5V 
Arduino Mega mit ein paar HEF4050BP benutzt, allerdings ist die refresh 
Rate des Displays im loop extrem langsam.

...

void loop()
{
   
 myGLCD.print("Test", CENTER, 50);
 myGLCD.clrScr();   //Clear Screen

}

Man sieht richtig wie es von rechts nach links gelöscht/ wieder 
beschrieben wird.

Bei einem SPI Oled bring gleicher Code keine Diashow... Der ist 
allerding auch deutlich kleiner.

Liegt das an den (provisorischen) HEF4050BP ?

Die Gatterlaufzeit von High-> Low und wieder zurück hören sich mit 
35-70ns bzw 55-100ns  nicht gerade schnell an.
Das Display kommt später direkt an einen 3.3V Controller, ist im moment 
nur zu Testzwecken am Mega. ICh hoffe dann wird das besser.

[spess53 (Gast)]

Hi

Welcher Idiot benutzt HEF4050BP? Die gibt es auch als 74HC4050. Und 
wesentlich schneller.

MfG Spess

[Ion (Gast)]

spess53 schrieb:
> Hi
>
> Welcher Idiot benutzt HEF4050BP? Die gibt es auch als 74HC4050. Und
> wesentlich schneller.
>
> MfG Spess

Weil sie nunmal als einziges da waren.

Aber danke :D eine indirekte Antwort ist auch ne Antwort :)

[Axel S. (a-za-z0-9)]

Ion schrieb:
> Liegt das an den (provisorischen) HEF4050BP ?

Nein.

> Die Gatterlaufzeit von High-> Low und wieder zurück hören sich mit
> 35-70ns bzw 55-100ns  nicht gerade schnell an.

Das ist vollkommen irrelevant. So wahnsinnig viel schneller als die 
Begrenzung durch die Gatterlaufzeiten gibt dein Arduino die Daten 
sowieso nicht aus. Ich tippe einfach mal auf eine saudumme Ansteuerung 
des Displays. Also z.B. feste Wartezeiten statt das "Befehl fertig" Bit 
zu pollen. Bei einem HD44780 ist das nur schlechter Stil. Bei einem GLCD 
ist das dann tödlich.

[Ion (Gast)]

Axel S. schrieb:
> Bei einem GLCD
> ist das dann tödlich.

Ist ein TFT mit einem S1D19122 Controller

[Rudolph (Gast)]

Lass mal das myGLCD.clrScr(); weg.

[Sputnic (Gast)]

Rudolph schrieb:
> Lass mal das myGLCD.clrScr(); weg.

Wenn ich das ganze display löschen will und neu beschreibe sieht man wie 
es sich neu aufbaut, das sollte deutlich schneller gehen...

wenn es bei einem satz schon pulsiert... das versuche ich ja damit zu 
testen

[Ion (Gast)]

sry für den falschen benutzernamen, sollte Ion sein.

[Karl H. (kbuchegg)]

Sputnic schrieb:
> Rudolph schrieb:
>> Lass mal das myGLCD.clrScr(); weg.
>
> Wenn ich das ganze display löschen will und neu beschreibe sieht man wie
> es sich neu aufbaut, das sollte deutlich schneller gehen...

Dann sieh dir mal den Source Code zu clrScr an, wie der das macht.

>
> wenn es bei einem satz schon pulsiert... das versuche ich ja damit zu
> testen

PS: man löscht das ganze Display sowieso so wenig wie möglich. Man teilt 
sich as anzuzeigende auf in 'konstante Texte', die sich nicht ändern und 
daher nicht dauernd ausgegeben werden müssen. Und den anderen Rest, der 
sich im Betrieb laufend ändert (Zahlenwerte etc), den gestaltet man so, 
dass man mit laufendem übermalen zum Ziel kommt.

[Ion (Gast)]

Karl H. schrieb:
> Dann sieh dir mal den Source Code zu clrScr an, wie der das macht.

_fast_fill_16(0,0,((disp_x_size+1)*(disp_y_size+1)));

Der malt einfach mal drüber...

Karl H. schrieb:
> man löscht das ganze Display sowieso so wenig wie möglich.

Bei Text nicht aber bei bewegtem Vollbild ist das halt nötig...

[Karl H. (kbuchegg)]

Ion schrieb:
> Karl H. schrieb:
>> Dann sieh dir mal den Source Code zu clrScr an, wie der das macht.
>
>

> _fast_fill_16(0,0,((disp_x_size+1)*(disp_y_size+1)));
> 
>

>
> Der malt einfach mal drüber...

ok.
und wie macht _fast_fill das?

Wir können das Spielchen noch ein paar Stunden weiter treiben. Wenn du 
wissen willst, warum das Löschen so lange dauert und ob du etwas dagegen 
tun kannst, dann wirst du wohl nicht umhin kommen, den Code so lange in 
die Funktionen hinein zu verfolgen, bis du auf unterster Ebene angelangt 
bist und genau weisst, was zum Display übertragen wird. Und dann kann 
man sich ansehen, ob man da etwas einsparen kann bzw. ob es eine andere 
Möglichkeit gibt.

> Karl H. schrieb:
>> man löscht das ganze Display sowieso so wenig wie möglich.

>
> Bei Text nicht aber bei bewegtem Vollbild ist das halt nötig...

Bei bewegtem Vollbild malt man das neue Bild einfach über das alte 
drüber.  Und da möglichst auch nur die Bereiche, die sich verändert 
haben.

[JensM (Gast)]

Die Laufzeiten des Gatters können nicht das Problem sein.
Es werden eine Handvoll Zeichen mit 100ns übertragen.
Bei 100 Zeichen wären das 10us -> 100000 mal / Sekunde.

Ich denke, dass es Interferenzen sind die sichtbar werden.

Das ablöschen und beschreiben geschieht mit einer ähnlichen Frequenz wie 
die Bildwiderholfrequenz des Controllers.

Ermittle mal die wirkliche Laufzeit der Loop Funktion, z.B. indem bei 
jedem Durchlauf ein Ausgangsbit getoggelt wird.

Gruss JensM

[Axel S. (a-za-z0-9)]

Karl H. schrieb:
> und wie macht _fast_fill das?

Darüber kann man zumindest begründete Vermutungen anstellen. Also aus 
der _16 schlußfolgern, daß das Display wortweise mit 16 Bit beschrieben 
wird. Und dann kann man aus der Displaygröße (die der TE nach wie vor 
geheim hält) ausrechnen, wieviele Datentransfers dafür nötig sind. Und 
dann aus der beobachteten Refresh-Rate zurückrechnen wie lange so ein 
Worttransfer dauert. Meine Vermutung: deutlich länger als die 100ns 
Verzögerungszeit der Pegelkonverter.

Wenn man sowas schick haben will, dann nimmt man ein Display das intern 
die doppelte Datenmenge eines Frames halten kann und sich zwischen zwei 
Frames umschalten läßt (dafür kann man auch eine Scrolling-Funktion 
mißbrauchen). Außerdem baut man einen neuen Frame immer im RAM auf, 
transferiert ihn anschließend in den unsichtbaren Frame des Displays und 
schaltet erst zum Schluß das Display um. Und wenn man sehr gut ist, 
synchronisiert man das noch mit dem Refresh des LCD-Controllers.

Auf der anderen Seite kann man auch eine unbekannte Library aus dem 
Arduino-Umfeld nehmen und sich nachher wundern warum das scheißlangsam 
ist und so häßlich aussieht.

[Ion (Gast)]

Axel S. schrieb:
> Displaygröße (die der TE nach wie vor
> geheim hält)

2.5 " bei 320x240

Axel S. schrieb:
> unbekannte Library

UTFT Libary mit einem 'outdated' S1D19122 Controller.

Axel S. schrieb:
> dann nimmt man ein Display

Das Display habe ich deswegen genommen weil es ein 2.5" ist das recht 
quadratisch ist und die Anschlüsse am längeren Ende des Displays hat.

Das ist eine der Hauptvoraussetzungen gewesen.
Das LCD hatte allerdings nur ein chinese bei aliexpress und hatte keine 
Adapterplatine, deswegen ist es zum testen an einen Mega gekommen

[Karl H. (kbuchegg)]

JensM schrieb:

> Ich denke, dass es Interferenzen sind die sichtbar werden.

Du sprichst da ein wahres Wort gelassen aus.
Das könnte in der Tat der Fall sein.