Bodmer / TFT_eSPI

Arduino and PlatformIO IDE compatible TFT library optimised for the Raspberry Pi Pico (RP2040), STM32, ESP8266 and ESP32 that supports different driver chips
Other
3.69k stars 1.07k forks source link

STM32 ST7789 SPI2 #2968

Closed JFBow closed 9 months ago

JFBow commented 10 months ago

Hello Bodemer, Bravo and thank you for this library which works very well with a 240x240 screen with ST7789 without CS driven by an STM32F401 (blackpill) on SPI 1. For example drawXBitmap.ino runs without problem. As soon as I try with SPI2, black screen and more rarely snow screen (multicolor), despite numerous tests carried out. Configuration file attached. TFT_eSPI_STM32_ST7789_setup.zip Arduino IDE Configuration 2.2.1, STM32Duino 2.6.0, TFT_eSPI 2.5.33 Bad pin name? For example for the TFT_DC and TFT_RST pins it is PB_0 and PB_1 which works and not PB0 and PB1. What to do ?

Subsidiary question, if your library is perfect, it has a size that is not negligible. Is there a library that would do a lot less stuff like Greiman's for OLED, SSD1306Ascii, which only works in text (which is what I need).

Thank you for your help

Bodmer commented 10 months ago

I suspect this is down to "noise" on the signal lines to the TFT while the processor boots and the GPIO get set to the right state. The displays without a CS line and in particulr the ST7789 for some reason are particularly susceptible to this. For some reason the ST7789 then fails to initialise properly, I speculate this may be because the SPI buffer in the chip gets garbage in it during boot and this is not cleared by a subsequent reset. I have not had the same problem with a TFT with a chip select line.

Re. code size. You can reduce the FLASH needs by disabling unwanted fonts in the setup file.

I did some experiments with different processors with a minimally useful Blink sketch example:

Arduino IDE default Blink sketch
UNO
Sketch uses 936 bytes (2%) of program storage space. Maximum is 32256 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 2039 bytes for local variables. Maximum is 2048 bytes.

Mega
Sketch uses 1548 bytes (0%) of program storage space. Maximum is 253952 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 8183 bytes for local variables. Maximum is 8192 bytes.

STM32F401
Sketch uses 11508 bytes (8%) of program storage space. Maximum is 131072 bytes.
Global variables use 1156 bytes (1%) of dynamic memory, leaving 64380 bytes for local variables. Maximum is 65536 bytes.

RP2040
Sketch uses 52220 bytes (2%) of program storage space. Maximum is 2093056 bytes.
Global variables use 10224 bytes (3%) of dynamic memory, leaving 251920 bytes for local variables. Maximum is 262144 bytes.

ESP32
Sketch uses 237117 bytes (18%) of program storage space. Maximum is 1310720 bytes.
Global variables use 21048 bytes (6%) of dynamic memory, leaving 306632 bytes for local variables. Maximum is 327680 bytes.

You can see here the huge difference in required FLASH and RAM for different processors. The ESP32 is particularly high as the sketch runs on top of an RTOS (Real Time Operating System - the "Windows" of the microprocessor world!) The STM32F401 for example probably requires relatively complex USB drivers to be loaded.

Here are the results for TFT_eSPI with just the GLCD sketch enabled and a SPI ILI9341 display running the "Colour_Test" sektch:

UNO
Sketch uses 12972 bytes (40%) of program storage space. Maximum is 32256 bytes.
Global variables use 306 bytes (14%) of dynamic memory, leaving 1742 bytes for local variables. Maximum is 2048 bytes.

Mega
Sketch uses 13702 bytes (5%) of program storage space. Maximum is 253952 bytes.
Global variables use 306 bytes (3%) of dynamic memory, leaving 7886 bytes for local variables. Maximum is 8192 bytes.

STM32F401
Sketch uses 21652 bytes (16%) of program storage space. Maximum is 131072 bytes.
Global variables use 1496 bytes (2%) of dynamic memory, leaving 64040 bytes for local variables. Maximum is 65536 bytes.

RP2040
Sketch uses 63268 bytes (3%) of program storage space. Maximum is 2093056 bytes.
Global variables use 10836 bytes (4%) of dynamic memory, leaving 251308 bytes for local variables. Maximum is 262144 bytes.

ESP32
Sketch uses 257205 bytes (19%) of program storage space. Maximum is 1310720 bytes.
Global variables use 21356 bytes (6%) of dynamic memory, leaving 306324 bytes for local variables. Maximum is 327680 bytes.

Notice that for some processors like the ESP32, the percentage use of FLASH and RAM is very little different when comparing the trivial blink sketch to a minimal TFT_eSPI! Given that this was the target processor for library this is not really a problem.

Another alternative, if FLASH and RAM is a problem in your use case, is to use the STM32F411 "Black Pill", which has significantly more RAM and FLASH abailable for programs.

Bodmer commented 10 months ago

I thought the Adafruit_GFX library may better suit your needs. This is the required resources for the same "Colour_Test" sketch (minor adaptions to work with the Adafruit library).

Sketch uses 25392 bytes (19%) of program storage space. Maximum is 131072 bytes.
Global variables use 1636 bytes (2%) of dynamic memory, leaving 63900 bytes for local variables. Maximum is 65536 bytes.

Comparing the same sketch with TFT_eSPI:

STM32F401
Sketch uses 21652 bytes (16%) of program storage space. Maximum is 131072 bytes.
Global variables use 1496 bytes (2%) of dynamic memory, leaving 64040 bytes for local variables. Maximum is 65536 bytes.

So TFT_eSPI appears to be more memory efficient.

Bodmer commented 10 months ago

I forgot to disable the font loading so I have updated the figures above. These now look more as I would expect as the library has run on an UNO in the past.

JFBow commented 10 months ago

Really thank you for all these details which arrive so quickly !

Yes, I think CS always on is a good candidate for malfunctions. Indeed, out of the dozens of tests that I did on SPI2, once or twice it worked, and on SPI1 only once or twice where it did not work, pressing NRST on the blackpill was then sufficient to start the display correctly ! (this is not a blackpill problem because with a black screen, the data sent over the serial link is correct). On the other hand, the SPI port which is not used by the screen is used by an SD card which always works regardless of the SPI port, but its CS is used.

Well probably it's a problem because I found this: https://www.instructables.com/Adding-CS-Pin-to-13-LCD/ I don't know if I would have the courage to go for it especially since there is also this solution in 1.54 inch ST7789 with CS, I hope that the rendering will be as beautiful as with the 1.3 inch : https://fr.aliexpress.com/item/1005005560238498.html?spm=a2g0o.cart.0.0.ab36378dZpSiNf&mp=1&gatewayAdapt=glo2fra

For memory, agree to reduce the number of loaded fonts and also to switch to blackpill STM32F411 if space runs out. THANKS.