How to blank waveshare EPD display using zephyr lvgl

[mhanuel26]

I have been trying to make blanking work on 7.5in EPD display from waveshare without success. I started using the sample at sample/subsys/display/lvgl/ , it writes to the display but it looks it is not refreshing the whole screen when blanking is on.
Maybe I don't understand the usage of blanking_on function.
I have also tried to call some lvgl function on the current screen like
lv_obj_clean(lv_scr_act());
with no different results.
I have tried playing with background but have not found a way to clear the make all pixels white in the display at start up of my application.

I know for sure there is an issue if I left my display on, waveshare recommend to shut down, I have one pin on the pi shield I am using to turn display off but driver doesn't have that pin defined, you can look here at the shield I am using. With this simple code below (end of main.c in sample/subsys/display/lvgl sample)

` lv_obj_t * main_page = lv_obj_create(lv_scr_act());
lv_scr_load(main_page);
lv_obj_set_size(main_page, LV_HOR_RES, LV_VER_RES);
lv_obj_clean(main_page);

hello_world_label = lv_label_create(main_page);
lv_obj_align(hello_world_label, LV_ALIGN_RIGHT_MID, 0, 0);
lv_label_set_text(hello_world_label, "hola mundo");

lv_task_handler();
display_blanking_on(display_dev);

// lv_task_handler();
// // lv_obj_invalidate(lv_scr_act());

while (1) {
	// 
	k_sleep(K_MSEC(10));
	// lv_task_handler();
}

}`

I am getting the behaviour seen in this video

I found that placing the PWR pin of the shield to low level after the initial refresh stop the display from increasing the darkness of the text which finally produces that blinking effect as well. But I don't think this is related to the ability to black the screen or maybe?

Does someone has any idea what can I try ?

Comments will be appreciated!
Thanks

[faxe1008]

If you want to have a full refresh you can set this Kconfig option
lvgl.c

[mhanuel26]

Hi @faxe1008 Fabian,

I was trying to set this define in my project but I could not find where or how.
Doing CONFIG_LV_Z_FULL_REFRESH=y in prj.conf does not work.

There is a Kconfig file in C:\ncs\2.4.2\modules\lib\gui\lvgl\kconfig but this define is not there. It looks this will change a property in the display driver structure configuration right? i.e. disp_drv.full_refresh = 1;

I also was looking at this for changing the bit in driver , but I am not sure if it is the right way as sample project don't do ay explicit init of the display driver.

It is possible to change it ina different way at program execution? Or do you know how to enable in the lvgl sample project?

Will appreciate your comments,
Manuel

[faxe1008]

You have to add this to the prj.conf of the project or add it as an overlay. In essence yes it will set this flag. I'd recommend reading up on the application development page in the docs, there the peoject structure and kconfig are explained.

Yes you can set this flag at runtime, by getting the display driver. Unless you want to make this dynamically adjustable there is really no reason not to use kconfig.

[mhanuel26]

Hi @faxe1008 Fabian,

Thank you for all suggestions , unfortunately after looking at lvgl sources for zephyr using the nordic sdk 2.4.2, the lvgl.c file does not have the same content as you share so I was not able to properly set the CONFIG_LV_Z_FULL_REFRESH flag. I noticed there is a 2.5.0 version available, after installing it and created a new lvgl sample project I was able to set the flag in prf.conf
So now I have prj.conf as

CONFIG_LV_Z_MEM_POOL_NUMBER_BLOCKS=8
CONFIG_LV_Z_SHELL=y
CONFIG_MAIN_STACK_SIZE=2048

CONFIG_DISPLAY=y
CONFIG_DISPLAY_LOG_LEVEL_ERR=y

CONFIG_LOG=y
CONFIG_SHELL=y

CONFIG_LVGL=y
CONFIG_LV_MEM_CUSTOM=y
CONFIG_LV_USE_LOG=y
CONFIG_LV_USE_LABEL=y
CONFIG_LV_USE_BTN=y
CONFIG_LV_USE_IMG=y
CONFIG_LV_USE_MONKEY=y
CONFIG_LV_FONT_MONTSERRAT_14=y

CONFIG_LV_Z_FULL_REFRESH=y

and I was able to build and flash into nrf52840dk_nrf52840.

