Incorrect calculation of color data size using bits_per_pixel for ST7789 LCD driver (IDFGH-8241)

[MulattoKid]

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.

IDF version.

v4.4.2 1b16ef6

Operating System used.

Linux

How did you build your project?

VS Code IDE

If you are using Windows, please specify command line type.

No response

Development Kit.

Custom Board

Power Supply used.

External 5V

What is the expected behavior?

When calling

esp-idf/components/esp_lcd/src/esp_lcd_panel_st7789.c

Line 164 in 1b16ef6

static esp_err_t panel_st7789_draw_bitmap(esp_lcd_panel_t *panel, int x_start, int y_start, int x_end, int y_end, const void *color_data)

to write pixel data to the ST7789 display controller configured in 18bpp mode, 3 bytes should be written per pixel, both in SPI and 8-bit parallel interface mode.

What is the actual behavior?

I believe the way that the size of the color data to be transferred to the display is calculated in panel_st7789_draw_bitmap

esp-idf/components/esp_lcd/src/esp_lcd_panel_st7789.c

Line 189 in 1b16ef6

size_t len = (x_end - x_start) * (y_end - y_start) * st7789->bits_per_pixel / 8;

is incorrect.

The ST7789 controller (and other similar ones) support both R5G6B5 (16bpp) and R6G6B6 (18bpp). In the case of 16bpp the calculation works fine as 16 / 8 = 2. However, for 18bpp, we still get 18 / 8 = 2, which is wrong; it should be 3. The specification states that each color component should occupy the 6 high bits of a byte, which means 3 full bytes are required.

Steps to reproduce.

1. Configure the ST7789 driver to 18bpp mode
2. Call panel_st7789_draw_bitmap
3. Check the value of len in panel_st7789_draw_bitmap and see that it's not equal to pixel_count * 3bpp

Debug Logs.

No response

More Information.

No response

[suda-morris]

@MulattoKid Nice catch! We will fix it ASAP.