Issue with RGB Endian Setting in ST7789 Driver causing wrong order of colors (IDFGH-10145)

[giddeonzeix]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

Hello,

I've encountered an issue related to the ST7789 LCD driver.

According to the ST7789 datasheet (https://www.waveshare.com/w/upload/a/ae/ST7789_Datasheet.pdf), section 9.1.28 MADCTL (36h): Memory Data Access Control, bit D3 is used to declare the RGB/BGR order.

However, in the ESP-IDF LCD component (specifically in components/esp_lcd/include/esp_lcd_panel_vendor.h line 22), this bit is used to set the RGB data endian:
lcd_color_rgb_endian_t rgb_endian; /*!< Set RGB data endian: RGB or BGR */

This seems to be a misunderstanding. The actual endian setting for the ST7789 is specified in the datasheet, section 9.2.1 RAMCTRL (B0h): RAM Control. The second parameter's bit D3 (ENDIAN) defines the order of the colors. If this bit is not set, the color order will be red, blue, green instead of the expected red, green, blue.

I was able to fix this issue by adding an extra initialization step after calling esp_lcd_panel_reset(panel_handle); and esp_lcd_panel_init(panel_handle);

// Extra initialization
esp_lcd_panel_io_tx_param(io_handle, RAMCTRL, (uint8_t[]){0x00, 0xE8}, 2);

Could you please add an extra flag for the RGB endian setting in the esp_lcd_panel_vendor.h file to correctly configure the color order for the ST7789 LCD?
since many people run into this issue with the TTGO T-Display S3 .

Thank you for your attention to this matter

[suda-morris]

Hi @giddeonzeix I see. The ST7789 and many other LCDs like arranging the ram data in "big-endian" by default.

In our example, we enable this Kconfig option, so the LVGL library can change the RAM data endian on its side. In applications that are not using LVGL library, I'm not sure if there're also such a configuration. But if not, yeah, your solution of overriding the RAMCTRL is also a good idea!

Note, the RAMCTRL is a vendor-specific register (see it's on the command table 2). So we can't guarantee there will be such a feature on other LCDs.

[giddeonzeix]

I would like to clarify that my previous statement was not specifically related to LVGL. Instead, I developed an LVGL driver for the LILYGO T-Display S3 using IDF 5.01 and the ESP_LCD component. In this implementation, I utilized the I80 parallel bus interface and the ST7789 panel. Before incorporating LVGL, I conducted a preliminary test to ensure the driver's functionality before using lvgl ,by using the esp_lcd_panel_draw_bitmap function (refer to the C function below). This test aimed to verify color accuracy and other aspects.

During this testing phase, I discovered that the default configuration of the ESP_LCD using the ST7789 panel on the ESP32 platform has the incorrect endianness. The color order is incorrect, particularly with regards to the placement of the green color. Regardless of whether the color order is RGB or BGR, green should appear in the middle. While it is possible to address this issue by adding another layer to correct the color order, it would be more appropriate to modify the default configuration to ensure correct operation.

Based on my research across various versions of the ST7789 panel (VW, V, VI, S, etc.), all of them have the RAMCTRL register at 0xB0, which includes an ENDIAN bit (D3). Moreover, the ESP_LCD component already includes a vendor-specific ST7789 panel. I have not encountered any datasheets for the ST7789 that do not include the RAMCTRL register.

after all esp_lcd has a few vendor specific panels one is the ST7789 or other SSD1306 etc. sould it not go in there ?

I hope this revised explanation provides clearer information regarding your situation.

#define RGB565_Blue 0x001F
#define RGB565_Green 0x07E0
#define RGB565_Red 0xF800

void fill_color_test()
{
    uint16_t *picture = (uint16_t *)malloc(DISP_BUF_SIZE_BYTES);
    memset(picture, 0, DISP_BUF_SIZE_BYTES);

    for (int y = 0; y < 50; ++y)
    {
        int ofs1 = y * EXAMPLE_LCD_H_RES;
        int ofs2 = (y + 50) * EXAMPLE_LCD_H_RES;
        int ofs3 = (y + 100) * EXAMPLE_LCD_H_RES;
        for (int x = 0; x < EXAMPLE_LCD_H_RES; ++x)
        {
            picture[x + ofs1] = RGB565_Red;
            picture[x + ofs2] = RGB565_Green;
            picture[x + ofs3] = RGB565_Blue;
        }
    }
    esp_lcd_panel_draw_bitmap(panel_handle, 0, 0, EXAMPLE_LCD_H_RES, EXAMPLE_LCD_V_RES, (uint16_t *)picture);
    vTaskDelay(pdMS_TO_TICKS(1000));
}