Display-Refresh-Rate

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.

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 schrieb:
> Karl H. schrieb:
>> Dann sieh dir mal den Source Code zu clrScr an, wie der das macht.
>
>

1

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

2

> 

3

>

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

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.

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.