I'm trying to understand how to interface TFT driver ILI9486. I'm doing this because I want to control TFT display with PIC microcontroller and not AVR (for which libraries already exist). I own the following display. It looks like that only 8-bit parallel bus can be used for communication between uC and driver + some control lines for reading, writing, etc.

enter image description here

So far I managed to understand what needs to be done in order to read from or write to the driver and whether the currently latched data on the parallel bus is either command or parameter to command. However, I do not understand the following graph under "Display Data Format" section of driver datasheet.

enter image description here

I understand everything (and it is well explained in early sections of the datasheet) from RESX to RDX control line. However, I have no idea what could those colored bits of data on data lines of parallel bus (D0 to D7) mean.

Only part that seems logical is that each dashed line window represent 2x 8-bits or 16-bits total; and this is then somewhat "mapped" as 18-bit data. Does first (yellow colored) sequence of bits represent some command and then following (RGB colored) bits have to do something with addressing the pixel location/formation? What is "Frame Memory"? Why are bits colored as RGB? Does this sequence of byte transmission represent command, following by command parameter data? Assuming from n-bit/pixel means that such data must be transmitted in explained manner to achieve illuminating single pixel on the display? Is the color of shown pixel then determined by state of individual bits in each window of 16-bits? For example, if all 16-bits are HIGH state, then pixel is white, and if they are LOW, pixel is of black color?

Then there is also graph for 18-bit/pixel order, where D6 and D7 are blank in dashed line window and each window includes 3x 6-bit data transfer (where first row being only Red, second Green, third Blue). One can have a look at the following datasheet.

P.S.: I would really appreciate any advice or explanation on this topic, since I could find very little information about this stuff on web.

  • \$\begingroup\$ the colored diagam shows 16 bits of data that affects a single pixel ... it shows which bits affect which color \$\endgroup\$
    – jsotola
    Commented Apr 18, 2021 at 23:11
  • \$\begingroup\$ see section 7.2.1 ... 16 bit mode uses 2 byte transfers ... 18 bit mode uses 3 byte transfers \$\endgroup\$
    – jsotola
    Commented Apr 18, 2021 at 23:16
  • \$\begingroup\$ section 7.7 shows the different interfaces that you could use ... you could refer to the AVR library and copy its functions \$\endgroup\$
    – jsotola
    Commented Apr 18, 2021 at 23:28
  • \$\begingroup\$ Usually the library is available in C source form, it should be easy to adapt it for you MCU \$\endgroup\$ Commented Apr 19, 2021 at 6:28
  • \$\begingroup\$ @LorenzoMarcantonio Hmm not so eazy, tho... I tried that first and realized I'm no match for that library (beginner in C). However I might give it a chance or two to solve which registers needs to be replaced.. \$\endgroup\$
    – lucenzo97
    Commented Apr 19, 2021 at 11:09

1 Answer 1


The display has memory for the RGB values for each pixel and that is called the frame buffer, and you basically display an image on the screen by first telling the chip which address (pixel) you begin writing from and then you send the required amount of data (e.g. whole screen) in any of the available pixel formats you want to write it.

The display is set to 8-bit bus so that is what you must work with when communicating with the display. Internally the pixel data in memory has 18 bits per pixel, 6 bits for each component of red, green and blue values. This means that you can set the RGB values between 0 and 63 for each component, where 0 is turned off and 63 is fully on. You are correct that setting all bits off for all RGB bits is black, and all bits on for all RGB bits is white.

The display controller provides you with several modes in which you can write the 18-bit pixel data, but as it is already wired for 8-bit operarion only two modes make sense.

One of the commands allows to write the three color components as 3 bytes of 24-bit data, with each red, green and blue in their own bytes, and only 18 bits of the 24 bits sent are used by the display. As the display can use only 6 bits from the 8 bits, and it uses the most significant bits, the format is compatible with 24 bits per pixel data, the least significant bits are unused.

The command sequence you show in your post is for writing pixel data in the mode 16-bit 565 mode, where a data of single pixel can be sent with only 2 bytes, but it can only send 5 bits of the red and blue but internally the 16-bit 565 format is converted to the 18-bit format, so you have less color bits to send which is faster and saves memory space on your MCU.

What the diagram does not show is how to set the address (i.e. starting from which pixel) where to write on screen.

  • \$\begingroup\$ Any idea if 16 or 18-bit format is already set in such "LCD Shield" (since 8-bit data bus is also already chosen) or can be modified through either control lines (probably not) or data lines? \$\endgroup\$
    – lucenzo97
    Commented Apr 19, 2021 at 14:33
  • 1
    \$\begingroup\$ You don't have the data pins available on the shield for anything else than for the 8-bit bus, and therefore the shield will select 8 bit interface on the display controller (or the display comes with a flex cable that does it and exposes a 8-bit bus for the shield). You can send 18-bit colors by sending three bytes with 18 bits in total, or you can send 16 bit colors by sending two bytes. \$\endgroup\$
    – Justme
    Commented Apr 19, 2021 at 15:28
  • \$\begingroup\$ Is it 18-bit OR 16-bit mode or EITHER 16-bit or 18-bit mode? Shouldn't this format also be pre-set by the shield? I doubt the driver would separate either of modes, so one must also be defined by shield, then? \$\endgroup\$
    – lucenzo97
    Commented Apr 19, 2021 at 16:05
  • \$\begingroup\$ Actually, I just found out that this setting can be modified by special command transferred to driver via data bus (if one looks into it, one can found this information at page 200 of driver's datasheet). \$\endgroup\$
    – lucenzo97
    Commented Apr 19, 2021 at 16:11
  • \$\begingroup\$ @Keno I am sorry but I don't understand what is unclear to you. One way or another, the shield exposes only a 8-bit bus you must use to send data, so you cannot send other pixel formats than the ones that can be sent over the 8-bit bus. It is up to you which kind of pixel formats you want to send over the 8-bit bus, either two bytes per pixel in the 16-bit 565 format or three bytes per pixel in the 24-bit format which will have full control to send the 6-bit RGB values. \$\endgroup\$
    – Justme
    Commented Apr 19, 2021 at 16:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.