-
        

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 14

Thema: Arduino TFT Display: total lahme Ausgabe!

  1. #1
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    09.10.2014
    Beiträge
    2.415

    Arduino TFT Display: total lahme Ausgabe!

    Anzeige

    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?

  2. #2
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    27.08.2013
    Ort
    Region Basel
    Alter
    59
    Beiträge
    2.435
    Hallo,
    Zitat Zitat von HaWe Beitrag anzeigen
    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)
    Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?

  3. #3
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    09.10.2014
    Beiträge
    2.415
    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 !
    Geändert von HaWe (12.12.2014 um 10:15 Uhr)

  4. #4
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    27.08.2013
    Ort
    Region Basel
    Alter
    59
    Beiträge
    2.435
    Hallo,
    Zitat Zitat von HaWe Beitrag anzeigen
    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)
    Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?

  5. #5
    Erfahrener Benutzer Roboter Genie Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    49
    Beiträge
    1.241
    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.
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  6. #6
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    09.10.2014
    Beiträge
    2.415
    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-)
    Geändert von HaWe (12.12.2014 um 12:45 Uhr)

  7. #7
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    27.08.2013
    Ort
    Region Basel
    Alter
    59
    Beiträge
    2.435
    Hallo,
    Zitat Zitat von Rabenauge Beitrag anzeigen
    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)
    Geändert von Peter(TOO) (12.12.2014 um 13:05 Uhr)
    Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?

  8. #8
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    09.10.2014
    Beiträge
    2.415
    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.

  9. #9
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    27.08.2013
    Ort
    Region Basel
    Alter
    59
    Beiträge
    2.435
    Hallo,
    Zitat Zitat von HaWe Beitrag anzeigen
    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)
    Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?

  10. #10
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    09.10.2014
    Beiträge
    2.415
    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.

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. SPI-TFT Display gesucht für Arduino Mega, nur (!) Pins 50-53 plus Spannung (o.Touch)
    Von HaWe im Forum Suche bestimmtes Bauteil bzw. Empfehlung
    Antworten: 20
    Letzter Beitrag: 12.11.2014, 11:29
  2. Antworten: 3
    Letzter Beitrag: 21.10.2014, 17:37
  3. Suche Raspberry PI TFT Display
    Von robosapiens im Forum Kaufen, Verkaufen, Tauschen, Suchen
    Antworten: 2
    Letzter Beitrag: 28.03.2014, 20:02
  4. TFT Display ansteuern
    Von HVflash im Forum AVR Hardwarethemen
    Antworten: 1
    Letzter Beitrag: 03.08.2010, 13:10
  5. TFT display ansteuern
    Von A.T.I.R im Forum Elektronik
    Antworten: 5
    Letzter Beitrag: 24.05.2005, 14:00

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •