A137 Touch TFT 320 x 240 unter 5€

[Torsten C. (torsten_c)]

Hallo zusammen,

der Markt wird gerade von solchen Touch-TFT Schields "überschwemmt":

Beitrag "Re: China SUPER Bauteile-Schnäppchen Thread"

Ich bin gerade dabei, die Gamma-Korrektur zu optimieren. Außerdem 
benötigen die Bibliotheken, die ich gefunden habe, vier Schreib- 
zugriffe pro Pixel und nutzen teilweise nur 65536 Farben, so wie in den 
Beispielbildern in der Anlage.

http://misc.ws/2013/11/08/touch-screen-shield-for-arduino-uno/

Eigentlich sollten aber laut Datenblatt auch
> "8-bit interface (3 transfers/pixel) 262 144 colors"
gehen, wo pro Transfer nur die 6 MSBits benötigt werden.

Vielleicht gibt's das schon irgendwo und ich hab's übersehen. Wir wissen 
auch nicht, wie lange der "Hype" noch anhält. Wenn ich fertig bin und 
Interesse besteht, kann ich den Code auf github aktualisieren.

https://github.com/TorstenC/A137_TouchTFT_320x240

[Martin S. (der_nachbauer)]

Wen's interessiert:

Von Sprite gibt es für solche Displays mit ILI Controller einen Artikel, 
der beschreibt, wie man (z.B.) für den Raspberry einen Kerneltreiber 
erstellt.
Damit kann man dann den X Desktop auf den Teilen anzeigen - praktisch 
für "aufwendigere" UIs.

http://spritesmods.com/?art=rpi_arcade&page=2

Lässt sich relativ leicht anpassen, ich habe das mit einem meiner 
Displays mal ausprobiert - funktioniert prima.

[Torsten C. (torsten_c)]

Martin Schröer schrieb:
> für den Raspberry

Danke für die, die damit was machen.

> touchscreen isn't connected: it wouldn't have much use on a mini
> arcade case, and would require extra hardware to get working
> because the RPi doesn't have integrated AD-converters

Der Raspberry ist ja knapp 10 mal so teuer wie das Dislplay-Shield. In 
der Bibliothek ^^ geht's darum, das "billige" Display so billig wie 
möglich als Bedieneinheit einzusetzen, also als Ersatz für LEDs und 
Taster.

BTW: Ich habe gerade die Gamma-Korrektur mit den RGB-Werten gemacht und 
siehe da: Es kommt was Vernünftiges bei 'raus. Die Hardware-Gamma- 
Korrektur ist nur "finetuning". Der Gamma-Wert liegt um und bei 2.6, 
also ziemlich hoch.

Hat jemand so ein Display mit ILI9325, ILI9328, HX8347G oder SPFD5408 am 
"Uno R3" im Einsatz?

Ich bin gerade dabei, die Schriftarten und Widgets (Touch-Tasten) so zu 
zerlegen und zu komprimieren, dass sie in den engen Flash des "Arduino 
Uno R3" passen.

[Gerri (Gast)]

Tolles Projekt!


Torsten C. schrieb:
> BTW: Ich habe gerade die Gamma-Korrektur mit den RGB-Werten gemacht und
> siehe da: Es kommt was Vernünftiges bei 'raus. Die Hardware-Gamma-
> Korrektur ist nur "finetuning". Der Gamma-Wert liegt um und bei 2.6,
> also ziemlich hoch.

Bekommt die Hintergrundbeleuchtung eventuell zu wenig Spannung?

[René B. (reneb)]

Hallo,

schickes Display. Kann man das auch an anderen Controllern z.B. über ein 
Speicherinterface anschließen oder den Zugriff beschleunigne, indem man 
z.B. den SRAM-Ausgang des AVR nimmt (z.B: beim ATmega162 vorhanden)?

Kann der Controller auch noch mehr, oder muss ich den Bildaufbau immer 
selbst Pixel für Pixel am µC vornehmen?

[Torsten C. (torsten_c)]

