Arduino TFT Display: total lahme Ausgabe!

[HaWe]

EV3 verwendet auch ein SPI-Display.
An was all für Dingen es auch immer liegen mag: Die Treiber-Bibliotheken sind sicher wesentlich. Es kann aber doch nich wahr sein, dass das obige Display mit diesem Treiber
https://github.com/Nkawu/TFT_22_ILI9225
alleine schon fast 1 Sec braucht nur für 1x Clear screen !
In dieser Zeit machen ja der NXT (ARM 7) und erst Recht der EV3 (ARM 9) den kompletten Test von vorne bis hinten!
Und auch der Due (ARM Cortex) ist ja nicht mal annähernd so schnell wie der NXT, obwohl er ihn bei einfachen Berechnungen locker abhängt!

Die Frage ist also: wo kriege ich schnellere Libs her, die die Display-Ausgabe wenigstens um den Faktor x100 beschleunigen ?
Eine Echtzeit-Anzeige z.B von PixyCam-Daten (beschriftete Rechtecke an Positionen erkannter BLOBs) ist ja sonst absolut unmöglich (und die schafft sogar der NXT locker !)

ps,edit:
Dass die Bytecode-Interpreter-VMs (NXC, RobotC, Java/Lejos, C#/Mono) hier oft komisch abschneiden, ist ja zu erwarten, die haben einfach den Interpreter schlecht optimiert.
Aber NXT mit nxtOSEK C und EV3 mit gpp C sind ja ebenso native Executables wie die mit SKetch-gpp C++ erstellten Compilate und müssten daher ähnlich schnell laufen können (gemessen am cpu-Takt) - WENN die Treiber vernünftig programmiert sind !

[Peter(TOO)]

Hallo,

EV3 verwendet auch ein SPI-Display.
An was all für Dingen es auch immer liegen mag: Die Treiber-Bibliotheken sind sicher wesentlich. Es kann aber doch nich wahr sein, dass das obige Display mit diesem Treiber
https://github.com/Nkawu/TFT_22_ILI9225
alleine schon fast 1 Sec braucht nur für 1x Clear screen !

Scheint am Controller zu liegen!
Es gibt keinen Befehl für clear, man muss an jede Zeichenposition im Controller-RAM einzeln schreiben um dass Display zu löschen

Andere Controller haben dazu einen Befehl und machen den Rest dann selbst.

Hier noch das Datenblatt zum ILI9225B:
http://www.inhaos.com/uploadfile/otherpic/ILI9225B.pdf

MfG Peter(TOO)

[Rabenauge]

Vergiss es.
Diese Displays _sind_ einfach nicht schneller, da sie z.b. keinen eigenen Bildschirmspeicher haben.
Rate mal, wieso ich schon paarmal sagte, dass es mehr oder weniger sinnfrei ist, sowas zu benutzen.
Das einzige was du machen kannst ist, die Ausgaben so zusammenkürzen, dass immer _nur_ das aktualisiert wird, was auch wirklich nötig ist.
Wenn du allerdings z.B. fettgedruckte Graphen in Echtzeit mit nem Hintergrundbild wirklich brauchst dann gibs auf- das wird nix.

Dass selbst der ClearScreen so lange dauert, liegt wahrscheinlich daran, dass es den Befehl gar nicht gibt (rat mal, warum die Dinger so spottbillig sind, aus den Rippen schneiden die dich auch die Chinesen nicht), sondern das Display einfach komplett mit schwarzen Pixeln beschrieben wird.
Man kann mit den Dingern schon durchaus einiges an grafischen Ausgaben machen, aber dann muss man wirklich bissel was von der Grafikprogrammierung verstehen.
Auf meinen kleinen 1.8ern (die grösseren benutz ich wegen der Sinnlosigkeit gar nicht) bekomme ich immerhin solche Spielereien wie Analoguhren mit nen paar Zusatzanzeigen grade noch "flüssig" hin (so dass der Sekundenzeiger halt nich ruckelt) aber das wars dann auch.
Dazu muss man aber wirklich die Aktualisierungen aufs Äusserste treiben, also wirklich konsequent nur das schreiben, was auch wirklich geändert werden muss-und zwar pixelweise.
Die TFT`s können ja nicht mal Text ausgeben, auch der wird rein grafisch gerendert.

[HaWe]

da gebe ich dir mal 100% Recht
Ich wäre ja gern bereit, auch mehr Geld auszugeben -
Displays für 40 EUR, u.a. welche direkt aus Italien oder Deutschland hatte ich aber auch schon durch, nur DIE funktionierten bisher ÜBERHAUPT nicht, mit KEINER Lib (insgesamt wohl ein Dutzend Displays vergblich auf dem Mega und Due durchprobiert!).
Jetzt endlich eines, was wenigsten auf beiden Plattformen ÜBERHAUPT funktioniert, wenn auch quälend langsam!

Aber erkennen muss man schon was bei 20 Tabellen-Zeilen und 4-5 Spalten für ca. 100 zu überprüfende Werte (bevor irgendwer fragt: für ein neuronales Backpropagation-Netz) oder für 1:1 Echtzeit-Grafik für die Pixie-Cam in voller Auflösung. 2.2" (240x320) ist schon sehr grenzwertig klein.

Wenn du mir also ein super schnelles Display, gerne auch 4", gerne auch Touch, empfehen könntest, das 100% mit 5V und 100% mit 3.3V und 100% mit Due und 100% mit Mega und 100% mit den SPI-Headern (und höchsten 2 extra DPins) funktioniert - ich würde es SOFORT nehmen, und dafür auch notfalls bis zu 100 EUR ausgeben.

Es muss nur wirklich schnell und zuverlässig funktionieren.

Irgendwelche 100%igen Vorschläge? 8-)

[Peter(TOO)]

Hallo,

Diese Displays _sind_ einfach nicht schneller, da sie z.b. keinen eigenen Bildschirmspeicher haben.
Rate mal, wieso ich schon paarmal sagte, dass es mehr oder weniger sinnfrei ist, sowas zu benutzen.
Das einzige was du machen kannst ist, die Ausgaben so zusammenkürzen, dass immer _nur_ das aktualisiert wird, was auch wirklich nötig ist.

Dazu muss man aber wirklich die Aktualisierungen aufs Äusserste treiben, also wirklich konsequent nur das schreiben, was auch wirklich geändert werden muss-und zwar pixelweise.

Ich musste das Problem mal so lösen, dass ich im RAM zwei Schattenkopien des LCD-RAMs angelegt habe.
Zuerst wurde dann alles in den einen Buffer geschrieben. Anschliessend wurden dann nur noch die Unterschiede zwischen den beiden Buffern ans Display gesendet.

Das Problem war, dass das Gerät schon bestand und somit auch das Display festgelegt war, mit einen Firmware-Update waren dann aber neue Features verlangt worden.

---- Nachtrag -----

War ein 128x64 Display.
Am Ende war das alles so schnell, dass man beim Text scroolen nur noch graue Balken sah, da kam das Display nicht mehr mit (Reaktionszeit).

MfG Peter(TOO)

[HaWe]

ist das jetzt ein Lösungsansatz für mein Adafruit-Display mit ILI-irgendwas-Treiber?
ich brauche nämlich WIRKLICH ein schnelles, das wenigstens nxtOSEK-Geschwindigkeit auf dem Due hat.

[Peter(TOO)]

Hallo,

ich brauche nämlich WIRKLICH ein schnelles, das wenigstens nxtOSEK-Geschwindigkeit auf dem Due hat.

DAS kannst du mit dem ILI-Chip und SPI schon mal vergessen.
Vielleicht mit dem Parallel-Interface des ILI?

Die theoretisch minimale Zeit wird durch die Übertragungszeit für einen Befehl und die Ausführungszeit für diesen gegeben.
Dann kommt eben noch die Intelligenz des Controller ins Spiel.
Wie viele Befehle braucht es z.B. für einen ClearScreen ......

MfG Peter(TOO)

[HaWe]

ja, ich dachte mir schon dass das mit dem ILI nicht geht, ich brauche aber eine Lösung, und zwar SPI, weil keine DPins mehr frei sind.
Wie gesagt, auch das EV3 Display läuft ja per SPI, aber ist rasendschnell.

Es muss also wschl eine komplett andere Hardware her.
Aber welche?

Die Befehle zur bisherigen Lib findest du in der Lib:
https://github.com/Nkawu/TFT_22_ILI9225
er scheint beim cls augenscheinlich tatsächlich mit schwarzen Pixeln zu übermalen, das ist ntl der performancemäßige Supergau.

also, wie gesagt, neues Spiel, neues Glück.
Am besten sogar 4" Touchscreen, denn der 2,2" ist eigentlich wirklich zu klein.

Aber mit superschneller SPI-Hardware für Mega und für Due (5V + 3.3.V) und Sketch 1.5.8 aufwärts.

[Peter(TOO)]

Hallo,

ja, ich dachte mir schon dass das mit dem ILI nicht geht, ich brauche aber eine Lösung, und zwar SPI, weil keine DPins mehr frei sind.
Wie gesagt, auch das EV3 Display läuft ja per SPI, aber ist rasendschnell.

Es muss also wschl eine komplett andere Hardware her.
Aber welche?

Also ich würde mal sehen, was da für ein Controller auf dem Schnellen Display ist!

Und dann nach einem LCD mit diesem Chip suchen!

Ich würde dieses schnelle LCD am Arduino anschliessen (Beim Due muss man etwas aufpassen, wegen den 3.3V).
Mit etwas Glück findet man eine passende Bibliothek, andernfalls passt man eine an oder schreibt eine Eigene.

MfG Peter(TOO)