Bigger LCD : is it possible ?

xerox

Member
Noob question:

Is it possible to replace an ILI9341/XPT2046 2.8" display already running in a project with a bigger one ?

I mean , do bigger (4"-5") SPI display with same touch controller exist ?

If yes are there hardware issues in replacement and last but not least can I adapt teensy code to new resolution ?

Thank you.
 
Off hand, I didn't notice any larger ILI9341 240x320 displays at Amazon.com. There is a 3.2" display, but that likely is not a big enough jump.

There are various ways to get a bigger screen, but it will involve rewriting the code. Perhaps all you have to do is change a few things (different driver, maybe spell a few things differently).

Or maybe you need to rework then sketch more drastically. For example, some of the SPI display drivers keep a copy of the display image in read/write memory in the Teensy. As you get larger, the memory requirements will quickly go beyond what a Teensy can handle. So you have to move to displays that keep the images in the memory on the display, and it may impact how you write to the display. I posted links for the Gamedunio3 system here:
 
There are lots of displays out there, But again it may depend on what you want and how much code you wish to change.
For example there is a whole thread (probably more than one) on the RA8875 display, such as: https://forum.pjrc.com/threads/57280-RA8875-from-Buydisplay?highlight=buydisplay

For example I have picked up a few of the ones like: https://www.buydisplay.com/default/4-3-tft-lcd-display-module-controller-board-serial-spi-i2c-mcu
You can get these with either a Resistive touch or a capacitive touch controller. Would suggest the capactive one, but I think the resistive one is the XPT2046 or so controller.

Problems are, they run completely different code bases and so your display code might need a lot of work to adapt.

Now if 3.5" was big enough, you cold go with the ILI9488 display, like: https://www.ebay.com/itm/3-5-SPI-Se...x320-ILI9488-w-Touch-Support-65K/264435686230
Which is 480x320, and we have libraries that work pretty similar...
 
Thank you for replies,
At last, it seems no large display than 3,2-3,5" are available with SPI interface, and rewriting code is for me impossible due to lack of knowledge, perhaps modify it a little, and with the help of author maybe.
For the money, the 3,2" one will worth a try....
 
You can also get 7" LCD with SPI but be careful with them. Some of them the pixel is not square. That means drawing circle does not look like a circle on screen. Square is not square !!

C03nalsWEAARfS5.jpeg
 
@xerox - There have been a few displays and the like suggested here, however it is very hard for any of us to give you any complete suggestions, with as little information as you have so far provided, such as your current setup, an idea of your requirements and the like.

So far all we know is you have an ILI9341 display which has an XPT2046 touch screen controller. So my assumption is that you are using one by PJRC. What graphic library are you using to run it? There are at least a few like one by Adafruit, Paul's - ili9341_t3, Mine - ili9341_t3n, Frank's - ili9341_dma (I think)... Note: most of the libraries I mentioned here are or were based off of Adafruits, but there are areas we diverged and or extended. What processor are you using?

The reason I ask questions like this, is for example if your display code is based on one of these drivers, then there is a reasonable chance that if for example Adafruit sells a larger display that meets your requirements, than adapting the code to the new display may not be that difficult. It is not necessarily you have to purchase their display to use it, but obviously their code is more likely to have been tested on their displays...

Speed? - If your requirements are that you must have blazing fast updates to the screen, then you need to understand what using each type of display might do to your updates and the like.
Example: The ILI9341 has 320x240 pixels and it takes 2 bytes per pixel to update the screen(153600 bytes). The ILI9488 display is 480x320 (so twice as many pixels) AND it requires 3 bytes per pixel to be output (460800) so it takes 3 times as many bytes to be output over SPI to update the full display. So it takes 3 times as long...

RA8875 - Many of graphic primitives on these displays have hardware acceleration, so depending on your application, it may be slow it may not be. More details about this up on Sumotoys Wiki on this: https://github.com/sumotoy/RA8875/wiki There are a few different libraries for these displays, including Adafruit (GFX) as well as Sumotoys...

