Only white screen with STM32 Nucleo-64 L467RG + Waveshare 4" ILI9486 + TFT_eSPI <SOLVED>

Hello

As topic and I have really gone through the files setting more then once but I have obviously missed something.

2 files included that have been modified according to what I have:

User_Setup.zip (6.4 KB)

I assume that lib should specifically work with the combination Nucleo-64 and the ILI9486 Waveshare display so something is wrong, and yes I have flipped the dip switches on the display back and forth.

This is the display:

And this is the board:

I cant really see anything wrong to the pin numbers? The reset pin 9 works and thus confirmed the pin numbers for the other pins but still only white screen no matter what example I test.

Kevin_tsvg

Bodmer calls these Waveshare abortions "Rpi_ILI9486"
Look at this Setup :
C:\Users\ .. \Documents\Arduino\libraries\TFT_eSPI\User_Setups\Setup33_RPi_ILI9486_STM32.h

You may need to change the TFT_CS, TFT_DC, TFT_RST defines.
You may need to look at Touch setup too.

Untested.

David.

You should use RPi which i take as raspberry pi when the display is built for Arduino UNO and similar?? That makes you very confused to say the least, should be another named fex Nucleo_ILI9486 or so instead, oh well.

But finally it works! Also touch, thanks! :slight_smile:

Display is very slow though and I don't think it can be used in parallell mode on the Nucleo, or? If TFT_eSPI even supports that on this board because that would have been the last thing to do.

The Waveshare abortion consists of using Shift Registers to receive SPI commands. Then bit-banging the result to a cheap Parallel 8080-16 ILI9486 Panel.

Originally done for RPi as a Hat. Then they produced an Arduino version as a Shield.

I have never used one. But Bodmer has a driver for it and it should work pretty well.

No, you can NOT run this Shield in Parallel mode.

If you want a 320x480 display for Nucleo-64 choose a ST7796S Chinese Red SPI board. They work well with TFT_eSPI.
Avoid the ILI9488 SPI boards.

David.

Ok then the naming made a little sense, now when I know.

Isn't that ST7796S SPI as well and thus slow? I know SPI displays are slow but It takes literally half a second to fill the whole screen with a color.

A parallell 4" 480x320 or 800x480 Arduino compatible display workable with TFT_eSPI or similar lib and I would probably have bought it take right away.

Bodmer does support 800x480 via 8080-8 Parallel interface. However I have never used his particular driver.

Actually native SPI can work pretty fast with the correct library and target. e.g. ST7796S with TFT_eSPI on an ESP32. SPI can use DMA. Parallel can't really use DMA.

When Arduino was born there were only AVR targets. Careful use of Parallel was much faster than the AVR's crap SPI peripheral.

Nowadays there are SAM3X, SAMD21, STM32, ESP8266, ESP32, Teensy, ... targets.

Most of the Arduino SPI class implementations on these other targets are really, really, really crap. (except ESP32, Teensy)

Individual TFT libraries might handle the SPI themselves e.g. Bodmer makes STM32 work well.
Adafruit optimise for their brand of target MCU. While leaving the non-Adafruit official Arduino SAMD21 targets with poor performance.

It does become very fiddly if you try to support multiple targets, architectures etc.

There is always room for improvement. Explain your "problem".

That STM32L476 on the Nucleo can do SPI at 40 MHz, plus DMA. You should be able to do buttery smooth animation with a "proper" driver

Yes that is true, that is though highly unfortunately something that I would not have a single clue about how to do.

Well I'm in the make of a little fancy (i hope) menu and when I change a page to the main page fex I don't want it to take 0.5+ second before the new one updates since its so slow. and numbers that moves fast is the same there, to slow.

Good to know because I know I have seen such a display.

Good info and I think I starting to lean towards that one now because its way, way to slow as it is now.

Explain your problem.

E.g. quote library example by name. Quote hardware by name (or post link or schematic)

Quote actual time or specific slow feature.

Readers can often replicate your setup e.g. Nucleo-L476 with TFT_eSPI. Much easier with known examples.
Alternatively write a small sketch that illustrates and quantifies the problem e.g. prints times.

David.

True that. Used hardware is the same as the top and as a lib so if I do the "UTFT_demo_480x320" from TFT_eSPI it takes 15.293 seconds, is that normal speed with SPI and that resolution? I can only compare to a 3.5" parallell one I have and in that case its night and day for even an more complex similar demo.

If I run fex:

tft.fillScreen(TFT_WHITE);
tft.fillScreen(TFT_BLACK);
tft.fillScreen(TFT_WHITE);

