Hi, all.

A while ago I started making a touchscreen gauge using a 4D Systems "Gen4" display for the graphics and an Arduino as a controller.  However, I came up against an insurmountable problem; the 4D Systems screen isn't capable of refreshing quickly enough to move the gauges smoothly.

Some brief info on 4D Systems screens, if you're not familiar with them:  They make it easy to create touchscreen controllers.  You use a nice graphical IDE to create gauges, buttons, sliders, etc. which you upload to the screen.  I then use an Arduino to handle the I/O.

Here's a link to a video to show how the gauge works and also the fact that it moves too slowly.

There's nothing that can be done about the screen, the refresh rate is just too slow.  So my question is: Do you know of any other makes of touchscreen that I can use to do the same job, but with an adequate screen refresh rate?

I'm not an expert programmer, so I don't have the skills to just take a bare screen and create everything I need to run it.  This also isn't an academic exercise, so I don't have the time to become a programming expert either!  I'm just looking for alternative routes to producing the end product; a cool looking touchscreen gauge with smooth movement!

Cheers in advance.

PS. Here's a video to show how the gauge works and also the fact that it moves too slowly.

...And here's a video to show how fast the gauge needs to work (Skip to 1:46)

Welcome to embedded programming in the real world.

Unfortunately, I'm not aware of any easy answer for you. I suspect the LCD screen refresh rate is almost certainly fast enough (60Hz or better probably), but updating the graphics buffer is what is slowing you down. This is the problem with using canned graphics libraries and UI builders--they work great for buttons, sliders, and the like, but fall down when asked to do real-time work. Are you sure you're really looking for a new LCD, or are you actually looking for a more performant graphics library (or processor)?

In any case, I developed an LCD audio meter bridge once. The LCD refresh rate was 60Hz and plenty fast enough, but the ARM processor driving it couldn't do all the necessary computations AND redraw a new frame buffer to the LCD every 16ms using any canned graphics library. I ended up writing my own library, including pre-computing multiple graphics pixel buffers and writing my own font cache. That plus a fast memcpy() gave me the time I needed to do all the calculations plus redraw the frame buffer in less than the LCD's 16ms refresh rate. If you're looking for real-time performance, you'll have to do something similar or find a graphics library capable of real-time performance. Most off-the-shelf touchscreen drivers aren't designed for such real-time performance. 

As a start, you could try creating pixel buffers of the needle at EVERY possible position in memory, and then blitting the correct needle position onto a copy of the meter dial, and then copying that result to the frame buffer. The current code is probably redrawing the needle at the correct position EACH time it changes, which is bound to be slow on most embedded processors without GPUs. Another option is to find a display driven by a processor with an embedded 3D GPU engine, and then either find a graphics library that uses it OR write the critical speed parts in OpenGL ES.

Like Bob11 said there might not be an easy answer.  Without sounding like an ad, one path to look into might be the Renesas Synergy platform.  It has the Express logic GuiX tools available for users and from there you can create some pretty nice displays.  The S7 parts have some pretty reasonable performance that could produce the speed your looking for without having to write low level drivers.  The Synergy platform has taken a lot of the low level work out of the project for the developer.  They have lots of examples, and a nice forum with Renesas paid technical folks answering questions.  Might be a bit of work and maybe more programming then your looking for, but its another possible path.  

Take a look at the FT81x chips from FTDI (more precisely, the FTDI spin-off Bridgetek). They are quite interesting.

The chip does not have a frame buffer, but it has 1MB of RAM for bitmaps and whatnot. It has an LCD driver, a rendering engine, a graphics coprocessor specifically designed for GUI stuff, audio output (with built in sounds), backlight controller and in general pretty much everything you may want in an embedded systems's display. It also contains a touchscreen controller, either resistive with single touch or capacitive with multitouch. Furthermore, every display object can have an 8-bit tag and when the user touches an object, the chip tells you not only the coordinates, but also the tag, which is very handy for buttons.

When you first read the manuals, it seems very strange. But the more you play with the thing, the more you realise that the FTDI guys have actually thought about the problem and you can have a pretty nice display with not too much code.

You talk to the chip via SPI @ 30MHz or QSPI @ 20MHz, the latter allowing you a 10MB/s data rate. But since you're not drawing the bitmap yourself, you just send commands to the coproc and the renderig engine, you don't need very high traffic.

The chip, by the way, can play back video with sound, if you feed it via the SPI. Admittedly, it's limited to AVI container with MJPEG video and PCM, uLaw or ADPCM audio, but it's still impressive.

Newhaven Displays sells TFT panels equipped with that chip, but you can connect the chip to pretty much any TFT. Newhaven has the schematics for their displays on their website, so you can take a look at an example there.

I'm not related to FTDI, Bridgetek or Newhaven in any shape or form, but I used one of those displays in a recent project and I was quite satisfied. It was kind of a learning curve to understand how it works (and the Bridgetek docs are not the highest guality; if you also read the older FT80x docs from FTDI, that will help). But then, it's really easy to make good-looking GUIs with not much effort.

I'll also recommend the Bridgetek based displays, RS and Farnell both sell them in a range of sizes and formats.

Having tried a few things (libraries on ST ARM processors and RPi4, other SBCs) I reckon the separation between main processor and graphics processor works very well and allows you to avoid a full on "applications" processor and OS for simple instruments.

MK

I'd say it is not a problem to implement the 2nd video speed on an ST's TouchGFX. Try it, they have an excellent built-in simulator, which will give you the picture with real display speed. 

https://www.touchgfx.com/

To me, it took very small amount of time (after an education curve :-)) to develop a cool looking and very fast GUI for STM32F769IDISCOVERY (80$). Taking to account that they have a FreeRtos in the heart, integrate the TouchGFX GUI with my application was just no time. 

P.S. Previously I had had multiple projects with LCD screens, however all of them were working similar to your video #1. However, with ST TouchGFX you'll get a real-time "mobile-phone" like experience on the embedded system.

P.P.S.I am not working neither for ST nor for TouchGFX)

Thanks, everyone, for the replies.  Very helpful info, which I will look into :)