René B. schrieb:
> Kann man das auch an anderen Controllern z.B. über ein
> Speicherinterface anschließen oder den Zugriff beschleunigne, indem man
> z.B. den SRAM-Ausgang des AVR nimmt (z.B: beim ATmega162 vorhanden)?

Ja klar. Die Pins am Shield sind allerdings für den UNO R3, diesen 
Vorteil würde man dann nicht nutzen. Ansonsten gibt's auch einen Haufen 
anderer billiger Dispays, auch größer und unter 10€. Aber fast alle mit 
den o.g. (fast identischen) Controllern: ILI9325, ILI9328, HX8347G oder 
SPFD5408.

Vorteil dieses Shields: Die Pegelanpassung auf 5V ist schon drauf. Auf 
einem Arduino Mega würde es auch passen, wäre aber langsamer, weil der 
Datenbus auf mehrere Ports verteilt ist.

Beim Arduino Due, ST32F4Discovery usw. (3,3V) kann man auch Displays 
ohne Pegel-Anpassung anschließen.

> Kann der Controller auch noch mehr, oder muss ich den Bildaufbau immer
> selbst Pixel für Pixel am µC vornehmen?

Außer scrollen kann der nix.

Man setzt sich einen "Viewport" und legt die Increment-Richtung fest 
(z.B. "Top Down Left Right" oder jede andere Kombination) und ballert 
dann einfach nacheinander 2 oder 3 Bytes pro Pixel raus, also nach jedem 
Byte einmal kurz WR auf Low.

Ich bin gerade dabei, die Schriftarten im µC-Flash abzulegen und 
effizient in einen Viewport zu schreiben.

[Fritz (Gast)]

Kann man auf dem Display eigentlich auch was erkennen wenn die 
Hintergrundbeleuchtung aus ist?
Ich such noch eine Display in der Größenordnung, dass man im Freien auch 
ohne Beleuchtung (wegen Akkuverbrauch) gut ablesen kann

[Torsten C. (torsten_c)]

Hallo zusammen,

ich bin gerade dabei, eine Codepage "zusammen zu schustern". In den 
üblichen west- oder mitteleuropäischen Codepages sind viele 
typografische Glyphen, die ich nie benötigt habe. Andererseits kann man 
für einen Touchscreen sicher viele in mehreren Schriftarten verfügbare 
Glyphen gut gebrauchen, z.B. für Wetterstationen, Checkboxen usw.

Wie seht Ihr das?

Anbei mal ein Codepage-Entwurf; bei den blau hinterlegten Codes habe ich 
mich an die Standards gehalten.

Die Schfiftart "Segoe UI" hat z.B. alle o.g.Glyphen!

Bei den folgenden Schriften fehlen nur wenige:

In „Arial Unicode MS“ fehlen: ⏏⟲⟳⦾⦿⬆⬇
In „Lucida Sans Unicode“ fehlen: ⏏☀☁☂☃☇☎☐☑☒☽☾⟲⟳⦾⦿⬆⬇�
In „Consolas“ fehlen: ‣↗↘↶↷↺↻⇒⇔⇦⇧⇨⇩∀∃∄∅≙⏏◐◑◒◓◔◕☀☁☂☃☇☎☐☑☒☽☾⟲⟳⦾⦿⬆⬇�

Also, falls noch jemand Verwendung hat, meldet Euch bitte, es sind noch 
"Plätze frei".

[Torsten C. (torsten_c)]

Mit einer einfachen Lauflängenkodierung für die "antialiased" Glyphs 
ergeben sich für eine fast komplette Codepage (s.o.) übrigens einige 
"optimale" Größen, siehe erstes Bild.

Ein 26 Pixel-Font benötigt mit rund 15 KiB also etwa die Hälfte des 
Flash-Speichers eines „UNO R3”, siehe zweites Bild.

[Torsten C. (torsten_c)]

Ich habe mal 'ne Frage: Hat schon mal jemand Störungen im Radio gehabt, 
mit so einem Touch-Screen? Ich habe nur so ein FM/AM Radio im Auto und 
bin noch nicht zum ausprobieren gekommen.