Unfortunately, the display does not refresh the whole screen, at least with the original demo code, the lvgl snipped code in main is basically

hello_world_label = lv_label_create(lv_scr_act());

lv_label_set_text(hello_world_label, "Hello world!");
lv_obj_align(hello_world_label, LV_ALIGN_TOP_RIGHT, 0, 0);

count_label = lv_label_create(lv_scr_act());
lv_obj_align(count_label, LV_ALIGN_BOTTOM_MID, 0, 0);

lv_task_handler();
display_blanking_on(display_dev);

while (1) {
if ((count % 100) == 0U) {
	sprintf(count_str, "%d", count/100U);
	lv_label_set_text(count_label, count_str);
}
lv_task_handler();
++count;
k_sleep(K_MSEC(10));
}

For my test what I am doing is build and flash with the Hello world label at different locations by changing the positions of the label. so I build flash and see results. The old contents on the display are retained while new label is written.

I also noticed that the original demo when run onto the nordic dk is not refreshing the counter label, in fact it has the Text letter that does not change at all, something looks like it is not working properly at least for this nordic sdk?

Do you know what else can I try to debug this?

I will really appreciate your comments to help debug this further,

Thank you again,
Manuel

[mhanuel26]

Hi @faxe1008 ,

I found this on the serial trace when running my application

By looking at what is doing, it is reverting the full_refresh flag.

Maybe this is the cause of not getting a full refresh.
If this makes sense, do you know from my application how to specify the screen size?

Thanks,
Manuel

[faxe1008]

Yes you have to set CONFIG_LV_Z_VDB_SIZE to 100. Arguably this should be preselected when enabling the full refresh.

[mhanuel26]

Hi @faxe1008 ,

Thank for that, it fix the issue with size I was having, I am still trying to understand why the old contents on the e-paper are not been refreshed. I think the full refresh should be active now since I am seeing an increase in RAM size required after enabling it from 12% to 30%.

I have tried to do this

lv_obj_clean(lv_scr_act());
lv_obj_invalidate(lv_scr_act());
lv_task_handler();

But old contents are still on the screen. So far the snipped I have trying is

lv_obj_clean(lv_scr_act());
lv_obj_invalidate(lv_scr_act());
lv_task_handler();

hello_world_label = lv_label_create(lv_scr_act());
lv_obj_align(hello_world_label, LV_ALIGN_CENTER, 0, 0);
lv_label_set_text(hello_world_label, "HELLO WORLD");

lv_task_handler();
display_blanking_off(display_dev);

while (1) {
    lv_task_handler();
    k_sleep(K_MSEC(10));
}

Do you know how full refresh should work for an e-paper screen and the needed lvgl api sequence to send?

I certainly appreciate your comments,

Thanks again,
Manuel

[faxe1008]

Hi,

if LVGL is working correctly you do not need to perform the clean or invalidate yourself.

Do you know how full refresh should work for an e-paper screen and the needed lvgl api sequence to send?

LVGL simply manages a draw buffer for you where it "draws" buttons and text etc. The draw buffer is in the format that your display requires. When you cause an invalidation of an area, e.g. by updating a widget or interacting via touch, that draw buffer is modified and then flushed to the display. The last step is part of the display driver.
To troubleshoot I'd be increasing the log levels and check if there are any oddities. If that does not help try to first verify that your display works correctly by manually manipulating the draw buffer and flushing it. If that works you either have an issue with your LVGL event loop mechanism or the issue is inside LVGL. Both of these cases using a debugger or strategic print logging will get you further.

Regards,
Fabian

[mhanuel26]

Hi @faxe1008 Fabien,

I am getting better understanding of the issue which is probably configuration commands not targeted specifically for my driver display which is GD7965

After comparing wit hthe Waveshare sources how init differs I have found several differences which I am adjusting, some like the PWR setting are easy to change, for instance as per datasheet this is the command and data sequence options,

The tested and working arduino code used the following settings

Now, I have modified the original waveshare_epaper_gdew075t7.overlay to reflect this sequence such as seen here (pwr setting)

The original code was sending a different values and actually missing one at the end (number 0x11) as seen in the logs

But when further inspecting the differences, I found the "VCOM and data interval setting (CDI)" register

And here is where I found that I cannot easily extend the values using the overlay, as the cdi value in the overlay (see point 2 in the previous snip) is defined as an integer, for instance

