Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

problem with LCD Refreshing rate

Hello,

I recently designed a model in Quartus which connects to a color LCD device and shows what ever is on the SRAM.

I am using the NIOS processor to fill the RAM with the relevent Data (PICS,ANIMATIONS and so).

One problem is that the reading cycle time of a byte is 55nsec.

the LCD can work up to 33MHZ(840X480) so I'm not able to fully use the LCD's Resolution(I'm using 8 MHZ which is 480X272 Res).

another Problem is the Data size (24 bits - 8 red + 8 green + 8 blue).

I cant write 2 cycles on the sram for every Pixel because it doesent match the 8 MHZ timing.

so what i did is to normalize the data bits to 15 bits per each pixel (5r+5g+5b) and decrase the lcd's speed to 8 mhz

for every screen I want to load I need to fill up the ram with 480*272 Addreses(130.5Kbytes).

The problem is that the NIOS clk seem to be 50MHZ but the actual one is much slower,so it takes me about 2 secs to fill up the sram.

that gives me a slow refresh rate on the LCD.

are there any sugesstions to make the NIOS RUN faster?

Is my techniqe OK?

are there any other good methods to work with LCD so I would able to exploit the SPEED and pixel bits?

thanks for all the helpers,

Asaf

24 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Then, what you have so far referred to as a ram (sram) interface is actually the raw control pins of the LTM display?

    Nevertheless, you said you have address/data/save lines: this seems indicate some sort of memory, buffer or control block between the Nios system and the fpga pins connected to the display. So, why you need to keep up streaming data?

    My guess is that you have a very primitive LCD interface with a minimal memory buffer and this forces you to constantly write picture data even if it doesn't change. Is this right?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    Then, what you have so far referred to as a ram (sram) interface is actually the raw control pins of the LTM display?

    Nevertheless, you said you have address/data/save lines: this seems indicate some sort of memory, buffer or control block between the Nios system and the fpga pins connected to the display. So, why you need to keep up streaming data?

    My guess is that you have a very primitive LCD interface with a minimal memory buffer and this forces you to constantly write picture data even if it doesn't change. Is this right?

    --- Quote End ---

    Yes...actually the lcd doesnt have any memory at all...so i have to use the sram like a memory for the lcd
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    You are again calling 'sram' something which I guess is not a sram (e.g. a static random access memory), since you say it's not a memory but you use it like a memory.

    What exactly is this?

    Case 1:

    You only have the LCD dsplay and Terasic provided you no interface logic at all.

    So, ideally you must design a component which can store the whole screen information and automoatically drives the LCD pins at the rated frequency in order to keep it refreshed. On the Nios side you update the controller memory only when you need to change the image on the display.

    Case 2 (more probable)

    Terasic sent you a sample project together with the LCD. The project includes a display controller and sample code to drive it. It might have not a great performance (like most demo projects), but it will surely work and it is a good starting point.