Warning on using Sumotoy's libraries - There is a lot of great stuff there, but he has not been at all active for at least a couple of years, so many of these displays require changes to work with newer boards like the T4 and T3.6 or T3.5. Some of them have been adapted to work, and some of us have those on our machines, we are still trying to figure out a good way to handle this type of issue where the library owner is no longer active. Example we have a good version of the RA8875 library.

Again hard to give any other suggestions, without having some idea of what it is you actually need....
 
Looks like fun,

I don't have much time to look at this in detail,

But, my quick look shows that you are using the ILI9341_t3 library and it looks like your project may want as high of speed as it can get.

If you try the ILI9488 display like the one I showed from EBay, you should probably try the library, that a few of us played with, for that display: https://github.com/mjs513/ILI9488_t3
I believe that library has most of the stuff to make it reasonably compatible with the ILI9341_t3 library plus many/all of the extensions from my ILI9341_t3n...

I see you have a custom font. I believe our library will support it. But again sizing might be different. That is if you are using a font like: DroidSansMono_48
Will that one be the right size when the display is larger?

Again not sure how well it will work when again you are pushing around 3 times as many bytes over SPI...

Good luck
 
As you can see from images, resolution is not so important, but if more resolution=more SPI data throughput things get worse.....

Just to understand how it works I'll try with ILI9488

Thank you
 


I've seen some projects using succesfully those buydisplay ones , what's the difference (interface) between these two ?

https://www.buydisplay.com/default/5-inch-tft-lcd-module-800x480-display-controller-i2c-serial-spi (the one you suggested)

https://www.buydisplay.com/default/tft-5-inch-lcd-display-module-controller-board-serial-i2c-ra8875

Isn't RA8875 using SPI protocol ?

Thanks
 
What is the difference between the two of them? Hard to say without looking through their reference documents. Could simply be more or less the same display but configured slightly different.

And note: RA8875 boards from Buydisplay may be configured for Parallel pin output, maybe even I2C, 3 pin SPI and 4 pin SPI. I have a few of theirs and they are configured for 4 wire SPI.
However at least one of them did not come that way, and I had to change some of the solder jumpers on the back of the board.

Again I am not an expert, but the 5" boards I have of theirs, in order to get capacitive touch, the display came with an external small wire cable, with a really small connector that you needed to solder to some board... Their 4.3", which I have a couple and their 7" which I do not have, you can get the Capacitive touch setup on the end connector 2x20 sort of like RPI and you talk to it using I2C. Again you have the option to configure the talking of the display to a few different hardware Interfaces.
 
Hmmmm, I forgot to scroll down the webpage for all of both display informations (including datasheets, interface configuration, and example codes)

They seem to be the same controller-equipped RA8875 but despite both are 5" the one labeled "RA8875" has 480x272 resolution instead of 800x480
 
I've found a tweaked code for the project I posted using the buydisplay RA8875 display.
The author of tweak (not the original author) had to use Teensy3.6 because of lack of CPU resource of 3.2 when switching from ILI9341 ,any comment about ?
 
@xerox,
I guess you are working on a ham radio project - SWR/power meter? That's very interesting, I just started thinking about a Teensy 4 antenna-analyzer/auto-tuner/SWR meter myself, for after I finish my current project: a stand-alone T4 based WSPR encoder/transmitter.

Like you I have been wanting to use a larger screen, particularly for my SDR work. However, I think I'm just going to move up to 3.5", probably from Adafruit. It has a different controller, but of course works with their own graphics library, which is the basis for the Teensy ILI9341 libraries - in fact I read recently that it works directly with the Teensy libraries. There are a couple of factors to consider: a higher pixel count will increase the SPI interface the screen refresh time, and add extra computational load in the graphics processing. It's also $39.95, which is more expensive than the Chinese ones.

Several years ago (before the Teensy) I purchased a 5" RA8875 display to use with the Arduino Due. I know it was meant to have hardware acceleration but even so I found it too slow to be useful for dynamic graphics.

Derek
AC1IN
 
