Was meinst Du mit 8bit?
Das kenne ich nur in Richtung Ansteuerung eines Display, wobei ich Das dann als Parallel in 4bit oder 8bit-Mode kenne, wobei die Bits hier die Datenleitungen sind, hinzu kommen noch RS, RW Display such E und ggf. die Display-Beleuchtung (Das eher bei LCD).
SPI erschlägt diese ganzen Dinge mit MISO/MOSI als Bus- und CS als Einzel-Pin.
I²C wäre auch noch eine Alternative, nutze ich recht gerne, ist aber um Längen langsamer als SPI oder ein paralleler Mode - kommt aber halt mit den zwei I²C-Pins aus.
So, TFT geht dann wieder mehr in Richtung Grafik
Da bin ich ebenfalls auf der Seite der Seriellen und erschlage das reine Display wieder mit Miso/Mosi und CS.
Einen Touch hat noch Keines meiner Displays - wenn Beides zusammen gehört, müsste das Datenblatt dazu was wissen.
Wenn das Touch-Zeug separat ist, wird sich Das auch irgendwie ansprechen lassen - Datenblatt wirst Du wohl noch Keines haben, da Du noch suchst?!?
Der Lib ist's egal, ob SPI oder I²C in HW oder SW, Parallel in 4Bit oder 8Bit.
Wenn die Pinne dazu vorrätig sind, warum nicht.
Im Programm selber unterscheidet sich der Aufruf dadurch in keinster Weise (klar: sofern die verwendete Lib die verschiedenen Modi unterstützt).
Aber egal wie schnell der µC die Daten zum Display prügelt - viel schneller, als das Display Die auch anzeigt, wird's nicht - auch muß für einen halbwegs sinnigen Zugriff via 4/8 Daten-Bits ein Port genutzt werden, damit man die Bits 'auf einen Schlag' setzen kann.
Und Lesen muß Das dann auch noch Wer - ok, bei Animationen wird man wohl nur gucken müssen.
Hat zwar Nichts mit der Übertragung zu tun, aber in wie fern ist der Rand entscheidend?
Der Verdrahtungsaufwand ist merklich kleiner und außerdem hat ein ESP8266 zuwenig verfügbare Pins, selbst beim ESP32 kann es problematisch werden, meist will man ja noch mehr anschließen. Ein Touch ohne Touchcontrolelr z.B. am ESP8266 erfordert externen Hardware-Aufwand weil die ADC/IO-Kombi nicht vorhanden ist.
Beim ESP32 würde es zwar gehen, macht aber wieder zusätzlichen Programmieraufwand.
Werde es mit SPI mal versuchen.
Mit einem Arduino war es zu langsam.
Mal sehen wie schnell es mit dem neuen Modul ist
Grüße
ich wünsche doch lieber ein frohes 2019...
Die echten SPI-Displays können zumindest 26MHz SPI-Clock, mache auch 40MHz.
Die 2,8...4.0" haben meist ILI9486 als Controller und HC4094 als Shiftregister um SPI zu machen, da ist bei 20MHz Schluß. War mir bisher aber nioch nicht wirklich zu langsam, Filme abspielen will ich da nicht.
Hatte mal vor Jahren mit Arduino im SPI versucht ein Künstlichen Horizont "AHRS" darzustellen.
Ist an dem Display gescheitert SPI war zu langsam, ( Hatte fehler gemacht )
Und ich bin auch nicht so gut im Programieren, um es zu verbesser.
Werde mal schauen ob das mit em SPI und den neuen Modul besser ist.
Die benutze ich seit ner Weile. Wenn die Hardware und die Software stimmt, gibt's da keine Fehler und schnell genug ist es locker.
Die Library hab ich mit 2,8", 3,5" und 4" Displays am laufen.
Davor hatte ich ein 8bit parallel Display das hab ich am nodemcu mit ESP8266 nicht zum laufen gebracht
Die benutze ich seit ner Weile. Wenn die Hardware und die Software stimmt, gibt's da keine Fehler und schnell genug ist es locker.
Die Library hab ich mit 2,8", 3,5" und 4" Displays am laufen.
Davor hatte ich ein 8bit parallel Display das hab ich am nodemcu mit ESP8266 nicht zum laufen gebracht
Ich füge mal noch 2,4" und 2,2" dazu. 2,4" und 4" mit Touch, die Touch-Button mit der Extension der TFT_eSPI.
Ein Bekannter ist recht intensiver Nutzer der Sprite Extension.
Läuft auf ESP8266 und ESP32 zuverlässig und stabil.
ich frage mal genauer, soweit ich weiß, irgendwelche Laufschriftgeschichten binnerhalb seines Wetterdisplays.
Die Spriteausgabe zum Display ist schneller als die Textzeile im Display direkt zu überschreiben.
Verringert/verhindert Geflacker beim Weiterscrollen.