But if you see the waveshare implementation they are sending two values, such as seen here

Unfortunately the function that sets this CDI looks like is expecting always an int and not an array of values like in the PWR config, but when looking at the logs coming out of the board I see the following

Number 07 CDI[3:0] is coming from the overlay and the value of 29 directly from the code, I presume the overlay is setting the set_cdi function to the uc8179_set_cdi using the compatible name as in here

And the function is actually setting the values in a fix manner I guess as shown here

I have manually changed the function to send 0x10 0x00 (as the arduino code does) instead of the 29 07 as lvgl does, such as

So now the output logs are

The display does not seems to refresh correctly the screen but I still need to check the rest of the differences, it seems the arduino code is sending more commands than lvgl for this display but anyway probably at this point one of my questions is that the overlay name actually match my display name but the differences make me think the overlay is for a different driver.
I will finish modifications and retest.

Can you give me your comments on what is the best way to handle this differences and if this is a new driver configuration, what is the best way to integrate changes back into the code perhaps.

Thanks,
Manuel

[mhanuel26]

Hi @faxe1008 Fabien,

After trying to make logs more verbose expecially the LVGL I am gettimng this error

The only change that is actually causing this is the following line (The commented line at the end)

If I left the line out or commented I get the following traces using my modified version of the configuration

The configuartion changes to match arduino code which works has the resuklt thaat can be seen on this short video.

Can you suggest something to help me debug this further?

[mhanuel26]

HI @faxe1008 Fabien,

I think the log issue is solved it was apperently the stack size of that process so I increase it from 2048 to 8192, i.e.

I am using zephyr 2.5.0 which last week was the latest from Nordic SDK.

Now with modification so farthe MCU is not giving good e-paper refresh, as shown in the video it looks it writes but then screen start to blink into dark colors and funny stuff.
I noticed something, the arduino is setting the LUT for this scree but the LVGL code not as I have not defined those in the devicetree overlay, other displays drivers on the LVGL like the SSD16xx has some LUT, so I was trying to follow the example to define the LUT for this display driver but I run into a situation I am unsure, here is the thing

Arduino LUT are defines as

So it looks arduino src defines
LUT_VCOM
LUT_WW
LUT_BW
LUT_WB
LUT_BB

when looking at the LVGL driver uc81xx.c

I am not sure what with be the equivalence for those. I was about to start adding them in my device tree overlay like this

the values in that image are taken from the ssd16xx overlay but which correspondance is is my doubt, for instance is lutc matching the LUT_VCOM in arduino src?

About the partial refresh, I think I was pasting a snip when I was having issues with logs and I was having commented the

I see there is only one refresh but as I said before it is still not working propoerly, maybe the LUT thing.

Can you please give me your useful comments to continue debuggng further this.

Many thanks,
Manuel

[mhanuel26]

@faxe1008 Fabien,

Any comments about the LUT question above?

I will apprecite any comments to help in debugging.
Thanks,

Manuel

[faxe1008]

From what I can see in the driver you are using you can should be able to set those values:
uc81xx.c

Other then that if you are sure that you have picked the right controller:
https://docs.zephyrproject.org/latest/boards/shields/waveshare_epaper/doc/index.html

All that you can really do is compare the SPI communication between Zephyr and a known working implementation.

[mhanuel26]

Hi @faxe1008 Fabien,

I have some progress, I was following the configuration of old code posted by waveshare, I found an updated repo here which the LVGL code for SDK 2.5.0 follows pretty close. I did a couple of modifications to match the PSR and CDI configuration, the original LVGL has PSR as 0x1f and CDI as 0x10 0x07 in the payload of those commands, the arduino has PSR 0xf and CDI 0x11 0x07.

With those modifications and the ones that you suggest for full refresh I see the LVGL clearing the screen at start up.
The demo application prints a hello world in the middle and a counter at the bottom, the snip of main loop code is this

my prj.conf is

CONFIG_LV_Z_MEM_POOL_NUMBER_BLOCKS=8
CONFIG_MAIN_STACK_SIZE=8192

CONFIG_DISPLAY=y