Der Touchscreen funktioniert ja quasi wie zwei Potentiometer. Bei dem 
A137-Shield werden die Potentiometer-Enden recht hochfrequent zwischen 
0V und 5V hin und her geschaltet, weil sie zusammen mit den 
Datenleitungen an den gleichen Pins angeschlossen sind. Der Touchscreen 
ist ja eine großflächige Sende-Antenne.

[Torsten C. (torsten_c)]

René B. schrieb:
> Kann man das auch an anderen Controllern z.B. über ein
> Speicherinterface anschließen oder den Zugriff beschleunigne, indem man
> z.B. den SRAM-Ausgang des AVR nimmt (z.B: beim ATmega162 vorhanden)?

Verschiedene Touch-TFTs mit 320 x 240 Pixel gibt's ja haufenweise bei 
Aliexpress. Der Witz bei diesem A137 ist, dass es ohne Löten auf ein 
Arduino Uno passt.

Aber um die Frage zu beantworten: Ja, wenn man die Pins ensprechend 
zuordnet geht bei allen, die ich kenne, auch die Speicher-Schnittstelle, 
und natürlich auch entsprechend schnell. In Kombination mit DMA geht's 
dann wohl nochmal schneller.

Fritz schrieb:
> Kann man auf dem Display eigentlich auch was erkennen wenn die
> Hintergrundbeleuchtung aus ist?

Ich hab's noch nicht probiert, melde mich dann aber.

[Torsten C. (torsten_c)]

Die Hintergrundbeleuchtung ist über 22 Ohm-Widerstände direkt an einen 
AMS1117 3,3V-Regler angeschlossen und läuft konstant (ohne PWM) mit 
11,4..12,9mA.

Gerri schrieb:
> Bekommt die Hintergrundbeleuchtung eventuell zu wenig Spannung?

Also 20mA könnte sie sicher ab und wäre dann heller.

Fritz schrieb:
> Kann man auf dem Display eigentlich auch was erkennen wenn die
> Hintergrundbeleuchtung aus ist?

Ich müsste 'ne Leiterbahn durchtrennen, um das auszuprobieren; das habe 
ich im Moment nicht vor.

[Fritz (Gast)]

Torsten C. schrieb:
Ich müsste 'ne Leiterbahn durchtrennen, um das auszuprobieren; das habe
> ich im Moment nicht vor.

Ok alles klar, trotzdem danke, werd mir bei Gelegenheit wahrscheinlich 
selbst mal ein, zwei Module bestellen und selbst testen.

[Torsten C. (torsten_c)]

So, der Touchscreen läuft nun auch. Um die Standardabweichung (s. 
Anlage) etwas zu verringern, werde ich es morgen nochmal mit
> "ADC Noise Canceler = ON"
probieren.

z="0" heißt dabei: Keine Last, z="7" heißt 7 Batterien als Last, siehe 
Foto.

[Fallpauschale (Gast)]

Hallo Thorsten,

vielen Dank für Deine Arbeit. Ich hab mir auch so ein Display geholt und 
auf das Arduino Uno gesteckt. Als IDE nutze ich immer Eclipse mit WinAVR 
(flashen mit avrdude). Leider will dein Quellcode nicht übersetzt 
werden. Das inline will der avr-gcc wohl so nicht. Aber prinzipiell muss 
das ja auch ohne funktionieren, wenn auch nicht so effektiv.

Leider wird gar nichts angezeigt. Nun weiß ich eben nicht, ob es an der 
Hardware liegt, oder ob doch noch ein Fehler in der Software ist.
Wäre es möglich, ein fertiges .hex File zu veröffentlichen?

Vielen Dank
Dani

[Karsten B. (karstenbrandt)]

Hallo Thorsten,

Danke für Deinen Code auf github. Super Arbeit. Nun tut mein 
Display-Shield auch auf meinem Arduino DUE :)
Mit Deine IO-Funktionen mit Modifikationen in Arduino übernommen. Wie 
gesagt, es läuft.
Zwischenzeitlich fand ich auch noch eine eine Bibliothek auf CooCox : 
http://www.coocox.org/driver_comp/spfd5408-c1059.html?mc=4&sc=24
Die Zeichen- und Textfunktionen von denen habe ich übernommen, da diese 
etwas flexibler und schneller sind.

