In esp_lcd, an LCD panel is represented by esp_lcd_panel_handle_t, which plays the role of an abstract frame buffer, regardless of the frame memory is allocated inside ESP chip or in external LCD controller. Based on the location of the frame buffer and the hardware connection interface, the LCD panel drivers are mainly grouped into the following categories:
Controller based LCD driver involves multiple steps to get a panel handle, like bus allocation, IO device registration and controller driver install. The frame buffer is located in the controller's internal GRAM (Graphical RAM). ESP-IDF provides only a limited number of LCD controller drivers out of the box (e.g., ST7789, SSD1306), More Controller Based LCD Drivers are maintained in the Espressif Component Registry.
I am new to driving displays within esp-idf and I have a few examples running, but I wanted fool around with the idf to get a better understanding of what was going on. I noticed that there is a function (https://docs.espressif.com/projects/esp ... l_handle_t) for initialising the ssd1306 using the controller based driver. The examples I have seen so far have used the i2c interface driver instead of this. Is there any benefit of one over the other.
If I use the controller based driver, the framebuffer will be present on the GDRAM of the ssd1306, which the esp is connected to via a i2c. Won't this be slower than having the framebuffer in memory?
Maybe I am misunderstanding what is meant by a framebuffer. According to this https://www.stealthylabs.com/blog/2020/ ... uffer.html resource online, programs write to the framebuffer first and when its time to show something on the screen, it writes it to the GDRAM of the display. So in this case would I be writing to the GDRAM of the esp everytime I write to the framebuffer?