n00b question: How big of a screen?

[TwelveSquared]

Trying to decide if TouchGFX with some variant of STM32H7 is the right solution for us and the Boss wants to know how big of a screen we can expect to drive and still get quality resolution and snappy feel. How do I determine memory requirements and refresh time?

[Tesla DeLorean]

Most of my 27" screens look fine at 60 Hz

Seem to recall you usually run out of bandwidth on STM32 implementations due to 1Gbps (2-lane DSI) or 50-60 MHz pixel clock

Figure 1024 x 768 would be serviceable

The STM32 isn't going to be able to do FHD, QHD or UHD type displays

>>How do I determine memory requirements and refresh time?

Well each pixels going to take a couple of bytes or three..

Figure several MB, of 32-bit SDRAM, the sweet-spot of those devices is likely to significantly exceed the resolution limits you'll hit much earlier.

[ktrofimo]

Can't tell much about DSI displays, but for parallel RGB-TFT it looks like 1024x600 16bpp (RGB565) @30Hz ​is almost top configuration. In some screens I'v got glitches that could be removed only by simplifying layout (at least I couldn't find another solution yet).

For 7" screen it looks pretty good. But 800x480 is not that bad either, and quality might be even better because of higher frame rate (about 50Hz). Technically it should be possible to increase pixels clock for 1024x600 in order to get higher FPS, but it depends on screen very much. For my screen I can use only 30MHz and any other pixel clock frequency results in weird blue pixels at the gray edges.

And high pixel clock requires very high SDRAM bandwidth.

Memory requirements ​is 1024x600x2 bytes = 1.17Mbytes per buffer. And because it is recommended to use separate bank for each buffer it is better to give 2Mbyte per buffer, so 4Mbytes in total of SDRAM. May be 2 or 4 bank chip with total volume of 4 or 8 Mbytes should be good enough.

Memory bandwidth is little tricky to calculate (it depends on ​many parameters including how MCU is actually read and write data), but quick and dirty calculation shows that 32bit SDRAM @125MHz and CAS Latency 3 should have about 160Mb/s bandwidth while 1024x600 16bpp @30MHz screen requires 57 Mb/s (36% of max bandwidth). This figure looks like correct because even in 16bit mode SDRAM was fast enough to feed my screen.

[TwelveSquared]

@Community member​ thanks for your reply. A few months ago I looked into TouchGFX a little and seem to recall that some formulas were shown to calculate the memory requirements etc., but I can't seem to find that information now.

1024x768, supposing each pixel requires 1 byte (in a 256 color format) that would require 786,432 bytes of memory just to hold the image; double that if I want double-buffering; then this would imply I need a micro with external RAM if I understand correctly, or is that basically a given whenever any kind of graphics are involved?

[TwelveSquared]

@ktrofimo​ thanks very much for your answer. Are you using the TouchGFX software to manage what's displayed on the screen? Regarding the visible glitches you mentioned, was that due to hardware limitations or software issues?

[ktrofimo]

1. Yes, TouchGFX

2. Hard to tell exactly why it happens. Had no time to dig deep. Simplifying layout helps and ot was enough for me

[Tesla DeLorean]

I think for the most part you either have 16-bit or 24-bit options for pixels. Figure 2 and 1/4 MB minimum, likely want to have an active and paint buffer, so 4.5 MB bare minimum. Plus whatever you want to cache/unpack fonts, and bitmaps, etc.

The typical catch-of-the-day SDRAM probably going to be 8MB (64Mbit) or 16MB, you're basically trying to pick a singular part with VERY HIGH RUN RATES, that will be a) cheap and b) long lived (used by many, profitable to keep making, or have a replacement for), c) non-exotic foot print for cheap PCB/PCBA

I think you can do internal screen buffering on small screens, figure 390x390 circulars, 320x240 type screens.

Would also suggest wiring up a QSPI memory, use the 16-pin SOIC 300-mil, everyone has parts in this form-factor without weird/unique land patterns and ground. Provides for lots of options. Support in STM32 upto 256 MB single bank.

[TwelveSquared]

@Community member​  are you talking about a QSPI flash memory for things like bitmaps? Which STM family have you used for graphics? I was looking at the H7 but it seems the L4 might actually be more capable (supporting touch sensing within the SoC for example), the other difference being "high performance" for the H7 vs "low power" for the L4. But should I expect that to affect refresh rates and the like?

[Tesla DeLorean]

QSPI NOR Flash can hold application and resources, these can always be significantly bloated in the graphic space. Value Line H750 have little official Internal Flash.

Most of my actual work is with industrial headless stuff, but I did a lot of sprite and raster display stuff in my youth, lot of Windows work, did a stint doing media players, and I can run panels on my pet/side projects. Mostly F4, F7 and H7, latterly DSI and HDMI. Got a pretty good handle on the process, methods and clocks. Not using TouchGFX, as most of what I need isn't that tarty, and I can draw directly into the frame buffer.

I think you'd need L4+ for LCD support, don't recall the state of external RAM on those devices (slow, muxed?), but the H7 is a least 4x the Horse Power and a far more powerful MCU / FPU combo.

L4+ supposed to support low resolution 390x390 (or so) displays, for internal memory, and a means of optimizing non-visible regions (circular), personally I'd think it's ill suited to anything hi-resolution.