Hallo Zusammen,
da ich gerade etwas Lust zum spielen habe und hier ein kleines
TFT-Display
(
http://www.instructables.com/id/Cheap-TFT-22-inch-Display-on-Arduino-ILI9340C-or-I/
)
rumliegt, habe ich es mal in Betrieb genommen.
Ich habe es an einen Arduino DUE angeschlossen, die Libs von Adafruit
runtergeladen und siehe da: es funktioniert ohne Probleme.
Inbetriebnahme: ca. 30 Minunten.
Jetzt überlege ich mir, was man Lustiges damit machen könnte.
Hier eine kleine Funktion um den Adc anzuzeigen:
Hier mal eine Version für einen deutlich schnelleren Signalupdate. Damit
wird das Signal im Bildschirm "flüssig". Man merkt sich einfach das
letzte Signal und überzeichnet dann die alte Linie mit "schwarz". Der
Vorteil: eine Linie Zeichnen braucht weniger Punkte als eine Bereich
löschen.
Der Nachteil: Mit dem Speicher auf einem Arduino Uno wird es eng.
Was möchtest Du uns mitteilen?
Das machen täglich 100 Leute in 10 Minuten und die hälfte davon
schreiben in Foren ihre Probleme!
Das die Displays nix kosten ist auch jedem hier klar, soll das ein
Projekt werden?
>Na dann programmiere doch Pac-Man, Phönix-Arcade oder wenigstens den>Amiga-Ball drauf.
Das wäre eine lustige Idee. Einfach das fertige boing.c nehmen und die
Grafikroutinen umbiegen:
https://github.com/glfw/glfw/blob/master/examples/boing.c
Allerdings ist vermutlich die SPI zum Display zu lahm.
Markus schrieb:> Die MISO Leitung ( braun ) scheint man nicht zu brauchen.
Das wäre für solch ein einfaches Display auch seltsam.
MISO heißt einfach, Master Input <- Slave Output
Was sollte dir da der Slave auch mitteilen. Bei der Verwendung von den
Cardslot könnte das anders sein. Damit habe ich mich aber nicht
beschäftigt ob dieser nur für den Controller IC da ist, oder aber auch
für den Atmega
Markus F. schrieb:> Was sollte dir da der Slave auch mitteilen.
Da bist du offensichtlich noch sehr am Anfang deiner Kenntnisse
über Displays.
Intelligente Applikationen können das auslesen was im Display-
Speicher geschrieben steht um diese Daten zu verändern.
Ausserdem ermöglich das Lesen die Fähigkeit zu kontrollieren
ob überhaupt ein Display angeschlossen ist und welche Infos
der Hersteller gespeichert hat.
Nicht zuletzt könte man sich eine Loopback Funtionalität
schreiben welche die Zuverlässigkeit der Datenübertragung
überprüft/bestätigt.
Arduinoquäler schrieb:> Da bist du offensichtlich noch sehr am Anfang deiner Kenntnisse> über Displays.
Dies mag ich nicht verneinen und kann mir das auch sehr gut bei
Komplexeren aufgaben sehr gut vorstellen. Was ich mir aber nicht
vorstellen kann ist, das diese Funktionen von den meisten Arduino Usern
sinnvoll genutzt werden. Die gewünschte Interaktion mit einen Display
beschränkt sich dort meistens doch eher auf die Anzeige.
>Was ich mir aber nicht vorstellen kann ist, das diese Funktionen von den> meisten Arduino Usern sinnvoll genutzt werden.
Für einen Arduino UNO ist es nützlich, weil 2K Ram nicht für ein Bild
ausreicht.
Der Arduino DUE hat dagegen genug Speicher.
STMler (Gast)
>Markus schrieb:>> Allerdings ist vermutlich die SPI zum Display zu lahm.>Nö, wieso?>Bei mir läuft der Ili9341 mit 20MHz am STM32 und DMA ohne Probleme.
Ein sehr guter Hinweis. Standardmäßig ist die Arduino DUE SPI auf 4MHz
gestellt:
https://www.arduino.cc/en/Reference/SPISetClockDivider
Hinter tft.begin kann man den Clock für den Arduino DUE hoch setzen:
1
tft.begin();
2
SPI.setClockDivider(5);
Ich habe ihn mal auf 5 gestellt, also 84MHz/5=16.8Mhz
Damit läuft das ganze etwas schneller. Allerdings nicht so viel
schneller wie es die Clock hergeben würde. Zwischen den SPI Bytes sind
Lücken weil in der SPI-Lib nicht die DMA verwendet wird:
https://github.com/arduino/Arduino/blob/master/hardware/arduino/sam/libraries/SPI/src/SPI.cpp
Sie nutzt einen Interrupt. Da gäbe es also etwas Optinierungsbedarf.
Markus schrieb:> Da gäbe es also etwas Optinierungsbedarf.
Jetzt brauchst du also nur noch die doofen Universal-Libs
von Arduino durch selbstgeschriebene ersetzen damit du hier
nicht immer herumjammern musst dass alles so langsam ist.
ef schrieb
>https://cdn-shop.adafruit.com/datasheets/TM022HDH26_V1.0.pdf dieses>Display wird von Adafruit verwendet.
Das Adafruit-Display unterscheidet sich von den 4€ Displays: Es hat
Pegelkonverter für 5V eingebaut. Ich bin mir also nicht sicher, ob man
die LED-Versorgung vergleichen kann.
Pegelkonverter sind auf der blauen Adafruit Printplatte, hier geht es
aber um das Display an sich. Im Datenblatt zum Displaymodul wird
angegeben, wie viele LEDs verbaut wurden und wie hoch If/Uf sind.
Auf den roten Printplatten von ebay ist oft nur ein 3.3V LDO + SD card
slot.
Hallo @Marksu,
Marksu schrieb:> Ich habe es an einen Arduino DUE angeschlossen, die Libs von Adafruit> runtergeladen und siehe da: es funktioniert ohne Probleme.> Inbetriebnahme: ca. 30 Minunten.
kannst du mal hier die Libs auflisten, die du verwendest?
Und wieviel Flasch belegen die Libs (in Kb) ?
Danke!
Hier ein Sketch für einen durchlaufenden Zähler auf dem Display.
Es ist ein gewisser Aufwand: Die Library löscht beim Textzeichnen den
Hintergrund nicht. Deshalb muss man vorher ein gefülltes Rechteck über
die alten Werte zeichnen.
Ergebnis des Compiler bzgl. Speicherauslastung:
"Der Sketch verwendet 18.380 Bytes (3%) des Programmspeicherplatzes. Das
Maximum sind 524.288 Bytes."
Man könnte eigentlich mit der Kombination Arduino DUE und 2.2' TFT ein
schönes Universalmessgerät basteln.
Hier mal am Beispiel Frequenzzähler. Mein Signalgenerator kommt leider
nicht ganz auf die 10MHz. Theoretisch sollte der DUE-Frequenzzähler aber
22MHz können.
Es gibt 1000 schöne Projekte wenn man mal google nutzt und bestimmt 20
Libs.
z.B
U8G
Utft
Dazu gibt es noch soviele "tolle" Standard Libs, da kann man seine
eigene Implementierung für das Display einbringen.. diese muss man von
einer vorhandenen Lib fast nur noch rüberkopieren.
EDIT: Hab so eines auch noch rumliegen und habe eine Große Auswahl an
Code falls ich es benutzen möchte.. vor dem Kauf "ergoogelt".
>z.B>>U8G>Utft
U8G: Die hatten wir schon, sie für einfarbige LCDs:
https://github.com/olikraus/u8glib
Utft: Das könnte interessant sein, allerdings wird nur das ILI9341
aufgeführt und nicht das ILI9340, möglicherweise sind die aber gleich?
https://github.com/dgolda/UTFT/tree/master/tft_drivers>Es gibt 1000 schöne Projekte wenn man mal google nutzt und bestimmt>20 Libs.
Ja, das ist war. Im Grund braucht man die Unterhaltung im MC-Netz gar
nicht, weil schon alles "im Google" steht ;-)
Scherz bei Seite: Dieser Thread dient als Anleitung für die schnelle
Inbetriebnahme des Displays und zum Erfahrungsaustausch über gute
Software dazu.
Ist mir jetzt zu hoch wieso man ein einfaches 1000gleiches SPI Display
zum 1000sten durchkauen muss.
Nur mal so daherbefürchtet.. ili9325,9340,9341 und andere haben höchst
identische SPI Instruction Sets damit es schonmal läuft.. Eventuell muss
man nur nen bisschen die initialisierung anpassen und das Datasheet
lesen.
Philipp K. schrieb:> Ist mir jetzt zu hoch wieso man ein einfaches 1000gleiches SPI Display> zum 1000sten durchkauen muss.
Markus möchte eben auch ein bisschen mit herumlabern. Das ist
die Begeistung die daraus spricht mit wenigen Klicks und
ohne wirkliche Eigenleistung etwas zustande gebracht zu haben.
Das wirst du doch verstehen, oder?
Mir scheint, Du bist hier etwas schwerer von Begriff, deshalb wiederhole
ich einfach noch mal den Satz von oben:
>Scherz bei Seite: Dieser Thread dient als Anleitung für die schnelle>Inbetriebnahme des Displays und zum Erfahrungsaustausch über gute>Software dazu.
Kannst Du folgen?
Da Deine Beiträge dem Ziel des Thread abträglich sind und zum Thema
nichts beitragen, poste wo anders. Mach Dein eigenes Thema auf.
Markus schrieb:> Kannst Du folgen?>> Da Deine Beiträge dem Ziel des Thread abträglich sind und zum Thema> nichts beitragen, poste wo anders. Mach Dein eigenes Thema auf.
Wen meinst Du?
Also zum Thema, hier hilft jeder mal gerne, da ist Deine Überschrift
schon zu beklagen und vielleicht auch das falsche Forum gewählt worden.
Ich würd sogar fast "Verschieben" in Projekte oder Offtopic vorschlagen
da dieser Thread keiner Hilfe Bedarf oder zur allgemeinen Information
Beiträgt wenn man dazu befähigt ist den ersten Google Beitrag der
Adafruit Library anzuklicken (Tolles Tutorial).
>Wen meinst Du?
Nicht Dich. Ich meine den Typen, der hier die letzte Zeit in
verschiedene Threads unter verschiedenen Psydonymen reingrätscht und die
Qualität des MC-Net ganz massiv stört. Hier nennt er sich sich
LCDLiebhaber, Arduinoqualer und in anderen Thread c-hater oder cyblord.
>Also zum Thema, hier hilft jeder mal gerne, da ist Deine Überschrift>schon zu beklagen und vielleicht auch das falsche Forum gewählt worden.
Ich weiß, es ist einigen Leuten ein Dorn im Auge, wenn hier der Begriff
"Arduino" auftaucht. Aber ich bitte zu bedenken, dass es oben in der
Leiste sogar einen Filterknopf für den Begriff gibt.
>Ich würd sogar fast "Verschieben" in Projekte oder Offtopic vorschlagen
Das würde ich überhaupt nicht vorschlagen. Der Thread ist eine
Hilfestellung für die Inbetriebnahme und die Optimierung des Displays.
Wenn Du genau hinschaust, findest Du einige Ergebnisse:
1. beschleunigtes Kurvenzeichnen für Analogsignal
2. Hinweise zur Optimierung der SPI am Arduino DUE
3. Link auf das schwer zu findende Datenblatt des Displays
4. Schaltplan für den Displayanschluss, passend zum geposteten Code
Ich bemühe mich, den Thread dahingehend klar strukturiert zu halten. Das
ist in keinster Weise ein Laber-Thread.
Und um es gleich zu sagen: Die Adafruit-Bibliothek ist nicht das Ende
der Fanenstange. Dieser Thread kann dazu dienen, falls jemand eine
bessere, schnellere Bibliothek kann er sie hier posten.
Es gibt hier im Thread auch einige Codebeispiele, die man einfach
herunter laden kann und in 2 Minuten ausprobieren kann. Open-Source lebt
von solchen Beispielen. Ich weiß, mittlerweile gibt es eine zunehmende
"Nehmer-Einstellung" ... die Leute wollen alles in Google finden und
nichts mehr beitragen.
Ein allgemeiner Hinweis auf Google ist allerdings zu nichts nütze. Schau
Dir einmal Stackoverflow an, dort sieht man, was Qualität ist.
Wenn Dir der Thread zu "low-level" ist, dann müsstest Du Dir einen
anderen suchen.
Ich benutze selbst nur Arduino und Notepad++.
Markus schrieb:> 1. beschleunigtes Kurvenzeichnen für Analogsignal
Wäre jeder mitm 8bitter draufgekommen um den geringen SPI Speed zu
kompensieren.
> 2. Hinweise zur Optimierung der SPI am Arduino DUE
Naja mit den 16,8Mhz biste schon nah dran .. ein Write Clockcycle darf
66ns lang sein.. könnte bedeuten, ich bin jetzt kein Profi, aber da
sollten 30Mhz drin sein. Vielleicht geht da noch mehr.
> 3. Link auf das schwer zu findende Datenblatt des Displays
Für 9Pins und SPI?
Damit ich auch mal was beitrage, erster google Beitrag "SPI DUE DMA":
ILI9341(new)SPI library for Due supporting DMA transfer(Uno, Mega,..
compatible)
https://forum.arduino.cc/index.php?topic=265806.0
Wäre vielleicht mal eine Ansicht wert, habe keinen DUE aber das Display
sieht identisch aus.
Philipp K. (philipp_k59) schrieb
>Markus schrieb:>> 1. beschleunigtes Kurvenzeichnen für Analogsignal>Wäre jeder mitm 8bitter draufgekommen um den geringen SPI Speed zu>kompensieren.
Natürlich. Sogar jemand mit einem 4-Bitter wäre darauf gekommen. Das
Problem ist nämlich unabhängig von der Wortbreite ;-)
Der Sinn so ein einfaches Beispiel zu posten liegt darin, dass sich
jemand der es ausprobiert eine halbe bis eine Stunde Arbeit spart.
Außerdem kann man von Codevorlagen ausgehend seinen eigenen Code
weiterentwickeln.
>Damit ich auch mal was beitrage, erster google Beitrag "SPI DUE DMA":>ILI9341(new)SPI library for Due supporting DMA transfer(Uno, Mega,..>compatible)>https://forum.arduino.cc/index.php?topic=265806.0>Wäre vielleicht mal eine Ansicht wert, habe keinen DUE aber das Display>sieht identisch aus.
Danke dafür. Die Library ist super. Ich habe sie gerade mal mit dem
ADC-Code ausprobiert ( siehe Anhang ). Der geht ab wie die Post. Die
Darstellung ist jetzt sehr flüssig, auch bei großen Amplituden.
Das ILI9341 ist so weit ich weiß das gleiche wie ein ILI9340 nur mit
Touchscreen. Im Bild auf GitHub ist auch nur ein ILI9340 abgebildet,
weil das ILI9341 mehr Anschlüsse auf der SD-Kartenseite hat.
Markus schrieb:> Natürlich. Sogar jemand mit einem 4-Bitter wäre darauf gekommen. Das> Problem ist nämlich unabhängig von der Wortbreite ;-)
Hauptaugenmerk lag auf dem SPi Speed.. wenn du einen 4Bitter mit SPI
kennst biste ja richtiger Profi wa.. kenn ja nichmal ich.
>Hauptaugenmerk lag auf dem SPi Speed.. wenn du einen 4Bitter mit SPI>kennst biste ja richtiger Profi wa.. kenn ja nichmal ich.
Ah, ich sehe schon, da sind Dir als Profi die Feinheiten meines
Software-Designs wohl entgangen. Tatsächlich gibt es bei meinem
ADC-Graph einen kleinen Trick für die flüssige Darstellung der Kurve:
Üblicherweise wird bei graphischen Anwendungen der neue Bildschirm im
Hintergrund gezeichnet und dann wenn die Zeichnung fertig ist, der
Bildschirm umgeschaltet. Das nennt man "Double-Buffering". Das
verhindert ein Flackern beim Zeichnen und ergibt ein ruhiges Bild.
Ich vermute, dass das Display aus Speicherkostengründen kein
Double-Buffering erlaubt ( zumindest mir das im Treiber nicht direkt ins
Auge gesprungen ). Deshalb lösche ich die alten Linienstückchen immer
kurz vor dem neu Zeichnen eines Linienstückchens. Das ergibt dann eine
optisch ein deutlich ruhigeren Eindruck.
Einen ähnlichen Optimierungsschritt hat auch die Counterroutine, welche
ich oben gepostet habe, durchlaufen. Vor dem Neuzeichnen muss nämlich
der Hintergrund gelöscht werden. Mach man das für den gesamten Screen,
gibt das kein schönes Ergebnis. Um die Wirkung zu verbessern, muss man
sich auf Teilbereiche beschränken.
Ja das weiß ich, jetzt denk mal nach..
Die meisten 8bitter z.B AVR können Architekturbedingt nur Mainclock/2
Spi-Speed.. also bei 8Mhz eben auch mal nur 4Mhz Spi Speed.. wenn Du da
den Bildschirm löscht und der TFT-Controller keinen befehl dafür hat
siehst du die Zeilen einzeln Flitzen..5FPS bei Löschen/Neuschreiben
eines ganzen Schirmes.
Also löscht/überschreibt man nur die gezeichneten Linien in
Hintergrundfarbe, quasi so wie Du das optimiert hast ;)
Die meisten Librarys sind ja mehr für die Masse und das man erstmal was
sieht.
>Ja das weiß ich, jetzt denk mal nach..
Denk mal nach: das Verfahren ist auch optimal für eine Software-SPI auf
einem 4 Bit Controller.
>Die meisten 8bitter z.B AVR können Architekturbedingt nur Mainclock/2>Spi-Speed.. also bei 8Mhz eben auch mal nur 4Mhz Spi Speed.. wenn Du da>den Bildschirm löscht und der TFT-Controller keinen befehl dafür hat>siehst du die Zeilen einzeln Flitzen..5FPS bei Löschen/Neuschreiben>eines ganzen Schirmes.
Meiner Erfahrung nach gibt es aber auch unschöne Effekte bei relativ
schneller SPI. Die einzig saubere Methode für den Bildaufbau ist ein mit
der Updatefrequenz des Displays synchronisierter Bildwechsel mit
Doppel-Puffer.
Wenn es den nicht gibt, ist es immer gut, die Zeichenroutinen auf
möglichst kleine Änderungen im Bild zu optimieren.
Markus schrieb:> Meiner Erfahrung nach gibt es aber auch unschöne Effekte bei relativ> schneller SPI. Die einzig saubere Methode für den Bildaufbau ist ein mit> der Updatefrequenz des Displays synchronisierter Bildwechsel mit> Doppel-Puffer.> Wenn es den nicht gibt, ist es immer gut, die Zeichenroutinen auf> möglichst kleine Änderungen im Bild zu optimieren.
Dann hast Du ja eine Menge vor mit Deinem Display, das ist bae rkein
Monitor, und ein selbst implementierter Framebuffer sieht auc handers
aus.
Naja weiterhin Viel Spaß ;)
>Denk mal nach: das Verfahren ist auch optimal für eine Software-SPI auf>einem 4 Bit Controller.
Da bin ich jetzt aber gespannt wie Du mir das mit allem drum und dran am
praktischen Beispiel mit Produktbeispielen erklärst.
>Naja weiterhin Viel Spaß ;)
Philipp, ich bin Dir ja dankbar für den Hinweis auf die Library. Also in
so fern ist von meiner Seite aus alles gut. Wenn Du durch Zufall auf
eine schöne Grafikanwendung stößt, würde ich mich freuen, wenn Du den
Link postest.
Hier eine etwas "zusammengepanschte" Echtzeit-FFT.
Die Anzeige des Frequenzpeaks liegt etwas daneben und mein
Sinusgenerator scheint auch nur einen ungefähren Sinus zu produzieren.
Die oben verwendete FFT habe ich auf GitHub gefunden und das Display
dran gebaut und die Ausgabe von Linear auf Log umgestellt.
Obwohl ich einen Sinus angelegt habe, sieht man einige Harmonische.
Jetzt frage ich mich, ob der Effekt nicht auch von der eigentlichen
FFT-Berechnung stammen könnte. Ich vermute nicht, denn die ganze
Rechnerei ist als Double ausgeführt und soweit ich hier im MC-Netz
gelesen habe, wird auf dem ARM auch wirklich mit Double gerechnet und
nicht wie beim AVR nur mit Float auch wenn der Typ als Double definiert
ist.
> Ich vermute nicht, denn die ganze> Rechnerei ist als Double ausgeführt und soweit ich hier im MC-Netz> gelesen habe, wird auf dem ARM auch wirklich mit Double gerechnet und> nicht wie beim AVR nur mit Float auch wenn der Typ als Double definiert> ist.
Vermuten kann ich auch, aber warum wenn Man(n) die wahrheit mit objdump
-d schnell rausfinden kann ! :).
So-wie-so ist wharscheinlich so von egal... stammt dein Sinus signal vom
12 bit ADC ? oder berechnet ?....
Einfach am PC rechnen lassen und die Ergebnisse anschauen :)
Hat jemand von dem Display die Board-Dimensionen?
Im Internet gibt es die zwar Haufenweise zu kaufen, aber ich kann
nirgends die genauen Größenangaben finden.
>Das ist kein 9340 sondern ein 9341, und wenn man die>Angebote sorgfältig durchliest findet man auch die Doku>dazu. So wie hier z.B.:>Ebay-Artikel Nr. 281353505264
Danke für den Link, danach hatte ich die ganze Zeit gesucht.
Auf der Ebay-Seite gibt es auch einen Link zum gesamten Doku-Paket mit
Sourcen für verschiedene Prozessortypen:
http://ecksteinimg.de/Datasheet/CP11002.zip
Im Paket findet sich auch ein "Schaltung.jpg" in dem Header 9 dem
Anschluss des Displays entspricht.
Es gibt dort auch ein Schaltbild mit Transistor für die
Hintergrundbeleuchtung, doch wo soll der sein?
Markus schrieb:> doch wo soll der sein?
Wohl nirgends ....
Die LED Beleuchtung ist nackt herausgeführt ..... nur noch
einen Transistor und zwei Widerstände (Basiswiderstand
und LED Strombegrenzung) aussen dazuschalten.
Vermutlich ist dieser Schaltplan auch nur irgendwo bei
einem Imitator geklaut.
Sinn würde deine Arbeit wirklich machen wenn du mal von diesem Arduino
Framework weg kommst, so ist das alles nur mit Kanonen auf... Nein halt,
anders rum... Mit Spatzen auf Kanonen geschossen.
Nimm normales GCC, das können dann die Laien in ihrer ArduinoDingens
kompilieren und man hat auch was fürs GCC.
Markus schrieb:> Im Paket findet sich auch ein "Schaltung.jpg" in dem Header 9 dem> Anschluss des Displays entspricht.> Es gibt dort auch ein Schaltbild mit Transistor für die> Hintergrundbeleuchtung, doch wo soll der sein?
Es gibt das 2.2" Display mit ILI9341 Controller in mehreren sehr
ähnlichen Versionen. Unterschiede sind z.B. verschiedene Baugrössen der
SMD Widerstände (0805 vs 1206). Zusätzlich gibt es noch eine Variante
mit dem Transistor, oft auch an den bereits verlöteten gelben
Stiftbuchsenleiste zu erkennen + die Möglichkeit einen SPI Flash
Speicherchip zu verlöten.
>Es gibt das 2.2" Display mit ILI9341 Controller
Danke für die Information, ef.
>Sinn würde deine Arbeit wirklich machen wenn du mal von diesem Arduino>Framework weg kommst
Der Sinn des Arduino Frameworks und der Boards ist, dass es jeder in
wenigen Minuten benutzen kann.
Wenn Du z.B. das Display und einen Arduino DUE und ein Steckbrett hast,
kannst Du dieses wunderbare Demo im Anhang, welches ich gerade aus der
Library genommen und für den Arduino DUE umgebaut habe, in 5 Minuten
benutzen.
Im anderen Fall ... nicht.
noch vergessen, ein Unterschied ist auch noch: Bei der Variante ohne
Transistor sind in den SPI Leitungen zur SD Karte Serienwiderstände
verbaut. Bei der Variante mit Transistor wurden die Serienwiderstände
entfernt, dafür bekommen die folgenden Signale einen Pullupwiderstand
- CS für SD Karte
- SCK für SD Karte und Flash Chip
- MOSI für SD Karte und Flash Chip
Markus schrieb:> Kennt jemand eventuell noch andere gute Libraries, die man verwenden> könnte?
Ja! Für normalduinos wie UNO, Nano, Mini ist hier ein
fast 10x schnelles Library wie die UTFT.
https://github.com/sumotoy/TFT_ILI9340
Passt hervorragend zum Display QVGA_TFT_LCD_240x320:
http://www.elecfreaks.com/store/22-tft-lcd-tft0122sp-p-672.html
Benötigt wird noch dazu die standard Adafruit_GFX Library!
Beschaltet habe ich die displays wie im beigefügtem Schaltplan.
(Achtung, benötigt Level-Convertierung!!!)
Hier noch mal das Sternenfeld. Ich habe die Helligkeit vom Abstand
wieder abhängig gemacht und etwas modifiziert, dadurch kommt dann
wirklich der 3D-Effekt zustande.
Hier die neuere Version.
Das Bild oben zeigt nicht ganz die richtigen Farben. Obwohl die Schrift
auf dem Display grün und der Hintergrund schwarz ist, sieht man auf dem
Foto der Digitalkamera weiße Schrift auf blauem Grund. Erstaunlich ....
Ich habe mittlerweile ein 1.8' ILI9341 bekommen.
Was seltsam ist:
Die Anschlussbeschriftung zeigt die Namen SDA und SCK was eher auf eine
I2C als eine SPI-Schnittstelle hin deutet.
Ich habe das Display einfach mal an das Projekt für die SPI
Schnittstelle angeschlossen und siehe da: es funktioniert trotzdem.
Das einzige Problem: es hat nur 160x128 Pixel. Dadurch ist die
Grahikausgabe falsch justiert.
Weiß jemand, wie man das ändern kann?
chris_ schrieb:> Ich habe mittlerweile ein 1.8' ILI9341 bekommen.
Welche Belege veranlassen dich dazu anzunehmen dass es
sich um einen ILI9341 Controller handelt?
chris_ schrieb:> Die Anschlussbeschriftung zeigt die Namen SDA und SCK was eher auf eine> I2C als eine SPI-Schnittstelle hin deutet.
Ja, die Chinesen sind da sehr freizügig in ihrer Namensgebung.
chris_ schrieb:> Ich habe das Display einfach mal an das Projekt für die SPI> Schnittstelle angeschlossen und siehe da: es funktioniert trotzdem.
Wenn die Software für das ILI9341 so oh-la-la funktioniert heisst
es noch lange nicht dass es sich beim Display um einen ILI9341-
Controller handelt
chris_ schrieb:> Das einzige Problem: es hat nur 160x128 Pixel.
Das hast du doch vorher gewusst als du das Display bestellt hast?
chris_ schrieb:> Dadurch ist die Grahikausgabe falsch justiert.
Nein. Die Software ist falsch, nicht für dieses Display geschrieben.
chris_ schrieb:> Weiß jemand, wie man das ändern kann?
Ja.
Hi chris_,
ich habe auch so ein Display und an einen STM32F103 angeschlossen. Es
ist ein ILI9341 mit 160x128 Pixel. Es läuft super, aber
man muss aber ein wenig am Adafruit ILI-Treiber drehen:
/* for mirrored display change this
void Adafruit_ILI9341::writePixel(int16_t x, int16_t y, uint16_t color)
{
#ifdef DISPLAY_MIRROR_X
x=ILI9341_TFTHEIGHT-x-1;
#endif
if((x < 0) ||(x >= _width) || (y < 0) || (y >= _height)) return;
setAddrWindow(x,y,1,1);
writePixel(color);
}
void Adafruit_ILI9341::writeFillRect(int16_t x, int16_t y, int16_t w,
int16_t h, uint16_t color){
#ifdef DISPLAY_MIRROR_X
x=ILI9341_TFTHEIGHT-x-w;
#endif
*/
Ja, man braucht nur ein paar Bildchen machen und ein wenig
an der Software herumdaddeln, und ein wenig schönreden, und
schon wird aus dem "unbekannten Display" ein ILI9341.
Nach dem Motto: wenn ich es auch nicht weiss rede ich solange
hin bis es das ist was ich haben will.