Ssd1306 for lv_port_esp32 available?

I started to use LittlevGL on the ESP32 platform (using ESP-IDF with lv_port_esp32 as a submodule).

Is there a driver for lv_port_esp32 for the SSD1306 using I2C / TWI available?

Before starting to port a driver by myself I want to check whether there’s already a driver I can use?

I’ve a running code for the SSD1306 available which I can use. In one of the threads I found a discussion on the new API (branch new_api), but I’m not sure whether to use the new_api or not? Waht’s the difference?


As far as I know, the important features from new_api exist in 6.0+ and the branch was abandoned.

Not yet, but I do have a display based on that controller laying around, so if you want we can work on adding it to the lv_port_esp32 repo, you “only” need to implement the init function and the flush function.


Yes, that’s the case.

I implemented a first version for the SSD1306 driver, it’s included in this fork and branch here

In the updated Kconfig choose:

  • Predefined display: none
  • Predefined pins: none
  • Display controller: SSD1306
  • Protocoll: I2C
  • Landscape, width 128, height 64
  • GPIO for SDA and SCL

For DISP_BUF_SIZE use with the above values for height and width.



static lv_color_t buf1[DISP_BUF_SIZE];
lv_disp_buf_init(&disp_buf, buf1, NULL, DISP_BUF_SIZE);

Reducing DISP_BUF_SIZE (e.g. /8) gives a performance decrease. I use ssd1306_set_px_cb to set the pixel. The buffer buf1 can then be send efficiently to the SSD1306.

Todo’s are

  1. Cleanup Kconfig using predefined display settings and/or the WEMOS LOLIN Board
  2. Check that SPI is not initialized
  3. Code cleanup (included files, Kconfig defines, …)

It would be good if you could test with your board, too.


1 Like

Hi Andreas,

Great, I think I have one of those displays laying around so I will test it this weekend.

Yes we can add the WEMOS LOLIN Board as predefined board, are you working with it? If so, can you upload a picture to update the README.

As far as I know this is the first monochrome display on the lv_port_esp32 repo :smiley:


Hi Carlos,

yes, I’m working with that board. Please find a (draft) screenshot in I’ll replace this in the next days with a more representative screenshot. See the link to my fork above, use branch ssd1306_add…

We should work on Kconfig. The predefined configuration is not working at least for me. If for example setting “M5Stack” everything is fine, but not because all relevant configuration is created. The #if CONFIG_LVGL_TFT_DISPLAY_CONTROLLER == TFT_CONTROLLER_ILI9341 is true because TFT_CONTROLLER_ILI9341 is 0 and so it’s always true. For other predefined configuration always ILI9341 is used.
When selecting not a predefined board but choose the display controller manually, it’s fine.

Do you want me to open a seperate ticket?

I can work on Kconfig - I thing the best way is to introduce some “helper” symbols. Using “select” is not working for me yet (see Kconfig stackoverflow. If we find a better solution later we can clean up in the future.


Hi @an-erd,

I’ve been busy with work tasks but today I will be able to test your repo :smiley:

Are you refering to the predefined configuration on your repo for the SSD1306 display?

Yes, let’s open a new ticket for it, thanks.

From what I understand on your question the following symbols are not being generated?


I didn’t checked that before, will check it today.


@an-erd I’ve opened a new issue to list all the menuconfig improvements , can we place there all the improvement ideas? what do you think?

Hi @an-erd,

Just to let you know that yesterday and today I was able to test your work, had to clone the master branch and saw some improvements on the menuconfig, now the SPI related signals aren’t visible then choosing the SDA and SCL pin numbers :slight_smile: .

Also noticed that the project isn’t using the demo project example, instead a Hello world! label and a line on the top left corner of the display, that’s a good choice because of the nature of the display I think.

I added a function on the ssd1306.c file to zero the oled memory after the initialization but I think that’s not necessary.

Also noticed you added a new board, the M5Stick :smiley:

Thanks a lot for the work you’ve put on this, hope to see it available on the main repo soon :slight_smile:

Hello Carlos,
I did some further work on the lv_port_esp32.

  • I needed to change back the sdkconfig and pin configuration. It’s not working properly for my toolchain in esp-idf 3.3.1, because when not adding a default value the assigned values are not correct, and when default values are used they’re included in every case. I need some mor time to work on this topic.

  • I split the main.c code to use the previous code for non-monochrome displays and to use a simple “Hello World!” for the small monochrome displays.

  • Yes, I added the 64x128 OLED display (probably it’s working for the 128x128 display, too, using the SH1107 display controller. They are used in the M5Stick (the little brother of M5Stack, but EOL) devices.

  • Updated rotation (landscape/portrait) for ssd1306 and sh1107 OLED displays, and made changes in Kconfig.

  • Update to Readme and some cleanup (indentation, …)

Also, I already used the code from branch “display_orientation” already, it’s working for my M5Stack.
And included the code to support mpi3501, commits up to 4/1/20 #8daaede.

I compared to the current master, and I’d provide a PR today.


1 Like

Hi @an-erd,

Thanks for the PR, I have merged it, I will test it later today (I played a bit with your repo fork over the weekend), I agree the Kconfig files need more work. I have left some comments on the PR so we can plan further work on the monochrome support, if you don’t have time I can implement it, you’ve already done a lot of work.


Hi Carlos,
where can I find the comments you left on the PR? I have some time to continue working on that. Also, I could start working on “LVGL configuration” in


Ok, found your comments. Good idea, I will implement it that way.

lvgl configuration from the menuconfig was done here:

It was just some testing, I have implemented enabling built-in fonts and default font so far.

Thanks, I’m now a bit loaded with my dayjob but i can test things at night.


I tested the lvgl_kconfig branch, and added another option (LV_MEM) to it.
Is there any reason why we don’t put it in master yet? With this Kconfig configuration the lv_port_esp32 tree stays clean and doesn’t show any changes (“dirty”). (Besides the small thing of sdkconfig, which I would put in .gitignore, too)


I didn’t added it into master because I was trying to get all or most of the configuration options on it before making it available, we can add it to master, please send your PR.

Yes, I think we need to stop tracking the sdkconfig, I have already done that in another project and I didn’t had any issue.