Aber nochmals: Danke für Deine Arbeit.
Vielleicht kannst Du Deine Bibliothek auf github noch aktualisieren.

Gruß

Karsten

[PD (Gast)]

Hallo,

ist es möglich das Display per SPI zu betreiben? Ich habe auch Interesse
an dem Display würde aber gerne nicht so viele Pins verbrauchen.

Gruß, PD

[Torsten C. (torsten_c)]

Nein, höchstens ganz langsam z.B. mit einem MCP23S17.

Alternativen:

http://www.aliexpress.com/item/-/1926403267.html

"all interface" ist eindeutig mit SPI. Vielleicht auch dieses,
aber ohne Gewähr:

http://www.aliexpress.com/item/-/972762808.html

Aber langsamer ist der Bilschirmaufbau dann trotzdem.

[Torsten C. (torsten_c)]

Karsten Brandt schrieb:
> Vielleicht kannst Du Deine Bibliothek auf github noch aktualisieren.

Hmmm, bin auf STM32 umgestiegen. Wenn das fertig ist, dann gibt's die 
Lib für den STM32. Sorry.

Wer sich einen Schaltplan bauen will: Ich habe das Display mal 
abgeknibbelt.

[Torsten C. (torsten_c)]

Karsten Brandt schrieb:
> Vielleicht kannst Du Deine Bibliothek auf github noch aktualisieren.

PS: Ich habe mein letztes Projekt mal hochgeladen, der Code sieht nicht
"schön" aus, aber funktioniert. Vielleicht hilft es Dir oder 
irgendjemandem. Touch geht jedenfalls. Bei Gelegenheit mache ich nochmal 
ein YouTube-Video vom TimeTimer:

https://github.com/TorstenC/A137_TouchTFT_320x240/tree/master/Mikrocontroller/Atmel%20Studio/TimeTimer

Viele Infos gibt es übrigens auch im 
Beitrag "2.4" Display-Shield (SPFD5408) an Aduino DUE"

[Torsten C. (torsten_c)]

Kleines Preis-Update, nun für 3€:

> 93.8% of buyers enjoyed this product! (44 votes) 176 orders

http://www.aliexpress.com/item/-/32254339975.html

[Neuling (Gast)]

Guten Tag,
dank euer Beitrag konnte ich mein Display, welches von mir schon
eigentlich aufgegeben wurde jetzt wieder belebt werden.
Was ich aber fragen wollte , gibt es auch eine Libraries
wie für das 3,2 Zoll Display und wo kann man sie finden?
Danke an euch

[Torsten C. (torsten_c)]

Neuling schrieb:
> das 3,2 Zoll Display

Welcher Chip ist denn da drauf? Vielleicht einer von denen hier?

#define  ILI9320    0  /* 0x9320 */
#define  ILI9325    1  /* 0x9325 */
#define  ILI9328    2  /* 0x9328 */
#define  ILI9331    3  /* 0x9331 */
#define  SSD1298    4  /* 0x8999 */
#define  SSD1289    5  /* 0x8989 */
#define  ST7781     6  /* 0x7783 */
#define  LGDP4531   7  /* 0x4531 */
#define  SPFD5408B  8  /* 0x5408 */
#define  R61505U    9  /* 0x1505 0x0505 */     
#define  HX8347D    10 /* 0x0047 */
#define  HX8347A    11 /* 0x0047 */  
#define  LGDP4535   12 /* 0x4535 */  
#define  SSD2119    13 /* 3.5 LCD 0x9919 */

Quelle: http://radiokot.ru/circuit/digital/home/174/01.txt

[Torsten C. (torsten_c)]

Hier auch als Set, aber vieiel zu teuer:
http://www.banggood.com/UNO-R3-ATmega328P-Board-2_4-Inch-TFT-LCD-Screen-Module-For-Arduino-p-945755.html