Just wondering if anyone has had any success configuring a SPFD5408 TFT LCD screen to work with a board similar to the ESP32 Dev Module?
I have tried out Bodmer's TFT_eSPI library, and I am aware that it does not support this chip. But, in theory it could, since the datasheet indicates in sec 8.1.5 that SPI communications are possible, so long as the 8080 parallel lines are all grounded. I have compared the 9341 datasheet, and it seems to have a similar command set, so I tried to do some basic SPI commands, with no success.
I have also messed with MCUFRIEND_kbv, and modified the ports, with moderate success, but would get strange pixel artifacts on the screen. A problem I couldn't resolve.
After nearly 2 months of experiments, I have 3 options. Maybe someone has had some success (or misery) with the SPFD5408 can make a suggestion?
See if Bodmer's TFT_eSPI library can be extended to add support for the SPFD5408
Try to solve the mysterious pixels that appear when using 8080 parallel communications from hacking MCUFRIEND_kbv to work with the ESP32.
Just give up on this controller, and use a known stable one that is better supported.
Please look at this message
FormalDeGID bought the same screen from ElectronicFans on AliExpress.
Please run LCD_ID_readreg.ino sketch. Compare with his report.
If you have the same 0x3229 screen, you should ask for a full refund. It does not work. ElectronicFans will not provide a datasheet. I have asked them.
Since FormalDeGID had provided the link, I ordered a screen from ElectronicFans for myself.
It arrived on Friday. However this screen contains an ILI9340 controller and works 100%.
Another owner has sent me the 0x3229 shield. I have not been able to display properly.
If I could obtain a datasheet for the 0x3229 controller, I am certain that I could get it working.
I spent a few hours trying to retrieve the ID using my modified MCUFRIEND_kbv command library. I wasn't sure where to find the LCD_ID_readreg.ino project, or if that project is compatible with ESP32 ports. One challenge with the ESP32 is that it only has 1 port that can be read/write, and the other is 'read only' on the higher pins. So, it takes some trickery to even get a response given that you actually need 2 write ports (control and data). I heard there are other ways to simulate ports.. buuut.. do I really want to continue spending time at this, given the disparaging results others have had? The chip, just may be faulty, as you suggest.
I am considering going with an ILI9431 chip now.. SPI seems like it is a 'must have' for the ESP32 chip, given the limited ports. I know Bodmer's library supports ILI9431, so that should be easy-peasy to make work, in comparison.
After downloading the latest copy of MCUFRIEND_Kbv, and Adafruit_GFX libraries, I finally got the thing to work! I had to edit the data pins for my situation, but graphictest_kbv.ino is writing text and lines like a champ!
The 7783 id was telling me that maybe I should keep trying with this library. I think that at one point, when I wasn't getting a ReadId response, I began forcing the commands specified with the 5408 chip. A lot of videos and samples suggested this was safe, so long as you knew the chip. I pasted the 5408 Begin() sequence from another project here. I was getting partially working results this way, maybe because some commands are similar, but, clearly it wasn't the chip I thought it was?
Is the 7783 in any way related to the SPFD5408? Still a little confused why this started working..
You have a regular Sitronix ST7781 controller. It has been supported by many TFT libraries for several years i.e. for Uno, Mega. It has ILI9320 style registers like a SPFD5408.
Obviously MCUFRIEND_kbv and TFT_eSPI libraries are the only TFT on an ESP32. Bodmer only supports the common controllers. I have supported ST7781 on Uno since 2015. ESP32 since it was born.
I describe the hardware mod for TTGO R32 boards. Bodmer provides diagrams and better description.
Thanks so much for your help David. I had a look at the TFT_eSPI user setup options, and indeed there does not appear to be support for the ST7781 (as of this post).
I was even able to successfully run TouchScreen_Calibr_native.ino to get the touch screen to work from MCUFRIEND_kbv now, too. I see you had to modify Touchscreen.h, to get that to work.
I will be using this library as the core to my project!
It is trivial to add support for different MIPI-style controllers e.g. ILI9341, ST7789, ... because they all share the same User registers. Just different Manufacturer registers used in init()
I doubt if Bodmer will bother with ILI9320-style e.g. your ST7781. Register addresses, function, ... vary greatly.
I have updated the TouchScreen_Calibr_native.ino example on GitHub.
It should give you correct X, Y pins. And calibrate easily.
I tried the new version of the project and seems to work fine. Not sure exactly what was changed with it, but it passed the smoke test!
However, in an unrelated issue, I was having problems with 2 of the 3 controllers.. including one that was working yesterday.. but today, the back light seems too bright. I measured the power, and it was 3.29V and 4.99V.. through an adapter that can deliver all the current it wants, so no changes to the code, or power.
I then swapped screens with one that didn't have a backlight issue before, and it too, was abnormally bright. Though, I had not tested that screen with this working code before.
But then, I unpacked a screen that I had previously kept in it's package, and it works perfectly fine. Not too bright.. same power, same code.
I find it a little disconcerting that I have a different behavior on all screens that self report as 0x7783. The only difference with the working one is that it was fresh out of the package. I am wondering if these screens are cheap because they age very fast or something? Hmm.
My theory is that warehouses have had "replacement screens" for mobile phones. Models that were sold in 2008 are obsolete now. So it is unlikely that anyone will want a "replacement screen" of this size.
The surplus stock is bought cheaply. Soldered to a generic shield pcb. Without any consideration for correct backlight current or electrical spec for Uno, Mega, ...
Then shields go onto the Ebay / AliExpress market. And are sold by lingerie shops.
It would make little difference to the assembly cost if they had a series resistor for the backlight.
And if they used 74LVC245 buffers instead of 74HC245. And AMS1117 regulator for the backlight.
Customers would be happy to pay more for a "well designed shield".
Very happy customers might even increase the lingerie sales.
I have quite a collection of "Mcufriend Shields". Some take too much current. Some are ok.
Since I always use 3.3V GPIO the HC245 is no problem. I will not use the "missing AMS1117" shields on a Uno, Mega, ...
The practical difference to the Calibration sketch for ARM / ESP.
If you use the default Touch pins, it will tell you which pins are X and which are Y.
If you run on an AVR Arduino, it has always diagnosed which pins are connected to the Touch Panel. And always which are X, Y.
An ARM is not really capable of driving a 300R Touch Panel. A Due can only source 3mA from its GPIO pins.
One thing that I might add, is that the 2 modules that went into 'super bright' backlight mode yesterday, that previously weren't, were being serial communicated with a 115200 baud rate. Whereas the one module that is displaying normally, has been 9600 baud each time. Literally the only difference that I can think of (same code, same power source, otherwise).
I am wondering if maybe the higher frequency baud rate induced some extra capacitance in the devices causing damage to the chips. I see no protective caps on the 2 IC's on the back, which is a little suspicious. Not sure if the damage is permanent, or if maybe the module will be fine if I swap back to it today.
Have you ever heard of a problem like this with these controllers? I can't really think of any other explanation for this. Maybe someone could conduct an experiment to see if this is plausible?