STM32F429 LTDC 2Layer - Problem with external LCD (640x480)

Posted on May 02, 2014 at 12:55

Because you exceeded the framebuffer memory's bandwidth?

JW

Posted on May 02, 2014 at 13:09

Where is the limit? The datasheet says ''LCD-TFT controller up to SVGA resolution'' - so does this not work with double-buffering?

Here is an cut-off from page 22:

The LCD-TFT display controller provides a 24-bit parallel digital RGB (Red, Green, Blue)

and delivers all signals to interface directly to a broad range of LCD and TFT panels up to

SVGA (800x600) resolution with the following features:

• 2 displays layers with dedicated FIFO (64x32-bit)

Posted on May 02, 2014 at 13:54

> Where is the limit?

There are many variables going to the limit calculation - such as memory type and buswidth, FMC timing settings, LCD resolution and timing, color scheme used, parallel load on FMC - so there is no simple answer.

OTOH, it's the kind of back-of-the-envelope calculation you should've performed beforehand, and I am not going to do your homework. It may well be that this was not the root of your problem.

JW

Posted on May 06, 2014 at 11:40

I think JW is right. A Layer in ARGB8888 and an resolution of 640x480px takes ~70 MBytes/second.

I'm new to ARM and to external RAM - so i'm not shure about all these things. The SD-RAM is clocked with 90MHz (SYSCLK/2) and has an CAS latency of 3. Does this mean, that i can only read data with 30MHz in best case (no refresh) because it takes at least 3 clock cyles before the data is available? The RAM

http://www.issi.com/WW/pdf/42-45S16400J.pdf

has an programmable CAS latency of 2 or 3. The example uses an CAS latency of 3 - why not 2?

I changed the Layer-Pixel-Format from ARGB8888 to ARGB1555 which needs the half of the bandwidth. So i can use 2 layers now.

But when i calculate with th 30MHz (CAS latency of 3@90MHz) and 16bit-RAM-width i get 60Mbytes/second - which is not enough for the 1 Layer ARGB8888 or the 2 Layers ARGB1555 - but it works. Why?

Also i see, both the DMA_FIFOMODE and the SDRAM_READBURST are DISABLED. Does the LTDC can handle Bursts?

Another option is to use an 32Bit-wide RAM - does it bring twice of the performance or is there another bottleneck i did not see at the moment?

Thank you in advance...

Posted on May 16, 2014 at 09:09

Can someone tell me how does the CAS-Delay is related to the timing? I got many results from google - but no precise result (many links for PC tuning).

Does it take e.g. the 3 Clock cycles (CAS-Delay: 3) for every access? And why the Timing Parameters from the datasheet say (for the -5 type):

Access-Time:

CAS Latency 3: 4.8 ns

CAS Latency 2: 5.4 ns

shouldn't it be inverse?

Posted on May 16, 2014 at 10:01

It takes some time since the column address is established (i.e. READ command issued) to get the data from the row latch through the ouput multiplexer. While physically this is some minimum time given by the construction of the address decoder/output multiplexer/latch, for design/traditional reasons in datasheets it is not expressed plainly in nanoseconds, but as a combination of number of clocks (CAS latency - 1) and the ''remainder'' time (that's the ''access time''), which at the end of the day yields you the output-data-to-clock setup time (thus, specified access time can't be longer than clock time, it would yield negative setup time i.e. data arriving late). Do your own math exercise for these times for the given memory (hint: 7.5+5.4 is roughly the same as 2*5+4.8, the reserve goes to allow for some clock jitter and internal skews and similar).

If you really want to push things to the edges, I'd recommend you to familiarize yourself in depth with the concepts of synchronous memories and with the details of working of FMC, DMA and the rest of the chip. At least the first issue is not really matter of discussion on this forum, and the second requires quite a lot of homework, too.

And, to avoid disappointment, I'd recommend to cut down the optimism in your requirements. The easiest way is perhaps to decrease the color depth.

JW

Posted on October 13, 2014 at 21:58

@lohse.dirk

First, calculate the required memory bandwidth:

ARGB8888 = 4 x 8 bits = 32 bits = 4 Bytes.

Each frame: 640 x 480 x 4 = 1228800B/sec = 1.17MB

For 25fps refresh rate you need 29.25MB/sec memory bandwidth.

Then calculate the memory bandwidth

memory bandwidth  = SDRAM frequency x SDRAM bandwidth / CAS latency

SDRAM frequency can be HCLK/2 or HCLK/3, max = 90MHz for 180MHz HCLK.

SDRAM data line can be 8, 16 or 32 bits wide.

memory bandwidth = 90MHz * 4Bytes / 3= 120MBytes/sec.

However, if you use burst transfers there is no CAS latency between sequencial transfers so the max memory bandwidth can reach 360MBytes/sec.

If you want to use the USB peripheral, the max HCLK that allow you to have 48MHz clock for the USB is 168MHz, so the max available bandwidth is (168/2)*4=336MBytes/sec

The required bandwidth for the LCD-TFT controller is about 30% (10% with burst transfers) of the available bandwidth. If you use 16bit SDRAM data line then you will use about 60% (20% with burst transfers) of the available bandwidth and 80% (40% with burst transfers) if you use 8bit SDRAM data line.

You use the rest of the bandwidth for image copy, move and other tasks.

Important notes:

I have not calculated any possible overhead of the sync signal.

It is impossible to have only burst transfers. The max memory bandwidth is never available because every time you start a new transfer to or from the SDRAM, you will have CAS latency. However burst transfers significantly increase the overall performance.