That takes around 2.5 seconds to complete and I can very easily see the changes. Shouldn't it go at least a little bit faster to fill a screen even over SPI?

If I run TFT_Char_times from the TFT_eSPI so does the last number with the biggest font take 21.689ms per character which is ok if I only need to change one digit but when several the time will surely increase to such degree that I guess it would just not be acceptable, as it fex is now with tft.fillScreen.

"UTFT_demo_480x320" is useful for people familiar with UTFT on a Mega2560.

The "graphicstest" style of examples are better for time comparisons.
I don't possess a "Waveshare abortion" but can tell you what a 320x480 native SPI does. e.g.
ST7796S with SPI_FREQUENCY = 40MHz : UTFT_demo_480x320 = 4.761 sec
ST7796S with SPI_FREQUENCY = 20MHz : UTFT_demo_480x320 = 5.617 sec
ST7796S with SPI_FREQUENCY = 8MHz : UTFT_demo_480x320 = 10.714 sec

The Waveshare is limited to 20MHz. So I would expect about 6 seconds

ST7796S with SPI_FREQUENCY = 20MHz : TFT_graphicstest_one_lib

TFT_eSPI library test!
Benchmark                Time (microseconds)
Screen fill              623418
Text                     98927
Lines                    1265262
Horiz/Vert Lines         65582
Rectangles (outline)     40847
Rectangles (filled)      1509637
Circles (filled)         501178
Circles (outline)        452745
Triangles (outline)      255603
Triangles (filled)       750434
Rounded rects (outline)  170257
Rounded rects (filled)   1645034
Done!

ST7796S with SPI_FREQUENCY = 20MHz : Viewport_graphicstest (240x320)

TFT_eSPI library test!
Benchmark                Time (microseconds)
Screen fill              267910
Text                     98632
Lines                    548326
Horiz/Vert Lines         31082
Rectangles (outline)     22191
Rectangles (filled)      496043
Circles (filled)         215081
Circles (outline)        196965
Triangles (outline)      121334
Triangles (filled)       283955
Rounded rects (outline)  84376
Rounded rects (filled)   558808
Done!

As I said earlier. Run all of the TFT_eSPI library examples. It will show you the capabilities (and limitations) of this library on your hardware.

Those examples don't use DMA. Appropriate use of DMA can make a dramatic performance. Especially when there is heavy computation like JPEG or GIF decoding.

David.

Thanks a lot for the tests. And it seem that this Waveshare is not something that is recommended for anything fast since it doesn't seem to be the board.

I have tested pretty much all of the examples, takes a surprisingly long time to compile new but to say the least so is it all very limited in speed even with max SPI speed.

You expected about 6 seconds for the 320x480 it but as mentioned its 15.2 seconds to complete. If I remove all the fillScreens its down to half of that 7.2 seconds and close. The screen fill with any color is very slow and probably won't be possible to get any faster on this one anyway and thus the Waveshare can't be used, which is annoying but oh well.

I just noticed that I can also see some ghosting from any white text that have been on for a longer time then about 20 - 30 seconds which i see as surprising, I mean its not a OLED. Its not permanent and can be erased with a white fill screen fex but if on for long times say 20 min, which it was once, its a little harder to erase.

But ok I will buy the ST7796S since that seem to be very fine, just a bummer that it can't be connected directly to the Nucleo like the waveshare. But I guess the long pins can be used for that and thus just a long female pin header, or what they are called.

You can plug any "Mcufriend style" parallel Shield into your Nucleo.
TFT_eSPI supports 8-bit Parallel and it supports many 320x480 controllers.
e.g. ILI9481, ILI9486, HX8357, ST7796, ...

MCUFRIEND_kbv works out of the box with every "Mcufriend style" parallel Shield on a Nucleo. i.e. it supports more controllers than TFT_eSPI. But TFT_eSPI is more sophisticated and probably faster.

As I said. I don't have the Waveshare Shield. It is definitely convenient to plug a Shield into a Nucleo. I would expect it to run pretty fast with TFT_eSPI. So I am wondering what you have done in your User_Setup.

Run the Read_User_Setup.ino sketch. Copy-Paste to your message.

Don't remove code from the examples. Just run the library examples in their virgin state. Then we can replicate your setup (if possible).
It is unfortunate that I do not want to buy a Waveshare. I can probably test most other display types. (on AVR, Due, Nucleo, Teensy, ESP8266, ESP32, RPi Pico, ... targets)

