reduce LCD BW and memory by doubling pixels/lines, is that possible?

[andrea venturi]

hi,

i have a STM32F429 custom board with 320x240 display. now my boss want to move to larger display with 1024x600 resolution still RGB 18 bit Hsync/Vsync DE and Dotclock.

i'm plan to test it at full resolution (RGB565 with 16bit per pixel) as i have a 8MB SDRAM so framebuffer(s) room is not an issue, but i'm wondering about the STM32F429 capability to sustain such bitrate stream between ext SDRAM and the RGB encoder HW module (at 60Hz refresh rate?)

is that feasible and/or tested?

on the other hand, i'm asked to put up a larger screen, not a higher res! :)

so i'm wondering if there's a way to double every pixel on a line (from 1024 to 512) and/or to double any line (from 600 to 300) or reduce refresh rate (from 60 to 30..), so BW would decrease up to 1/8.

anyone chiming in with his thoughtful hints!? :)

bye

[Martin KJELDSEN]

Hi @Community member​,

60Hz is a tall order for an STM32F4 at 1024x600 resolution, depending on what you want your application to do. The STM32F469-DISCO in our ATs (800x480) struggle with full screen transitions, for instance, but if you're not moving a lot of pixels at the same time then you may be fine =)

You may be able to play around with LTDC image width/height parameters to blow up the framebuffer by some factor.

/Martin

[andrea venturi]

Martin, thanx for the quick reply

the app is NOT dynamic at all.. so very few pixels are moving. mainly when transition from screen to screen with "no fancy" animation.

if i could refresh @30Hz. that would be great.

then i do not understand what you mean with "blow up the framebuffer".

reducing the resolution would be my first aim, but AFAIK a LCD display has fixed resolution. that's why i envisioned to "double" pixels or lines to at least give to ext memory bus some relief!

i'dl surely "play around" with LTDC if i could have some lead. any example ?

bests

[waclawek.jan]

By this time, you're surely intimately familiar with AN4861 for bandwidth calculations.

You can also start with considering L8. I know the pain that means.

> reduce refresh rate (from 60 to 30..),

That's a question for which the answer is to be found in the DS for the display. Lower refresh rate may be available but I doubt it will go as low as 30Hz. Also, the DS may allow that, and the display may then exhibit unbearable flicker...

> double any line (from 600 to 300)

That won't help you, you'd need to read the information for a single line twice, that's the same bandwidth.

> double every pixel on a line (from 1024 to 512)

This prehaps may be viable, and I'd even try to cut it to 1/3 which is still more than your original display has. I'd do this by feeding the LTDC from the R-tap of PLLSAI 1/3 of the pixel clock rate, and output the real pixel clock towards the LCD through the SAI from the Q tap of the PLLSAI. There may be some skew involved, so I'd be prepared to delay that clock e.g. through a cascade of external 74xx gates at least on the prototype.

There are also displays with controllers with embedded memory out there, although I don't know/won't investigate about availability for your target size/resolution.

JW

[andrea venturi]

thanx for the advices!

maybe i forgot to mention, but of course the solution "should be" compatible with the "TouchGFX" library/binary blob, because we work with that editor/framework.

the "screens" are completely different because the model with 320x240 is a different product then the model with 1024x600 screen size (it's just that the "STM32 board is the same, recycled..)

now i'd just like to understand if the trickery about changing refresh rate or doubling the pixel time (very clever the hint about Q&R TAPs to tweak, thanx..) can be hijacked on top of a TouchGFX setup..

as soon as i'll get the HW prototype, i'll make up my first test and i hope to give back some positive feedback as soon as i find out something

Andrea