[ek_ra8d1] Thin horizontal lines on the screen

[kisvegabor]

It was already fixed but it's shown again on my end. Earlier it was related to caching I believe.

[jeremy-baker]

The blue lines on the screen are caused by 2 different issues.

1. For the lines in body of the Unique visitors graph (on the Analytics screen), the triangles overlap the rectangular fills by 1 pixel, if I move the triangles start up by 1 pixel jeremy-baker/lvgl@7803da7 then the blue horizontal line is removed.

2. I found that there is an issue with fill with rounded corners (this uses the Dave2 API renderwedge to create the rounded corners). renderwedge changes the cliprect internally, so you have to check the renderwedge is actually inside the cliprect before drawing it jeremy-baker/lvgl@9f680f2

[jeremy-baker]

I also added checks for renderwedge in border drawing :-
jeremy-baker/lvgl@1a468e6

and arc drawing (this fixed an issue I was seeing with Partial and Direct rendering) :-
jeremy-baker/lvgl@b1b4537

[kisvegabor]

I've created a Pull request from the Dave2D-devel in your repo. It was a little bit cumbersome because that repository is not a fork of the original lvgl repository.

Would you mind forking the original LVGL repo so that I can merge the change easier in future?

We have this short summary about Pull request, in case you are interested.

[kisvegabor]

I still see the stripes on the screen. See on the video:

VID_20231218_212300208.mp4

Could you try with the latest code from this repo if it's the same on your end?
A lot of fixes were merged so it might happen that something was lost.

[jeremy-baker]

I don't see this issue, using the latest version of the code.

[kisvegabor]