Hi Derek,
SWR/Power meter doesn't need that great resolution, I think in Loftur TF3LJ project all those routines about modulation analyzer and touch menu are pretty useless and resources-consuming, probably a 4-bars no-menu indicator would be enough (20-200-2000W + swr one) , also no need for digit power indicator , like the usual needle one does....
So there would be more room for RA8875 things , so 5" or 7" display with T3.2
But it would mean rewrite the entire code, and I have obviously no skill in this.
I will try to achieve something-like with Arduino when Nextion display arrives...

However teensy 3.6 + RA8875 is already available and working , while Teensy 4 with 7" LCD is still work-in-progress here : https://groups.io/g/RadioStuff
 
How good is the RA8875? Last time I tried to use it I couldn't get it to stop flickering! Could be my fault.

I've been using the 7.0" 800x480 EVE displays that run on the FTDI FT813 chip using SPI (also compatible with QSPI but I don't know how to configure that with Teensy4). It's quite hard to get a good library for them but if there's interest for it I could try to clean up my implementation and put it up on Github.

Here's a little demo of how far along I got playing with it (sorry for vertical video):

 
Linarism, that looks fantastic! I at least would be interested in using something like that in a project - but I have to admit my time for projects has been very little lately. I never got anything that fully fleshed out working on the RA8875, but I did use it for a very minimalistic UI and found that being very intentional about only redrawing what changed seems to be the approach that gave me the best results.
 
I'd be very very interested in getting a quick look peek at how you were able to get this system running.

For me, please do not spend a lot of time cleaning up your current implementation as I don't expect you to give me a production ready library... I'd just like to see a general overview of what was involved in getting the EVE Embedded Video Engine up and running.

Thanks very much for your consideration.
 
There is also the Gamduino 3 7" 800x400 FT815 GPU, fully developed library and tested with Teensy 4.
I am using a couple with Teensy 3.2
 
I'd be very very interested in getting a quick look peek at how you were able to get this system running.

For me, please do not spend a lot of time cleaning up your current implementation as I don't expect you to give me a production ready library... I'd just like to see a general overview of what was involved in getting the EVE Embedded Video Engine up and running.

I would recommend starting with the Gameduino code for trying the displays that include FT810, FT812, and FT815.

I first tried the RiverDi 7" display using the GD3 code that was modified to work with Teensy3.2. Then as I changed to use the not supported Matrix Orbital Display , I ended up modifying a lot of the guts until I got tired and just rewrote it instead. For example for the touchscreen to work on some displays (like the Matrix Orbital), you literally need to upload the firmware needed to overwrite touchscreen controller code on each boot. It's ridiculous!

It's important to note that I could only get this display running in a full screen refresh operational mode. That is, I do not overwrite the changed pixels, all implementations redraw the entire screen at 60FPS. Likely this approach feels faster than changed pixels because there is less time wasted on the microcontroller and instead a very limited set of commands (instruction set?) is sent to do a full rewrite. The biggest benefit I noticed is the free automatic anti-aliasing for SUB-pixel movements and FRACTIONAL line widths. It's very nice to look at. In fact, I loved it to much that I write a little GUI library that could automate the animation and composition for me. It's this part that needs to be cleaned up. The driver will not make this difference for the chip, it's instead really been painful OOP...
 
Linarism, that looks fantastic! I at least would be interested in using something like that in a project - but I have to admit my time for projects has been very little lately. I never got anything that fully fleshed out working on the RA8875, but I did use it for a very minimalistic UI and found that being very intentional about only redrawing what changed seems to be the approach that gave me the best results.

That sounds efficient for SPI! That probably makes the difference for flicker. Maybe I should give it a second try if there's a nice super-bright display I could find for it.
 
Just keep in mind that the costs of EVE2 / 3 screens are not economical. However the screen performance is excellent. Matrix Orbital screens have quite advanced touch controllers, however additional routines must be implemented inside of the library for gameduino.

It is possible to adjust the library to work with the SdFat beta library and the SDIO reader of teensy 3.6 and teensy 4!
 
Back
Top