Arduino TFT Display: total lahme Ausgabe!

[HaWe]

hi,
warum sind die Arduino Displays so total lahm bei der Ausgabe von Schrift und Grafik!?
Im Vergleich zu Lego NXT und EV3 Displays brauchen die ja 200 - 300x so lang bei identischen Tests!
Das ist ja zum Davonlaufen!

http://www.mindstormsforum.de/viewto...tart=60#p64772

Kann man das SPI oder die Algorithmen irgendwie mal deutlich beschleunigen?

Oder gibt es andere deutlich schnellere Display-Alternativen?

[Peter(TOO)]

Hallo,

http://www.mindstormsforum.de/viewto...tart=60#p64772

Kann man das SPI oder die Algorithmen irgendwie mal deutlich beschleunigen?

1. Welche Displays vergleichst du da?
2. Seriell (SPI, IIC), 4-Bit und 8Bit sind nun mal unterschiedlich schnell.
3. Welche Bibliotheken verwendest du? Universelle Bibliotheken sind auf das langsamste Display auf dem Markt zugeschnitten, soll ja mit allen auf Anhieb funktionieren.

Wenn du den NXT/NXC mit dem Arduino Due vergleichst ist der Due beim Rechnen 500-1'000 mal schneller. Auch wenn die Bibliothek hundsmiserabel codiert ist, können die Algorithmen gar nicht so langsam sein. Bleibt also nur das Interface, und dessen Code, welches bremst.

Grundsätzlich gibt es zwei grundlegende Varianten einen Treiber aufzubauen:
1. Man macht zuerst alle Berechnung und legt die Daten ans Display in einem Buffer ab, dann wird der Buffer ans Display gesendet.
2. Man gibt die einzelnen Zwischenresultate gleich ans Display aus.

Bei einem langsamen Prozessor und einem langsamen Display kann man mit 2., im Idealfall, die Ausgabezeit nahezu halbieren.

Ach einen grossen Unterschied macht die Implementierung des Display-Interfaces aus.
Bevor man Daten ans Display senden kann, muss man erst abfragen, ob das Display noch busy ist, also noch irgendeinen Befahl abarbeitet.
Dazu hat man auf Low-Level zwei Möglichkeiten:
1.
Warten bis nicht Busy
Befehl oder Daten ausgeben

2.
Befehl oder Daten ausgeben
Warten bis nicht Busy

Bei 2. verliert man unnötig Zeit, denn Display und Prozessor könnten parallel weiter rechnen!

Beim NXT verwendest du vermutlich immer die selbe Hardware, ebenso bei den EV3.
Da vergleichst du also nur die Software, zumindest innerhalb der Gruppe.

Bei den Arduinos hast du andere Hardware. Die Rechentests sind vergleichbar mit den Anderen CPUs.

Beim Displaytest müsstest du aber unterschiedliche Displays mit den passenden Bibliotheken vergleichen. Möglicherweise hast du nur die lahmste Variante auf dem Markt ergattert. Das sagt also nichts über den Arduino selbst aus!
Dein Display Test besagt nur, dass das Verwendete Display mit der verwendeten Bibliothek, ne lahme Ente ist.

Der Unterschied zwischen NXT/NXC NXT/leJOS bei der Graphik liegt rein an der Software. Lustigerweise ist der leJOS bei Graphik viel langsamer und bei Text einiges schneller.

Die grundsätzliche Frage ist WAS du vergleichen willst?
Out of the Box Systeme oder was sich, mit etwas Optimierung (z.B. bessere Bibliotheken), aus der Hardware rausholen lässt?

MfG Peter(TOO)

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