lcd framebuffer bus techinal question

[lpcware]

Content originally posted in LPCWare by Paride on Thu Jan 08 09:40:33 MST 2015
Hi All,

I'm an electronic engineer used to PIC, Atmel and similar and I'm trying to step into the ARM world.
I need to design a measurement instrument with a tft lcd and I'm looking at some NXP ARM mpu/cpu (lpc1788 or lpc 1835) with integrated lcd controller, I'm digging into the datasheets but I still have some questions.

From my understanding, In case I use an external ram memory as frame buffer, the integrated lcd controller can access it through the dma.
First question: the datasheet says that the lcd dma is 16 to 32 bytes long. Is there a way to program it to refresh an entire lcd screen automatically or every time the dma FIFO runs out I need to load new addresses and restart the dma?

Now let's say that I'm also running my program from an external flash memory, this means that the bus (ahb and external) is actually shared between the lcd controller that keeps refreshing the image from the ram and the cpu which fetches instructions from the external flash, correct?
In the question and answer on the nxp website (pasting the link doesn't work) someone is actually reporting lcd tearing effects and the answer form nxp is to change the access priority in the AHB matrix so that the lcd has an higher priority compared to the processor fetching data and instructions.
Second question: I suppose that making such changes slows down the cpu, the question is how noticeably is it? Is there a way to estimate it? I'm worried that, because in my case the cpu will always be running the software and acquiring data, it will always be slowed down by the lcd continuous refresh.

In the end the question is..is it actually useful to use the internal lcd controller or there are so many downside that it's not worth it?
I was interested especially in the colour look up table function so I can reduce the memory used for images and widgets but if the system is too slow I may consider and external lcd controller.

[lpcware]

Content originally posted in LPCWare by Paride on Fri Jan 09 07:10:33 MST 2015
I would like to avoid using 2 cores Bavarian. 
I'm looking into the dma controller for the peripherals and I was hoping that I could be acceptably responsive to the incoming data even when I'm busy updating the framebuffer.
I'm looking into the excel spreadsheet pointed by starblue and In my case I get a bandwidth occupation of about 20%.

Bavarian can you clarify your last statement about the bandwidth calculator?
Considering an lcd bus occupation of 20% can I say that I have the remaining 80% of bus bandwidth available?
The idea is still the same, using the external ram for the framebuffer and probably for some data(still evaluating if I can fit all the data in the internal ram) and an external flash for some other code/storage.
The 20% bus occupation leave me hoping that I have still enough bandwidth for this scenario.
From what I'm reading about the architecture, because the ahb matrix is multilayer, a nearly perfect scenario would be the cpu working from internal flash/ram which gets 1 layer and the lcd managing the ebi with the external ram which gets another layer. In this case the cpu and the lcd controller are not "disturbing" each other, correct?
In case the cpu also wants to access the external bus than the arbitration/priority scheme is applied and the 20% that I get from the excel spreadsheet is no more valid because I cannot estimate how often and for how long the cpu will access the external bus. Is this what you are trying to tell me?

[lpcware]

Content originally posted in LPCWare by giusloq on Fri Jan 09 06:54:41 MST 2015
This is a very interesting thread. I'm in the same situation as Paride: I need to develop a nice HMI on a 4.3" 480x272 TFT LCD and I'm thinking to use LPC43xx with precompiled emWin libraries delivered by NXP.

I started with some demos on my MCB4350 dev board from Keil, but the results aren't so good (you can see a video here: https://drive.google.com/file/d/0B4HaZMq4exDidGZzZjdTVmNkS00/view?usp=sharing). How is it possibile to reach the performance shown in the video indicated by bavarian?

There are two possibilities.
I made some error and I need to configure better my dev board (maybe something is wrong with LCD controller configuration). Anyway I started from the example project emwin_hello_world available in lpcopen_2_12_lpcxpresso_keil_mcb_4357.zip.
The second explanation could be the poor performance of pre-compiled emwin libraries delivered from Nxp over the touchgfx libraries used in the video suggested by bavarian.

What is the truth?

[lpcware]

Content originally posted in LPCWare by bavarian on Fri Jan 09 06:17:29 MST 2015
The internal RAM (96 kbytes) of the LPC1788/4088 will be a bottleneck. But the LPC1800/4300 offer more internal memory and also more CPU power.
In case of a static picture (always the same display frame data) the CPU load is 0. Then it depends on your frame updates how much the CPU is loaded.
If you have somehow the need for high real time capabilities, then I recommend to have a look at the LPC4300 with its two cores Cortex-M4 and M0.
With one core you could serve your real time needs and with the other one you handle the display and other I/O stuff.

I created an Internet radio example for the LPC4300 which uses this approach, all I/O and the TFT stuff is handled by the M0 and the MP3 decoding and other audio stuff is done on the M4. One of the advantages in product development and maintenance is the rather independent software development for the 2 cores. For example an upgrade of the GUI does not affect the real time behaviour of the audio decoding.

The bandwidth calculator needs to be handled with care, it only covers the channel frame buffer --> LCD controller --> TFT in a rather simple way. Any bus activity on the SDRAM from CPU side, or from GPDMA side will decrease the available bandwidth for the LCD controller transfers.

Regards,
NXP Support Team

[lpcware]

Content originally posted in LPCWare by Paride on Fri Jan 09 06:08:32 MST 2015
Thanks starblue, that's exactly what I was after to make some evaluations!

[lpcware]

Content originally posted in LPCWare by starblue on Fri Jan 09 05:12:58 MST 2015
There is a bandwidth calculator for LPC178x at
http://www.lpcware.com/content/nxpfile/lcd-bus-bandwidth-calculator-lpc177x8x

You might also want to search the forum for "lcd bandwidth".

[lpcware]

Content originally posted in LPCWare by Paride on Fri Jan 09 04:29:03 MST 2015
Thanks Bavarian,

I was unsure about how much I had to manage the dma for the lcd.
If the cpu load could be as low as the one indicated in the movie you linked I think I have enough room for my application and data processing.
I'm still unsure I could make it with only the internal ram for the framebuffer but at this point I think I need a dev kit to investigate more.

[lpcware]

Content originally posted in LPCWare by bavarian on Fri Jan 09 03:58:15 MST 2015
For such a picture size the internal LCD controller in the LPC1788/4088 or the LPC1800/4300 series is a perfect choice.
For this number of pixels you can create a highly sophisticated GUI with 16-bit colors, slide effects, alpha blending etc using emWin. Displays with more pixels require more calculations and therefore you might run into frame update problems
With the ARM core you work on the update of the display frame buffer, the transfer of the buffer into the TFT is managed by the LCD controller. You don't need to care about the DMA actions of the LCD controller. A complete display frame gets updated automatically, based on the settings you made to the LCD controller (pixels, color depth, frame rate etc). The LCD controller has a high priority in the AHB matrix.
If you use palettized colors you could think about working with an internal frame buffer, saving the external SDRAM might be an advantage.

See what's possible with a 480 x 272 display in a demo from Mjölner with the LPC4357 (not emWin based):

http://www.youtube.com/watch?v=dvSK0oXQqfA

A display with an integrated controller using for example an SPI interface of course makes it possible to shrink the number of pins and use for example a controller with 64-pin or 100-pin package.

Regards,
NXP Support Team

[lpcware]

Content originally posted in LPCWare by Paride on Fri Jan 09 03:55:24 MST 2015
Hi R2D2 :-)

