external gram / vram / videoram - any experience?

[Beck.Karl-Michael]

Posted on July 06, 2018 at 15:50

Hello,

we are running a stm32f49xxx mcu with sdram which is used as a video ram.

now with higher product lines we have more traffic on the memory bus causing flickering. With code optimization we can reduce it but it appears again and again with every minor change we make in the stm32 application code.

as far as i understand the lcd controller requests in 60fps rates the data from for the picture from the sdram which interfers with the applications access to the sdram causing the flickering.

if we had a lcd controller with own framebuffer the flickering should disappear as the frame is buffered in the gram, right?

i just had a look on the solomon systech ssd1963...

Is there anyone who has experience with this issue, maybe can suggest a concrete model of lcd controller which works good with the stm32f49xxx? Some tips what i need to be aware off?

As far as i understand the gram should be adressable through the memory controller, in order dma2d can be used to transfer the frame to the gram. More 'major best practices' known for this?

Thanks so far.

[Tesla DeLorean]

Posted on July 06, 2018 at 16:51

What is stm32f49xxx? You mean F429 or F469?

Is your external bus 32-bit wide?

How large (resolution) is the screen and frame buffer? Are you using multi-frame buffers? You don't have to get far to get into the 54-60 MHz bandwidth and 100 MBps

Consider parts with more internal memory, and DSI.

L4+ Series?

[waclawek.jan]

Posted on July 06, 2018 at 16:51

No experience with this here, but have you read the related appnotes (

/external-link.jspa?url=http%3A%2F%2Fwww.st.com%2Fcontent%2Fccc%2Fresource%2Ftechnical%2Fdocument%2Fapplication_note%2Fgroup0%2F25%2Fca%2Ff9%2Fb4%2Fae%2Ffc%2F4e%2F1e%2FDM00287603%2Ffiles%2FDM00287603.pdf%2Fjcr%3Acontent%2Ftranslations%2Fen.DM00287603.pdf

This is a reocurring question here so you may want to search the forum.

JW

[waclawek.jan]

Posted on July 06, 2018 at 16:54

Clive,

Consider parts with [more internal memory], and DSI.

I thought the MIPI/DSI module is just a hangoff on a very same LTDC as in the MIPI-less mcus, so it can't make a difference bandwith-wise... did I miss something?

Jan

[Tesla DeLorean]

Posted on July 06, 2018 at 17:19

DSI doesn't eat a shed load of pins, so the arguments for wide memory buses and pin utilization are easier to have.

I don't think the STM32 design and SDRAM are good at high pixel clocks. I had to buy a video card in around 2000 with a 250 MHz Video DAC, so I think the design here is pretty nut-less.

640x480 24-bpp @ 60 Hz -> 75 MBps, you need multiple frames, and expect to be able to render fast than you can raster.

Definitely not going to be able to render to a frame buffer in an SSD1963 faster than you can to SDRAM

[Tesla DeLorean]

Posted on July 06, 2018 at 17:27

https://community.st.com/0D50X00009XkVwISAV

 

[waclawek.jan]

Posted on July 06, 2018 at 17:43

DSI doesn't eat a shed load of pins, so the arguments for wide memory buses and pin utilization are easier to have.

Aaaaah so, I see, thanks for the clarification.

I don't think the STM32 design and SDRAM are good at high pixel clocks.

I don't believe it was meant to be. It's just that it's (relatively) easy to slap together modules onto a bus, so why not doing it. This is fairly good for the smaller panels (QVGA) as you spare the cost of the controller and can show off (see 'F429 Disco), but anything beyond that IMO does not make much sense. But again, I don't understand the huge interest in the 'H7s and this world.

The videocard you bought back then probably also had dual-port (D)RAMs (aka 'graphic RAMs'), and for a reason.

JW

[Tesla DeLorean]

Posted on July 06, 2018 at 18:09

I think it was a Matrox Millennium series card, and I had to get a memory upgrade to get to an 8 MB frame buffer to drive the display I had. Probably late 1990's trying to Google it.

>>

This is fairly good for the smaller panels (QVGA)

 ..

Yeah, I think it is probably great for retro Nintendo games, or Colecovision Donkey Kong. Or low end thermostat. The market I think expects the clarity of a smart phone screen at this point.

>>But again, I don't understand the huge interest in the 'H7s and this world.

The H7 seems to tries to do things a Tablet chip running Linux/Android could do better/cheaper. It clocks 400-500 MHz so is an impressive CM7 w/FPU-D, but the lack of a working DSI implementation seems to have dampened up take significantly. That and a realistic path to FHD or UHD seem to constrain the use cases.

Still something that could replace legacy PC applications with a small box and a fanless micro, that has availability beyond 1-2 years, and isn't an IP infringement rats-nests.

[Tesla DeLorean]

Posted on July 06, 2018 at 18:21

>>

Aaaaah so, I see, thanks for the clarification.

The LTDC is still going to be a bandwidth bottleneck that is shoveling data to the display interface, be it RGB pins or DSI.

By the time you hit the 500 MHz 2-lane limit of the DSI, the 50-62.5 MHz clocks on the F769I-DISCO are hitting a bandwidth wall on the rastering side, and the ~100 MHz SDRAM

[Beck.Karl-Michael]

Posted on July 09, 2018 at 11:58

Sorry, stm32f469 - no l4 series.

buswitdh to SDRAM  is 32 bit.

We have 800x480 px at 16bit pixeldepth with doublebuffer.

> 

Consider parts with more internal memory, and DSI.

Yes, the idea was to use a ltc controller with internal memory for the current frame.

So transfer is only done once when the frame changes.

The iram is used for stack, the rest is allocated on the heap in sdram.

I could give it a try allocating some data for the application model in the iram.

Something similar helped last time [1]

But now we have much more data, way too far to allocate all in the iram.

I must read some more about the memory controller.

Maybe there is a way to give higher prio to the transfer lcd controller<-&gtsdram than the prio application<-&gtsdram.

That could help also...

[1]

https://community.st.com/0D50X00009XkftQSAR