MI0283QT-2 mitHX8347 ist echt langsam

Hallo Nils,

ich habe das Display an einem ATXMEGA128A1, der Controller läuft mit 
16MHz, SPI gerade mit 8 da Prescaler minimal 2 ist. Werde am WE mal auf 
16MHz SPI-Takt gehen aber ich habe wenig Hoffnung. Habe gestern zwischen 
2 MHz und 8 MHz gewechselt und die Geschwindigkeit ist gleich geblieben. 
Liegt also wohl nicht am SPI Takt.

Ich würde schon gerne das komplette Bild ändern. Da kommt später ein 
Menü drauf und je nach Auswahl /es lebe der Touch Screen) kommt dann was 
ganz anderes.

Gruß
Gepi

Hallo,

ich habe es erst angeschlossen und komm jetzt nicht dazu.

Unter http://www.youtube.com/watch?v=bm5Or11FYwI&feature=related gibts 
ein Video, das Display wird parallel im 16bit Modus angesteuert.

Wegen Schaltplan einfach nach dem Board googeln (OIC32MX4 von Microe).

Bei Microe gibts auch den Code zur Ansteuerung zum Download (für PIC32).

Gruß
Gepi

Hallo,

Code ist im Anhang (hoffe das klappt so). Der Code ist so ziemlich 
dasselbe wie der, den man bei Watterott runterladen kann.
Für die parallele Ansteuerung habe ich noch keinen eigenen Code, gerade 
keine Zeit.

Zur seriellen Ansteuerung: Im Datennblatt steht Serial Clock Cycle min. 
20ns.
Gehen wir also vom Minimum aus, dann kann ich den Controller in einer 
Sekunde mit 50 Millionen bits vollballern (theoretisch, so wie ich SPI 
verstanden habe), meine 8MHz SPI-Takt sollte der Controller also können. 
Wenn ich nun bei 8MHz pro Periode 1 bit übertrage und ich pro Pixel mit 
16 bit Farbtiefe 16 bits brauche, dann dürfte es ~154ms dauern bis ich 
das Display in einer Farbe befüllt habe. Ich hab jetzt keine Ahnung ob 
und wenn ja wie lange mein ATXMEGA braucht das SPI Senderegister neu zu 
beschreiben? Evtl kommt da aber noch was drauf.

Jedenfalls hab ich den Controller angesteuert über SPI mit 8MHz und 
brauche ~0,5 Sekunden bis das Display "voll" ist. Das ist mir zu langsam 
wenn ich dem Bild beim Aufbau zuschauen muss.

Code für parallele Ansteuerung gibts bei mikroe.com, muss man eben bissl 
suchen.

Gruß
Gepi

Wie ist denn das Display vom Kontrast, Blickwinkel und 
Tageslichtempfindlichkeit?

Im Manual stehen ja ganz imposante Blickwinkel (bis zu 80°), ist das 
realistisch?

Vielen Dank, Stefan

Moin zusammen,

ich habe ein STM32F4-Discovery erstanden. Nettes Teil :)

Würde nun gerne ein TFT (via SPI) anschliessen, und bin über das 
Watterott TFT (http://www.watterott.net/projects/mi0283qt) gestolpert. 
Nun eine einfache (hoffentlich richtige) Rechnung:

Der STM32 läuft mit 168Mhz. Er sollte also sagen wir 48Mhz SPI Takt 
schaffen (< 168/2). Minimale SPI Taktlänge des HX8347 ist lt. Datenblatt 
20ns, also max. 50Mhz Takt. Das würde bei 320x240x16Bit folgende Zeit 
für das komplette Schreiben des Bildschirms (Nur Pixeldaten) geben:
>>> 1000/(48e6/(320*240*16))
25.6ms, entspricht ca. 39 Frames pro Sekunde. Das wäre also schon mehr 
als Videotauglich :).

Ich frage mich nun ob sich die theor. Daten auch in der Praxis 
errreichen lassen. Kommen die verbauten Pegelwandler 74LVC244 (lt. 
Layout der Adapterplatine) da mit (lt. Datenblatt, würde ich sagen ja? 
unsicher). Hat schon jemand hier praktische Erfahrungen gesammelt und 
kann hier berichten?

Ich sehe gerade im Datenblatt dass der STM32F407VG nur max. 37.5MBit/s 
auf SPI1 kann. SPI2 und SPI3 können max. 21MBit/s. Das entspricht dann 
für SPI1 32 ms pro Frame oder 31 Frames/s.

Hmm hat der TFT Controller eigentlich ein Dual Framebuffer, so dass man 
Puffer A füllen kann und dann umschaltet auf Puffer B (d.h. Bildaufbau 
nicht sichtbar, ... mal schauen.)

Kai O. schrieb:
> ich habe ein STM32F4-Discovery erstanden. Nettes Teil :)
>
> Würde nun gerne ein TFT (via SPI) anschliessen, und bin über das
> Watterott TFT (http://www.watterott.net/projects/mi0283qt) gestolpert.


Das habe ich auch gerade gemacht und mal ne Anwendung gebaut die einen 
Testbildschirm anzeigt (Farbverlauf)

Der Code ist weder schön noch effizient, was ich aber noch ändern will. 
Der Einstieg mit dem Display auf nem STM32F2 oder F4 ist damit aber 
schnell möglich.

Schau dir mal das hier an

http://www.mafu-foto.de/elektronik/arduino/98-touch-library-fuer-arduino-und-watterott-mi0283qt-2-display

ist zwar kein Xmega aber das sollte sich ja portieren lassen...

Hi ich möchte das Thema nochmal aufgreiffen.
Hab das gleiche Problem wie ganz oben

Also ich habe einen MSP430F247 und steuere den mit SPI 16MHZ
und bei mir braucht das ding auch rund 500ms.
Hat irgendwer ne idee an was es liegen könnte?
Hab eig. zum größte Teil den Orginal Treiber verwendet( HX8347)

Was ich festgestellt habe ist, dass ein einzelner draw(color)
ca 8us braucht.
Das sich natürlich bei 320*240*8 extrem bemerkbar macht (das is die 
Hauptbremse würd ich sagen)
Mein erster Ansatz war das ich diese 2* wr_SPI(data) in 1 wr_SPI(data) 
zusammengefasst habe was schonmal 1 call einspart. (hat auch ca. 100ms 
gebracht).
Aber jetzt weiß ich auch nicht mehr weiter... evtl SPI zu lansam? ka..

Hat schon jemand das ding mit SPI vernünftig ans laufen gebracht?

mfg Sogge

Geht aber leider ned hab nur max. 16MHZ, über den externen quarz, zur 
verfügung (die Hardware ist schon fix)
Da der MC nicht mehr kann.

Hat irgendwer noch eine andere Idee? Software technisch? is da noch was 
raus zu holen?
Wie gesagt nutze eig. den orginal Treiber