TFT (touch): Reaching high refresh rate cost-effectively

I am thinking of starting a project with very low computational burden - mostly just using a UI to change when and how outputs will change over long periods of time. I was planning on having the UI be touch but I could also use soft keys off the edge possibly.

I haven't decided on a size specifically yet but probably something 3.5" or above is a good place to start. Pixel resolution should probably be 320x240 or above as well.

So, what's the best Arduino + TFT combo that could get me to a "decently fast" refresh rate?
And to qualify that question a bit - I'm hoping screen redraw, if noticeable, is at least fast enough to not be a burden. Maybe I'm looking for about 1/5 ~ 1/2 second to clear the screen and draw some text and shapes on top. Something that actually operates in units of >1Hz is preferable though - is something like that feasible with Arduino?

My last constraint is cost. Looking to do this under about $40 if at all possible.

Bottlenecks in the past for me have been with SPI tfts and the generally slow clock speed of Arduinos, at least when you compare them to modern CPUs (which is a bit unfair, I'll grant). I haven't tested a parallel tft but that is definitely an option - I just need confirmation that it can achieve the kind of refresh rate I was hoping for or if there is some other technology that can instead.

Let me know if you have any ideas! Or "near misses" will help me understand the general limitations I'll be running up against too.

If you want to use an Arduino, check how much of a single image fits into its RAM. If you only want dancing bar graphs or walking text, that’s okay with most displays and almost immediate refresh.

Did you confuse “refresh” and “frame” rate? For playing videos and the like get an old smartphone.

Hey thanks for the reply.

Did you confuse “refresh” and “frame” rate? For playing videos and the like get an old smartphone.

Perhaps the issue is that I’ve never achieved anything close to a “frame rate” just doing normal draw calls, not actually trying to stream video. I don’t know if I need that here either - mostly I’m looking for a not-glacially-slow transition if the user were to request another menu. So this might be screen clear + draw some text + some shapes. The amount drawn and fidelity really depends then on how fast it is. Anecdotally I’ve noticed fonts and sprites tend to be quite slow, presumably because it’s sending out the array data for the image pixel-by-pixel over SPI every time.

When you mentioned RAM, were you talking about on-TFT memory? I’ve never used one with an SD card but I imagine that yes, without actually sending all the data out over SPI it will be much quicker. Is that how UIs are generally done?

Timing depends on the intelligence of the display controller. If it only can paint pixels, AKA GDI printer, the transfer of those many pixels will be very time consuming. If it can at least paint characters, in various font sizes, text output does not require much transfer time. Dunno for sure, but I can imagine that clever display controllers are expensive.

Computer displays are served by a graphics card with all kind of hardware acceleration, like cached fonts and images, and DMA transfer of changed data. All that is available only with systems supporting DMA and much very fast RAM (366MHz) for bulk data transfers. Slow Arduinos at 16MHz and SPI instead of DMA cannot compete with even a RasPi or Smartphone display capabilities.

I like the RA8875 based displays that Adafruit sells. (You can also get more varieties of displays with the same RA8875 chip from other sellers.) The RA8875 does a large amount of the processing for you. So instead of drawing a circle pixel-by-pixel, you just send the circle command to the RA8875 and it does it for you. It's not a perfect graphics co-processor for the Arduino but it's the best one I know.

For what you are doing, it is probably not necessary to go for the more-expensive graphics. Just update your screen in a sensible manner. Instead of erasing the entire screen and refreshing it totally, just update what changes: the actual measurement values. So split screen drawing into drawLabels() and drawValues() functions.

With a little more effort, it's possible to get high update rates in the 50-60Hz range on most of the simple Arduino displays. For example, remember what value you drew last time and only redraw the digits which changed. For bar charts, only add or subtract to a bar instead of redrawing the whole bar. For fancy coloured backgrounds, use a mathematical function to describe the background so you can erase any pixel back to background color without touching any surrounding pixel. I like using vertical gradients that can be drawn with horizontal lines or rectangles. They look good and the redraw-cost is very low.

Thanks again for the replies. It's helping me to get a sense for the options available to me.

I looked into things a bit more myself and found that some people can achieve ~60Hz when using beefier CPUs like the ESP. Speed of TFT screens, refreshing whole screen, flickering on SPI - Displays - Arduino Forum

I don't know if I need to go this far for my purposes, but at least it helps understand how it's possible. Several timesaves that I knew about but didn't necessarily want to get into like double buffering also came up. I think I'd need the right hardware support for that though, and again... might be overkill for what I'm trying to achieve.

Anyway the most interesting part of that thread to me was mention of achieving decent framerates even on an Uno in monochrome. I'm not entirely sure if I want to go monochrome but I would definitely not be opposed to low color depth, maybe 8-bit or so.

So this is probably me not understanding the specs well enough, but I don't think the TFTs I've used in the past have options to change to a different color mode (at least a lower depth one - I think I looked into it on one of them and saw the option to change from a 16-bit to a 24-bit mode). Is there a TFT out there that I could achieve a low color-depth on? (and again still around 3.5" or so).

And on the same note of me not understanding specs, I actually do have an RA8875 from another project laying around. I do agree that the hardware accel helps but sprites and custom fonts (e.g. more sprites) are still the bottleneck there.

Anyway, I was reading on its features a bit and it was unclear if there was something I was failing to use like on-chip memory. It certainly doesn't have an SD card slot on it or anything like that, so maybe it's a different model that was being discussed. If there were any way to just preload most of the menu graphics onto the RA8875 (or any chip for that matter) I think that would fit for my application too.

So if anyone can recommend a particular (touch) TFT that supports a low-color (but ideally not monochrome) mode or has some onchip memory, I think that's all I'm really looking for here. Or if there are other technological thrifts I'm not considering, let me know...

You want menu graphics at high frame rates? What kind of a menu is that?

Numbers and bar charts are very quickly redrawn with no on-chip memory.

Not precisely. As I mentioned several times, the exact goal is just bringing down redraw times to lower how noticeable they are. So in no way am I targeting a real frame rate, just snappier performance if possible.

To qualify the "fail case", In a previous project that had some mid-size sprites (some custom buttons and large ~32x48 monochrome numbers) the act of drawing them all when the menu screen changed could take 3-5 seconds. This was true with the RA8875@480x320 even but it did manage to severely cut down the time drawing any rectangle or other basic shape took which means I'll probably take advantage of that and go less sprite-heavy next time.

Anyway I understand that you can avoid the extra costs of drawing text if you don't use custom fonts. The problem is just that the choices you get with those fonts are very limited. Worst-case I could just design around the RA8875's normal font size though, I guess, since it's such a performance save compared to getting custom fonts in there.

You are doing something inefficient. Custom fonts are very fast on the RA8875 even at that large size.

I ran 32x40 character sizes on a display without the RA8875 (one of the 2.5" TFTs from Adafruit) and it was slow initially. Bad flickering when updating the numbers.

I increased the SPI speed by one stage and focussed on only updating the digits which changed and there was no flickering and very fast response. This display also had a speedometer needle, other animations and a pretty background image for the needle and digits to move over.

Show your code if you want help identifying the inefficiency.