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]

@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

[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?

[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?