LCD resolution question

[electroRF]

the Graphic LCD I ordered has resolution of 160X128.

I'd like to calculate how much memory I'll need in order to store an image that is to be displayed.

I made the following calculation:

1. 160X128 is 20,480 pixels.

2. Each Pixel's color is set by 2-bytes (R,G,B in 5,6,5 configuration).

3. That means that in order to load an image on the LCD, I need my PIC to hold a memory of 20,480 X 2-Bytes = 40,960 Bytes, i.e. 40KB memory size.

Is that correct?

Thank you

 

[edeca]

It depends how you want to store the data. The easiest way to work with will be to hold the R,G,B values for each pixel as a byte each. This makes computation and array handling much easier. That is going to need 61440 bytes though, or 60KB.

Your calculations are correct if you store exactly 2 bytes for each pixel. That suits your 5/6/5 configuration nicely but makes the code a little bit tougher.

However if the screen has memory of its own then you don't need to keep a whole shadow copy in RAM on your device. You just read, modify, write the pixels that you'd like to adjust.

 

[electroRF]

Hi Edeca, Thanks!

I have some questions please regarding the storage method you suggested.

1. How does it make it easier to work with if you hold the R,G,B value for each pixel as a byte each?
How can you store 16 bits (RGB values are 5,6,5) in one byte?

2. How did you reach the result of 61440 bytes?

The LCD has an embedded 16-bit uC, but no memory was mentioned in the datasheet.

 

[edeca]

There are two basic ways you can interface to a graphic LCD, especially the larger multi colour ones. Some have a processor friendly interface such as I2C, SPI or parallel and you feed them simple commands. These need to have inbuilt memory so they can store a copy of what should be on the screen. On the LCD board will be a chip that is responsible for refreshing the display multiple times a second.

Alternatively some screens have a raw pixel interface which you must feed with a simple video signal at a fast rate. This makes it possible to do video but is much harder to work with and your processor needs enough RAM to keep a copy of the screen at all times. A lot of processor cycles will be taken up keeping the screen refreshed unless you have dedicated circuitry in the processor (such as the inbuilt display driver on the 24F series PICs, which is designed to work with these).

The first is common for small to medium screens, often in monochrome but sometimes with colour. The second is more common on medium to large pixel count displays such as STN/TFT screens. Your screen is definitely the first type and therefore it will definitely have memory.

This means that you do not need to keep an entire copy of the screen at once in your chip. Happy news! However you still need space to store any image data which you will send to the screen.

With regard to storing this data I suggested 3 bytes per pixel as this keeps the code simple. If you pack your 5,6,5 data into two bytes (not one, obviously this is not possible) then you end up with an arrangement like RRRRRGGG GGGBBBBB in two bytes. I have not checked your datasheet in detail but it usually makes sense to store it in the same way the GLCD expects to receive it. However what if you want to modify a pixel? You have to unpack the three values with some code or modify them in place.

This is less code efficient than simply storing NNNRRRRR NNGGGGGG NNNBBBBB in three bytes. You have the raw value in each byte and can easily operate on it using the mathematical opcodes your processor has. Many 8 bit uCs have addition and subtraction in a single cycle, some even have multiplication and division. This is more code efficient but 1/3rd less memory efficient across the whole screen.

Hope this helps.

 

[electroRF]

Hi Edeca,
Thanks a lot for your awesome help and explanation.

The GLcD expects to receive each pixel color as 2 bytes (RRRR-RGGG GGGB-BBBB).
You suggest to store it in my external PIC each pixel as three bytes, and every time before transmitting a pixel to the GLCD, use a function (that I'll simply write) that will convert the 3-byte pixel to 2-byte pixel?

How much memory would you advice me to have in my external PIC?
I'm gonna order 18F pic (with 3 breakpoints), and I'd love to get a recommendation.

Thank you

 

[ronsimpson]

What do you want to put on the LCD?
No PIC has that much RAM.
Pictures and text can be drawn on a LCD with out storing the entire picture.