CONFIG_LVGL=y
CONFIG_LV_MEM_CUSTOM=y
CONFIG_LV_USE_LOG=y
CONFIG_LV_USE_LABEL=y
CONFIG_LV_USE_BTN=y
CONFIG_LV_USE_IMG=y
CONFIG_LV_USE_MONKEY=y
CONFIG_LV_FONT_MONTSERRAT_14=y

CONFIG_LOG=y
CONFIG_LOG_BACKEND_SHOW_COLOR=n
CONFIG_DISPLAY_LOG_LEVEL_DBG=y
CONFIG_LOG_MODE_DEFERRED=y
CONFIG_LOG_BUFFER_SIZE=12288
CONFIG_LOG_MODE_MINIMAL=n
CONFIG_SHELL=y
CONFIG_SHELL_LOG_BACKEND=n
CONFIG_LOG_BACKEND_UART=y

CONFIG_LV_Z_SHELL=y
CONFIG_LV_LOG_LEVEL_TRACE=y

CONFIG_LV_Z_FULL_REFRESH=y
CONFIG_LV_Z_VDB_SIZE=100

Now I would have thought this will refresh the screen every second incrementing the counter, but instead the display is cycling thru some color changes, i.e. backgorund changes from white to black and to red, text is adjusted to lighter colors and counter is incrementing (after the initial "Text" string in the counter label) and the cycle takes several seconds and start over with white background.

Can you take a look a this one minute video for better understanding?

Here is the log for it.

[00:00:00.410,400] <dbg> uc81xx: uc81xx_set_profile: Initialize UC81XX controller with profile 0
[00:00:00.410,461] <dbg> uc81xx: uc81xx_set_profile: PWR
                                 07 07 3f 3f                                      |..??             
[00:00:00.410,614] <dbg> uc81xx: uc81xx_set_profile: BTST
                                 17 17 17 17                                      |....             
[00:00:00.410,766] <dbg> uc81xx: uc81xx_set_profile: PSR: 0xf
[00:00:00.410,858] <dbg> uc81xx: uc81xx_set_profile: TRES
                                 03 20 01 e0                                      |. ..             
[00:00:00.411,010] <dbg> uc81xx: uc8179_set_cdi: CDI
                                 11 07                                            |..               
[00:00:00.411,102] <dbg> uc81xx: uc81xx_set_profile: Apply optional configurations!
[00:00:00.411,224] <dbg> uc81xx: uc81xx_set_profile: Got to end of function!
*** Booting nRF Connect SDK v2.5.0 ***
[00:00:01.156,646] <dbg> uc81xx: uc81xx_write: x 0, y 0, height 480, width 800, pitch 800
[00:00:01.156,707] <dbg> uc81xx: uc81xx_write: ptl
                                 00 00 03 1f 00 00 01 df  01                      |........ .       
[00:00:01.253,051] <dbg> uc81xx: uc81xx_update_display: Trigger update sequence
[00:00:31.645,355] <dbg> uc81xx: uc81xx_write: x 0, y 0, height 480, width 800, pitch 800
[00:00:31.645,416] <dbg> uc81xx: uc81xx_write: ptl
                                 00 00 03 1f 00 00 01 df  01                      |........ .       
[00:00:31.741,546] <dbg> uc81xx: uc8179_set_cdi: CDI
                                 91 07                                            |..               
[00:00:31.741,638] <dbg> uc81xx: uc81xx_update_display: Trigger update sequence
[00:01:01.673,034] <dbg> uc81xx: uc8179_set_cdi: CDI
                                 11 07                                            |..               
[00:01:03.189,086] <dbg> uc81xx: uc81xx_write: x 0, y 0, height 480, width 800, pitch 800
[00:01:03.189,147] <dbg> uc81xx: uc81xx_write: ptl
                                 00 00 03 1f 00 00 01 df  01                      |........ .       
[00:01:03.285,278] <dbg> uc81xx: uc8179_set_cdi: CDI
                                 91 07                                            |..               
[00:01:03.285,400] <dbg> uc81xx: uc81xx_update_display: Trigger update sequence

Can you let me know your thoughts on what might be happening here, is LVGL or my display causing this?
Am I understanding correctly how this demo code should work?

Please let me know, your comments have been of great help.

Thanks,
Manuel

[faxe1008]

The sample increments the counter ~1 once per second. I think your display might not be fast enough for that. Try incrementing the modulus value and see if that helps.