Tft display mcufriend

Hello, I have an mcufriend display (photo), and I just can't figure out which pins to connect to my esp32 wroom, there is a description on the forum, but the pins do not fit my wroom, please help me connect correctly.

Hi mcuuser,

I found this picture

at ESP32-WROOM-32 and Uno-shield parallel TFT displays – thesolaruniverse

This should assist you to get the display up and running.
scuccess, photoncatcher

1 Like

Yes, you can use these displays with TFT_eSPI or with MCUFRIEND_kbv e.g.
#elif defined(ESP32) //regular UNO shield on TTGO D1 R32 (ESP32)

You just do a small hardware mod with the TTGO D1 R32 (ESP32) board and the Shield plugs in and goes.

I suggest that you copy the TTGO wiring. But you can re-configure with TFT_eSPI setup or by writing a "special" with MCUFRIEND_kbv.

Yes, the parallel works but it is a bit pointless. You waste a lot of GPIO pins. SPI displays are much more convenient. Especially with ESP8266


1 Like

Hi David,

'a bit pointless' might be a diplomatic description for connecting a parallel TFT shield to an ESP32, but the point is that a) I have a couple of these shields on the shelf, b) for the purpose of running animations the UNO is somewhat limited while the ESP32 offers in comparison a sea of memory and microprocessor power, c) SPI displays with the same dimensions as displays on parallel shields are definitely slower (Muybridge's horse Sallie Gardner doesn't 'run' that fast!), d) there is excellent suypport by Bodmer';s TFT_eSPI library. I constructed an ESP32 bench on which I can test all sorts of parallel shields

for ESP32 with SPI displays: see ESP32-WROOM-32 and ILI9341 TFT display – an interesting match – thesolaruniverse

regards, Photoncatcher

Post a link to your Muybridge's horse Sallie Gardner animation.
I suspect that it can run faster with SPI.

I quite understand your point. You might just as well use your parallel Shields.

I have both Uno Shields and SPI Protoshields. i.e. I can run displays of any size on ESP32.


Hello photoncatcher, thank you so much for your help, everything is working as it should!

Hello david_prentice, I'm not ready to modify yet) (not very good at iron-on issues), thank you for your help!

Dear Savid,

Sallie Gardner can be enjoyed galloping along
in Muybridge's Zoo on a parallel 320*240 TFT connected to a ESP32 WROOM32
(Muybridge’s Zoo for the ESP32WROOM – thesolaruniverse)

on a Nokia 5110 connected to a Wemos D1 mini ESP8266
(Nokia 5510 84*48 LCD and the ESP8266 Wemos D1 mini microcontroller board – thesolaruniverse)

and the original one: on an 128*64 SPI TFT connected to an Arduino Nano

The Nano example also has a Table that compares various microcontroller/display configurations

regards, Floris

1 Like

Thanks for the link. Monochrome displays are always going to look a bit "blocky". However the animation makes this less obvious.

Grayscale or full colour displays can give more attractive results but obviously the images require more storage than monochrome.
Converting grayscale to "speckle" monochrome is ok for big displays. After all, this is how black and white newspapers work. But it looks horrible on a 128x64 OLED.

A line-drawing or silhouette looks best on a monochrome display. e.g. your example sketches. The animations operate at a reasonable speed even with a Nano.

If the images were bigger you run into storage and speed problems.
Runlength encoding is both simple and effective. i.e. more frames or bigger frames.

Rendering monochrome images on a TFT can be speeded up by only plotting changed pixels.
OLED/GLCD images can be stored as arrays in native format e.g. vertical bits like KS0108 or SSD1306.