Regarding Red SPI displays and Shields. I mount headers and solder wire routeing on a custom ProtoShield. This means that I can run different displays on different targets.

You will see that most of the Display contributors have similar arrangements. i.e. Protoboard or ProtoShields that receive the popular TFT, OLED, GLCD, ...

Incidentally, the Nucleo-64 has pretty good functionality on its Arduino headers e.g. SPi, I2C, UART, PWM, ADC, ...
This does mean that mapping an 8-bit databus goes to random Port pins.
Less efficient than say PORTA on a Mega2560 but works well on an M4 target like your STM32L476

David.

Yes of course a shied for the new display, totally forgot about that those. And thanks for all the good info.

Read_User_Setup:

[code]
TFT_eSPI ver = 2.3.70
Processor    = STM32
Transactions = Yes
Interface    = SPI
Display driver = 9486
Display width  = 320
Display height = 480

MOSI    = GPIO 3838
MISO    = GPIO 3737
SCK     = GPIO 4343

>>>>> Note: STM32 pin references above D15 may not reflect board markings <<<<<
TFT_CS   = D10
TFT_DC   = D7
TFT_RST  = D8
TOUCH_CS = D4

TFT_BL           = D9
TFT_BACKLIGHT_ON = HIGH

Font GLCD   loaded
Font 2      loaded
Font 4      loaded
Font 6      loaded
Font 7      loaded
Font 8      loaded
Smooth font enabled

Display SPI frequency = -3107.20
Touch SPI frequency   = 2.50
[/code]

Why the SPI frequency is minus I have not a single clue about but shanging the SPI frequency doesn't make any difference either on the display nor the Read_User_Setup.

And I also added all the files used for this as well.Settings.zip (7.9 KB)

I saw that I had not comment out "#define STM32" and thought that was the problem, but that made it even worse with a complete white screen. The above Read_User_Setup is with STM32 defined since the Read_User_Setup flips out a little and doesn't show the pin numbers without it. But changing the SPI frequency strangely enough doesn't make any difference.

Yes, that looks odd.

My Setup33 says 20MHz:

// Nucleo-F767ZI has a ~216MHZ CPU clock, this is divided by 4, 8, 16 etc

#define SPI_FREQUENCY  20000000   // 27MHz SPI clock

Be patient. I expect that there are some readers out there with the same Waveshare. And Bodmer himself might comment.

David.

Yes mine as well.

There might we will see. Planned to buy the other mentioned display anyway since I don't have the effort to deal with this much longer and that is parallell and will always be fast even if something might not work to 100%.

Did another Setup check but without STM32 defined, now a frequency is seen but the pins are garbish:

[code]
TFT_eSPI ver = 2.3.70
Processor    = Generic
Transactions = Yes
Interface    = SPI
Display driver = 9486
Display width  = 320
Display height = 480

MOSI    = GPIO -138
MISO    = GPIO -137
SCK     = GPIO -143
TFT_CS   = GPIO -1
TFT_DC   = GPIO -1
TFT_RST  = GPIO -1
TOUCH_CS = GPIO -1

TFT_BL           = GPIO -1
TFT_BACKLIGHT_ON = HIGH

Font GLCD   loaded
Font 2      loaded
Font 4      loaded
Font 6      loaded
Font 7      loaded
Font 8      loaded
Smooth font enabled

Display SPI frequency = 20.00
Touch SPI frequency   = 2.50
[/code]

Here's a demo for a custom ST7789 240x240 LCD driver I wrote for an XMEGA MCU (Arduino's bigger brother running at 32 MHz, 16 MHz SPI)

Photos are loaded from a NOR flash (Winbond W25Q32), not a fan of SD cards...

Youtube demo

TFTs require 90 degree viewing. (especially the cheaper ones)

I am sure that your display is working fine. But your video looked crap !

David.

The TFT work just fine as such but its all just to slow. Probably with perfectly optimized drivers or such it would be faster but fast enough? I don't know. And I have not a single clue how to do that and is not something I expect anyone would do either since there are faster displays out there anyway.

If in a menu and you want to go back to the main page the screen will be erased with a fillScreen, then make a white background and the stuff that should be there. That would have take around 1.2 seconds which doesn't look really nice or pro at all.

Parallell display it is.

Go on. 320x480 pixels = 307k SPI bytes @ 20MHz or 123ms.

I would expect Bodmer to achieve 125ms.

Several readers have Waveshare e.g. ZinggJM, Bodmer, ? TFTLCDCyg, ...
They may not have your target Nucleo but would know the theoretical and practical performance.

David.