STM32F769 display driver

Let’s continue the discussion from github here. Maybe other’s will find it and jump into.
I noticed that the guide for the display driver porting, for the gpu fill operation each time fills just one line and repeats the same for every line. Is there a particular reason to do so since the chrom art can fill an area at once?

It’s just an example of how it could be implemented, as far as I know. Nothing prevents you from filling the whole area in one go.

I implemented the GPU features with STM32F429 first and shaped the function to work well with them. To be honest I don’t remember why I’ve chosen 1 line instead of the area. :slightly_frowning_face:
If it works with and area too then it’d be much better!

Then I’ll try to do the same on the F429. Lets see what happens :grinning:

I’m curiously waiting for the result! :slight_smile:

Sorry, I’ve been away for several days and I’m trying to restore my mind to the previous state :woozy_face:
I’ve replaced the code in the gpu_mem_fill with this piece of code bellow from the F769 project.
Changed the color mode to match the one for the F429 project and the result is :grimacing:
uint32_t xsize = fill_area->x2 - fill_area->x1 + 1;
uint32_t ysize = fill_area->y2 - fill_area->y1 + 1;
uint32_t destination = (uint32_t) dest_buf + (fill_area->x1 + fill_area->y1 * TFT_HOR_RES) * 4;
Dma2dHandle.Instance = DMA2D;
Dma2dHandle.Init.Mode = DMA2D_R2M;
Dma2dHandle.Init.ColorMode = DMA2D_OUTPUT_RGB565;
Dma2dHandle.Init.OutputOffset = dest_width - xsize;
Dma2dHandle.LayerCfg[1].InputAlpha = DMA2D_NO_MODIF_ALPHA;
Dma2dHandle.LayerCfg[1].InputColorMode = DMA2D_OUTPUT_RGB565;
Dma2dHandle.XferCpltCallback = NULL;

	/* DMA2D Initialization */
	if (HAL_DMA2D_Init(&Dma2dHandle) == HAL_OK) {
		if (HAL_DMA2D_ConfigLayer(&Dma2dHandle, 1) == HAL_OK) {
			if (HAL_DMA2D_BlendingStart(&Dma2dHandle, lv_color_to32(color), destination, destination, xsize, ysize) == HAL_OK) {
				/* Polling For DMA transfer */
				HAL_DMA2D_PollForTransfer(&Dma2dHandle, 10);
			}
		}
	}

I gave up with this idea since I’ve tried line to line rectangle fill and that worked without crashing the application and did not appear to have any weird lines on the buttons. Even though during benchmarking nothing weird appears, when running the demo theme I get this :grimacing:

What happens if you create a button, make it draggable (lv_obj_set_drag) and move it on the screen?
You can create it after the benchmark_create() to have something in the background.

@papadkostas

I’ve just made it work with dev-7.0. See https://github.com/littlevgl/lv_port_stm32f769_disco_sw4stm32/blob/dev-7.0/hal_stm_lvgl/tft/tft.c

A working CubeIDE project is in the dev-7.0 branch of this repo.

Man, hat’s off to you!! I see no issues now with the rendering.And the new demo is amazing!!
Something I’ve noticed, when the screen is rendering the CPU load goes up to 80% and even sometimes 97%. The chip is kinda hot, but not that much to cook an egg :grin: Isn’t supposed that DMA2D offloads it?

PS. It didnt compile because ‘DMA2D_TransferComplete’ was undeclared.

Thanks! :slight_smile:

The high CPU usage is normal because of the large resolution.
The GPU could offload much more if we used more images, but the current elements are software-rendered (e.g. rounded buttons) which are not so effective to render with GPU.

DMA2D_TransferComplete should be declared here: https://github.com/littlevgl/lv_port_stm32f769_disco_sw4stm32/blob/dev-7.0/hal_stm_lvgl/tft/tft.c#L423

Understood! :slight_smile:
The line you’re pointing at is the definition, not the decleration. This is what I mean but anyways.

Ah, got it. I’ve just fixed it.