I'm talking about some nxp mcu like lpc1788 with the lcd controller integrated into the chip so you don't need to use an external lcd controller. The models you are listing don't have the lcd controller integrated,.
I'll try to explain, lpc1788 and similar can actually connect directly to an lcd panel without any need for an external lcd controller like this:

nxp with lcd controller and framebuffer--->18/24 bit rgb to lcd panel

while in other cases you usually have an external lcd controller which can be integrated in the lcd panel or it can be another chip on your board

nxp with NO lcd controller and NO framebuffer--->parallel data to lcd controller with frame buffer-->18/24 bit rgb lcd panel

The main advantage of having it external is that the lcd controller has got its own memory for the frame buffer and it's easing the load on the cpu because once you load the data it will keep refreshing the screen without calling the cpu and it doesn't use the cpu ram memory.
In the other case if the lcd controller is integrated in the mcu you can do some nice "tricks" like using a colour look up table or palette so that your graphics takes less memory and because the framebuffer is in your internal memory it is even easier to manipulate.
Also consider that in case of lcd controller not integrated in the panel (so by using the one integrated in the mcu or another one on board as a separate chip) you can exchange panel quite easily so you are not tied to a single manufacturer as long on the lcd side you find the same interface like the 24 bit or the 18 bit.
Now, I'm considering the case of an lcd panel of  640x480 and 8 bit per colour which leads us to 640x480x8 = 2457600 bit / 8 = 307200 / 1024 = 300 KByte of ram needed for the framebuffer.
None of the parts I'm considering like lpc17xx or lpc 18xx have this amount of ram memory and even if they had, I'd still need ram for my software variables, then I need to use an external ram and probably also an external flash memory where I can also store some images and part of my program.
So at the end you would get something like this:

nxp with lcd controller--->18/24 bit rgb lcd panel
but through the external bus the mcu is also connected to:
nxp with lcd controller--> external bus to--->ram(variables and framebuffer)--->flash (code and images)

The integrated lcd controller has got a dma which will take care of transferring the data from external ram used for the frambuffer to the lcd controller which will then translate it and send to lcd but the problem is that the external bus and also the internal bus of the mcu(difficult to draw this here :-) ) is then shared by the lcd controller, which keeps accessing the memory to continuously refresh the screen, and the mcu which is fetching instructions or variables.
Because the internal bus gives priority to the mcu it means that probably you will see tearing effect on the lcd like reported by some people on the nxp question and answer (pasting the link here takes you to the general support page and not to the answer I found)  because the mcu gain priority when accessing bus and memory and lcd refresh is delayed.
In the answer I found on Nxp support, they say you can actually change priority so that lcd screen has an higher priority then the cpu, problem is that in doing so the cpu and then your software will be slowed down by the lcd controller continuously refreshing and accessing memories.

As said I'm new to arm architecture and at the moment I have no dev kit or something else to test so I'm just crunching datasheets...
What I'm looking for is: is this correct? Do you actually see the cpu slowed down so much in this case? Or is the speed difference actually small?

I'm thinking that this question is something so specific that if nobody answer I'll have to buy a dev kit and start testing performances...

[lpcware]

Content originally posted in LPCWare by R2D2 on Thu Jan 08 10:16:58 MST 2015

---

Quote: Paride
...measurement instrument with a tft lcd...

---

Not sure what this means in detail, but a simple 320x240 TFT with TouchPanel is working without problems with smaller MCUs like M3 (LPC13xx, LPC15xx, LPC176x)  :)