With the latest code the screen is fully broken on my end. :( Does it work for you?

[kisvegabor]

My bad, I messed up something with git.

[kisvegabor]

I'm testing with lv_demo_benchmark on which the think lines are clearly visible. 🙁

Other then that it works well in FULL mode, but in PARTIAL mode several screen are messed up. Can you reproduce it?

[jeremy-baker]

If I disable the framebuffer from being cached, then the PARTIAL mode improves (open configuration.xml, and in the properties of g_display0 Graphics LCD change the section of the framebuffer for Graphics Layer 1 from .sdram to .nocache_sdram) :-

I have updated LVGL code to commit f4e9eabb705649cdb8288d47c521409ae175977e ( lvgl/lvgl@f4e9eab ) and DIRECT rendering is broken, has DIRECT rendering changed?

[jeremy-baker]

lv_draw_buf_copy() removed the use of the GPU to do the buffer copy at some point, so it now done by the CPU, so the cache will come into play.

[kisvegabor]

The double buffered direct mode should be fixed by this: lvgl/lvgl#5248

How does disabling the cache affects the performance?

[jeremy-baker]

Direct rendering is fixed by #5248.
Running lv_demo_benchmark in Direct Rendering mode
FB cached :-
All Scenes Average CPU 81% FPS 24 Time 32ms (24+8)

FB not cached :-
All Scenes Average CPU 86% FPS 22 Time 36ms (27+9)

If the Dave2D is doing the drawing to the FB, the Cache will not have an effect on speed.
If the CPU is drawing to the FB, or doing a buffer copy from FB to FB, then having the FB cached will improve the speed.

[kisvegabor]

Sorry for the late reply. I've disabled the cache, but I still the see stripes.

[jeremy-baker]

I see evidence of tearing in Partial rendering mode using the Benchmark demo (and sometimes evidence of tearing in the Widgets demo), but I don't see the issue you show in the video :-

I still see the stripes on the screen. See on the video:
VID_20231218_212300208.mp4

The other issue I see in the Widgets demo, when using either Partial or Direct rendering, on the Profile screen, if I press "Logout" it is not re-drawn correctly :-

This occurs when the framebuffer is cached when using either Partial or Direct rendering. It doesn't occur in FULL rendering mode (even if the framebuffer is cached). I think it is caused by the fact the box shadow is drawn by the CPU, but the rest is drawn by the Dave2D, and the CPU drawing doesn't finish before the Dave2D drawing starts.

[kisvegabor]

I think it is caused by the fact the box shadow is drawn by the CPU, but the rest is drawn by the Dave2D, and the CPU drawing doesn't finish before the Dave2D drawing starts.

LVGL should give the fill task to Dave2D only when the prerequisite box shadow is finished. Besides the box shadow has a hole in the middle so the gray stripes here are not drawn by the SW render.

Shall we invalidate the cache before any SW drawing too?

[jeremy-baker]

I have done a quick test, invalidating and cleaning the DCache for the area to be drawn by the CPU, before the call to lv_draw_sw_box_shadow() makes no difference.

Invalidating and cleaning the DCache for the area to be drawn by the CPU, AFTER the call to lv_draw_sw_box_shadow() does improve thing a bit (most of the time), but it still doesn't solve the issue 100% : -

[kisvegabor]

Is there configuration now which has a good performance and has no artifacts? If so, let's set it as default to be sure people have good get started experience.

[jeremy-baker]

I have rebased the LVGL code to this commit lvgl/lvgl@86138aa and FULL Rendering with the framebuffer cached works on my board (with the Widgets demo). However, DIRECT rendering seems to be broken with the LVGL code at this point

[kisvegabor]

I made some experiments and fixes. Also simplified the the display driver to support only double buffer direct mode as it should be the fastest. While doing that I found a few issues:

• In double buffered direct mode we need to wait for VSYNC only after the last area
• The cache needs to be invalidated only on the last area

I wanted to create a PR, but by accident I merged it to master. Sorry for that... 🙁

If you would like to have discussion about it first I can revert it.

I've found a few issues in LVGL too, which should be fixed in lvgl/lvgl#5360

With this the performance is great, the only thing is missing to show CPU used based on FreeRTOS idle task. I've found that this way the real CPU usage is 33% of the currently displayed. See here lvgl/lvgl#5243

I still see the thin lines. Can you try on your end with the latest master and this LVGL PR lvgl/lvgl#5360?

[jeremy-baker]

I have tried with the latest master and this LVGL PR lvgl/lvgl#5360, and still see no evidence of any thin horizontal lines.
What is the configuration of your EK-RA8D1 board? I have DIP SW1-7 ON, the rest of DIP SW1 are OFF. The camera module is not fitted to the board.

[jeremy-baker]

Also, have you fitted the plastic stand-offs, so that the LCD PCB is held firmly to the main PCB?

[kisvegabor]

DIP SW1 2,3,4 were ON for me. Turning ON only 7 solved the issue 🎉 Thank you! So I had this issue due becasue he camera module was enabled but not used?

I think it should be documented in the README.

Please approve lvgl/lvgl#5360 and I'll merge it to master.

Seemingly the last thing:

With this the performance is great, the only thing is missing to show CPU used based on FreeRTOS idle task. I've found that this way the real CPU usage is 33% of the currently displayed. See here lvgl/lvgl#5243

Do you have any good idea for it?

[jeremy-baker]

This was in the Readme.md file on my original github repo :-
https://github.com/jeremy-baker/EK_RA8D1_LVGL9_Porting/blob/master/README.md
nitial work I did to get LVGL master branch (version 9 development) running on the EK-RA8D1 development board

Board Configuration.

MIPI LCD PCB attached to the main PCB.

USB cable connected from J10 to the development PC

DIP switch settings :-

7 - ON (SDRAM)

Others OFF

Debug printf output is via the Jlink VCOM port, 921600 8,n,1

I have no idea about the CPU usage when using FreeRTOS, I have not really thought about it.

[jeremy-baker]

I have added the EK-RA8D1 board configuration to the readme.md.

The issue was caused by SW1-2 being ON and SW1-4 being ON, the ETM Trace signals are on the same pins as the SDRAM, as are the Ethernet signals for ETH-A configuration (ETH_B configuration can be used with SDRAM).The camera (SW1-3) can be used at the same time as the SDRAM. From the EK_RA8D1 User's Manual ( https://www.renesas.com/us/en/document/mat/ek-ra8d1-v1-users-manual ) the permitted combination of SW1 DIP switch settings :-

[RenesasMan]

Gabor,

One method I have seen for measuring CPU in FreeRTOS is to increment a counter in the IDLE task, and periodically poll that counter.

The CPU load is calculated as something like:
cpu_load = 100* idle_counter_val/IDLE_COUNTER_MAX;

where IDLE_COUNTER_MAX is what idle_counter_val would be if no tasks were running, and the counter would increment constantly.

I haven't implemented this myself, but this is what I have been told by my colleagues and it makes sense.

Alex

[kisvegabor]

@jeremy-baker Great, I've updated the RAEDME.

@RenesasMan Thank you for joining.
I've tried idle counter way, but due to the many task yielding during rendering I got 20k idle counts in 300 ms.
I think we can follow the "idle" time way as described here and I would be happy to add it, however I have 2 questions:

1. I've found that the changes in FreeRTOS.h is overwritten on build. What is the ideal place to add some custom configs?
2. How can I set up (or use an already running) higher resolution timer? 1us would be perfect.

[jeremy-baker]

To be able to add your own custom configs to FreeRTOS, you need to add a user header file to the configuration, and add the custom configs in that header file.

1. In e2studio, open configuration.xml, select one of the Threads, and in the properties, under "General" add a header file name to "Custom FreeRTOSConfig.h", e.g. User_FreeRTOSConfig.h :-

2. Create the header file somewhere in the project, and add the FreeRTOS custom configurations in that header file. This custom header file will be included in the generated FreeRTOSConfig.h file (ra_cfg/aws/FreeRTOSConfig.h) (but will not be overwritten when the project contents is generated).

[kisvegabor]

Thank you, I'll try it out. Could you recommend a something about the timer too? Which timer shall we pick? Is there a 64 bit timer? All we need is starting the timer with 1us period and reading its current value

[jeremy-baker]

I have added a user FreeRTOS configuration header file to the project, there are no 64 bit timers, as far as I remember, however it may be possible to cascade 2 32 bit timers. I will have a look.

[kisvegabor]

Os based idle report is added here. I found that the the rendering time is little bit higher in some cases with Dave2D (compared to software render) but the CPU usage is only 25% instead of 50%.

It seems for letter drawing software render is much faster so we can consider not drawing it with Dave2D. It would help to draw tasks in parallel too.