How are pixels mapped into the LCD controller memory?

Are pixels directly mapped to controller memory and is the controller memory easily accessible.
I have been wondering how to put images to LCDs. But if all I need to do is to put pixel data to memory 1:1, it is not so hard.

The LCD must be initialised with correct settings first, I think.
I need to know how many bytes each pixel takes, and how colors are in the those bytes.
And I have to have suitable image data but there are converters for that.

There are many different LCDs and LCD modules out there. Each LCD module use a controller chips that controls the pixels on the physical display. How pixels are mapped depends on the controller chip used on the LCD module and how the controller chip has been wired up to the physical LCD panel.

For the most part the mapping is pretty straight forward and is documented in the LCD controller chip documentation.

As long as I can be sure that 100th pixel is controlled by 100th byte or some multiple in controller chip.

I have looked some controller datasheets but in my opinion, they are not very easy. There are a lot of control registers, for instance.

Different chips map the pixels differently in memory.

The monochrome displays typically use a single bit to turn on a pixel. But how it is mapped can vary.
Some map the pixels within the bytes horizontally across the display and some map them vertically.
But it isn't even that simple.
For example, when mapping horizontally it can be done in 8 bit bytes or 16/32 bit words a time. And then the pixels may be mapped MSB to LSB or LSB to MSB within the byte or word.
Don't forget that when doing more than 8 bit bytes, big/little endian byte issues can creep in since the LCD memory not be the same endian as the processor you are using to talk to it.

And then when mapping pixels vertically, some, like the popular ks0108, map map the pixels vertically within a byte LSB to MSB down on the display but then then each successive byte in memory moves horizontally left to right.

Color displays will have similar type mappings but will use more than a single bit for each pixel.
It could be a single byte or even multiple bytes per pixel.
And then the bits within the byte or word can represent actual colors or be indirect indexes into a color table stored somewhere else.

Another thing to keep in mind is that while the LCD module display will use some form of memory to map to the pixels, not all LCD modules give you direct access to it. For example some modules are intelligent and have a communications protocol that supports doing higher level graphic functions rather than just being a memory to pixel interface.
Some LCD modules don't allow reading the memory and only allow writing to it. With these types of displays you have some sort of local frame buffer which can get quite large if using a color display.

There are many different ways it is done so the only way to know is to read the datasheet/documentation for your particular LCD or LCD module.
If you want to play at this level, you will have to get very comfortable with the datasheet for the module and controller used on the module or find a library that takes care of all the low level interfacing and provides an API to access the pixels.

--- bill

Sure

After spending some value time with a LCD, I want to be sure it will be in production tomorrow also.

LMI:
Sure

After spending some value time with a LCD, I want to be sure it will be in production tomorrow also.

The Hitachi HD44780 controller used with the character mode LCDs has already been around for more than three decades if that's any solace.

Don

Yeah. Those are great devices, different colors and easy sw. But I want to offer something more, besides it is quite interesting too. There are no such standards for Graphic LCDs, or are there?

LMI:
There are no such standards for Graphic LCDs, or are there?

For graphics LCDs the KS0108 controller had been very common (around 150000 google hits). Closely followed by the ST7920 controller (126000 hits). I like the ST7565 controller more, but it is a 3.3V device and has only 40000 google hits.

For OLEDs, the SSD1306 (around 100000 hits) is probably the most common controller for monochrome graphics OLEDs.
True color OLED controller like the SSD1331 (11000 hits) or SSD1351 (15000) have lesser hits.

Not sure if this helps,
Oliver

olikraus:
Not sure if this helps,
Oliver

Thanks. I think it will.

I forgot to mention the TFT LCDs, with the ILI9341 (162000 hits).

There are Arduino libraries for all of these controllers. I guess you just need to enter the controller name into the library manager of the Arduino IDE and you will find a suitable lib.

Oliver