Configure fast work stm32 and ILI9486 display

[brightproject]

I have two hardware devices:

1. stm32f401ccu6 + ILI9486 display(3.5")
2. esp32 + st7789 display(2.8")
   Both are connected via 8-bit parallel interfaces.
   stm32f401ccu6 and display is connected like this

// Define STM32 to invoke optimised processor support
#define STM32

// Tell the library to use 8 bit parallel mode (otherwise SPI is assumed)
#define TFT_PARALLEL_8_BIT

// Define the display driver chip type
#define ILI9486_DRIVER

#define TFT_CS   PB6  // Chip select control pin
#define TFT_DC   PB5  // RS/CD - Data Command control pin
#define TFT_RST  -1  // Reset pin

#define TFT_WR   PB1  // Write strobe control pin 
#define TFT_RD   PB0  // Read pin

#define TFT_D0   PA0  // 8 bit parallel bus to TFT
#define TFT_D1   PA1
#define TFT_D2   PA2
#define TFT_D3   PA3
#define TFT_D4   PA4
#define TFT_D5   PA5
#define TFT_D6   PA6
#define TFT_D7   PA7

esp32 and display connected like this

#define ESP32_PARALLEL

#define ST7789_2_DRIVER
#define TFT_INVERSION_OFF

// ESP32 pins used
#define TFT_CS   33  // Chip select control pin
#define TFT_DC   15  // Data Command control pin - must use a pin in the range 0-31
#define TFT_RST  32  // Reset pin

#define TFT_WR    4  // Write strobe control pin - must use a pin in the range 0-31
#define TFT_RD    2

#define TFT_D0   12  // Must use pins in the range 0-31 for the data bus
#define TFT_D1   13  // so a single register write sets/clears all bits
#define TFT_D2   26
#define TFT_D3   25
#define TFT_D4   17
#define TFT_D5   16
#define TFT_D6   27
#define TFT_D7   14

When I run the test from the example on stm32, I get a run time of 5274 msecs.

When I load the example test in esp32, I get 477 msecs.

stm32f401ccu6 operates at a frequency of 84 MHz, and esp32 at a frequency of 240 MHz.
2.8 times faster, but 11 times faster in terms of speed...and it seems to me that something is wrong here.
The display itself, which has a resolution of 3.5 ", falls under suspicion, well, let's say, it displays an image a little slowly, because the frame size is larger in terms of space than the 2.8 " display.
But not 11 times?
Still under suspicion is the 3.5 "display driver, ILI9486, it seems to me that it is slow for this display.
In general, this is a shield for UNO, maybe it does not work well with stm32?
But the tests are not the most important thing that worries me.
I have an artificial horizon code that I successfully ran on esp32 + st7789.

And I am also trying to run this code on stm32 + ILI9486 but I am facing two problems:

1. very very slow work
2. the impossibility of setting the color depth setColorDepth(1) more than 1 byte.
   Perhaps someone will be able to reproduce this code on their devices (stm32 or esp32).
   I post two archives, they need to be installed via the arduino IDE as libraries.
   Stm32Link.zip
   GaugeWidgetsStm32.zip
   In the folder GaugeWidgetsStm32 open an example AI_Widget.ino and flash the board.
   Since I myself adapted this code, then in the file you need to add below line

• TFT_eSPI/TFT_eSPI.h

  Line 215 in 52384e4

  #include <Fonts/GFXFF/gfxfont.h>

these fonts

// New custom font file #includes
#include <Fonts/Custom/Orbitron_Light_24.h>  // CF_OL24
#include <Fonts/Custom/Orbitron_Light_32.h>  // CF_OL32
#include <Fonts/Custom/Roboto_Thin_24.h>     // CF_RT24
#include <Fonts/Custom/Satisfy_24.h>         // CF_S24
#include <Fonts/Custom/Yellowtail_32.h>      // CF_Y32

// Original Adafruit_GFX "Free Fonts"
#include <Fonts/GFXFF/TomThumb.h>  // TT1

#include <Fonts/GFXFF/FreeMono9pt7b.h>   // FF1 or FM9
#include <Fonts/GFXFF/FreeMono12pt7b.h>  // FF2 or FM12
#include <Fonts/GFXFF/FreeMono18pt7b.h>  // FF3 or FM18
#include <Fonts/GFXFF/FreeMono24pt7b.h>  // FF4 or FM24

#include <Fonts/GFXFF/FreeMonoOblique9pt7b.h>   // FF5 or FMO9
#include <Fonts/GFXFF/FreeMonoOblique12pt7b.h>  // FF6 or FMO12
#include <Fonts/GFXFF/FreeMonoOblique18pt7b.h>  // FF7 or FMO18
#include <Fonts/GFXFF/FreeMonoOblique24pt7b.h>  // FF8 or FMO24

#include <Fonts/GFXFF/FreeMonoBold9pt7b.h>   // FF9  or FMB9
#include <Fonts/GFXFF/FreeMonoBold12pt7b.h>  // FF10 or FMB12
#include <Fonts/GFXFF/FreeMonoBold18pt7b.h>  // FF11 or FMB18
#include <Fonts/GFXFF/FreeMonoBold24pt7b.h>  // FF12 or FMB24

#include <Fonts/GFXFF/FreeMonoBoldOblique9pt7b.h>   // FF13 or FMBO9
#include <Fonts/GFXFF/FreeMonoBoldOblique12pt7b.h>  // FF14 or FMBO12
#include <Fonts/GFXFF/FreeMonoBoldOblique18pt7b.h>  // FF15 or FMBO18
#include <Fonts/GFXFF/FreeMonoBoldOblique24pt7b.h>  // FF16 or FMBO24

// Sans serif fonts
#include <Fonts/GFXFF/FreeSans9pt7b.h>   // FF17 or FSS9
#include <Fonts/GFXFF/FreeSans12pt7b.h>  // FF18 or FSS12
#include <Fonts/GFXFF/FreeSans18pt7b.h>  // FF19 or FSS18
#include <Fonts/GFXFF/FreeSans24pt7b.h>  // FF20 or FSS24

#include <Fonts/GFXFF/FreeSansOblique9pt7b.h>   // FF21 or FSSO9
#include <Fonts/GFXFF/FreeSansOblique12pt7b.h>  // FF22 or FSSO12
#include <Fonts/GFXFF/FreeSansOblique18pt7b.h>  // FF23 or FSSO18
#include <Fonts/GFXFF/FreeSansOblique24pt7b.h>  // FF24 or FSSO24

#include <Fonts/GFXFF/FreeSansBold9pt7b.h>   // FF25 or FSSB9
#include <Fonts/GFXFF/FreeSansBold12pt7b.h>  // FF26 or FSSB12
#include <Fonts/GFXFF/FreeSansBold18pt7b.h>  // FF27 or FSSB18
#include <Fonts/GFXFF/FreeSansBold24pt7b.h>  // FF28 or FSSB24

#include <Fonts/GFXFF/FreeSansBoldOblique9pt7b.h>   // FF29 or FSSBO9
#include <Fonts/GFXFF/FreeSansBoldOblique12pt7b.h>  // FF30 or FSSBO12
#include <Fonts/GFXFF/FreeSansBoldOblique18pt7b.h>  // FF31 or FSSBO18
#include <Fonts/GFXFF/FreeSansBoldOblique24pt7b.h>  // FF32 or FSSBO24

// Serif fonts
#include <Fonts/GFXFF/FreeSerif9pt7b.h>   // FF33 or FS9
#include <Fonts/GFXFF/FreeSerif12pt7b.h>  // FF34 or FS12
#include <Fonts/GFXFF/FreeSerif18pt7b.h>  // FF35 or FS18
#include <Fonts/GFXFF/FreeSerif24pt7b.h>  // FF36 or FS24

#include <Fonts/GFXFF/FreeSerifItalic9pt7b.h>   // FF37 or FSI9
#include <Fonts/GFXFF/FreeSerifItalic12pt7b.h>  // FF38 or FSI12
#include <Fonts/GFXFF/FreeSerifItalic18pt7b.h>  // FF39 or FSI18
#include <Fonts/GFXFF/FreeSerifItalic24pt7b.h>  // FF40 or FSI24

#include <Fonts/GFXFF/FreeSerifBold9pt7b.h>   // FF41 or FSB9
#include <Fonts/GFXFF/FreeSerifBold12pt7b.h>  // FF42 or FSB12
#include <Fonts/GFXFF/FreeSerifBold18pt7b.h>  // FF43 or FSB18
#include <Fonts/GFXFF/FreeSerifBold24pt7b.h>  // FF44 or FSB24

#include <Fonts/GFXFF/FreeSerifBoldItalic9pt7b.h>   // FF45 or FSBI9
#include <Fonts/GFXFF/FreeSerifBoldItalic12pt7b.h>  // FF46 or FSBI12
#include <Fonts/GFXFF/FreeSerifBoldItalic18pt7b.h>  // FF47 or FSBI18
#include <Fonts/GFXFF/FreeSerifBoldItalic24pt7b.h>  // FF48 or FSBI24

This commented

• TFT_eSPI/TFT_eSPI.h

  Line 217 in 52384e4

  #include <User_Setups/User_Custom_Fonts.h>

This line with custom fonts, just comment it out.
// #include <User_Setups/User_Custom_Fonts.h>
For other examples, you need to return everything to its place.

Otherwise, the example code will generate a font error when compiling.
I did not succeed in adding fonts in another way, but this is a slight inconvenience and nothing more.
Perhaps someone will be able to load fonts in a more standard way.
I repeat, the code is compiled for both stm32 and esp32, it only writes text messages in log.

WARNING: The GaugeWidgetsStm32 library must run on esp32 architectures and may not be compatible with your stm32 board.

Do not pay attention to this, I ported this code from M5Stack.

video5330118765831010284.mp4

[brightproject]

I continue to search for options to speed up the graphics on stm32f401 + ILI9486 and stm32f411 + ST7789.
The first thing I did was to connect the default ST7789 display

#define TFT_CS   PB8  // Chip select control pin
#define TFT_DC   PB7  // RS/CD - Data Command control pin
#define TFT_RST  PB9  // Reset pin

#define TFT_WR   PB6  // Write strobe control pin 
#define TFT_RD   PB0  // Read pin

#define TFT_D0   PA0  // 8 bit parallel bus to TFT
#define TFT_D1   PA1
#define TFT_D2   PA2
#define TFT_D3   PA3
#define TFT_D4   PA4
#define TFT_D5   PA5
#define TFT_D6   PA6
#define TFT_D7   PA7

And immediately got the test completed in 2700 msecs, which is twice as fast as when connecting the display as I did above.
What is interesting - the display actually displays images for much longer than 2.7 seconds, it turns out that the microcontroller unloads data from its buffer into the display buffer, and this introduces a delay.
I don’t fully understand the mechanism of MCU operation with the TFTe_SPI library.
It seems like the MCU forms an image and places it in its buffer, and from there to the display framebuffer.
It turns out the case with the buffer stm32.
Moreover, there is no particular difference between stm32f401 and stm32f411.
The frequency of the first is 84 MHz, and the second is 100 MHz.

video5332342098601455914.mp4

stm32f401 + ILI9486 outputs only a black and white image and the color depth does not allow setting more than one

setColorDepth(1);

stm32f411 + ST7789 outputs a color image with a color depth of eight bytes

setColorDepth(8);

So I need to optimize the code for stm32.
As far as I understand, stm32f401/411 has a problem with sending data with a double buffer.
Deal with the buffer or whatever gives such a delay.
Although the same ST7789 display and esp32 are together, they simply instantly display information.
If I reassign pins other than those set by default, does the speed slow down - because the registers in stm32 and in the library are hard-coded and it is difficult to reassign them?
@Bodmer say please, was the TFTe_SPI library originally developed for esp32?
And only then adapted for stm32 and other platforms, do I understand correctly?
As far as I understand, the work of the library is optimized for esp32, but for stm32 it is not fast enough.
It's masking and bit shifting.
Link from Teensy's forum, but it describes well the 8/16 bit parallel interface, the operation of the control pins CS, DC/RS/CD, WR and RD.
Can you count on DMA support for stm32 and 8-bit parallel interface?
Or is the only way to optimize the code that displays the graphics, simplify the displayed graphical primitives on the display?

[brightproject]

A few more observations that intrigued me.
Firstly, I always considered the processor frequency to be an important characteristic of the microcontroller, but this turned out to be far from the case.
For working with graphics, the size of the SRAM is important.
Just the same, my MCU stm32f401/411 have SRAM sizes of 64/128 kB, respectively.
And esp32 has SRAM 512 kB - it's understandable why everything works very quickly on esp32 and does not slow down.
And it's not about the 240 MHz processor, although this also does its job.
My display has a resolution of 320*240 pixels.
I tried to reduce the display size of the sprite, up to 150*150 and 50*50.
Of course, the smaller the displayed image, the faster the display works.
I also tried to change the value of SRAM

• TFT_eSPI/Extensions/Sprite.cpp

  Line 39 in 52384e4

  _psram_enable = true;

//_psram_enable = true;
_psram_enable = false;

but for some reason there was no change ...
Previously, I didn’t really understand the stm32 families, and bought MCU STM32G431.
I thought, since the frequency is 170 MHz, I will display graphics on it ..
But it turned out that the chip is designed for mathematical problems, and the SRAM is only 24 kB.
So far I think that it is somehow possible to optimize the work of the library or my code, taking into account the size of SRAM stm32f411 or buy stm32f407.

[Bodmer]

Have you set the STM32 parameter for the port A bus use? See here:
https://github.com/Bodmer/TFT_eSPI/blob/master/User_Setups/Setup35_ILI9341_STM32_Port_Bus.h#L10

[brightproject]

Have you set the STM32 parameter for the port A bus use?

I don’t know what happened, but the display speed increased many times.
You are a wizard

video5339064405319495854.mp4

Thank you very much for your help and the library.
I already thought that stm32 could not be applied to my tasks in aircraft instruments, but the MCU stm32f411ce6u will still work for the good.
As far as I understand, it's all about the I/O registers and program instructions?

Previously, I connected the ILI9486 display to the stm32 in this way

#define TFT_CS   PB6  // Chip select control pin
#define TFT_DC   PB5  // RS/CD - Data Command control pin
#define TFT_RST  -1  // Reset pin

#define TFT_WR   PB1  // Write strobe control pin 
#define TFT_RD   PB0  // Read pin

#define TFT_D0   PA0  // 8 bit parallel bus to TFT
#define TFT_D1   PA1
#define TFT_D2   PA2
#define TFT_D3   PA3
#define TFT_D4   PA4
#define TFT_D5   PA5
#define TFT_D6   PA6
#define TFT_D7   PA7

Everything worked, but when connected in this way

#define TFT_CS   PB8  // Chip select control pin
#define TFT_DC   PB7  // RS/CD - Data Command control pin
#define TFT_RST  PB9  // Reset pin

#define TFT_WR   PB6  // Write strobe control pin 
#define TFT_RD   PB0  // Read pin

#define TFT_D0   PA0  // 8 bit parallel bus to TFT
#define TFT_D1   PA1
#define TFT_D2   PA2
#define TFT_D3   PA3
#define TFT_D4   PA4
#define TFT_D5   PA5
#define TFT_D6   PA6
#define TFT_D7   PA7

The speed has doubled.
It turns out that it is impossible to reassign control pins for stm32 other than "default"?
Can I have another question about esp32 and pins?
I am designing a printed circuit board for esp32-s3-wroom-1 and see that different pins are specified for different platforms in the settings files 1, 2, 3?
Somewhere the pin of the RD is replaced, somewhere the CS is not assigned at all.
I'm afraid that I'll design the board incorrectly by assigning pins, and lose speed, like on stm32.
As far as I know, with esp32 you can use any pins as you like, reassign and not be afraid.
In stm32, reassigning pins causes certain problems, especially the ADC pins.
Is it that you can assign any pins for the display to the esp32?
For example - Makerfabs used next pins for TFT-display

For backlight, pin 45 is used, and in your library this pin is used for data, and pin 38 is allocated for backlighting.
I'm very afraid to design the printed circuit board incorrectly, and thereby lose the display speed on the display, as was the case with stm32.
Please give advice on which setting to focus on pins for esp32-s3-wroom-1?

Does the library currently support the MIPI RGB interface?

[Bodmer]

Great, you have made good progress.

Create a prototype and test it before comitting to a PCB layout.

You should be able to assign the control pins as you wish without a performance penalty. Larger displays will be slower in proportion to the total pixel count. The data pins are best allocated to a particular port. See here:
https://github.com/Bodmer/TFT_eSPI/blob/master/User_Setups/Setup35_ILI9341_STM32_Port_Bus.h#L10-L15

[brightproject]

Great, you have made good progress.

I received a printed circuit board, at the design stage I included the ability to select the connection configuration to the pins using jumpers.
I chose two options - Setup206_LilyGo_T_Display_S3.h and Setup70d_ILI9488_S3_Parallel.h.
When I use connection diagram 206, the test is completed in 610 ms.
When I use the 70d connection scheme, the test is completed in 541 ms

Objectively, connecting 70d gives an increase in the speed of rendering on the display.
My surprise is that not long ago I connected the exact same display to a fairly old ESP32-wroom.
And there the test was executed in 477 ms, and this upset me, because... I thought that the new esp32-s3-wroom-1 would at least not be slower in speed than its predecessor.
It turns out that, despite the small choice in connection types, there is only one correct option when the data transfer rate to the display pins is maximum.
Is there some kind of software way to find the fastest combination of pins to connect a display?
Or is it possible to find the most profitable and fastest connection combination only by searching through the pins, soldering various options and testing?